Fun With Ebook Formatting: First Lines

One of the easiest ways to make your ebook stand out is to use first line treatments. By making the first lines of chapters or scenes after a break look different from the rest of the text you add visual interest to the “page” and (more importantly) you lessen the risk of confusing readers.

Text in an ebook “flows” to fit the screen. Plus, users can adjust the size of the display. If you use an empty line, for instance, to indicate a scene break–with no other visual clues–the page could break at the break and your readers could end up deeply confused about a point-of-view, time or setting jump.

Besides, first line treatments are fun. Here are a few screenshots off Lucy the Paperwhite Kindle.

first2Ever since I acquired a Fire tablet, I’ve been playing with colored images (I’ll try to get screenshots off a tablet–you’ll know I succeeded if color images show up here.)

Screenshot_2013-04-01-15-00-51 (2)

first1

(Did I actually write “expecially” in the sample? Crap...)

Screenshot_2013-04-01-15-02-14

Another trick is one I don’t care for myself, but a lot of people do like it. With ereader devices improving their displays, the drop cap looks better, too. (much thanks to William for this screenshot) Notice he used an embedded font for the heading and the drop cap. Embedding fonts is tricky not because the coding is difficult, but because fonts are creative property and there are/can be restrictions on their use. Always make sure you read the license agreements and follow the terms of use.

first3

Most of these first line treatments were created with paragraph styles that can be emulated in Word or Scrivener. (Not that I advocate using either program to format ebooks, but let’s get real, many of you do.) If you want to play with first line treatments, be sure you create a style sheet rather than using tabs, spaces or centering.

Realize, too, that different readers handle html coding in different ways. Not every device will display small caps, for instance. My oldest Kindle is flaky about displaying bolded fonts. You need to experiment and make adjustments.

A few tips:

  • Be very careful with first line treatments if you are using Scrivener or Word. Changing font sizes to make small caps can trigger bugs in eink Kindles and play havoc with the user’s ability to change display sizes.
  • Also, be careful when using Word to submit to Smashwords. If you are using a no-indent style, make sure to use a style-sheet instead of backspacing to delete the indent.
  • Experiment with your image sizes. Percentages work better than pixels.
  • Don’t be afraid of color. More and more readers are using devices with color displays and that can make your ebook look fabulous! Check how your graphics look in black-and-white to be sure there is enough contrast in grayscale so the image looks good on an eink device.
  • You can learn how to do these tricks in html by going to w3schools.com and searching for information on small caps, drop caps, embedding fonts and other goodies.

So what about you, readers? Any fun tricky-tricks you’d like to share?

Advertisements

22 thoughts on “Fun With Ebook Formatting: First Lines

  1. Hi Jaye:

    Nice ideas on the use of visual cues to set off opening paragraphs! One observation, though — it’s going to be difficult, if not impossible, to create a “display small caps for the first line” given that the user has control over font size, which will alter what constitutes the “first line” displayed.

    Also, using a graphic as the first letter may cause problems with software tools for the visually impaired. As I understand it, using the “alt” tag for the graphic, set to the letter it replaces, goes a long way to ensuring the book can be interpreted correctly.

    Jon

    • Jon,

      Jaye is correct. Even though it doesn’t seem to be documented, the Kindle devices that are KF8 compatible support the CSS pseudo-element selectors. Suppose the “p” tag for your first paragraph of each chapter has the CSS class of “start”. You can do this in your CSS:

      p.start:first-line
      {
      font-variant: small-caps;
      }

      [This assumes that the font you are using has small-caps variant forms or you have specified a small-caps font with @font-face. Also, you should have a @amzn-mobi media query to do something different in the old KF7 format.]

      • Thanks, William. Another good reminder to everybody. EXPERIMENT. What works one place doesn’t necessarily work in another. AND, sometimes they don’t tell you can do it, but if you try, you find that it works just fine.

        Having a convo right now with my partner about static text fixed at the bottom of the page. Kindle says it DOES NOT support it, but the tablet supports it fine. It’s dangerous though because the “page” can disappear altogether. Isn’t this fun?

  2. Ah ha! It’s a tricky trick using pseudo-elements, Jon. It makes the first line small caps no matter what size the display or whether the device is in landscape or portrait mode. Very cool.

    Good reminder about the graphics. Always, always make sure an alt= is in the source line.

    • Hi Jaye:

      Care to share that tricky trick’s details? While I doubt it would work on my Nook Tablet, it would be interesting to see what other e-reading software CAN interpret it correctly.

      Jon

      • Hi all:

        Just tried the pseudo class tricks. While they display correctly in Sigil, they do not work at all on the native (i.e., built-in) e-reader in the Nook Tablet.

        Now, my NT is a bit schizophrenic; part of it thinks its a Nook Tablet, and part of it thinks it can run Android software. I tried the same file on the Android software I have installed for e-reading: Nook for Android, Aldiko, and Bluefire (recommended by William). The Nook for Android software failed to even open the ePub! And, while Aldiko and Bluefire both opened it just fine, neither displayed the pseudo class changes.

        What does this suggest? To me, it seems that ePub files do not support pseudo classes. Some of this behavior can be simulated with classes applied to a “span”, but that first-line thing isn’t one of them.

        And now we know (unless I screwed it up on my end). “Failure is always an option!”

        Jon

      • Well, this is excellent information to know. It works on the Kindle just fine, but no go with the Nook OR Android. I just made a BIG note about that!

  3. William and Jon, here’s a puzzle for you guys to figure out:

    “The code for the stick to the bottom is:

    CSS
    .copy {position:fixed; overflow:visible; left:5px; bottom:5px; text-align:left;}

    HTML

    Text here.

    I don’t know if I made sense during lunch, but there’s a problem with it, though. When it runs through the Kindle Previewer, it says that “position:fixed” is not supported. It does show up on Kindle Fire and the computer versions. Kindle paperwhite and iPod/Pad don’t recognize it. Best case scenario, they just ignore it and the text goes to the top. Worst case, it ignores the entire page.

    The default position is “static,” “relative” is moving something in relation to other elements on the page, “absolute” cannot move from a specific place, “fixed” stays where you want it *on the screen* even when you scroll the page–which is why I can’t figure out why it’s not universal. It’s not related to the “page.”

    This is for making something like a copyright page. Text on the bottom. Interesting, no?

    • I don’t think there is any way to make position:fixed work in a reasonable way because people change the font size so drastically. However, you may have a test case for a technique that my oldest son and I invented when he came over for Easter dinner (yeah, that is what happens at my house). In the course of playing around with media queries, I discovered you could have media queries based on the width and height of the screen in EMs. My son suggested that you could use that to format your page differently depending on how large the user has set their base font size and keep stuff at the bottom of the page, but still on the page. It’s really hard to explain how it works, but I’ll send you a copy of a test file so you can see. On the E Ink devices, you have to have to navigate away from the page and come back to it to get the new sizes to take effect, but most people aren’t going to be changing the font on your front matter pages. On the Kindle Fires, the impact is immediate.

    • Hi Jaye:

      The only thing I can think of that might give you the look you desire here is to create the “fixed” portion of your text as a graphic, which may be possible to align to the “bottom” of the “page.” It would preclude anyone from resizing the text, but if it’s supposed to be some sort of legalese, anyhow, then keeping it small may work to your advantage!

      • I haven’t tried it myself, but have seen how it worked on my partner’s Kindle Fire. It worked beautifully even with display size changes and turning it from portrait to landscape. Basically, it means it works in KF8, but not in MOBI7. So media queries would be the key.

  4. Because Jaye really went above and beyond in helping me test this stuff, I have a special preview exclusively for the readers of her blog. The rest of the world will see this when I post over on the DBW Expert’s blog, but you folks get the sneak peek.

    Here’s another reason not to be afraid of color. Most people have avoided using color in their Kindle ebooks because there is simply no way to tell if someone is reading your book on a color-capable device or an E Ink device. At least, there wasn’t until I got obsessed with the problem. I know a lot of writers won’t ever care about something like this, but the folks who do care, really need this.

    So, if you ever wanted to show color graphics on the Kindle Fire tablets and greyscale-optimized graphics on the E Ink Kindles, I have the solution for you. First, I strongly suggest you get someone who understands how to use color to help you pick out the right graphics (spoiler alert: that’s not me, I still have to use Garanimal tags to get dressed in the morning). Also, if you are not comfortable hand-editing your HTML and CSS, you will want to get some professional help. Hint: Jaye does great ebook formatting.

    Here’s an example even I understand. Let’s suppose you have charts and graphs in your book (probably not a romance novel, but still). For color devices, you really want to draw the lines on your graphs in different colors, but that will be awful for the E Ink devices. For those you will want to use different style lines (dotted lines, dashed lines, etc.). In the past, you would probably settle for using the B&W graphs for your book. Not any more. You’ve got your color and black and white graphs all set. How do you create your ebook?

    In your html, you will put an img tag for the B&W version and give it a CSS class called “greyscale”. Immediately after that img tag, you put in another img tag for the color version, but this one has a class called “colour” (see, we’re going to be all hoity-toity Englishified with our tags).

    Now that that’s done, you create your CSS stylesheet. All the stuff that’s the same for old Mobi, KF8 color, and KF8 E Ink goes first. Then you put the KF8 specific stuff in the amzn-kf8 media query. Inside that media query, you have this:
    img.greyscale
    {display:none;}

    That completely removes the greyscale images from the layout for KF8. So, how do you get them back (and hide the color images) on the E Ink Kindles? You add another media query that looks like this:

    @media (device-aspect-ratio: 800/600) , (device-aspect-ratio: 600/800), (device-aspect-ratio: 758/1024) , (device-aspect-ratio: 1024/758)
    {
    img.greyscale
    {display:visible;}
    img.color
    {display:hidden;}
    }

    That media query says if the device this book is displayed on has an aspect ratio of 800×600, 600×800, 758×1024, or 1024×758, use the greyscale images. Otherwise, the color ones will be displayed. Why those particular ratios? Because those match the E Ink Kindles (all of which except the Paperwhite are 800×600, but you have to cover landscape mode too). And none of the Kindle Fires will match those aspect ratios.

    One more media query. Now, you need an amzn-mobi media query that includes the same CSS styles for the img tags as the E Ink media query. Plus whatever else you need to make the old format work.

    There you go. Now you know something that no one else in the world knew a week ago. There are a few tweaks to this to ensure that someone reading on the Kindle App on a PC, Mac, or Android devices gets the color images, but I’ll leave that for the real article.

  5. Oh my, I think I’ve earned my diploma out of kindergarten. I actually understand that! Now I’m going to have to try it. Thanks, William!

  6. Here’s our CSS for Drop caps Jaye (Kindle only). It’s a two-line drop that seems to work well:

    For KF8:
    @media amzn-kf8{
    span.dropcap, span.dropcapi
    {
    font-size: 300%;
    font-weight: bold;
    height: 1em;
    float: left;
    margin: -0.25em 0.1em 0 0.1em;
    }

    span.dropcapi
    {
    font-style: italic;
    }
    } /* END KF8-only styles */
    For old e-inkers/Kindle for iOS:

    @media amzn-mobi{
    span.dropcap, span.dropcapi
    {
    font-size: 1.5em;
    font-weight: bold;
    }

    span.dropcapi
    {
    font-style: italic;
    }
    } /* END MOBI-only styles */

  7. Thank you, Paul. Very useful. I’ve been trying to fool the Kindle into treating an ornament like a drop cap. So far, the machine is winning. 😀

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s