CSS / dropcaps

[theducks]

Originally Posted by Oldpilot

Oh, I couldn't agree more! Drop-caps remind me of medieval monks illuminating their manuscripts, and I have a happy feeling that I am settling into a soft chair by an open fire and sharing ideas with someone who cared how his (well, all the monks were male!) books actually looked.

You may have noticed, on the KDP forum this morning, that the KF8 update for the Kindle K3 keyboard reader seems to render drop-caps four lines deep, though the cap itself is scarcely three lines high, resulting in a rather silly effect whereby the cap sits to the left of lines 2 and 3 rather than at the top of the paragraph. Of course, this may have been only Punchy Gonzalez's CSS, but it confirms my decision to steer clear of drop-caps for the time being.

ADE will do that effect if you have the wrong Line-height called for your DC to main body font. It is a PITA to get it to look right, only to see some other reader SW render it totally different

[DiapDealer]

Originally Posted by Oldpilot

You may have noticed, on the KDP forum this morning, that the KF8 update for the Kindle K3 keyboard reader seems to render drop-caps four lines deep, though the cap itself is scarcely three lines high, resulting in a rather silly effect whereby the cap sits to the left of lines 2 and 3 rather than at the top of the paragraph. Of course, this may have been only Punchy Gonzalez's CSS, but it confirms my decision to steer clear of drop-caps for the time being.

It almost certainly was Punchy's Gonzalez's CSS.

Mainly because there is no difference in the way "drop-cap" code is rendered across the various devices that support KF8. In fact, the various renderers have no idea what drop-caps are.

The issue is line-height. And the default line-height is much larger on eInk devices that support KF8 when compared to the line-height on Kindle Fire devices. But there's absolutely no reason why the exact same drop-cap code would render any differently on a updated K3 than it would on a Kindle Touch. And users know (or are learning) that they can easily adjust the line-height when they come upon a KF8 book.

[Hitch]

Originally Posted by DiapDealer

I almost certainly was Punchy's Gonzalez's CSS.

Mainly because there is no difference in the way "drop-cap" code is rendered across the various devices that support KF8. In fact, the various renderers have no idea what drop-caps are.

The issue is line-height. And the default line-height is much larger on eInk devices that support KF8 when compared to the line-height on Kindle Fire devices. But there's absolutely no reason why the exact same drop-cap code would render any differently on a updated K3 than it would on a Kindle Touch. And users know (or are learning) that they can easily adjust the line-height when they come upon a KF8 book.

And, of course, line-height can be set. I saw Punchy's post. I'm debating on whether or not to reply, given that old Punch has now decided that he's a professional ebook-maker. Of course, I don't remember if his "go-to" tool, Jutoh, lets you set line-height in their quasi-CSS settings.

Hitch

[JSWolf]

Originally Posted by Hitch

And, of course, line-height can be set. I saw Punchy's post. I'm debating on whether or not to reply, given that old Punch has now decided that he's a professional ebook-maker. Of course, I don't remember if his "go-to" tool, Jutoh, lets you set line-height in their quasi-CSS settings.

Hitch

But, the KF8 code in the eink Kindles ignores Line-height and has a larger then standard line-height. So if you do a drop caps that looks good on an eink Kindle, it won't look good on a Kindle Fire.

[DiapDealer]

Originally Posted by JSWolf

But, the KF8 code in the eink Kindles ignores Line-height and has a larger then standard line-height.

No. The eInk Kindle reader does not ignore the line-height attribute... it just doesn't honor line-height values less than 1.2em or 120%. Nor does the Kindle Fire's reader, for that matter (section 3.1.7 of the Amazon Publishing Guidelines).

Yes, there is a fundamental discrepancy in the default, user-adjustable, line-spacing setting on eink Kindles compared to the Kindle Fire's reading app, but that doesn't have anything to do with the internal CSS line-height attribute specified in the ebook. It's an issue of scale. And it can be overcome by the user simply choosing a smaller line-spacing setting.