Formula for calculating drop caps

[Doitsu]

I've found many drop caps examples on the Internet, but none of the authors explained how they arrived at the values that they used and often the examples only worked with the fonts that they used in their examples.

IMHO, there must be a way to calculate the perfect values for font size, padding, margins etc. for any given font if the cap and line heights are known.

[pdurrant]

When rendering ebooks, the line height is variable, as is the font. So it's only possible for the rendering engine to get drop caps right, and the ePub spec doesn't have any way to specify the information needed for an ePub rendering engine to know that drop caps are intended.

I believe that KFX has some explicit drop cap coding, which is why Amazon can get drop caps right in KFX.

But also bear in mind that some caps have descenders (e.g. Q) which makes doing generic drop caps even more tricky.

[RbnJrg]

Originally Posted by Doitsu

I've found many drop caps examples on the Internet, but none of the authors explained how they arrived at the values that they used and often the examples only worked with the fonts that they used in their examples.

IMHO, there must be a way to calculate the perfect values for font size, padding, margins etc. for any given font if the cap and line heights are known.

Hi Doitsu;

There is no such formula. Why? Because you not only have to deal with font-family and css but also with different rendering engine. It's known that -for example- ADE displays the things in a different way than WebKit. And you can't control that because a formula for ADE won't work for WebKit.

Your best bet is to float a square/rectangle and enclose the letter inside it. Sometime ago I posted about that:

https://www.mobileread.com/forums/sh...1&postcount=31

https://www.mobileread.com/forums/sh...2&postcount=55

https://www.mobileread.com/forums/sh...0&postcount=17

In the first link, I deal with the "tricky" Q to show that the method is the same no matter the letter.

Regards
Rubén

[Hitch]

Originally Posted by Doitsu

I've found many drop caps examples on the Internet, but none of the authors explained how they arrived at the values that they used and often the examples only worked with the fonts that they used in their examples.

IMHO, there must be a way to calculate the perfect values for font size, padding, margins etc. for any given font if the cap and line heights are known.

In my humble opinion, Doits, it's not possible. I wish to hell it were. We've done I-don't-know-how-many books with dropcaps, both print and eBook, and there's simply not one-size-fits all. The base font, the leading (line-height), the dropcap font, all cause variables.

We've spent a small fortune developing "perfect" dropcap coding for given fonts--and each and every one is custom-coded, for the base font in a given size parameter against the dropcap font. EVERY single one, each letter has its own coding. Not the entire alphabet, each letter. It's a lotta, lotta work.

Not to mention, ever try to determine the x-height of a font? Or find a font with a "tall x-height?" Easier said than done, brother. Font metrics are a whole other rant of mine...lol

Hitch

[Doitsu]

Originally Posted by RbnJrg

Your best bet is to float a square/rectangle and enclose the letter inside it. Sometime ago I posted about that:

Thanks for the links! I'll check them out.

Originally Posted by Hitch

Not to mention, ever try to determine the x-height of a font?

That's actually relatively easy.
What I've still haven't figured out is how to optimize drop caps css rules for specific fonts based on these values.

[Hitch]

Originally Posted by Doitsu

Thanks for the links! I'll check them out.


That's actually relatively easy.
What I've still haven't figured out is how to optimize drop caps css rules for specific fonts based on these values.

When shopping for them? I find it annoying as hell. I had this one client, insisted that we had to use this font that I knew was going to be disastrous in MOBI. She INSISTED that her text had to have a tall "x-height" (because she read some "design" article someplace, telling her that that was the key to readability, of course...), and I was trying to find one that would suit her and work in MOBI. I tried to shop by winnowing, right? Yeah, as Scooby-Doo would have said, rots o'ruck.

Without going through gyrations, I tend to use Typograf to get fast/easy font metrics, but for example, do any of my other FIVE font managers have that info? Nooooooo, and try to explain to the font manager softare companies WHY it matters, having comparable metrics for fonts. Try to explain what happens if you put a small font in the same line, as a tall font, and it's viewed in MOBI 7, without embedded fonts. It's like the whole "eyes glazed over" thing.

/grump.

Hitch

[RbnJrg]

Originally Posted by Doitsu

What I've still haven't figured out is how to optimize drop caps css rules for specific fonts based on these values.

You can't. I tried and I couldn't. Once you have optimized the css code for ADE, it won't work for Webkit or Readium or whatever. Do the try. Sigil uses Webkit. Try finding a css code that shows perfectly the dropcap in Sigil (let's suppose that you found a formula for doing that in Sigil with any kind of font-family). Open that epub in ADE and the dropcap won't display of the same way. And you can't control that because you don't know what engine will use the ereader to display the epub.

But regarding to float a square, you can get practically the same output under ADE, WebKit, Readium, etc. Of that way the problem is reduced about how to center horizontal and vertically the letter inside that square.

[Doitsu]

Originally Posted by Hitch

In my humble opinion, Doits, it's not possible. I wish to hell it were. We've done I-don't-know-how-many books with dropcaps, both print and eBook, and there's simply not one-size-fits all.

There's a new initial-letter CSS rule that'll make creating drop caps much easier.

For example:

Spoiler:

h1 + p::first-letter {
  -webkit-initial-letter: 2;
  initial-letter: 2;
  margin-right: 0.2em;
  color: red;
}

However, I've found only one app that actually supports this new rule: iBooks.

EDIT: Gitden Reader also supports initial-letter, but not ADEPT DRM.

[Hitch]

Originally Posted by Doitsu

There's a new initial-letter CSS rule that'll make creating drop caps much easier.

For example:

Spoiler:

h1 + p::first-letter {
  -webkit-initial-letter: 2;
  initial-letter: 2;
  margin-right: 0.2em;
  color: red;
}

However, I've found only one app that actually supports this new rule: iBooks.

EDIT: Gitden Reader also supports initial-letter, but not ADEPT DRM.

You're basically doing a boxed letter, there, Doits, aren't you? Can you show me a different letter that isn't boxed?

Hitch

[DNSB]

Originally Posted by Doitsu

There's a new initial-letter CSS rule that'll make creating drop caps much easier.

For example:

Spoiler:

h1 + p::first-letter {
  -webkit-initial-letter: 2;
  initial-letter: 2;
  margin-right: 0.2em;
  color: red;
}

One minor nit is that if you have any text between the h1 header and the paragraph where you want the drop cap, it will receive the drop cap instead.

<h1 class="whatever">Prologue</h1>
<p class="dateline">London, Sept. 17, 1940</p>
<p>As the air raid sirens screamed, Martin headed down the stairs to the cellar.</p>

[Doitsu]

Originally Posted by Hitch

Can you show me a different letter that isn't boxed?

I haven't got the faintest idea how to do this, I merely adapted the website code for epub3 books. (I won't use drop caps CSS, until initial-letter becomes widely adopted.)

Originally Posted by DNSB

One minor nit is that if you have any text between the h1 header and the paragraph where you want the drop cap, it will receive the drop cap instead.

I didn't mention this issue, because I assumed that it'd be obvious to ebook designers familiar with pseudo selectors.

[jhowell]

Originally Posted by Doitsu

There's a new initial-letter CSS rule that'll make creating drop caps much easier.

Amazon's Enhanced Typesetting does drop caps in a similar way to initial-letter. During conversion to KFX format if the book is coded in a way that appears to be trying to produce a drop cap then kfxgen removes the original drop cap coding and replaces it with:

dropcap_chars: 1,
dropcap_lines: 3,

Where dropcap_chars indicates how many initial characters of the paragraph should be drop caps and dropcap_lines indicates how many lines high to make it. The drop cap automatically adjusts to the font, font size, line height, etc.

(Do you have any idea whether initial-letter is on a track to being standardized? The article that you linked is over three years old.)

[Doitsu]

Originally Posted by jhowell

Amazon's Enhanced Typesetting does drop caps in a similar way to initial-letter. During conversion to KFX format if the book is coded in a way that appears to be trying to produce a drop cap.

Do you happen to know what CSS rule(s) will trigger drop cap processing?

Originally Posted by jhowell

(Do you have any idea whether initial-letter is on a track to being standardized? The article that you linked is over three years old.)

AFAIK, it's only supported by Safari.

[Turtle91]

Originally Posted by DNSB

One minor nit is that if you have any text between the h1 header and the paragraph where you want the drop cap, it will receive the drop cap instead.

<h1 class="whatever">Prologue</h1>
<p class="dateline">London, Sept. 17, 1940</p>
<p>As the air raid sirens screamed, Martin headed down the stairs to the cellar.</p>

I think that was just the example he used. You dont have to use h1 + p as the selector you could use any selector. eg:

p.first::first-letter {...}

<h1>Chapter Title</h1>
<p class="dateline">London, Sept. 17, 1940</p>
<p class="first">First paragraph, or any paragraph that you want the drop-cap</p>

[PoP]

Originally Posted by Doitsu

...
AFAIK, it's only supported by Safari.

And seemingly not even on Safari 5.1.7, the outdated last version for Windows.