formatting an ebook

This post may end up being more of a rant than normal. My apologies in advance.

Formatting an ebook is one of the most enjoyable yet simultaneously one of the most frustrating experiences. I love the feedback I get from happy authors who are pleased with the final result. At the same time, there are so many small details that must be addressed, in search of the “perfect” ebook format. I’ve outlined them below, according to outlet.

Formatting an ebook for iTunes/Apple:

Doesn’t play well with others. Exports from Pages look BEAUTIFUL on iPad and iPhone but look like total crap on any other device. Hello?! Apple does not build apps that work well on other platforms…period. Yes, you can export from Pages to ePub…but if you want to work with any other outlet besides iTunes, you will need to do extensive “under the hood” coding.

Embedded fonts: yes, possible with the addition of an extra file that indicates that embedded fonts are to be used (if you’re declaring fonts in your CSS and then calling them within the CSS, why in the world should an extra file be required??). This file is the same one as is used for fixed format layouts. Now, if you want to specify fonts that the iPad has pre-installed, you have to get REALLY creative. Specifying fonts will not work within paragraph or span classes. If you want to be specific about the font, you need to use a samp tag.

Dumb use of hyphenation – which a reader can turn on/off universally in the Settings section, OR a smart coder can tweak in the code (I addressed this here:

iBooks Author – again, doesn’t play well with others. Leave it up to Apple to design something that’s intuitive and design-conscious, but only available on its own platform, for its own devices…and then they write that into the software terms of use to tie you up legally to Apple products.

Will pull your products from the iBookstore if you advertise that your other books are available anywhere else but iTunes – even if it’s just for sales on your own website.

I am sure there’s more….but I can’t wait to get to my next victim: Nook.

Formatting for Nook

Nook runs on an Adobe Digital Editions, which has become an antiquated pile of junk. Feel free to disagree with me, many people actually like it. My main frustration with Nook and ADE is that it shows images at their actual size. This doesn’t sound like a problem, until you think about all the screen sizes that are now available, with additional screen sizes in development…and who knows what size they’ll be. In the past, it was possible to set max image width at 520 px and height at 660 px and be fairly confident that it would look nice on the screen. Now, the outlets are requesting insanely large image sizes (think “retina display”) AND the screens themselves are larger, PLUS people are still reading books on their desktops and laptops. How do you maximize for that? Other outlets have set a default max-height and max-width to 100%, so you just plop an image in there and they’ll resize so the image fits the screen without going over. BUT NOOK keeps the image size the same, regardless of screen size (and you can’t use standard CSS to specify a max height or max width). That’s just dumb. Now, if you have a “large” image size, you have to specify either width=”100%” or height=”100%”.

Having an image size default to max height and max width at 100% would be an awesome tweak, Nook and ADE. Get with the program.

Children’s books are a bear on the Nook. They have a really cool children’s book proprietary format, including their “read aloud” feature, but as of right now, only the big publishers are able to use it. If you’re using PubIt to deliver ebooks to Nook, you are not allowed to use their special children’s book format. Add insult to injury: Nook doesn’t have any specs for children’s books besides their proprietary format…which they’re not sharing. This is a huge issue – it requires hours & hours of development time to figure out exactly how the book is showing up on an actual device. And even then, it doesn’t look nearly as cool as the ones big publishers are able to make. Fair? Heck, NO!

Formatting mobi for Amazon/Kindle

Kindle Previewer just released a new version. Oh, please, Kindle, won’t you be consistent?! I love you lots, but you could be so much easier. Ok, so here’s the deal: Kindle Fire (original and HD) is the BEST Kindle format that has been released, bar none. Kindle Paperwhite is a close second. These 2 formats are as close to ePub as you can get. Enter iOS – and a very different format emerges. In other words, what you see on Kindle Previewer for Kindle Fire is VERY different from what you’ll see on Kindle for iPad/iPhone. And hugely different from the original Kindle format. Significantly different from Look Inside on Amazon’s website (which doesn’t look like ANY other format). My problem with this is – how do you code for that? If it’s possible to code bells & whistles on Kindle Fire, but the file bombs on iPad, then you have to go back to something that’s simple enough to work on iPad too. You effectively lose any advantage that Kindle Fire offers because you have to use the least common denominator. AND if Look Inside looks like crap, who’s going to want to read the book anyway?

AMAZON, major issue here. If you’re going to let people purchase Kindle Fire books, they need to AT LEAST be compatible with the devices that you’ve said are Kindle Fire compatible. They should look the same on Kindle Fire vs. iOS vs. Look Inside vs. Paperwhite. Consistency is key.

Things that don’t work well on ANY device:

Drop caps. Kindle doesn’t handle line spacing well for drop caps at all. iPad and iPhone display them differently, even though it’s the same coding. I’ve dropped this from all my ebooks. Love it in print, not a fan for digital.

Large quote marks. This is a fun typographical tool, but it looks silly on ereaders. The line heights adjust according to the large quote sizes, making line height inconsistent. Not recommended.

Bottom Line

Amazon, Barnes & Noble, and Apple need to make the customer experience their first priority and make beating out their competitors a secondary goal. Having inconsistent formatting – even within one’s own set of devices – makes everyone look bad, from the ebook developer, to the author, to the sales outlet itself. The outlets would sell more books and have happier customers if they would pay better attention to the basics: a consistent, predictable reader experience.

The one good thing: many of these issues are new. Just like the weather in Oklahoma, if you don’t like it, just wait 15 minutes and it will change. I have full confidence that the issues we see today will be different from the issues that we see in 6 months.

So what about you? Are you seeing inconsistent formatting in ebooks…or even your own books? Frustrated yet? I feel your pain and would love to help you get the very best looking ebook possible – just let me know if I can help.

Tagged on:             

4 thoughts on “The Holy Grail: Formatting an Ebook That Works for Everyone

  • January 2, 2013 at 11:58 am

    ADE has gotten a lot better over the past year. Unfortunately, Nook hasn’t, particularly on iOS and OS X. It is still a broken mess that is far, far buggier than the actual ADE in OS X. If you’re looking for an ADE-based reader in OS X, your best bet is ADE. If you’re looking for an iOS reader, the most spec-compliant ADE-based reader I’ve found by *far* is NeoSoar. In fact, that’s the *only* ADE-based reader that renders my drop caps correctly on iOS.

    For drop caps on Kindle, I recommend specifying separate styles for @media mobi and @media kf8. Use a nice drop cap style for the KF8 slice and just use a larger letter size on the mobi side. This gives you generally good drop caps on devices that support KF8, while rendering an acceptable substitute on iOS and other non-KF8-capable readers that bizarrely support HTML and CSS to differing degrees, depending on the reader. (Unfortunately, this makes iOS Kindle a real nightmare for publishers, and it will remain so until they release a KF8-capable Kindle for iOS.)

    With that said, even in KF8-land, Kindle can’t seem to get basic CSS support right. The theoretically KF8-capable Paperwhite (at least in the previewer) displays drop caps wrong (too low). I’m pretty sure I already filed a bug report. Hopefully they’ll fix it in the not-too-distant future.

    The line height problem for large quote marks is a flaw in your content and/or fonts. It should be avoidable by using large-quote fonts with the same intrinsic height (ascender, descender, and line gap) as your main font even if those glyphs actually fall outside the specified dimensions. Alternatively, if you’re doing larger quote marks by using a larger font size for those glyphs, set line-height to a smaller value. (Note: if you’re doing content for Kindle, the minimum line height, whether intrinsic or explicitly specified, is 1.2. This can cause unexpected surprises, particularly when dealing with drop cap alignment….)

  • January 2, 2013 at 1:13 pm

    Correction: That should be @media amzn-mobi and @media amzn-kf8.

  • March 6, 2013 at 11:58 am

    Love this article – it confirms how I feel about so many of these platforms!! I often have clients viewing books on Kindle’s iPad app – and then I have to go back and make adjustments based on what they’re seeing there – when it looks so good already on the other platforms! As you said, it’s so frustrating having to build for the lowest common denominator – which go figure that would be iPad when it comes to Kindle. They just can’t stand each other, can they? Looking forward to the day when customers will come first, everyone will play nice, and things will be more consistent across the board!!

  • July 10, 2014 at 8:11 am

    Hi there….For the dropcaps problems I have a solution for Kindle.

    For starters, on Kindle, you have dropcaps capability on KF8 but not on the old mobi Kindles because old mobi ignores the ‘float-left’ HTML text attribute. So dropcaps are just not possible in old mobi format. So use upcaps(Big and Bold) instead.

    Here’s the media query in HTMLcode:

    /* use dropcaps for kf8*/

    @media amzn-kf8 {
    span.dropcaps {
    margin-bottom:-0.5em; }
    /*use upcaps for old mobi*/
    @media amzn-mobi {
    span.dropcaps {
    font-size: 150%;
    font-weight: bold; }

    Just copy the above code directly and put it inside the section of the HTML code at the top of every epub chapter. Or you could implement this code only once if you do it before you split the chapters up in epub on Sigil. Do not insert this code into the CSS style sheet — it will be ignored.

    Implementation of the above HTML media query code, in plain English, simply means this:

    If the system is KF8 then use proper dropcaps, otherwise if it’s old mobi then use upcaps(big and bold) instead.

    Then implement dropcaps/upcaps in each first para chapter code like this:

    Hovering effortlessy….

    You could also add smallcaps after the dropcap/upcap to make the above result look even more elegant. But don’t use HTML small-caps(wont work in old mobi) — use the ‘font-size’ attribute within the CSS instead. Capitalize manually and make the size of words in the smallcaps about the height of a lowercase ‘h’ or ‘t’ and implement this directly after the dropcap or ‘upcap’.

    /* Put in CSS*/
    scan.small_caps {
    font-size: 0.8333em;
    Implement small_caps in your code like this:

    Hovering effortlessy, the Serpent Eagle….

    I’ve also found that actually using the smallcaps attribute on KF8 is too small. And the way that I’ve done it above — this will also work for old mobi devices as well.

    I’ve tested the above code on both old mobi and KF8 and found no problems with it. You may also have to fiddle with the values to get what you personally like and want though.

Leave a Reply

Your email address will not be published. Required fields are marked *

Current ye@r *