As Valoric suggested, I've compiled a list of the bugs that are known to exist in Adobe Digital Editions. Since it's unlikely that these bugs will be fixed (especially in the firmware of reading devices), the only option is to be aware of them and any possible workarounds.
Bugs in all versions
1
Centering horizontal rules
The attribute 'text-align' is not implemented for the hr tag, thus 'text-align: center' has no effect on a horizontal rule.
Workaround: set the left and/or right margin to half the width of space left over from the horizontal rule, e.g.:
Code:
hr {
width: 50%;
margin-left: 25%
}
2
Arbitrary break in long paragraphs
Very long paragraphs may display with arbitrary page breaks, leaving large gaps at the bottom of the page. The actual length required to trigger this behaviour changes depending on surrounding text, but it seems the paragraph needs to be longer than 1024 characters.
Workaround: none known
3
Text shifted to right after a br tag in centered text
If the text in centered and one of the following characters is the first to be displayed after a line-break that has been forced by a br tag, then the text on that line will be shifted to the right by 0.8em: '(' '{' '[' and em-dash
Workaround: wrap the text on the line after the break in a span which has the attribute 'margin-left: -0.8em;'
Bugs in specific versions
1
Multi-level ToC entries lose the first level
[Desktop ADE 1.72] If the table of contents contains three or more levels, then the first level of entries will not be displayed. This only applies if there is only one ToC entry at the first level, e.g. if the ToC has the following layout then the first-level entry will not appear:
Code:
First level
Second level
Third level
Third level
Second level
Third level
Workaround: ensure that your ToC has two or more first-level entries.
Bugs in the epub spec
These are often reported as bugs in ADE, but are in fact the result of it adhering strictly to the current epub or css specs.
1
Margins lost with a page break
If a block element is styled with the page-break-before/after: always attribute, then the top margin for the first element on the new page will be set to 0 no matter what is specified in the css. This is correct according to
Section 13.3.3 of CSS 2.1:
Quote:
|
In the vertical margin between block boxes. ... When a forced page break occurs here, the used value of the relevant 'margin-bottom' property is set to '0'; the relevant 'margin-top' used value may either be set to '0' or retained.
|
Workaround: use the padding-top attribute instead to force a top margin on the first element of the next page.
note: This only applies to page breaks that are forced through the use of the css 'page-break-*' attribute. Page breaks caused by a new xhtml flow will respect the block margins properly.
2
Margin: auto fails to work
While margin: auto is supported in the epub spec, it also specifically allows it to be forced to 0 in
Section 3.3:
Quote:
|
Reading Systems may set the value of any margin property whose specified value is auto to 0.
|
Workaround: avoid the use of margin:auto. EricDP has posted an example of how to simulate its function on centered text using display:inline-table
here.
3
Floated elements don't display in full
Any element which has a float or other positioning attribute applied to it exists outside the normal document flow. Since css2 doesn't have a proper page model, it fails to specify how user agents should handle floated elements that are larger than the size of the page.
Unfortunately, the interpretation used by ADE is not particularly friendly. Floated elements will only display on the page on which they are first encountered. Any content which overflows the lower page boundary is lost. Furthermore, under some circumstances the first line of any text block that follows the float (through the application of a 'clear' attribute) may be lost as well.
Workaround: avoid large floated elements, particularly large blocks of text, though this also applies to images. In particular, avoid floating elements around empty space, as this may lead to some loss of the following text.
Error handling issues
1
ADE doesn't show any css styling
This is caused by an error in the css file, most commonly a misspelling or missing semi-colon. The css code must be completely free of errors or ADE will disregard everything and revert to the default styles.
There is a convenient tool to check your css at
w3. If you have embedded fonts, then the code for the font-embedding will always produce errors as the validator can't access the relevant urls, but these reports can be disregarded.
These are the bugs I could find that have been reported in this forum. Please post any additions if I've missed something out.