Reply
Contributor
dgatwood
Posts: 5
Registered: ‎09-17-2011
0 Kudos

[BUG] current iOS Nook app (3.3.0.24) CSS handling is very broken

 

Fairly simple content that looks fine in Adobe Digital Editions, web browsers, etc. looks awful in the Nook iOS app.  Example at:

 

http://www.gatwood.net/nook-ios-bugsample.epub

 

 

The bugs I'm seeing are in two areas:

 

 

Drop caps:

 

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.

 

 

Inverted text:

 

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.

 

Contributor
dgatwood
Posts: 5
Registered: ‎09-17-2011
0 Kudos

And another one.

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.

 

Contributor
dgatwood
Posts: 5
Registered: ‎09-17-2011
0 Kudos

Re: [BUG] current iOS Nook app (3.3.0.24) CSS handling is very broken

Bug #1 is caused by Nook completely ignoring the top margin for an outer inline-block element when drawing the contents of block elements inside it. Removing one level of structure results in positioning that is still wrong, but is at least consistent with other readers that are based on outdated versions of Adobe Digital Editions. Bug #2 can be worked around by adding a bit to the height property's value so that there is more tolerance built in.
Contributor
dgatwood
Posts: 5
Registered: ‎09-17-2011
0 Kudos

Re: [BUG] current iOS Nook app (3.3.0.24) CSS handling is very broken

[ Edited ]

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.

 

Top Kudoed Authors
User Kudos Count
4
2
Users Online
Currently online: 38 members 647 guests
Please welcome our newest community members: