Kindle CSS Weirdness

Here are some Kindle CSS gotchas I’ve come across recently. I’ll update this post with more such oddities as (or if) I come across them.

  • text-align:center; fails if designated as !important, even if the left and right margins are set to zero.
  • text-indent:0; fails (ignored). It works if you specify the measurement: text-indent:0em;

These quirks are present in each of the reader programs I tried: Kindle Previewer, Kindle for PC, and Mobipocket Reader. This leads me to suspect that they are bugs in Kindlegen rather than in the Kindle reading software; I don’t know how Kindlegen works but my guess is that it contains a CSS translator that generates inline formatting, leading to possibilities of flawed HTML being generated if the translation code isn’t spot-on. If so, we can hope that these quirks will be fixed in a future Kindlegen release. In the meantime, the potential work-arounds/trade-offs are obvious — but note that Stanza on iPad requires !important in order to center body text; you might want to force body text centering on Kindle by using <div style="text-align:center;"><p class="MyCenteredClass">...</p></div> instead, in order to maximise the portability of your ePub.

ePub Validation, iTunes and Flightcrew

You might already be aware that iTunes modifies any ePub files that it transfers to a device, by adding its own metadata file (iTunesMetadata.plist) into the ePub container. Epubcheck version 1.1. issues warnings when validating such modified files, because the files present in the ePub no longer match the manifest in the content.opf file. While I think the iTunes developers were extraordinarily rude in silently modifying user files in this way, in practice I have to admit that it’s hardly a game-breaker. Still, you might consider it cleaner and more elegant to ship ebooks that have been freshly-generated and not exposed to iTunes.

On the subject of ePub validation, if you haven’t already done so it’s well-worth checking out Flightcrew, which is capable of finding many problems that epubcheck misses. The author has blogged about it here.

ePub-compatible Kindle Centering

Amazon’s current Kindle-formatting guidelines offer two ways of centering content. The recommended method is to enclose the element within <center>...</center> tags, and the alternative is to apply the formatting within the element’s tag: <p align="center" style="text-indent:0">...</p>.

Unfortunately, neither of those methods are ePub-compatible; they will cause the ePub version of the book to fail validation. In the meantime, using simple CSS centering that’s suitable for ePub formatting, such as h3 {text-align:center;} doesn’t work on Kindle.

Handcrafted Ebooks offers a general solution to such cases where the ePub and Kindle versions of a book require different formatting or content, based on text-processing tools that generate the appropriate coding for ePub and Kindle as needed. The advantage of this is that it’s possible to use advanced ePub formatting, while also creating (simplified) Kindle files from the same set of XHTML sources. The disadvantages are that it adds complexity to your workflow, and that your published ePub file can’t simply be turned into a Kindle file by running it through Amazon’s Kindlegen converter. (Or at least, such a conversion will not lead to professional-looking results).

To help get around these two problems, I’ve now found two ePub-compatible ways to center elements on Kindle. Firstly, you can code heading elements directly in CSS; you just have to force the left- and right-margins to be zero. For example: h3.title {font-weight:bold; text-align:center; margin:0 0 0.75em 0 !important; page-break-after:avoid;}. Secondly, you can wrap content in a <div style="text-align:center;">...</div> block. You can also apply a CSS class to the <div> tag, of course, so you can make it do the more usual kind of CSS centering used with ePubs as well.

In the version of Gerard’s Herbal that will be offered to retail stores, I used the first method to center titles, and the second method to center images. The second method also works on body text (update: I’ve found a case where it failed, while trying to center several lines of body text in a short file. Possibly Kindle makes a judgement about the proportion of body text you’re trying to center, much as iBooks seems to. In any case, I was able to center the text by applying style="text-align:center;" to each paragraph individually).

It’s important to note that the above centering methods are not documented in the current Amazon Kindle Formatting Guidelines, and therefore technically they are unsupported and might possibly stop working in future. On the other hand, if the different centering requirements of ePub and Kindle are the only things keeping you from having an ePub file that’s fully portable to Kindle, simply by running it through Kindlegen, then you might well decide that the downside of using an unsupported/undocumented feature is worthwhile.

iBooks v1.2 File Update Failures and Glitches

When you transfer a new version of an ePub file into iBooks, it can fail to recognise the new information. Generally I find this to be a problem when fine-tuning CSS in order to improve a layout, because iBooks refuses to show my changes, making the edit-debug cycle incredibly frustrating; the last thing you want to see is the previous version of the book you’re developing. In Handcrafted Ebooks I mentioned that exiting iBooks and running different software would fix this. Unfortunately, this no longer works reliably with iBooks v1.2 and IOS 4.2, both of which were recently rolled out by Apple. Maybe it’s something to do with IOS 4.2’s multi-tasking abilities, allowing iBooks to cling more tenaciously than ever to phantom data; for whatever reason this problem now seems harder to clear by loading other applications.

Happily, the IOS 4.2 Task Manager (aka the Multitasking App Tray) lets you work around this as follows: exit iBooks, double-tap the Home button, and you will see a list of recent applications that includes iBooks. In this list, press and hold the iBooks icon until the red-circled ‘-’ sign appears, then tap that sign. The iBooks application should close, and vanish from the list. Double-tap Home to exit the App Tray, then re-start iBooks and re-open the book you’re working on. So far, this has worked reliably for me — and saved a lot of hair-pulling when incrementally testing new ePub versions.

Update, February 2011: iBooks version 1.2.1 seems to have improved the above issue. I now find that the following sequence is usually sufficient: 1. close the book in iBooks, returning to the app’s Library view. 2. Delete the old version of the book from within iTunes. 3. Drag the new version of the book into iTunes and wait for it to sync. 4. Open the book in iBooks. However, the occasional glitch can still occur, so you might still need to resort to the old method.

iBooks v1.2 for iPad Supports Auto-Hyphenation

This is a welcome update, and makes justified text more readable on iPad/iBooks. It also illustrates a benefit, discussed in Handcrafted Ebooks, that comes from leaving control in the hands of the user where possible. An ePub that doesn’t enforce justification choices, will “just work” with the new hyphenation feature.

On the downside: this new version seems to glitch sometimes when switching between chapters, re-displaying the same page repeatedly instead of moving to the desired new one. I never noticed this in the previous version, though that’s not conclusive proof that the issue didn’t exist there. In the limited v1.2 testing I’ve done so far, I’ve only seen this problem when viewing double-page spreads; switching iBooks to its single page view proved to be a work-around, as did selecting a different font or font size. Enabling or disabling auto-hyphenation made no difference. Time will tell if it’s going to be a problem that crops up a lot, and what if anything ePub creators can do to avoid it.

Update:I came across this again in the latest book I’m formatting, when I changed a line of CSS from this: h4.title {font-size:120%; margin-bottom:0.3em !important;} to this: h4.title {font-size:120%; margin: 0 0 0.3em 0 !important;}. I tried several alternative ways to force the top margin to be zero, both in my CSS file and inline with “style=…”, but all had the same effect of triggering the iBooks chapter-change bug with one particular text-size selection.

iBooks/iPad and Text Justification

(Note: this appears to be broken/obsolete as of iBooks 3.0.1; see the comments)

A new (to me) wrinkle on iBooks for iPad: at first sight, this e-reader refuses to let you override body text justification without applying dummy <span> tags. But while working on the ePub edition of Ransom Seaborn, I found that Ransom’s journal entries – which I’d left-justified to differentiate them from body text – worked just as I wished without any extra effort. Some experimenting led me to the theory that iBooks is happy to honor text justification in style A, as long as you’ve established body-text style B. This would make sense, since the user’s settings would then be respected for body-text proper, while allowing the book designer to apply text justification to other paragraph elements.

You can see this from the following two screen shots, which are based on exactly the same test CSS and XHTML, the only difference being that the first paragraph has been copied and re-pasted in the second shot. The ‘voting power’ of that extra paragraph seems to persuade iBooks that this is the body text style, and that the left-justification requested for the final paragraph can therefore be honored. I think this is good news, not least because it saves me a significant amount of tagging work on Ransom Seaborn :-)

One Paragraph of normal body text

Two Paragraphs of normal body text

Introduction

Handcrafted Ebooks is a fairly technical guide to ePub formatting and ePub-Kindle portability. It’s aimed at those who are happy to use (or learn) XHTML, CSS, text-editing and text-processing with standard, cross-platform tools. It’s in the nature of such a project that updates and corrections will be required from time to time — since publication, Apple has already released new versions of both its ePub reader (iBooks) and its mobile operating system (IOS) that have outdated previously-valid information.

For business rather than technical reasons, I’ve also been refining my approach to Kindle portability, concentrating more on maintaining a single ePub file that can be converted directly to Kindle format (and accepting the compromises that must be made in order to do so), instead of using automated tools to generate individually-tweaked files that target ePub and Kindle respectively from a single set of XHTML sources, which is the focus of the Kindle-porting chapter in the book.

Clearly, that’s quite a lot of updating and going forward, I expect there to be more. Up to now, I’ve been maintaining a single page for updates, downloads and discussion related to Handcrafted Ebooks, but that’s not going to work in the longer term. Hence this blog.