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

[brewt]

CORRECTION/EDIT:

CSS DROP CAPS DO WORK IN AN EPUB ON A READER

Message 54 of this thread has an epub that it all works in. If you use Calibre to create it using this solution, set your base font size to Zero to make it work correctly there.

Rest of thread preserved for posterity.

Thanks to all who made it work: Jelby, Llasram, Peter Sorotokin, and Kovid Goyal.

-bjc


/////////////////////////////////////////////////////





At least, I haven't seen it. Attached is what happens with this code:

css:
span.first {
font-variant: small-caps;
margin-left: -0.5em;
}
span.drop {
font-size: 400%;
font-weight: bold;
line-height: 0.75;
float: left;
margin: 0 0.125em 0 0;
}

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


Now the idea that Sony needs to change their code-interpretation is probably indisputable, but who is going to call Sony and correct them? And then get them to distribute a fix? Or Adobe (DE has the same problem)?

C'mon, guys, prove me wrong. Oh, and showing something work in a browser on a computer doesn't count.

-bjc

[Jellby]

I don't have a Sony to try, but I'm the author of the ePUB example.

I'm pretty sure the problem is that the reader interprets "line-height: 0.75" by lowering the top "border", while browsers typically raise the whole "block" (the drop cap in this case).

I don't claim to be a CSS expert, far from it... I'm not even sure what the correct behaviour could be. Maybe I should add a "vertical-align: top" property? Could you try it?

What I'm sure it's doing wrong is rendering the "I - The Birth of the Prince and the Pauper" line, it should be ignored in the text flow (and, ideally, displayed as a page header from the next page).

[mtravellerh]

Originally Posted by Jellby

I don't have a Sony to try, but I'm the author of the ePUB example.

I'm pretty sure the problem is that the reader interprets "line-height: 0.75" by lowering the top "border", while browsers typically raise the whole "block" (the drop cap in this case).

Obviously you're right, Jellby. Sony uses the ADE rendering engine and we knew about this same problem as we have talked about it before. Sony, therefore, generally just reacts the way ADE does.

[brewt]

Originally Posted by Jellby

I don't have a Sony to try, but I'm the author of the ePUB example.

I wasn't trying to pick on you (really really). Your example just happened to look and work better than anything else I had tried. My own experiments were awesomely dismal.

Originally Posted by Jellby

I don't claim to be a CSS expert, far from it... I'm not even sure what the correct behaviour could be. Maybe I should add a "vertical-align: top" property? Could you try it?

I would be delighted to.

The Sony Ebook Software is a reasonable simulator for what happens on a Reader. It doesn't care so much about the 300k limit that a real Reader does, but otherwise it's close, if you want to try it.

Oh wait. The Sony stuff is Windows only, and you're running on Linux, if I recall.

But again, I would be delighted to try it, if you wish.

-bjc

[llasram]

Originally Posted by Jellby

I don't have a Sony to try, but I'm the author of the ePUB example.

I'm pretty sure the problem is that the reader interprets "line-height: 0.75" by lowering the top "border", while browsers typically raise the whole "block" (the drop cap in this case).

I think part of the problem is that the interpretation of the 'line-height' in this case isn't necessarily the most unambiguous way to achieve the result you want. According to the CSS spec, setting 'float' causes the <span/> to become a block-level element. Setting the 'line-height' causes the size of the line-box to become 0.75 of the current em-size, or 3ems. It then says that "[u]ser agents center glyphs vertically in an inline box, adding half-leading on the top and bottom," but "[w]hen the 'line-height' value is less than the content height, the final inline box height will be less than the font size and the rendered glyphs will 'bleed' outside the box." To me this is ambiguous about *how* they bleed -- ADE appears to shrink the line-box at the top & bottom, but then only bleed the glyph out the bottom.

Instead, try setting a 'line-height' of 1em and a 'height' of 1em. That should force the size of the block and line-box to be the same. That said, you probably don't want to set the font size to 400% -- that's 4x the font-size, but the default 'line-height' is probably more than 1.0. The only way to get consistent results is to set the default line-height to a value you control such as 1.2, then you can set the font-size in the drop-cap to something like 4.8em to force it to be 4 lines tall.

[Jellby]

Originally Posted by brewt

I wasn't trying to pick on you (really really).

I didn't take it that way, don't worry.

Oh wait. The Sony stuff is Windows only, and you're running on Linux, if I recall.

Yes, and I tried unsuccessfully to install Calibre (and ADE in a virtual machine), so right now I don't have any real ePUB reader...

Originally Posted by llasram

IInstead, try setting a 'line-height' of 1em and a 'height' of 1em. That should force the size of the block and line-box to be the same. That said, you probably don't want to set the font size to 400% -- that's 4x the font-size, but the default 'line-height' is probably more than 1.0. The only way to get consistent results is to set the default line-height to a value you control such as 1.2, then you can set the font-size in the drop-cap to something like 4.8em to force it to be 4 lines tall.

Silly me, I thought a line-height with no units would be a multiple of the current line-height, not just ems... Well, I don't care that much that the drop-cap is an exact number of lines (and I'm reluctant to specify a line-height for normal text, that should be set by the reader), I'm more worried about having unnecessary blank margins above (and especially below) the drop cap. Even if I specify "line-height: 1em; height: 1em", the box is larger that the letter... but I guess that's unavoidable, and depends on the exact font and character (a parenthesis or a Q or accented letter may extend above or below other usual letters).

So, we need to find a compromise. I think it could be enough to combine your suggestion with a negative top-margin, so I propose this:

span.drop {
  font-size: 400%;
  font-weight: bold;
  float: left;
  margin: -0.15em 0.125em 0 0;
  line-height: 1em;
  height: 1em;
}

For testing purposes, I'm uploaded the modified book (without illustrations, to reduce filesize), I'd be glad to see screenshots from Sony, ADE and Calibre...

[mtravellerh]

This is ADE. No changes I guess

[mtravellerh]

Calibre looks fine

[llasram]

Originally Posted by Jellby

Yes, and I tried unsuccessfully to install Calibre (and ADE in a virtual machine), so right now I don't have any real ePUB reader...

If you grab the stand-alone executable version of ADE, it actually runs perfectly fine under Wine.

Originally Posted by Jellby

Silly me, I thought a line-height with no units would be a multiple of the current line-height, not just ems...

Alas not... The difference between using ems vs. no units is that with no units cascaded elements will be that multiple of their font-size, no matter what the font size is. With ems, you fix the line-height to a particular measure which then doesn't change with changing font-sizes.

Originally Posted by Jellby

Well, I don't care that much that the drop-cap is an exact number of lines (and I'm reluctant to specify a line-height for normal text, that should be set by the reader)

I actually don't think it should be a problem as long as it's an em-based or unitless measure which varries with font-size. Because the spec doesn't specify an exact default value there isn't any other way to get pixel-perfect layouts.

Originally Posted by Jellby

For testing purposes, I'm uploaded the modified book (without illustrations, to reduce filesize), I'd be glad to see screenshots from Sony, ADE and Calibre...

I apparently should have tested what I was proposing, and I apologize for not having done so :-/. As already posted, no change. However, playing around with it, I discovered that the culprit is the negative left margin on 'span.first'. I hesitate to theorize why ADE doesn't want to float the float before text which is pulled left of the left margin / into the box occupied by the float, but there you go.

[Jellby]

Originally Posted by llasram

However, playing around with it, I discovered that the culprit is the negative left margin on 'span.first'. I hesitate to theorize why ADE doesn't want to float the float before text which is pulled left of the left margin / into the box occupied by the float, but there you go.

Damn! So it's still Adobe's fault, but for a different reason. Now, what could be the solution?... Maybe combining "position: relative; right: 0.5em" and "margin-right: -0.5em" for span.first... but gosh! that's dirty hacking!

If you grab the stand-alone executable version of ADE, it actually runs perfectly fine under Wine.

Do you have a link to that stand-alone executable?

[llasram]

Originally Posted by Jellby

Do you have a link to that stand-alone executable?

It's linked to from this Adobe knowledgebase article. You can ignore all the directions and just wine the exe without any special setup.

[brewt]

Poking through Adobe, it seems they knew the drop cap codes wouldn't work a year-and-change ago:


http://blogs.adobe.com/digitaleditio...ntent_for.html



Posted by: Joseph Gray | October 26, 2007 10:54 PM

I'll look at the drop cap code. It's most likely a bug in the Digital Editions. All of these properties are supported and should work.

Support for justification is optional per W3C CSS spec and support for margin value of auto is optional per IDPF OPS spec. We are planning to implement them at some point, but you can never rely on a reading system to support those.


I'm reasonably sure there's been an update or two since 10/07 to ADE, so, this hasn't been on the priority list.

And, as long as we're at it:

Posted by: Kuldeep Kumar | December 23, 2008 01:35 AM

There is no way to turn off page number marks at this point, but it is on our list.



Confession is good:

Posted by: vuchrfvdvr | October 1, 2007 10:46 AM

Some other CSS that doesn't seem to work in Digital Editions are the following:

text-align: justify;
margin-left: auto;
margin-right: auto;


More on the party line:

http://blogs.adobe.com/digitaleditio..._editions.html

-bjc

[mtravellerh]

Justify works fine with the Calibre epub engine.

[Jellby]

Originally Posted by brewt

Poking through Adobe, it seems they knew the drop cap codes wouldn't work a year-and-change ago:

I'll look at the drop cap code. It's most likely a bug in the Digital Editions. All of these properties are supported and should work.

Support for justification is optional per W3C CSS spec and support for margin value of auto is optional per IDPF OPS spec. We are planning to implement them at some point, but you can never rely on a reading system to support those.


I'm reasonably sure there's been an update or two since 10/07 to ADE, so, this hasn't been on the priority list.

If Llasram is right, and there's no reason to believe he isn't, the drop-caps themselves do work, it is the code after that that breaks them... I mean, maybe they actually fixed the caps, but left some other bug around.

So let's check it, how does this one look? (check chapters IX and XXXII too, they should have a larger negative indent in the first line).

[brewt]

Gettin' close - I'll add more screen shots later......