View Full Version : Known bugs in ADE


charleski
08-15-2010, 08:23 AM
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.:
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:
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 (http://www.w3.org/TR/CSS21/page.html#allowed-page-breaks) of CSS 2.1:
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 (http://www.idpf.org/doc_library/epub/OPS_2.0.1_draft.htm#Section3.3):
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 (http://www.mobileread.com/forums/showpost.php?p=1013062&postcount=18).

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 (http://jigsaw.w3.org/css-validator/). 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.

HarryT
08-15-2010, 08:48 AM
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 the horizontal rule, e.g.:
hr {
width: 50%;
margin-left: 25%
}



I think this is slightly wrong. You need to set the margin to half the width of space left over by the horizontal rule. Eg, if you want a rule that's 70% of the page width, that leaves 30% remaining, so you'd set the left margin to half of that space, or 15%:

hr {
width: 70%;
margin-left: 15%
}

Jellby
08-15-2010, 11:28 AM
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 (http://www.w3.org/TR/CSS21/page.html#allowed-page-breaks) of CSS 2.1:

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.

You can also use a dummy element for a pagebreak, like this:

div.pagebreak {
page-break-before: always;
height: 0;
padding: 0;
}

<p>... text before the pagebreak</p>

<div class="pagebreak">&nbsp;</div>

<h3>After the pagebreak</p>

I'm not sure now whether ADE would accept the short and empty form: <div class="pagebreak" />, if it does, that's cleaner. The drawback is you cannot include this forced pagebreak in the CSS for h3.

GeoffC
09-11-2010, 07:01 AM
Hey guys, can we sticky this and then develop it as a useful resource .... ?

hpstricker
11-25-2010, 03:17 PM
You may call it a "missing feature", I'd like to call it a bug: the missing Back-button in ADE (but also, as I have seen it in the iPad) make internal links partly useless.

hpstricker
11-25-2010, 03:17 PM
Put an image inside an <a href> tag, and the image won't be sensitive: the link doesn't work.

Adjust
11-25-2010, 04:10 PM
Images not hyperlinkable

If you put the image in a p class tag then you can hyperlink them.

<p class="image"><a href="Contents.xhtml"><img src="images/CH04.jpg" alt="4" width="100%" /></a></p>

hapax legomenon
12-02-2010, 01:29 PM
A stupid question: does this affect only Adobe DE desktop software or does this also affect ebook reading devices as well?

If it affects devices, which devices? I would guess that Sony renders epub through Adobe DE firmware. Are there other devices which do the same thing?

hapax legomenon
12-11-2010, 08:50 PM
Here is a list of devices which use the Adobe parser http://blogs.adobe.com/digitalpublishing/supported-devices

mlewis78
12-12-2010, 06:34 PM
What about other ADE bugs, which make ADE unusable on my laptop now? I posted this in another thread just now, but ever since I added a library adobe epub file that was corrupt, I have a message in my ADE display that says "verifying file". It's in a box and won't go away, so ADE is frozen and unusable. I've uninstalled ADE and downloaded again, but the same thing keeps showing up. I've tried uninstalling several times with no good results.

charleski
12-22-2010, 05:42 AM
ever since I added a library adobe epub file that was corrupt, I have a message in my ADE display that says "verifying file". It's in a box and won't go away, so ADE is frozen and unusable
I'm afraid this is a problem related to your particular system. This list is only aimed at rendering bugs and other issues with ADE that will affect everyone. From looking at your thread it seems your problem lies with Kaspersky and a corrupt downloaded file.

Bonex
01-03-2011, 05:21 PM
I used a different workaround for bug 3 (Text shifted to right after a br tag in centered text).
If you add a &nbsp; at the beginning and ending of the line, the text stays centered. In this way you don't risk to have the text moved left using a different viewer.
Example:

<p style="text-align: center;">This is a normal line<br />
(this one will be moved right in ADE)<br />
&nbsp;(this one should be centered)&nbsp;</p>

soparch
04-15-2011, 08:47 AM
If you put the image in a p class tag then you can hyperlink them.

<p class="image"><a href="Contents.xhtml"><img src="images/CH04.jpg" alt="4" width="100%" /></a></p>
I have a book in which all the chapter headings are images. I have used a p class but they still don't work in ADE.
<p class="center1" id="chap1"><a href="../Text/TOC.xhtml#ch1"><img alt="" src="../Images/foreword.jpg" /></a></p>

Am I missing something?
Soparch

Adjust
04-16-2011, 01:33 AM
Take a look here...I've supplied an example epub

http://www.mobileread.com/forums/showthread.php?p=1236105#post1236105

quisvir
08-16-2011, 02:12 PM
Just to add a small note: ADE all versions bug #3 also applies to text aligned to the right.

And thanks for this sticky! I just spent an hour trying to figure out wat was happening with a line that ended off-screen (right aligned text, right margin at 0). Now I can rest easy, knowing it's just Adobe's fault ;)

Peter Ahlstrom
11-01-2011, 01:38 PM
The (at least) desktop version of ADE will not display PNGs correctly that have a bit depth less than 8. They instead look very strange, like a linescreen has been applied to them.

pholy
11-14-2011, 04:49 PM
After changing the border styles in your test-0, I am convinced you have found a bug in the ADE engine. Note that in the attached picture the solid lines look slightly dotted - this is due to dithering to try to make the line look blue. When I changed the colour to #000000 (test-3) it looks exactly right - the lines, not where they are.

In the pictures you can see that the first data cell border (dashed) extends beyond the table border, and the second cell borders (dotted) start within the table and extend beyond the table and beyond the first cell border.

To me, that's a bug, not a feature.

It gets really weird if you remove the "width=100%" from the image spec, by the way --- another bug, I think. I think the size of the image is controlling the size of the its cell, leaving little left for the other cell.

Basically, there is an interaction in the handling of tables and images, which is handled poorly.

Pappersvingar
01-02-2012, 07:54 PM
I am so glad I found this sticky. I have been tearing my hair out trying to find out why epubs that look perfect in Calibre and Sigil show up without any formatting at all on my PRS-T1. Thanks to the validator I found a stray } in my stylesheet.

Question: does anyone know of any issues with using font-size for the headings in the CSS? I've had an issue with the headings not showing up at all on my Reader that was resolved by removing the font-sizes I'd defined. The headings worked just fine on my computer.

Adjust
01-02-2012, 08:14 PM
Question: does anyone know of any issues with using font-size for the headings in the CSS? I've had an issue with the headings not showing up at all on my Reader that was resolved by removing the font-sizes I'd defined. The headings worked just fine on my computer.

You can try using a percentage as your font measurement i.e font size=50%

JSWolf
01-02-2012, 09:45 PM
I am so glad I found this sticky. I have been tearing my hair out trying to find out why epubs that look perfect in Calibre and Sigil show up without any formatting at all on my PRS-T1. Thanks to the validator I found a stray } in my stylesheet.

That's not a bug in ADE. That just means you have to have your stylesheet error free.

Question: does anyone know of any issues with using font-size for the headings in the CSS? I've had an issue with the headings not showing up at all on my Reader that was resolved by removing the font-sizes I'd defined. The headings worked just fine on my computer.[/QUOTE]

Can you post your code? From the description, I don't see any issue.

Pappersvingar
01-04-2012, 02:38 PM
You can try using a percentage as your font measurement i.e font size=50%

I'll try that the next time I code.

That's not a bug in ADE. That just means you have to have your stylesheet error free.


I am aware of that now, and although that is not a bug in ADE, it was thanks to reading the first post in this sticky that I found out that one error in the CSS will make ADE ignore the whole stylesheet.

Can you post your code? From the description, I don't see any issue.

This is the first part of the stylesheet before I removed all font-sizes:

body {margin-left:2%;
margin-right:2%;
margin-top:2%;
margin-bottom:2%;}

p {text-indent: .3in;
margin-top:0;
margin-bottom:0;
font-size:1em;
text-align: justify;
font-family:"Times New Roman", Times, serif;}

h1 {text-align:center;
font-size:2.5em;
font-family:"Times New Roman", Times, serif;}

h2 {text-align:center;
font-size:1.75em;
font-family:"Times New Roman", Times, serif;}

This did not make ADE ignore the CSS, everything looked the way it was supposed to, except for the headings. The headings simply disappeared when the epub was viewed on my Reader.

When I removed the font-size definitions, everything worked like it should.

DaleDe
01-08-2012, 07:00 PM
I suspect that ADE cannot interpret what you want. What is 2.5 times bigger than itself? 2.5em makes no sense since you are asking it to make itself 2.5 bigger but then that would be an em. I suspect font-size units need to be something other than font-size.

Dale

JSWolf
01-08-2012, 08:30 PM
This is the first part of the stylesheet before I removed all font-sizes:

The code looks OK. Can you post an ePub with this code in it and I'll take a look.

Toxaris
01-09-2012, 02:11 AM
I suspect that ADE cannot interpret what you want. What is 2.5 times bigger than itself? 2.5em makes no sense since you are asking it to make itself 2.5 bigger but then that would be an em. I suspect font-size units need to be something other than font-size.

This is actually fine. I use it for quite some time. 1em will be interpreted as 100%, so 2.5em is equal to 250%.

theducks
02-09-2012, 05:18 PM
I was having fun styling chapter headings.
The results looked great in Sigil (validated in FC also) and Calibre.
When I tried on my PEz (ADE) all stop. Tried on my PC ADE, All stop

Note: if you view this file in ADE be prepared to Kill the process :rolleyes:

nrapallo
02-09-2012, 05:38 PM
Tried on my PC ADE, All stop

Note: if you view this file in ADE be prepared to Kill the process :rolleyes:

I got to view it on ADE v1.7.2.1131 on a WinXP pc, but not correctly; the first letter styles were ignored. ADE did indicate in the item info that minor difficulties prevented the proper display of the .epub.

It did (beautifully ) render in Sigil, ePubFixer (preview option), EPUBReader for firefox, calibre's viewer, (and probably on the kitchen sink as well!!! :p ). But yes, not on ADE.... (but no crash for me)

theducks
02-09-2012, 10:30 PM
I got to view it on ADE v1.7.2.1131 on a WinXP pc, but not correctly; the first letter styles were ignored. ADE did indicate in the item info that minor difficulties prevented the proper display of the .epub.

It did (beautifully ) render in Sigil, ePubFixer (preview option), EPUBReader for firefox, calibre's viewer, (and probably on the kitchen sink as well!!! :p ). But yes, not on ADE.... (but no crash for me)

This time it did not lock up. and yes, the styling was ignored.
(same version as you)

I was having fun :D and it turned out to be simple to make it similar to those old woodcut initial letters in my old DT books.

Jellby
02-11-2012, 05:59 AM
You have "style001.css" in the XHTML, but the file is "Style001.css", note the capital S.

nrapallo
02-11-2012, 11:38 AM
:rofl: Jellby, that fixed it! Now it DOES crash in ADE!!!!!!!!!!!!! :snicker:

:smack: It doesn't even display in ADE now.... :grin2: :dunno:

theducks
02-11-2012, 02:44 PM
You have "style001.css" in the XHTML, but the file is "Style001.css", note the capital S.

Good catch
I made up a sample (from my original work) and muffed it :o

This time I did get ADE to crash, not just lock-up :D

Jellby
02-12-2012, 04:19 AM
I don't know what's the reason for the crash, but "foreground-color" is not a supported CSS property (in the spec), and "boldest" is not an allowed value.

theducks
02-12-2012, 10:06 AM
I don't know what's the reason for the crash, but "foreground-color" is not a supported CSS property (in the spec), and "boldest" is not an allowed value.


foreground-color, boldest: Wonder where I got that idea from :smack:
(I must get rid of of my really old HTML notes)

THNX

theducks
02-12-2012, 10:09 AM
foreground-color, boldest: Wonder where I got that idea from :smack:
(I must get rid of of my really old HTML notes)

THNX

Add:
And it now works when I fixed it :2thumbsup

Jellby
02-12-2012, 10:34 AM
Nevertheless, ADE should not crash. Never. If it crashes, it's a bug.

And the CSS spec says unknown properties or values should just be ignored. So using "foreground-color" or "boldest" should not harm in a well-behaved renderer, they'd just do nothing.

nrapallo
02-12-2012, 11:10 PM
Add:
And it now works when I fixed it :2thumbsup

Attached it the FIXED .epub version, that doesn't crash ADE, for those so interested!

By the way, it was the keyword "boldest" that caused that crash. Using "bold" allowed ADE to function properly!!! :whistle:

theducks
02-15-2012, 07:25 PM
Attached it the FIXED .epub version, that doesn't crash ADE, for those so interested!

By the way, it was the keyword "boldest" that caused that crash. Using "bold" allowed ADE to function properly!!! :whistle:

I can confirm, once I cleaned up the stylesheet (errors), it work pretty good on my PEz. ( I went with numeric font weights)

sab1234
02-22-2012, 12:50 PM
Hello,
another bug that I have just recognized with 1.7.2 is related to font embedding.
Aparently it seemed to work for some fonts of my sample epub file but not all.
Later on I realised the issue seems related to the file size of the fonts.
One of my fonts was 112kB whereas the others just around 60 kB.
Once I made it smaller, it embedded fine.
And good news the 1.8 Preview version doesnt display this problem.

JSWolf
02-22-2012, 01:00 PM
:rofl: Jellby, that fixed it! Now it DOES crash in ADE!!!!!!!!!!!!! :snicker:

:smack: It doesn't even display in ADE now.... :grin2: :dunno:

It does work in ADE 1.8 Preview 3 that was released on February 16, 2012. ADE 1.7.2 does indeed crash.

nrapallo
02-22-2012, 03:19 PM
Nevertheless, ADE should not crash. Never. If it crashes, it's a bug.

And the CSS spec says unknown properties or values should just be ignored. So using "foreground-color" or "boldest" should not harm in a well-behaved renderer, they'd just do nothing.

It does work in ADE 1.8 Preview 3 that was released on February 16, 2012. ADE 1.7.2 does indeed crash.

Wow, did that February 12, 2012 post by Jellby prompt the February 16, 2012 ADE 1.8 release.... :chinscratch: :thumbsup:

carl_torstensson
06-05-2012, 12:02 PM
Media queries don't work. ADE don't just ignore the media query, it ignores the entire css if you have media queries in it. Sucks.

Toxaris
06-05-2012, 02:39 PM
Media queries are not supported in ePUB2, they are in ePub3. ADE does not work with ePUB3 yet.

carl_torstensson
06-07-2012, 06:22 AM
But it would be nice if ADE didn't ignore the entire css just cuz you add a couple of lines in the css for media queries for mobile phones.

Jim Lester
06-07-2012, 10:45 AM
But it would be nice if ADE didn't ignore the entire css just cuz you add a couple of lines in the css for media queries for mobile phones.

If the CSS isn't valid, ADE won't use it. You can consider this a known issue (it's hard to argue that it's a 'bug').

Jellby
06-07-2012, 01:28 PM
But ADE is a bit particular about what is a "valid" CSS. The CSS spec says that if a renderer doesn't know about some property, it should just ignore it (the property), ADE somehow decides that an unknown property means the CSS is invalid and it ignores it (the whole CSS file).

luckyparrot
11-19-2012, 10:40 AM
I have found that ADE tolerates both '@media amzn-mobi' and '@media amzn-kf8' without ignoring the whole CSS file. Anything else (that I've tried) causes ADE to ignore the whole CSS file, even 'not amzn-mobi'. Has anyone had any success with any other media queries?

DSpider
12-01-2012, 01:00 PM
On the desktop version of ADE, the library screen has been showing half the cover thumbnail ever since version 1.5 (since 2008).

JSWolf
12-02-2012, 10:18 PM
On the desktop version of ADE, the library screen has been showing half the cover thumbnail ever since version 1.5 (since 2008).

Not so. I've just taken a look at the cover view in the library view for 1.7.2 and it works perfectly. It shows the full cover.

DSpider
12-03-2012, 03:10 AM
Oh? And what dimensions did the cover have?

Hatgirl
01-12-2013, 05:57 PM
Huh, according to this Dec 2012 thread (http://forums.adobe.com/message/4937542#4937542) on the ADE support forums, there may be someone we can direct our bug reports to:


Jeff A Wright:
....
For submitting bugs we don't have a formalized process. Usually we are notified of potential issues via our support team. Unfortunately the volume is so low for ADE that it can be more difficult for them to spot trends.

If you can reproduce a particular error consistently feel free to reach out to me via private message or my e-mail jwright@adobe.com.

Jellby
01-13-2013, 03:19 AM
Time to drop him a message pointing to this thread?

lrui
03-20-2013, 03:59 AM
On the desktop version of ADE, .PNGimages cannot be displayed

Adjust
03-20-2013, 04:34 AM
On the desktop version of ADE, .PNGimages cannot be displayed

They display fine for me

JSWolf
03-24-2013, 07:05 PM
On the desktop version of ADE, .PNGimages cannot be displayed

ADE 1.7.2 and ADE 2.0 both display PNG format graphics just fine.

Jellby
03-25-2013, 04:15 AM
ADE 1.7.2 and ADE 2.0 both display PNG format graphics just fine.

Except in some case, see here (http://www.mobileread.com/forums/showthread.php?p=1813039) (post #16 in this very thread)

JSWolf
03-26-2013, 08:50 AM
Except in some case, see here (http://www.mobileread.com/forums/showthread.php?p=1813039) (post #16 in this very thread)

Given that is a message from 2011, has PNG with a bit depth less then 8 been tested with ADE 1.7.2 and 2.0?

Jellby
03-26-2013, 10:35 AM
I don't know, but it was tested in the Orizon reader (which uses something like a pre-2.0 version). You can try it in ADE now: http://wiki.mobileread.com/wiki/EPub_Reader_Test

JSWolf
03-27-2013, 03:21 PM
I don't know, but it was tested in the Orizon reader (which uses something like a pre-2.0 version). You can try it in ADE now: http://wiki.mobileread.com/wiki/EPub_Reader_Test

ADE 1.8.3 for Windows displayed the PNG images just fine.

ADE 1.7.2 for Windows did display the PNG bug.

ADE 2.0 for Windows did displayed the PNG images just fine.

Jellby
03-28-2013, 04:05 AM
In any case, we often say "ADE" to refer to the renderer used by Adobe-based ePub readers (mobile-sdk or whatever its official name is). I don't know if this particular bug is fixed in newer readers, but if anyone tries, he/she could add all the results to the wiki page :)

m4mmon
11-11-2013, 05:38 AM
Sorry to answer to this old post, but I encounter an annoying behaviour with "recent" versions of ADE and some other software like fbReader.
In french, it is typographically correct to write, let's say, "Mlle" with "lle" as superscript :
M<sup>lle</sup>
Same with "Dr", "Me", etc.
The annoying behaviour I am talking about is that the software might break the word between "M" and "lle" to render a new line within a paragraph, instead of starting before or after the complete word. It would break chemistry formulas, etc.
This is not related to hyphenation since it was the first thing I disabled when encountering this for the first time.

It does not happen with ADE 1.x and on my PRS-T1, or when viewing the xhtml file in any browser I have tried.
It happens with ADE 2.0, Adobe Reader and fbReader on a friend's Pocketbook 623. I suspect it happens on all recent readers.

May be someone has some trick to avoid that ?

Toxaris
11-11-2013, 08:58 AM
You could try a span with 'white-space:nowrap', but support for that is really poor. The behavious makes sense, since it has a tag inside a word. So, the renderer has no real idea that it belongs to the same word.

Jellby
11-11-2013, 09:30 AM
The behavious makes sense, since it has a tag inside a word. So, the renderer has no real idea that it belongs to the same word.

But there's absolutely no indication it is not the same word. Line breaks should only be allowed at spaces (or other specific characters). I don't know if the HTML/CSS specs have anything to say about that, but I consider these spurious line breaks a big flaw.

m4mmon
11-11-2013, 10:00 AM
You could try a span with 'white-space:nowrap', but support for that is really poor.

Thank you for the suggestion, sadly it did not work in ADE 2. I cannot test on the Pocketbook right now.

I also think it looks like a big flaw to me: no browser I have tested breaks the word like ADE 2. In case the text deals with chemistry formulas, I do not think it is a good idea to break at markups.

DaleDe
11-11-2013, 11:27 AM
But there's absolutely no indication it is not the same word. Line breaks should only be allowed at spaces (or other specific characters). I don't know if the HTML/CSS specs have anything to say about that, but I consider these spurious line breaks a big flaw.

I would agree. It is a bug that ADE should fix. Next they will be splitting on a span.

Dale

jbacelar
11-11-2013, 12:11 PM
M& #737;& #737;& #7497;. D& #691;. M& #7497;.

Mˡˡᵉ. Dʳ. Mᵉ.

Google: utf-8 modifier letter small (and the character in question). :)

m4mmon
11-11-2013, 12:13 PM
I will try to report that to the adobe guy mentionned here:
http://www.mobileread.com/forums/showpost.php?p=2379201

m4mmon
11-11-2013, 12:27 PM
M& #737;& #737;& #7497;. D& #691;. M& #7497;.

Mˡˡᵉ. Dʳ. Mᵉ.

Google: utf-8 modifier letter small (and the character in question). :)

Thank you, I will try your suggestion !

edit : It works, at least in ADE 2.0, as a drawback I have to embed a suitable font in order to get sure it will be properly displayed. Liberation does have those characters in it, so it is not a big deal.

JSWolf
11-11-2013, 09:52 PM
I would agree. It is a bug that ADE should fix. Next they will be splitting on a span.

Dale

Actually, not next, ADE splits on a span now. I tried a M<span class="test">lle</span> where test was to do the superscript in CSS and ADE 2.0 did split after the M.

DaleDe
11-12-2013, 03:36 PM
Actually, not next, ADE splits on a span now. I tried a M<span class="test">lle</span> where test was to do the superscript in CSS and ADE 2.0 did split after the M.
Yuk!

Dale

hpstricker
11-15-2013, 02:34 AM
I really wonder why this bug starts annoying people only now - it has been there since the release of ADE 2, and it is really a shame. I did send a detailed bug report to Jeff Wright more than six months ago (!). He answered that he would see the problem - but that was it.

m4mmon
11-15-2013, 03:10 PM
Same for me, my excuse is that I only switched to ADE 2 recently. FBReader is also affected on my friend's reader.

SBT
02-20-2014, 07:59 AM
When viewing an epub with SVG illustrations in ADE Desktop v. 2 and 3 and on Sony PRS-T1, paths rendered with <symbol> and <use> tags are not shown. The SVG validates properly with the W3C validator. Anybody know of the problem, and a workaround that doesn't imply a bloated SVG file?

EDIT:
I haven't seen it documented anywhere, but it seems ADE does not support <symbol>!
The workaround is to use <g> instead of <symbol>, and in the corresponding <use> tags use transform="translate(...)" instead of x=... y=...

dgatwood
03-22-2014, 07:53 PM
Actually, not next, ADE splits on a span now. I tried a M<span class="test">lle</span> where test was to do the superscript in CSS and ADE 2.0 did split after the M.

Try <nobr>....</nobr> tags around the content in question. It is gross and evil, but it can help work around bugs like this....

Incidentally, ADE's behavior is explicitly wrong according to the HTML spec, as of v4.01, section 9.3.5:


By convention, visual HTML user agents wrap text lines to fit within the available margins. Wrapping algorithms depend on the script being formatted.

In Western scripts, for example, text should only be wrapped at white space. Early user agents incorrectly wrapped lines just after the start tag or just before the end tag of an element, which resulted in dangling punctuation. For example, consider this sentence:

A statue of the <A href="cih78">Cihuateteus</A>, who are patron ...
Wrapping the line just before the end tag of the A element causes the comma to be stranded at the beginning of the next line:

A statue of the Cihuateteus
, who are patron ...


This is an error since there was no white space at that point in the markup.


Emphasis mine. So if ADE is wrapping at tag boundaries....


Dear Adobe,

Has anyone on your Digital Editions team ever actually read the HTML specification? Didn't think so.


Sincerely,
Your users

Jellby
07-16-2014, 11:31 AM
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 (http://www.idpf.org/doc_library/epub/OPS_2.0.1_draft.htm#Section3.3):

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 (http://www.mobileread.com/forums/showpost.php?p=1013062&postcount=18).

The latest RMSDK (in Kobo firmware 3.5.0) seems to support auto margins. There is hope!

It also displays Hebrew and Arabic characters correctly right-to-left (although Arabir rendering leaves much to be desired).

Doitsu
07-16-2014, 02:47 PM
It also displays Hebrew and Arabic characters correctly right-to-left (although Arabic rendering leaves much to be desired).

Is the default font as ugly as the default Kindle font (code2000) or are there other display issues with diacritics and/or ligatures?

Could you please take a screen capture of my Hebrew/Arabic test file with and without publisher fonts enabled?

Jellby
07-16-2014, 04:34 PM
Is the default font as ugly as the default Kindle font (code2000) or are there other display issues with diacritics and/or ligatures?

Could you please take a screen capture of my Hebrew/Arabic test file with and without publisher fonts enabled?

As far as I could see, the default font has no Hebrew or Arabic characters, my test was with embedded fonts. I will try your file, but I don't know if I can take a screenshot, and I have no camera at hand.

ETA: By the way, I didn't use the "dir" attribute, I just relied on the Unicode bidi algorithm (Hebrew/Arabic characters are intrinsically rtl).

Doitsu
07-16-2014, 04:54 PM
As far as I could see, the default font has no Hebrew or Arabic characters, my test was with embedded fonts. I will try your file, but I don't know if I can take a screenshot, and I have no camera at hand.
Doesn't the Kobo have some kind of keyboard combination or touch gesture that will take a screen capture of the currently displayed screen?
If the firmware of your model doesn't support the method described in this thread (http://www.mobileread.com/forums/showthread.php?p=2636828), just let me know whether the diacrictics are displayed exactly as in Sigil or Calibre.

ETA: By the way, I didn't use the "dir" attribute, I just relied on the Unicode bidi algorithm (Hebrew/Arabic characters are intrinsically rtl).

I'm well aware of the fact, that Hebrew and Arabic characters are intrinsically RTL, I just wanted to "dot my I's and cross my T's." :)

PeterT
07-16-2014, 05:07 PM
Doesn't the Kobo have some kind of keyboard combination or touch gesture that will take a screen capture of the currently displayed screen?

Unfortunately that function has been broken in recent f/w levels.

davidfor
07-17-2014, 12:23 AM
Could you please take a screen capture of my Hebrew/Arabic test file with and without publisher fonts enabled?

I put it on my Kobo Glo and took the attached photo. The font is set to Gothic and the largest that would get all the text on one page. If I set the font to "Document default", the only differences are in how the English text is displayed.

Doitsu
07-17-2014, 01:36 AM
I put it on my Kobo Glo and took the attached photo. The font is set to Gothic and the largest that would get all the text on one page. If I set the font to "Document default", the only differences are in how the English text is displayed.

Thanks for testing this! The Kobo does indeed display the Hebrew and Arabic texts RTL, but there are major display issues both with Hebrew and Arabic. Many Hebrew and Arabic letters partially overlap and there are gaps between some of the Arabic letters.

Jellby
07-17-2014, 03:28 AM
The problem seems to be diacritics/ligatures. The couple of Hebrew samples I've seen (without diacritics) looked fine, using Ezra SIL as well.

Jellby
07-17-2014, 04:24 AM
In my Aura it looks exactly the same as davidfor's picture, except that the Hebrew diacritics don't overlap with the next line (maybe because I have applied the line-height patch). By reducing the font size, some things change, for instance, the first two letters (bet, resh) appear inverted (resh, bet), with a ~60% overlap between them.

Jellby
09-09-2014, 02:49 PM
I don't recall seeing this reported. Apparently ADE doesn't like putting floats in the first line (even when there is only one line), unless the float is the first element in the block.

p span { float: right }

<p><span>TEST</span>A test paragraph with a float
as the first element. It is correctly floated, and appears
in the first line.</p>

<p>A<span>TEST</span> test paragraph with a float
not as the first element. It is correctly floated, but
moved to the second line.</p>

JSWolf
09-09-2014, 03:02 PM
When reporting ADE bugs, please report which version of ADE this was founbd with as there are now three different versions.

DaleDe
09-09-2014, 03:03 PM
I don't recall seeing this reported. Apparently ADE doesn't like putting floats in the first line (even when there is only one line), unless the float is the first element in the block.

p span { float: right }

<p><span>TEST</span>A test paragraph with a float
as the first element. It is correctly floated, and appears
in the first line.</p>

<p>A<span>TEST</span> test paragraph with a float
not as the first element. It is correctly floated, but
moved to the second line.</p>

I think it could be argued that this is the correct behavior. I don't think this is defined in the spec but if the figure is after the first character then floating it left on the first line would change the order of the information by placing the figure visually ahead of the character. I think the behavior of floating it left after the first character is correct. Which readers do it differently?

Dale

Jellby
09-09-2014, 03:47 PM
When reporting ADE bugs, please report which version of ADE this was founbd with as there are now three different versions.

This is 1.7, the only one I can try in linux. The same effect is seen here (http://www.mobileread.com/forums/showpost.php?p=2918292&postcount=8), which is ADE 2.0.67275 on Mac.

I think it could be argued that this is the correct behavior. I don't think this is defined in the spec but if the figure is after the first character then floating it left on the first line would change the order of the information by placing the figure visually ahead of the character. I think the behavior of floating it left after the first character is correct. Which readers do it differently?

I should note that the same happens with left or right floats (and also that my example was with a right float).
I'm not now in the mood of decoding the spec (http://www.w3.org/TR/CSS2/visuren.html#float-position) (rule #8 seems to be broken, but maybe some of the other rules play a role here), but the sample at the end of the section does not behave like ADE. You are probably right in that this may not be against the spec, but it is an unexpected (and undesired) behaviour, I'd say. I haven't tried in readers yet, but firefox (and calibre) seem to behave differently.

dgatwood
09-12-2014, 01:48 AM
I think it could be argued that this is the correct behavior. I don't think this is defined in the spec but if the figure is after the first character then floating it left on the first line would change the order of the information by placing the figure visually ahead of the character. I think the behavior of floating it left after the first character is correct. Which readers do it differently?


Hopefully all of them. The only situation where a float is allowed to move to a new line, AFAIK, is when you have too many of them to fit on a single line.

For sure, WebKit floats them both correctly (left or right) on the first line, so iBooks, Kindle (KF8), and most other non-ADE readers should float them correctly.

With that said, check your margins to ensure that you don't have a big top margin (which could push it down), and be sure to set that span to be a block element. Floating an inline element is nonsensical, and just about any random interpretation of such invalid CSS could probably be considered correct. :D

Jellby
10-04-2014, 10:11 AM
I think we already know that ADE likes breaking lines at element borders (<span>s, <em>s, etc.), even when there is no space. This is another sample of annoying results caused by this behaviour bug:

some text <a id="pg_123"/>and more text

When ADE thinks that it's OK to break the line between the <a> and "and", the first line ends with a visible space. It's as if there were an &nbsp; but worse (an &nbsp; doesn't stretch, this space does.

The workaround is simple:

some text <span id="pg_123"/>and</span> more text

but I'm afraid many published books already use the first code, and look broken.

PS. I've noticed this reading in my Kobo. I'm assuming this is an ADE bug, and not Kobo-only, but I didn't test, and I could be wrong.

dgatwood
10-06-2014, 04:02 AM
Media queries are not supported in ePUB2, they are in ePub3. ADE does not work with ePUB3 yet.

I know I'm replying to a very old post, and I'm being somewhat pedantic here, but I think it's worth noting that CSS "at rules" were defined way back in the original CSS1 specification, and any spec-compliant CSS parser is required to ignore any syntactically valid rules that it does not understand. So if ADE chokes on media queries, it's still a spec compliance bug, even according to the EPUB 2 specification. :)

With that said, it's easy enough to work around such bugs by moving any rules that anger ADE into a separate CSS file.


I have found that ADE tolerates both '@media amzn-mobi' and '@media amzn-kf8' without ignoring the whole CSS file. Anything else (that I've tried) causes ADE to ignore the whole CSS file, even 'not amzn-mobi'. Has anyone had any success with any other media queries?

IIRC, it works for basic media queries, but chokes on more complex ones.