Thread: ePUB Optimizer
View Single Post
Old 12-01-2014, 11:21 AM   #15
DiapDealer
Grand Sorcerer
DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.
 
DiapDealer's Avatar
 
Posts: 28,698
Karma: 205039118
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
Quote:
Originally Posted by Toxaris View Post
The point is, it is not a technical definition. Let me try to explain in more detail what my problem is. The purpose to remove as many glyphs as possible to get the smallest font files. Lets give an example. Lets say I implement Charis Sil as base font. That would mean that I would need 4 fonts to implement this correctly: regular, bold, italic and bolditalic. I cannot just do with one, because otherwise there would be no italic and such. All those 4 fonts have the same font-family of course.
Now, if I use certain glyphs in italic but not in bold, they could be removed from bold.
The way to discriminate between these fonts, are the attributes font-weight and font-style. I have to tell in the stylesheet which is which. If I don't add those, the reading application should fall back to the default value which is normal for both. If I would not use it, the wrong font would be used.
The same applies for all the other default values for all classes/tags. Headers are bold by default for example.

If I would ignore the font-weight and font-style, I would not know which glyphs could be deleted from the fonts in the same family. I could combine of course all used characters for that font-family, but then the font is not optimized fully. There is of course a difference between a font and a font-family.

I am actually quite surprised that ADE shows the font when the usage is actually not correct. Does it also render on ADE 1.7?

Perhaps I will add a feature that only discriminates on font-family used instead of actually used fonts as it is now.
As I said, I understand your reasoning perfectly: I just don't agree with it. It's a perfectly reasonable approach to take with a font that is intended to be used as a complete replacement of the body text (multiple @font-face declarations, multiple font-files to represent the entire font "family"), but I imagine that that same approach is going to remove a lot of ornamental fonts that are only used for chapter headers, drop/raised caps and the like. Situations where it would be perfectly sensible to base the subsetting on overall character/glyph usage (a per-family basis). Because weight/style just aren't usually all that relevant in a one-font-file, one @font-face, ornamental-only embedded font. *shrug*

And yes, ADE 1.7 renders the embedded font in my sample epub. I've yet to find a device/app that doesn't (not to say there aren't any).

Discrimination based on font-family would certainly be a useful feature for me. Otherwise, I have to remember that even though my epub passes validation with flying colors, there may be situations where my ornamental fonts disappear when using this plugin.

But enough!! Glad to see you contributing to the plugin cause. The more the merrier.

Last edited by DiapDealer; 12-01-2014 at 02:46 PM.
DiapDealer is online now   Reply With Quote