Css Drop Caps does not work in an Epub on a Reader

[Valloric]

Originally Posted by Jellby

I wonder if there is a way to have reader-specific CSS code, some rules that would be applied only by ADE, or only by Calibre... that would allow to work around known bugs or limitations.

Or Adobe could just fix DE...

We've reached the point where we can't use the features included in the standard just because the market leader for epub reading software (it's a rather small market, I agree) doesn't implement them... or worse, breaks them.

DE == IE?

[Jellby]

Originally Posted by Valloric

Or Adobe could just fix DE...

Yes, but I was trying to be realistic

[llasram]

Originally Posted by Jellby

I wonder if there is a way to have reader-specific CSS code, some rules that would be applied only by ADE, or only by Calibre... that would allow to work around known bugs or limitations.

Actually, the OPS spec almost provides such a thing. Check out the section on OPS Inline XML Islands. If AdobeDE correctly handles <ops:switch/> elements (I'm not sure that it does) and there's a non-default required-namespace it considers itself to handle (which I don't know what would be), then you can use that to <link/> in an AdobeDE-specific stylesheet. Hiding alternate <ops:case/> elements from renderers which don't understand it may be a bit of a challenge, but I think should be possible without too much kludgery.

Semi-alternatively, I'm planning to add <ops:switch/> pre-processing to Calibre e-book generation. So if you need to tweak the style sheet for Mobipocket, LIT, etc generation, you can specify the tweaking stylesheet right in the markup and just include it as-per-normal in the OPF-manifested book content.

[kovidgoyal]

The calibre epub engine supports javascript, so you can easily optimize your books for calibre.

[Peter Sorotokin]

OK, I finally got some time to look at what actually happens in the code. The problem is caused by a long-standing bug in our code and a particular nesting of spans.

The bug that we have is that if a float happens in the middle of the line, our engine always pushes it down, without attempting to shift it to the left or to the right.

Now the particular span nesting that this example uses has a span with a leading margin that contains a float as a first element. That margin is counted as content, so the float bug kicks in and the float gets pushed down.

A workaround is simply to put margin after on an element after the float, e.g.

<p><span class="drop">I</span><span class="first">n</span> the ancient city of London...

[Jellby]

Originally Posted by Peter Sorotokin

OK, I finally got some time to look at what actually happens in the code. The problem is caused by a long-standing bug in our code and a particular nesting of spans.

It's great to have some kind of official-ish answer, thank you very much. Your suggested workaround seems about the cleanest workaround possible (something cleaner would be a solution, not a workaround ).

A solution, of course, would be better, and while you're at it, you could fix the "display: oeb-page-header" thing

[Valloric]

Originally Posted by Peter Sorotokin

OK, I finally got some time to look at what actually happens in the code.

Wait... complaining actually worked? Haven't you people learned anything from Microsoft?

Seriously though, thanks for checking it out. At least we know someone at Adobe cares. That's a step in the right direction.

[igorsk]

Hi Peter, any news on full justification support?

[Peter Sorotokin]

Originally Posted by igorsk

Hi Peter, any news on full justification support?

Can't talk about future, remember?

[Peter Sorotokin]

Originally Posted by Valloric

Wait... complaining actually worked? Haven't you people learned anything from Microsoft?

Seriously though, thanks for checking it out. At least we know someone at Adobe cares. That's a step in the right direction.

Nice and simple test cases that are easy to run in debugger tend to get looked at, that's all. Complaining is not as effective.

And I am not fixing the bug - not yet at least. This is a fairly obsure use of CSS and this example does not work correctly in Opera and Mozilla. We have more serious glitches to address first.

[Jellby]

Originally Posted by Peter Sorotokin

This is a fairly obsure use of CSS and this example does not work correctly in Opera and Mozilla. We have more serious glitches to address first.

Does not? I tested with Opera and Firefox and it seemed to work fine, at least it did what I expected.

[Peter Sorotokin]

Originally Posted by Jellby

Does not? I tested with Opera and Firefox and it seemed to work fine, at least it did what I expected.

Here is Firefox 3.0.5, note missing negative margin:


Here is Opera 9.62, has exact the same bug as ADE:

[Jellby]

Originally Posted by Peter Sorotokin

Here is Opera 9.62, has exact the same bug as ADE:

Strange, this is Opera 9.60 for linux (attached).

Firefox 2.0.0.18, indeed, does not show the negative margin.

[brewt]

Peter - thanks for checking in on us and helping out. We appreciate the Float Bug Workaround for Drop Caps in Digital Editions (FBWfDCiDE).

Since our old friend Word (now with 300% more evil) doesn't do these things like this at all, and Indesign places Word Docs (taking with it the above-mentioned evil), is there a way to create the Drop Cap from within Indesign that would work in the Epub?

And on the (I know - touchy) subject of "glitches", may we recommend employing our friend Kovid Goyal? Not that I speak for him, but as an admirer, his efforts toward this whole digital reading thing have been pretty darn good....

-bjc

[Jellby]

Well, I applied the workaround to this book (since it's not illustrated, it's a smaller test file, but it's in Spanish). Could you people try it with different readers? It works fine with Opera here at home.

Things to look at:

All chapters: The drop cap should occupy around 3 lines, the top of the cap should more or less about the same height as the top of the first line. The drop cap should have the same indent as normal paragraphs, there should be some space between the cap and the text on the right, except for the first line (minimal space here). Chapter III is "standard".

Chapters I, IV... : The first line should be moved farther to the left, according to the shape of the A or L.

Chapter II: There must be a space in "A fines" (meaning the space in the first line is a bit larger than in Chapter I). To get this I used "white-space: pre" (and an entity for the space to prevent my text editor to wrap the line and thus add a spurious linebreak).

Chapters XXVII, XXXIII...: Here there is some punctuation before the drop cap. It should be the same font as the normal text, and more or less vertically aligned with the first line (I don't think there is a way to get this exactly without fixing the line-height for the normal text, which I want to avoid). In this case, the "predrop" text is indentend as normal paragraphs, the drop cap goes after that.

Chapter XXIX: Hmm... I'm not sure here... The second paragraph (starting with "--¡Elvira!"), depending on the line width, could begin still to the right of the drop cap, and this is a bit weird. If I wanted to prevent this, forcing the second paragraph to begin below the drop cap, would it be possible?

EDIT: I updated the file, it is now in post #50 (link).