Quote:
Originally Posted by tomsem
I think there's a reluctance to expose users to 'complexity' in terms of font selection and other design choices (justification, hyphenation etc.), for which most people have no expertise or interest, but it may be such features will come along later.
|
This has nothing to do with the user. The fonts would have to be embedded by the person who makes the ePub.
I'm fairly sure that it already respects the CSS inside the ePub regarding justification.
Hyphenation support would be nice, but no ePub renderer supports that currently (short of converting to PDF with Prince XML), so it's hard to fault them too much on that.
But, really, what kind of patronizing attitude is it to think that these choices are "too complex" for their user base?
Quote:
|
These are all first generation applications.
|
That's a little misleading. ePubs are zipped .xhtml; so ePub software uses the mostly the same algorithms as web browsers do. They're no doubt re-using Safari code to display the actual contents of the book. Safari supports embedded fonts of various sorts, and mobile Safari supports embedded .svg fonts. It must have been a deliberate choice to
remove these features from iBooks.
Certainly I have no problem with giving users the option to override the embedded fonts or main text font, so long as it defaults to the embedded fonts, and characters not included in the font used for the override revert to the embedded font if need be. Sounds like a good idea, actually