DROP CAPS IN KINDLE

Making an ebook work like a "real " book is the challenge we face every day in Kindle World.

Take drop caps.

It's often said, the closest we can come to a drop cap in Kindle is something one might more accurately call a LIFT cap: an enlarged initial letter that sticks above the first line of a chapter-starting paragraph.

But actual, book-like drop caps ARE of course available in Kindle Fire and Paperwhite, because they both use the kf8 version of Kindle, which pays attention to “float” and “padding” commands.

But what about the classic Kindle and the DX, both of which use the older mobi version of code? (As do the iOS apps.) How can you benefit from drop caps in Fire and not leave the poor relations out in the cold?

Here's a trick you can use.

Add code to the style section of your HTML file that divides the action between Fire mode (kf8) and the Kindle "classic" (mobi):

   @media amzn-kf8
   {span.dropcaps
      {font-weight:bold;
      font-size:338%;
      float:left;
      padding-right:0.1em;
      margin-top:-0.35em;
      margin-bottom:-0.35em;}
   }

  @media amzn-mobi
   {span.dropcaps
      {font-size:2em;
      font-weight:bold;}
   }

Getting the big letter to play nicely with the body of the paragraph will take some fiddling with the padding and margin specs. (And, as always, these big letters will look better in some font sizes than others. Nothing you can do about that.) It will probably turn out you need different specs for different letters. You can call out those differences by creating a separate span name and applying it to the appropriate paragraph in your book. Some letters may share specs, and can be clumped up in one listing in the style section, with the names separated by commas (.dropcap_a, .dropcap_e, etc.), below which you need only give the changed spec. You are unlikely to need every letter in the alphabet for a given book.

The code deploys like this:

   <p><b><span class="dropcaps">T</span>his particular morning</b>, ten-year-old Trevor Blake [etc].</p>
 
In the screen shots I've got four parallel paragraph starts. The first uses italics and bold to highlight the first few words. The big initial is based on <big><big>...</big></big>.

The second is the drop cap, the mobi set at 2 em, in bold italics.

The third uses <big><big><big>...</big></big></big>, highlighting in bold and roman type.

The fourth uses the dropcap code, in roman; again: 2 em font-size.

First up, Kindle Fire, font size 1:


Paperwhite looks pretty much the same.

Now here's a look at original Kindle in font size 6 (the largest reasonable-looking font for this device).

This shot just reveals paragraphs three and four. At the top, the result of three <big> tags. Below that, a 2 em capital from the "dropcaps" span for mobi. As you can see, the 2 em capital appears identical to what you get with three levels of <big> tags.

By the way, going above 2 em in the mobi font size gets you nowhere. Kindle, DX, and iOS all ignore larger fonts. According to Kindle Previewer, anyway.

Which brings up something that makes me nervous. I adapted my code for drop caps from the Amazon Kindle Publishing Guidelines, the official source of often difficult to understand and potentially misleading information.

In their version of the code, they use "3 em" for the alternate mobi font-size. Does that mean they don't know 3 em is no bigger than 2 em? Or does it turn out 3 em actually IS bigger than 2 em—in a REAL Kindle?

The last case would be bad for me—and by extension, you—because I'm basing all my conclusions on the ability of Kindle Previewer to give me an accurate picture of what happens in the various machines.

I believe that when it comes to using the <big> code, two levels are optimum. It's large enough to be noticed in all versions and at every reasonable font size. Four or five <big> tags WILL get you a bigger first letter, but there's a tendency for the line spacing to get out of whack. The gap between line one and line two expands noticeably as you add more <big> tags. Spacing between lines two and three, and so forth, appears unaffected.

As a consequence, before I got to messing about with actual drop caps, I might have suggested you use two <big> tags in the HTML code of each and every book you present to Kindle Direct Publishing.

Now we see the split-code technique gives one the equivalent of three <big> tags for mobi files, plus actual drop caps where available.

So here's the question: Should you use THIS code for everything?

Not necessarily.

I simply don't think drop caps are called for in most books. They seem old fashioned, a remnant of an earlier time. I can see them used for high fantasy novels, for children's fiction, for classic literature, perhaps, but not for most other fiction.

And probably not for non-fiction at all.

And there’s another problem: If your opening paragraph is only a word or two long, you have no proper place to put the “pocket” for the drop cap. The next paragraph sort of nestles right in there, hugging the bottom of the big first letter of the previous paragraph. Might be, the reader could miss the fact a new paragraph just started. It's an issue I think you need to consider.

In general, for these exotic creatures to look at home, every chapter-opening paragraph in your book would have to run at least two an a half lines long in the smallest possible font.

Is it worth it to rewrite your book just so you can use a feature that only shows up in some versions of Kindle? Up to you.

They do look pretty cool, though . . .

I think the take-home message here is that you can write code that operates differently depending on which version of Kindle the code finds itself running on. You may be able to use the kf8/mobi split-code method to resolve other compromises in the never-ending quest to make your ebooks look as good as they can.

Actually, further tests revealed you don't need to split the code to get mobi apps to go to 2 em. They go there all by themselves, in an effort to make it all the way to 320%. The rest of the code is foreign to them and they ignore it. But that doesn't mean you should forget about splitting the code. There are a lot of other compromises to address.