View Single Post
Old 01-16-2012, 07:40 PM   #6
Jim Lester
Evangelist
Jim Lester is less competitive than you.Jim Lester is less competitive than you.Jim Lester is less competitive than you.Jim Lester is less competitive than you.Jim Lester is less competitive than you.Jim Lester is less competitive than you.Jim Lester is less competitive than you.Jim Lester is less competitive than you.Jim Lester is less competitive than you.Jim Lester is less competitive than you.Jim Lester is less competitive than you.
 
Jim Lester's Avatar
 
Posts: 416
Karma: 14682
Join Date: May 2008
Location: SF Bay Area
Device: Nook HD, Nook for Windows 8
Quote:
Originally Posted by danrodney View Post
This does not apply to all Nooks. For instance it does NOT affect the 1st generation Nook, which still exhibits the older behavior and displays the embedded font without the user doing anything. So maybe it's just new Nook devices (including the Nook Color).
Quote:
Originally Posted by danrodney
Now I think it's gone too far. Is there no solution to bland looking books now?
The CSS override is not new. However, if you had your CSS at a level of specificity higher than the CSS we used to override, then it would win, which was how you were getting it to work. Unfortunately there was enough content (and tools such as InDesign) that was abusing this (basic body text being styled with a p.class rule, and the class being applied to almost all of the p tags in the document instead of just styling p or even better body and creating classes for the exceptions, for instance), and breaking major features (such as font and color selection that I mentioned before) for the reader.

Starting the 1.4.1 release (and this approach will start making it out to all of the clients) the CSS selectors at any level of specificity are being overridden to use the users choice instead of the author's choice. Or to put it another way the user complaint of "I can't see the content" trumps "This looks bland"
Until the 1.4.1 update the first couldn't be fixed, while as you already noted the user can potentially fix the last using the the Publisher Defaults (admittedly if they know that it is there - and the styling on the content is interesting enough for them to want to).

Quote:
Originally Posted by seneu
If they're going limit font choices, shouldn't the fonts at least have a big utf charactor set?
We are definitely looking into expanding the glyph set on the fonts as we go international. However the current font set should handle most Western European languages, and as you noted they do not have the glyphs for Cyrillic, Hebrew, Arabic or any of the Asian languages. The size of the font files is a definite problem for some of the clients (iOS and Google Marketplace Android application), and so here I can definitely see the case for using the language tag of the ePub or potentially the element to do something interesting. The counter argument for that is that the setting for using Publisher Defaults is sticky on the device, which takes care of most of the problems for users.
Jim Lester is offline   Reply With Quote