Double-stitching code to fight eReader incompatibility
I honestly had not expected how much work it would be, putting together my book Zen of eBook Formatting. After all, I had the blog tutorial to build upon, and yet, it took me many months to flesh out the final book, add in all the little details and additions, and tweak it to make sure it is as accurate as I can make it. Part of it had to do with the fact that eReaders have turned into a sea of incompatibility.
While the original “Take Pride in your eBook Formatting” tutorial is still every bit as relevant and applicable today as it was when I first published it a few years back, as soon as you want to go beyond the most basic formatting features, you get caught up very quickly in the morass of device limitations and quirks.
With each new device generation new problems are being introduced, and considering that we are now looking at fifth or sixth generation devices, one can quickly get lost in the maze of dos and donts of eBook formatting.
I am not pointing fingers here because every manufacturer contributes to the problem. Apple with its incompatible ePub implementations in iBooks for one, Amazon for other limitations and countless firmware bugs, Barnes&Noble for a different set of firmware bugs. Each of them making it harder for eBook formatters to navigate these waters and create reliable products.
Switching a font face, for example should be a completely trivial thing. According to the HTML standards which underly both the MOBI and EPUB format, you should be able to switch fonts anytime on a block level. Sadly, this is not true in the world of eBooks.
Typically a code snippet like this should work fine on any device, assuming we have a span style called “newfont” that sets a different font family.
<p>Let’s <span class="newfont">switch the font</span></p>
Sadly, all of Apple’s iBooks devices and software do not follow this standard. Not even a snippet like the following one works.
<p class="newfont">Let’s switch the font</p>
iBooks does not recognize font family settings in <p> and <span> elements, which is completely inconsistent with HTML standards. It is not a mere oversight, however, because Apple has been dragging this problem through all iterations of iBooks, since its inception years ago. One can only wonder what Apple’s software engineers are thinking.
I found that oftentimes I have to double-stitch solutions, nesting different solutions, so that if one doesn’t work there is always a fallback. The work-around to fix this particular problem is to use another block-level tag in order to pass the information to iBooks.
<p>Let’s <span class="newfont"><cite class="newfont">switch the font</cite></span></p>
While this is not the most elegant solution, and purists will scream out at the misuse of the <cite> tag here, the reality of things is that as eBook formatters we currently cannot afford to be purists. We need formatting challenges solved and in this case <cite> addresses a very specific problem. If Apple would stick to the standards in the first place, hacks like this would not be needed.
I found that the same kind of double-stitching is sadly needed if you want to strike out text, as in draw a line through it. It is not a very commonly used text feature, but if you need it, it is imperative that it shows up correctly.
Instinctively you would use the <strike> tag, which has been part of the HTML vocabulary since its inception. <strike>, however, has been discontinued with the HTML5 standard, and as a result there are now eReaders that no longer support it. They require the <del> tag instead, which, quite by coincidence, is not supported by some older devices, of course.
As in many cases, double-stitching the solution is the way to go for me and whenever I have to strike out text, it will look like this.
<p>This is how you <strike><del>strike out</del></strike> text.</p>
Once again, not the most elegant solution, but as you format eBooks, you will have to get used to seeing things such as this more and more often. As I said, with every new generation of eBook devices, the number of these types of inconsistencies will grow and the need to find and apply band-aid solutions will sadly grow with it.
If you want to find out more about basic and advanced eBook formatting techniques, make sure to check out my new book Zen of eBook Formatting, which details all the necessary steps to create professional-grade eBooks.
If you want to keep up with my eBook formatting work, don’t forget to subscribe to my Zen of eBook Formatting Newsletter. That way I can keep you updated about the latest developments, updates to my book, code snippets, techniques and formatting tips.
IBooks and fonts:
EPUB 2 -> add display options XML in meta-Inf folder and voilà, fonts work
EPUB 3 -> add specified fonts meta in package.opf and voilà! fonts work.
Strike & delete
Attribute a class to del, define text-decoration:line-through for class in CSS. When del isn’t supported, it will degrade to a span with a strike through.
iBooks actually does recognize CSS font-family calls on both and — you just have to include true in either the opf file metadata or in an added com.apple.ibooks.display-options.xml file. It’s detailed in iBooksAsset Guide (5.2 is the most recent version).
Sadly, neither is really a suitable solution unless you hand-craft your ePub files, which very few people do. So it is just another hack. Different from the one I am using, but a hack nonetheless, because Apple is not properly following the standard. Sadly, Calibre doesn’t have an easy way to inject meta data into a book permanently. You would have to do it every time you rebuild the book, so I do not see how this would be a more desirable solution than the one I offered up. At least my solution is entirely source-HTML driven.
Aside from that, the display-options.xml solution is outdated and is no longer supported with EPUB3 books going forward, from what I’ve been hearing.
My favorite bug regarding fonts and KF8 read on Kindle PW1 and PW2 is so called “helvetica bug”. If you use some embedded font only for headings and similar things but you don’t set default font family in body tag CSS (font-family: serif;) then when you turn on “Publisher font” all the paragraphs that are not using your embedded font are displayed as sans-serif , using Helvetica font.
Or the other bug if the paragraph CSS classes code contains crap like “font-family: Times” or even just “font-family: serif” (without adding the same line to body tag CSS code) text is displayed as Caecilia even if you change to other built-in Kindle fonts.
So moral of this story is: always add font-family property to body CSS code 🙂 🙂
@guido
Do you honestly think bloating (Thérèse is on orner word) the markup is a suitable solution? I’m honestly asking the question as it could turn really really bad for accessibility (something like 20% of the world’s population is impacted).
Semantic markup should be sacred in my opinion and bloat is a proof of bad quality, a.k.a style over semantics. That’s what we are trying to explain to InDesign developers, a software which is outputting the biggest *four-letter word* in the world and whose developers should go to hell since they are insanely incompetent when it comes to EPUB. Really.
If Apple is not following standards but offering a solution. Let’s use it. As people who care, the second we stubbornly enforce style, the standard is bleeding.
To me compatibility is the most crucial aspect and with that in mind, the mark-up solutions are definitely the best way to go about it. It is simply not an option for me—or most authors who want to self-publish their books—to learn the idiosyncrasies of every single device in the market and then try to address it with customized channel builds.
Apple is offering a solution, well, so am I, and mine does not require you to drill deep into the ePub package.
With the growing market of eReaders it is impossible to keep track of all firmware bugs, new ones as well as legacy issues, pretty much all of which are addressed by my strategy. Since I have not seen any side effects regarding accessibility, I see absolutely no reason why defensive programming and preemptive mark-up should not be preferable to strictly-by-the-book coding. So far my practical experience with this approach has been and until such time that I see reasons, aside purely academic ones, to take a different route, I will try to address firmware issues with mark-up as best as I can.
Rebecca, I could find only iBooks guide “5.1 revision 2”: is that the latest version?
I agree with what Guido said, but i’m using a different approach: making a “standard” epub for Kobo/Nook/ADE and a different one for iBooks, plus one for Kindle (ported with previewer rather than Calibre). I prefer to edit the code in Sigil and use a text editor to paste it there after.
ATM looking into device recognition to put into the CSS… It’s possible to recognize a Kindle Fire, maybe iBooks too (after all it’s just a software), but I’m afraid that I wont be able to code all the necessary differences in there, so I’ll end with a minimum of 3 ebook formats.