12-19-2012 01:04 PM
Fairly simple content that looks fine in Adobe Digital Editions, web browsers, etc. looks awful in the Nook iOS app. Example at:
The bugs I'm seeing are in two areas:
1. Floated element vertical positioning is completely wrong. When rendered correctly, the drop cap is aligned with the first two lines of content. Instead, Nook is showing it about 1.5 line-heights too low.
2. Drop cap element height is being either ignored or computed incorrectly. The specified element height should cause the second line to be indented. It isn't.
These problems persist even with "Publisher Defaults" enabled.
3. Nook is even overriding "!important" styles. This is *always* wrong. If a publisher explicitly marks a style as !important, it's usually a good indication that overriding that particular style declaration will likely break the content. Badly.
4. Nook is overriding styles that are not body styles. As a general rule, if it is defined more specifically than an element style (e.g. with a CSS class), the reader should not be overriding it unless there's a really good reason. The default mode absolutely should not override such styles as it currently does.
5. Nook's daylight style overrides the text color of all elements (which it should *not* do) and forces it to black, but leaves the background color alone. The *black* background color.
The combination of 3, 4, and 5 results in black-on-black text for the chapter number unless I enable the "Publisher Defaults" option to force Nook to behave. Oops. Not cool. And since this is the default mode, having missing chapter numbers is particularly bad.
6. Nook is failing to render small-caps as small-caps (not that I would expect that to work, given its ADE heritage).
There's really no good way for me to make my content look good on Nook until at least a few of these bugs are fixed.
12-30-2012 02:28 PM
And just to add a really obnoxious UI bug to my earlier list, if you have Personal Hotspot enabled, the top controls are almost completely hidden behind the resulting double-height menu bar, making the app borderline unusable.
01-03-2013 04:57 PM
01-26-2013 09:05 PM - edited 01-26-2013 09:13 PM
And another CSS handling bug that I can't work around. Nook on iOS allows the user to override the line-height attribute of CSS. In principle, this should be fine, if they had done it correctly. Unfortunately, they did not. Where it breaks badly is when you have a drop cap:
<p><span style="display: block; font-size: 1.5em !important; line-height: 1.48 !important; height: .95em !important;">C</span>an you see the problem?</p>
When the reader is set to the smallest line spacing, this displays correctly. At the middle setting, the drop cap is roughly baseline-aligned. At the widest setting, the drop cap is above the body text entirely.
If Nook were making the change correctly, those unitless line height values should have been treated as a multiplier of the new base line-height value, and everything should have "just worked".
Unfortunately, Nook appears to be computing those values only once, based on the smallest spacing, rather than recomputing them when you change the spacing. So as the user increases the line spacing, the line height of the drop cap stays the same, and thus the drop cap appears to move upwards relative to the body text, whose line height is increasing. Oops.