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.

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.

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.

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.

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=...

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:

Quote:

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:

Code:

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

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

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).