|
|
|
|
|
|
by Javalicious
876 days ago
|
|
|
Ages ago (2010-2011 I think?), I worked on a tool that exported and packaged text into .epub format. At the time one of the biggest headaches was the lack of good font rendering in ePub readers. Apple's Books app did an okay job, but some of the others just ignored the font settings, _even when an embedded font was packaged in the file_. All the more frustrating when you consider that the text was not English, and the embedded fonts were necessary for properly rendering the code points and not displaying question marks or boxes. No idea if the available readers have improved, but I'm all for this proposal of a self-contained reader. |
|
|
To me, that's a feature for a document reader, not a bug (although it should of course be user-configurable). Part of the appeal of Amazon's Kindle platform, as much as I dislike the proprietary format and extremely poor document management system, is that books just look very consistent.
My ePub reader follows the publisher-defined CSS more closely (by default), and I've seen some truly awful fonts and margin defaults on its e-ink display.
Ideally, markup and design should be decoupled enough for both to be achievable: A publisher-defined look by default, but correct rendering when the user selects the option to disregard the publisher's CSS.
> All the more frustrating when you consider that the text was not English, and the embedded fonts were necessary for properly rendering the code points and not displaying question marks or boxes.
Ok, that's just an annoying bug then. "Override publisher font" should ideally be smart enough to figure out that it doesn't actually have a suitable replacement for some glyphs. It does get tricky for mixed cases though, e.g. while it would be ok to mix fonts for single words in different scripts, this can get very ugly when it's individual characters (e.g. accented latin characters).