Known bugs in ADE

[Doitsu]

Originally Posted by Jellby

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, just let me know whether the diacrictics are displayed exactly as in Sigil or Calibre.

Originally Posted by Jellby

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]

Originally Posted by Doitsu

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]

Originally Posted by Doitsu

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]

Originally Posted by davidfor

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]

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]

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]

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]

When reporting ADE bugs, please report which version of ADE this was founbd with as there are now three different versions.

[DaleDe]

Originally Posted by Jellby

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]

Originally Posted by JSWolf

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, which is ADE 2.0.67275 on Mac.

Originally Posted by DaleDe

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 (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]

Originally Posted by DaleDe

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.

[Jellby]

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]

Originally Posted by Toxaris

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.

Originally Posted by luckyparrot

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.

[SBT]

I've problems with the following on ADE 4 which I do not have with the same document in ADE 2:

• white-space:nowrap ignored.
• negative margins ignored.
• <span style="border-top-style:solid"> is applied to the text preceeding the span.

It beggars belief that these should be actual errors, but I've not been able to replicate the behaviour on other viewers.

[Doitsu]

Originally Posted by SBT

It beggars belief that these should be actual errors, but I've not been able to replicate the behaviour on other viewers.

AFAIK, most new ADE4 features only work with ePub3 files. I.e., you'll have to code your ePub file as an ePub3 file to take advantage of the new ADE4 features.

I've created a simple test file with Sigil 0.8.4, converted it with the optional Sigil ePub3 plugin and both nowrap and the solid border top styles seem to work with ADE4.