View Full Version : Css Drop Caps does not work in an Epub on a Reader


brewt
01-08-2009, 02:05 PM
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
01-08-2009, 02:45 PM
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
01-08-2009, 03:21 PM
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
01-08-2009, 04:12 PM
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.


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 (http://ebookstore.sony.com/download/)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
01-08-2009, 05:30 PM
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
01-09-2009, 07:43 AM
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...

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
01-09-2009, 08:41 AM
This is ADE. No changes I guess

mtravellerh
01-09-2009, 08:46 AM
Calibre looks fine

llasram
01-09-2009, 09:17 AM
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.

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.

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.

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
01-09-2009, 11:35 AM
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
01-09-2009, 12:01 PM
Do you have a link to that stand-alone executable?

It's linked to from this Adobe knowledgebase article (http://kb.adobe.com/selfservice/viewContent.do?externalId=kb403051). You can ignore all the directions and just wine the exe without any special setup.

brewt
01-09-2009, 02:05 PM
Poking through Adobe, it seems they knew the drop cap codes wouldn't work a year-and-change ago:


http://blogs.adobe.com/digitaleditions/2007/08/publishing_docbook_content_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/digitaleditions/2007/08/the_point_of_digital_editions.html

-bjc

mtravellerh
01-09-2009, 02:20 PM
Justify works fine with the Calibre epub engine.

Jellby
01-09-2009, 02:48 PM
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
01-09-2009, 05:43 PM
Gettin' close - I'll add more screen shots later......

llasram
01-09-2009, 06:40 PM
Gettin' close - I'll add more screen shots later......

I've got something that seems to work in all the renders I've got handy. Instead of messing around with the more esoteric "display" values I'm setting a negative "text-indent" on the paragraph containing the drop cap. Modified version of the test EPUB attached showing what I mean (although other modifications are possibly necessary, as I change the properties of the .initial class).

Jellby
01-10-2009, 06:07 AM
So... negative "margin-left" causes havoc and "position: relative" is not supported.

Another "trick": negative indent for the paragraph and a correspoding marging-left for the drop cap (but I'd have to alter the code for the A and L case).

EDIT: Sorry, Llasram, I didn't see your post, being in page 2.

brewt
01-10-2009, 11:16 AM
1/9 3:40 pm, llasram versions attached. Any chance of getting the drop cap to drop a smidge?

Stanza included this time for fun - hardly any formatting at all in Stanza, and no hyperlinking.

Oh, one other thing I don't understand. Calibre is missing this line:

"I — The Birth of the Prince and the Pauper"

that all the other readers seem to pick up. Any ideas as to what we're seeing?

-bjc

zelda_pinwheel
01-10-2009, 11:31 AM
1/9 3:40 pm, llasram versions attached. Any chance of getting the drop cap to drop a smidge?

Stanza included this time for fun - hardly any formatting at all in Stanza, and no hyperlinking.

Oh, one other thing I don't understand. Calibre is missing this line:

"I — The Birth of the Prince and the Pauper"

that all the other readers seem to pick up. Any ideas as to what we're seeing?

-bjc
that means, calibre is the only one correctly rendering the code : that line is the page header, which should either be displayed as a running page header if that is supported, or not displayed at all. so far all the other displays incorrectly interpret it and include in the flow.

Jellby
01-10-2009, 11:42 AM
1/9 3:40 pm, llasram versions attached. Any chance of getting the drop cap to drop a smidge?

It's easy to make it drop... but it's not quite "portable", I mean that the exact positioning and size will depend on the font, line height, etc., and what looks fine in some configuration might look terrible (the drop cap overlapping the text, or huge blank spaces) in others. These settings are a compromise, something that is kind of guaranteed that won't look terrible in any configuration, at the cost of not being "perfect" in most of them.

mtravellerh
01-10-2009, 11:51 AM
It's easy to make it drop... but it's not quite "portable", I mean that the exact positioning and size will depend on the font, line height, etc., and what looks fine in some configuration might look terrible (the drop cap overlapping the text, or huge blank spaces) in others. These settings are a compromise, something that is kind of guaranteed that won't look terrible in any configuration, at the cost of not being "perfect" in most of them.

The result is good enough for me. Llasram, Jellby, do you mind much if I use that code for my books with drop caps? Of course, if you find any ameliorations, please lemme know. Thanks bunches, guys. One more solution to a problem.

Jellby
01-10-2009, 12:01 PM
Laasram, Jellby, do you mind much if I use that code for my books with drop caps?

Not at all, it's free if you like it :D

brewt
01-10-2009, 03:54 PM
Attached are a couple more shots, 1/9 3:40 pm, llasram version, with the largest and smallest typesize selected in ADE.

The proportionality seems consistent with the positioning of the drop cap to the rest of the paragraph. So altering the code to lower the drop cap should continue to provide consistent viewing regardless of size.

The code will have to be tweaked when a different typeface is selected. Or a different porportion of initial cap to regular type size is needed.

Have I pulled the right code out here?


css:
p {
text-indent: 1em;
margin: 0;
}
p.initial {
text-indent: -0.5em;
}
span.first {
font-variant: small-caps;
}
span.drop {
font-size: 400%;
font-weight: bold;
float: left;
margin: -0.15em 0.125em 0 0;
text-indent: 0em;
line-height: 1em;
height: 1em;
}
.afterA {
text-indent: -1em;
}
.afterL {
text-indent: -1.5em;
}

xhtml for chapter 1:
<p class="initial"><span class="first"><span class="drop">I</span>n</span> the
ancient city of London, on a certain autumn day in the second quarter of the
sixteenth century, a boy was born to a poor family of the name of Canty, who
did not want him. ...</p>


xhtml for chapter 13:
<p class="afterA"><span class="first"><span class="drop">A</span>&nbsp;
heavy</span> drowsiness presently fell upon the two comrades. The King
said&mdash;</p>



(Bad Coloring Job Mine. All Mine.)


So, if I've read this right, you've got more than 1 after-the-drop-cap-code, depending on, of course, the width of the letter (I's take up less horizontal space than W's. Err, A's).

Refresh my memory - even without scripting, doesn't css support some kind of variables that could detect the width of the letter for us, so we wouldn't have to hand-tweak the after-spacing on every drop cap? (ever the lazy one, I am).


-bjc

mtravellerh
01-10-2009, 04:03 PM
Attached are a couple more shots, 1/9 3:40 pm, llasram version, with the largest and smallest typesize selected in ADE.

The proportionality seems consistent with the positioning of the drop cap to the rest of the paragraph. So altering the code to lower the drop cap should continue to provide consistent viewing regardless of size.

The code will have to be tweaked when a different typeface is selected. Or a different porportion of initial cap to regular type size is needed.

Have I pulled the right code out here?


css:
p {
text-indent: 1em;
margin: 0;
}
p.initial {
text-indent: -0.5em;
}
span.first {
font-variant: small-caps;
}
span.drop {
font-size: 400%;
font-weight: bold;
float: left;
margin: -0.15em 0.125em 0 0;
text-indent: 0em;
line-height: 1em;
height: 1em;
}
.afterA {
text-indent: -1em;
}
.afterL {
text-indent: -1.5em;
}

xhtml for chapter 1:
<p class="initial"><span class="first"><span class="drop">I</span>n</span> the
ancient city of London, on a certain autumn day in the second quarter of the
sixteenth century, a boy was born to a poor family of the name of Canty, who
did not want him. ...</p>


xhtml for chapter 13:
<p class="afterA"><span class="first"><span class="drop">A</span>&nbsp;
heavy</span> drowsiness presently fell upon the two comrades. The King
said&mdash;</p>



(Bad Coloring Job Mine. All Mine.)


So, if I've read this right, you've got more than 1 after-the-drop-cap-code, depending on, of course, the width of the letter (I's take up less horizontal space than W's. Err, A's).

Refresh my memory - even without scripting, doesn't css support some kind of variables that could detect the width of the letter for us, so we wouldn't have to hand-tweak the after-spacing on every drop cap? (ever the lazy one, I am).


-bjc

Being lazy myself, how does it look like if one inserts the space on pure principle? Would the I look so bad for that? I'll have to try that, but finally I'll just have to check the practical usage in a book.

I think the
p {
text-indent: 1em;
margin: 0;
}

won't work for me. I will have to define a special p class for the first paragraph as I use points to define my indent, normally (15pt) (works better for mobi making). Or could I use the points for defining the indent? Or do I have to completely rewrite my code for those drop caps, thus having to make 2 source files?

Jellby
01-11-2009, 05:41 AM
The proportionality seems consistent with the positioning of the drop cap to the rest of the paragraph. So altering the code to lower the drop cap should continue to provide consistent viewing regardless of size.

Yes, that's what I expected. Since the lengths are given in ems, there should be no problem changing the font size, but changing the typeface or the line spacing (which different devices may allow, or have different defaults) could be different.

So, if I've read this right, you've got more than 1 after-the-drop-cap-code, depending on, of course, the width of the letter (I's take up less horizontal space than W's. Err, A's).

More than the width of the letter, it's about the shape of the letter. If the letter does not quite reach the top right corner, I add some negative spacing for the rest of the line, otherwise the flow is a bit strange, a sort of kerning. This happens for A and L. If the drop cap would not drop, i.e, if it would extend above the first line, but not below, I would use special code for letters that don't reach the bottom right corner, like T and W.

Another thing. In my tests, with a browser, the drop cap position was affected by the negative indent (it was displaced to the left), so I had to add a matching margin-left to the span.drop definition, and that would need to be changed in the .afterA and .afterL cases... I don't know if this behavior is normal or a "bug" in my browser, tough.

Jellby
01-11-2009, 05:47 AM
Being lazy myself, how does it look like if one inserts the space on pure principle? Would the I look so bad for that? I'll have to try that, but finally I'll just have to check the practical usage in a book.

I don't know if I follow you... There is a default spacing for all caps defined, only A and L have something "special", because of their shape.

I think the
p {
text-indent: 1em;
margin: 0;
}

won't work for me. I will have to define a special p class for the first paragraph as I use points to define my indent, normally (15pt) (works better for mobi making). Or could I use the points for defining the indent? Or do I have to completely rewrite my code for those drop caps, thus having to make 2 source files?

That is the definition for normal paragraphs, you can have whatever you want there ("text-indent: 15pt"), yes, you can use "pt" or "px" as units, I just prefer using relative units when possible, but it's true that maybe the indent should be defined in relation to the page width something like 3%, maybe? The special class for the first paragraph is already there: p.initial.

brewt
01-13-2009, 12:13 PM
Hmmm. don't think we're done yet.

The Evil Empire has a surprisingly elegant solution to the drop cap problem: It's a menu item in Word, and it creates a 1-celled table with the letter (or word) larger, with text wrapping around it to the right. It's undoable/redoable, and it manages all the drop caps' typeface etc with a style.

It works ok in output html, in the epub built by and read in calibre, but not in ADE.

#########################

Here's the code, attached is a pic and the epub:

<html>

<head>
<meta http-equiv=Content-Type content="text/html; charset=windows-1252">
<meta name=Generator content="Microsoft Word 11 (filtered)">
<title>I</title>
<style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
text-indent:.2in;
font-size:12.0pt;
font-family:"Times New Roman";}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
{margin-top:0in;
margin-right:0in;
margin-bottom:6.0pt;
margin-left:0in;
text-indent:.2in;
line-height:115%;
font-size:12.0pt;
font-family:"Times New Roman";}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>

</head>

<body lang=EN-US>

<div class=Section1>

<div>

<table cellspacing=0 cellpadding=0 hspace=0 vspace=0 align=left>
<tr>
<td valign=top align=left style='padding-top:0in;padding-right:0in;
padding-bottom:0in;padding-left:0in'>
<p class=MsoNormal style='line-height:38.55pt;page-break-after:avoid;
vertical-align:baseline'><span style='font-size:46.0pt;font-family:Arial;
color:black'>I</span></p>
</td>
</tr>
</table>

</div>

<p class=MsoNormal style='text-indent:0in'><span style='font-size:10.0pt;
font-family:Arial;color:black'>n the beginning God created the heaven and the
earth.* And the earth was without form, and void; and darkness was upon the
face of the deep. And the Spirit of God moved upon the face of the waters.* And
God said, Let there be light: and there was light. And God saw the light, that
it was good: and God divided the light from the darkness.* And God called the
light Day, and the darkness he called Night. And the evening and the morning
were the first day.</span></p>

</div>

</body>

</html>

Ideas?


#########################

Open Office's solution works more like a real css, but the code it produces isn't modifiable from within Writer, and each one is a modification of the style on-the-fly, so if you were to use it, you'd have to hack the file every place you did it, and the default makes a bad drop cap (in both the html and resultant epub) anyway.

#########################

............Lazy-boy here wants something he doesn't have to hand code......

-bjc

llasram
01-13-2009, 12:19 PM
The Evil Empire has a surprisingly elegant solution to the drop cap problem: It's a menu item in Word, and it creates a 1-celled table with the letter (or word) larger, with text wrapping around it to the right.

Ewwwwwww. Simple rule for if things should be a table in HTML: is the content actually a table? If no, then no. It appears MSWord creates a table here so that they can set the HTML 3.2-ish "align" attribute to "left," which has the same result as setting the CSS property "float" to "left" on a block-level element in any contemporary renderer. In other words, it achieves the same thing that all the basic previous drop-cap content does, only with 300% (or so) more evil.

zelda_pinwheel
01-13-2009, 12:22 PM
Ewwwwwww. Simple rule for if things should be a table in HTML: is the content actually a table? If no, then no. It appears MSWord creates a table here so that they can set the HTML 3.2-ish "align" attribute to "left," which has the same result as setting the CSS property "float" to "left" on a block-level element in any contemporary renderer. In other words, it achieves the same thing that all the basic previous drop-cap content does, only with 300% (or so) more evil.

:pandalol: MS Word : now with 300% more evil !!

Jellby
01-14-2009, 05:57 AM
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.

Valloric
01-14-2009, 11:02 AM
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
01-14-2009, 11:33 AM
Or Adobe could just fix DE...

Yes, but I was trying to be realistic :D

llasram
01-14-2009, 12:28 PM
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 (http://www.idpf.org/2007/ops/OPS_2.0_final_spec.html#Section2.6.3). 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
01-14-2009, 01:32 PM
The calibre epub engine supports javascript, so you can easily optimize your books for calibre.

Peter Sorotokin
01-14-2009, 01:41 PM
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
01-14-2009, 01:50 PM
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 :D).

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

Valloric
01-14-2009, 02:06 PM
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? :D

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

igorsk
01-14-2009, 05:16 PM
Hi Peter, any news on full justification support?

Peter Sorotokin
01-14-2009, 08:41 PM
Hi Peter, any news on full justification support?

Can't talk about future, remember?

Peter Sorotokin
01-14-2009, 08:50 PM
Wait... complaining actually worked? Haven't you people learned anything from Microsoft? :D

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
01-15-2009, 05:13 AM
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
01-15-2009, 11:12 AM
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:
http://sorotokin.com/misc/mozilla.gif

Here is Opera 9.62, has exact the same bug as ADE:
http://sorotokin.com/misc/opera.gif

Jellby
01-15-2009, 11:50 AM
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
01-15-2009, 02:18 PM
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
01-15-2009, 04:11 PM
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 (http://www.mobileread.com/forums/attachment.php?attachmentid=21365&d=1232113092)).

Peter Sorotokin
01-15-2009, 05:47 PM
If I wanted to prevent this, forcing the second paragraph to begin below the drop cap, would it be possible?


This:

clear: left;

placed on the second paragraph should do the trick (but I have not tried it).

Peter Sorotokin
01-15-2009, 06:18 PM
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?

Frankly, I am not an expert on that. I mostly create my EPUBs by hand or from something called "FB2" (mostly used for Russian books). I think you really should treat InDesign export as a starting point; certainly styling scripts/tools are needed to do this sort of things.

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

Oh, there is nothing touchy about bugs, especially bugs in CSS layout. Word may be evil, but CSS is insane. Unfortunately, we are stuck with both.

Kovid - I think he is studying for PhD in physics (as I once did). I'd say being a scientist is more noble than being a software engineer, so first, let's see if he gets bored with academia. Besides, he may not be able to work on free ebook stuff if he is employed by Adobe, so be careful what you wish for.

kovidgoyal
01-15-2009, 06:23 PM
Kovid - I think he is studying for PhD in physics (as I once did). I'd say being a scientist is more noble than being a software engineer, so first, let's see if he gets bored with academia. Besides, he may not be able to work on free ebook stuff if he is employed by Adobe, so be careful what you wish for.

Don't know about noble, I will say it's harder ;) What area of physics did you do your thesis in?

Peter Sorotokin
01-15-2009, 10:01 PM
Don't know about noble, I will say it's harder ;) What area of physics did you do your thesis in?

Well, it is easier to sell programs than theories ;-)

I did plasma and gas dynamics in that place: http://www.lle.rochester.edu/. But I have bailed out after getting MS.

Jellby
01-16-2009, 09:38 AM
clear: left;

Thanks, I used it, but not explicitly in the second paragraph, but in a "p.initial + p" selector (hoping that reading systems will support adjacent sibling selectors). What do people think about this, is it better having the second paragraph starting beside the drop cap or having a vertical space before it?

I also changed the "predrop" code to make it a bit more portable (now the displacement is from the top of the drop cap, not from the bottom).

brewt
01-16-2009, 01:48 PM
That looks pretty darn good. If I read your epub directly (sony pic).

I'm just having trouble getting the idea to work with my stuff now.


When I try to re-render your file in Calibre, I get the old problem in DE. (DE pic)

Maybe I'm missing something on some other level in rendering in calibre? If I wanted to rebuild your file in calibre (with modifications, say, adding double quotes) how would I rebuild it?

Calibre's Epub-to-epub got different results in DE/sony - my attempt at rebuilding it in calibre is attached. The Calibre Viewer seems to see the Calibre-rendered version ok, but DE has issues with it.

-bjc

Jellby
01-16-2009, 03:53 PM
When I try to re-render your file in Calibre, I get the old problem in DE. (DE pic)

Is that my file run through Calibre and saved as a different epub file (maybe with modifications)? Does the DE pic correspond to the epub file you attached? Does DE render the original file correctly (the drop cap and the poetry fragment under the chapter heading)?

If I wanted to rebuild your file in calibre (with modifications, say, adding double quotes) how would I rebuild it?

I don't know... I just unzip, modify with a text editor, and zip again. It seems Calibre is generating .css files for each chapter (maybe with the properties you modified), but I don't see what could be confusing DE.

brewt
01-16-2009, 05:03 PM
Clumsy of me:

The Sony pic is of your original epub. - Chapter 28.jpg
We've so far seen Sony and DE to render the drop caps similarly, and yes, DE did your original epub correctly, too.

The epub I attached was a straight re-render of the epub through calibre - I didn't change anything. Loaded it in, asked it to rebuild the epub.

The DE picture is of the re-rendered epub - the Sony viewer had the same problem on the re-rendered. - Chapter28-calibre-rendered.jpg

chapter28-calibre-viewer.jpg is of the calibre-re-rendered epub, in the calibre viewer.

Yes, calibre outputs 3 css's per html file. I've seen these css's exceed 1 meg in size, if I chose really aweful rtf files to start with.

I spent most of the morning trying to replicate your solution, and found that I couldn't get it to work by rendering in calibre.

-bjc

Jellby
01-17-2009, 10:01 AM
Well, I bit the bullet and installed Digital Editions in a Windows computer, I have to transfer the files between computers for testing, though.

I noticed that DE does not seem to support "position: relative" which means the "predrop" class (Ch. XXX, XXXIII) was not working properly. I change the code into something that seems to work. I also noticed I had the width and height of the cover image mixed up.

span.predrop {
font-size: 25%;
font-weight: normal;
vertical-align: top;
line-height: 1.9;
/*position: relative;
top: 0.4em;*/ /*ADE does not support this*/
}

Other problems with DE are:

- It does not support "font-variant: small-caps", or at least the last sentence of the book is not rendered correctly.

- It breaks lines before an em-dash. This is incorrect in Spanish, where em-dashes are used very much like parentheses. Think of a linebreak just before a closing parenthesis.

llasram
01-17-2009, 10:27 AM
Well, I bit the bullet and installed Digital Editions in a Windows computer, I have to transfer the files between computers for testing, though.

Did running ADE under Wine not work for you?

- It does not support "font-variant: small-caps", or at least the last sentence of the book is not rendered correctly.

Indeed :-/.

- It breaks lines before an em-dash. This is incorrect in Spanish, where em-dashes are used very much like parentheses. Think of a linebreak just before a closing parenthesis.

Yah, it appears to consider before and after any em dash fair game for a break, even places where breaks would be inappropriate in English as well. I tried solving this by using the Unicode "Word Joiner" character, but ADE doesn't recognize it. Much less ideally, but actually working across multiple renderers, I wrapped non-breaking bits in <span/>s with "white-space: nowrap" set. Thus CSS:

.nobreak {
white-space: nowrap;
}

And markup:

<p><span class="nobreak">—These</span> em dashes are like <span class="nobreak">parentheses!—</span></p>

Jellby
01-17-2009, 10:42 AM
Did running ADE under Wine not work for you?

I have an oldish linux in this computer, and it's already a bit crammed. My last experiences with Wine here were rather disappointing (like all text disappearing, it was impossible what the menus and buttons were for), so I decided it was better to install it somewhere else.

<p><span class="nobreak">—These</span> em dashes are like <span class="nobreak">parentheses!—</span></p>

Oh, my! I refuse to add that sort of markup to my books. It gets even more confusing if you have:

<p>—These em dashes are <em>like parentheses</em>!—</p>

Since <em> and <span> have to be properly nested, you'd have to close and reopen the <em>.

EDIT: Another thing DE seems to do is ignore the "linear=no" spine property...

llasram
01-17-2009, 11:01 AM
I have an oldish linux in this computer, and it's already a bit crammed. My last experiences with Wine here were rather disappointing (like all text disappearing, it was impossible what the menus and buttons were for), so I decided it was better to install it somewhere else.

Ah, fair enough. If/when you have GNU/Linux running on a more newish computer, ADE under Wine 1.0.1 runs 100% perfectly, with no glitches whatsoever.

Oh, my! I refuse to add that sort of markup to my books. It gets even more confusing if you have:

<p>—These em dashes are <em>like parentheses</em>!—</p>

Since <em> and <span> have to be properly nested, you'd have to close and reopen the <em>.

Alas, yes :-/. You could use Word Joiner and programmatically transmute so-joined text into the admittedly unfortunate markup.

EDIT: Another thing DE seems to do is ignore the "linear=no" spine property...

To be fair though, the OPF spec does say that reader systems may ignore the distinction between primary (linear="yes") and auxiliary (linear="no") content.

Jellby
01-17-2009, 11:48 AM
To be fair though, the OPF spec does say that reader systems may ignore the distinction between primary (linear="yes") and auxiliary (linear="no") content.

Yes, that's true, I just expected it to do something else...

Well, enough of talking about DE's shortcomings, this thread was about the drop caps, and I think the issue is solved for the moment, I'll be updating my epub files during the weekend.

brewt
01-17-2009, 02:00 PM
Attached is a re-render of your message 54 epub out of calibre, with a screen shot in ADE of chapter 1 of the re-render, and a sreenshot of your original in ADE.

The header on your original xhtml looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>CapĂ*tulo I</title>
<link href="css/style.css" type="text/css" rel="stylesheet" />
</head>
<body>


When the xhtml comes out of calibre, the header looks like this:

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title>CapĂ*tulo I</title>
<link href="resources/style_3_9.css" type="text/css" rel="stylesheet"/>
<link href="resources/Capitulo-01_0.css" type="text/css" charset="UTF-8" rel="stylesheet"/>
<link href="resources/Capitulo-01_1.css" type="text/css" charset="UTF-8" rel="stylesheet"/>
<link href="resources/Capitulo-01_2.css" type="text/css" charset="UTF-8" rel="stylesheet"/>
</head>
<body>


Could the lack of doctype in the re-render have anything to do with why it looks different? Or maybe the change to a content type?


-bjc
Charter Member, Deceased Equine Abuse Society.

brewt
01-18-2009, 04:34 PM
I WILL FINALLY DECLARE IT TO BE GOOD.

Mr Goyal pointed out a calibre-built solution in the settings for epub - set the Create Epub/Page Setup/Base Font Size to 0pt, and the llasram/Jellby/Peter solution works coming out of Calibre, too.

http://www.mobileread.com/forums/showthread.php?t=36688

-bjc

:rofl:

NicWest
11-27-2010, 08:31 PM
bit of a necro post, but I find this works well for ADE-kindle on 100% text:

.drop {
overflow: hidden;
line-height: 89%;
height: 0.75em;
font-size: 281%;
margin-right: 0.075em;
float:left;
}

example/images on this blog post: http://stunjelly.com/e-books-drop-caps/

The overflow hidden gets rid of the need for the negative margins that kindle gets so upset by

Alkinea
08-30-2012, 05:18 PM
Here are two pictures showing what my converter does for dropcaps:
http://soft.alkinea.net/kindle.jpg
or, with a different style:
http://soft.alkinea.net/nook.jpg
You can download it here:
http://soft.alkinea.net
Enjoy!

brewt
09-04-2012, 05:44 PM
You can download it here:
http://soft.alkinea.net
Enjoy![/QUOTE]

Not bad, not bad, doesn't seem to like Word-generated .odt files, and it doesn't seem to like mid-sentence italics, but that may still be a Word issue.
Doesn't seem to think too much of the fonts I use for embedding, but that still may be traceable back to Word.
-Brewt

Alkinea
09-07-2012, 01:46 AM
There were a few issues with drop-caps that have been fixed in 2.1
Try with the new version.
I'll do more tests with Word files imported in LibreOffice and I'll make sure it works.