2012 was a good year for Kindle developers. With the unveiling of the first-generation Fire tablet in late 2011 and the release of the KF8 Mobi format in early 2012, designing beautiful ebooks for the Kindle platform became a reality. KF8 introduced a fixed-layout specification for Kindle Fire, which opened the door to graphically rich titles—children’s books, graphic novels—in Mobi format. KF8 also greatly increased CSS2 compliance for standard reflowable ebooks, implemented a handful of CSS3 features (text shadow, rounded borders), and added support for embedded fonts. The subsequent rollout of KF8 to Kindle eInk readers running firmware 3.4 (including the new Kindle Paperwhite) and KF8′s support for @media queries to enable fallback styling for non-KF8 devices helped to increase rendering parity within the diverse Kindle ecosystem.
But while 2012 marks a huge leap forward toward the incorporation of modern Web standards into the Kindle platform, there is still much room for improvement in terms of multimedia/interactivity, content rendering, and ease of ebook development. Here is my humble*** wish list of improvements for the Kindle platform for 2013:
1. Add support for embedded audio/video to Kindle Fire
When KF8 was introduced in early 2012, support for audio/video was not included in the format—even though MP3 audio and MP4 video were already supported in Kindle for iOS. Nearly 12 months later, the Kindle Publisher Guidelines still read, “Currently, only Kindle for IOS [sic] supports audio and/or video content. Kindle e Ink devices and Kindle Fire do not support Kindle Editions with Audio/Video.”
Given that support for streaming multimedia content via Amazon Instant Video is such a highly touted feature of Kindle Fire, it’s rather surprising that Amazon has not been more assiduously pursuing support for embedded multimedia for Kindle Fire ebooks. As a result of this discrepancy—Kindle Fire supports KF8 but not audio/video, and Kindle for iOS supports audio/video but not KF8—there is no single Kindle platform that supports all the ebook features that Amazon offers. Those Kindle readers who opt to buy a Fire over an iPad are penalized by not being able to view embedded video in ebooks, and those who opt to instead read their ebooks on Kindle for iOS are penalized with a lower-quality reading experience, as embedded fonts and many key CSS features will not be supported. This should be rectified ASAP. Here’s hoping that by this time next year, embedded audio/video is supported on every Kindle tablet device, and that KF8 is supported on Kindle for iOS.
2. Add KF8 support for MathML
High-quality typesetting of mathematical equations is a challenge in most digital formats, and Kindle is no exception. Because Kindle’s KF8 format does not support MathML (a XML vocabulary for markup of math content that is part of the HTML5 specification and supported to varying degrees in different desktop and mobile Web browsers), the only viable typesetting option for including complex equations, matrices, etc., in ebooks is to embed the math content as images. However this approach is far from ideal, because when implemented as images, mathematical equations are not searchable or resizable by readers. Optimizing image size can also be challenging. See the Kindle Paperwhite screenshot below featuring two equation images scaled to the same size, which results in the longer equation (bottom) being more heavily “shrunk” than the shorter equation (top).
Adding MathML support to KF8 would remove the burden for equation sizing and resolution from publishers and developers, and place it on the ereader’s rendering engine, where it belongs. As Adam Hyde notes in his TOC post on math typesetting, the current state of MathML support in browsers and on the Web is rather woeful, forcing reliance on third-party libraries like MathJAX to correct and normalize rendering. But this presents a huge opportunity for ereader vendors like Amazon. Adding robust MathML support may provide a competitive advantage in the likely-to-grow ebook marketplace for math and science textbooks. iBooks already provides limited MathML support via its WebKit engine; your move Amazon!
3. Add a Monospace Default Font to Kindle Paperwhite
The Kindle Paperwhite ereader contains six system fonts: Baskerville, Caecilia, Caecilia Condensed, Futura, Helvetica, and Palatino. None of these is a monospace font. Monospace fonts are critically important for technical-book publishers, because elements such as code listings and ASCII art must be formatted such that every character is of equal width, in order for them to render properly.
Because Paperwhite supports the KF8 format, Mobi developers can embed their own monospace font if their content requires it (O’Reilly embeds the Ubuntu Mono font family in its Mobis). However, by default, Kindle Paperwhite has Publisher fonts turned off, so readers must navigate to the Kindle font menu themselves and enable the Publisher Font option—which they may not know they need to do. Compare the rendering of the code block below on Kindle Paperwhite with Publisher Fonts turned on (left) and Publisher Fonts turned off (right):
Kindle customers shouldn’t have to be educated to enable Publisher Fonts to ensure monospace content is displayed properly, and publishers shouldn’t be required to embed additional fonts (which bloat Mobi file size) to enable monospace functionality. Ereader vendors should provide a rich set of system fonts, optimized for their rendering engine, that meet the needs of publishers of fiction, technical reference books, or anything in between. Both legacy eInk Kindle devices and the Kindle Fire have monospace system fonts; please extend this support to Paperwhite as well.
4. Add more granularity to @media query support
One of the best CSS features added to KF8 was support for two specific @media queries: @amzn-kf8 and @amzn-mobi. These two queries allow Kindle developers to segregate their CSS so that styling that takes advantage of KF8 features (in an @amzn-kf8 block) is ignored on legacy Mobi7 Kindle ereaders, and fallback styling (in an @amzn-mobi block) will be used instead on the legacy devices.
This @media query support was a boon when Kindle Fire was the only device in the Kindle family that was KF8-enabled, because you could use @amzn-kf8 to specify not only KF8-specific features, but also four-color-specific styling for Fire tablets that would be ignored on the black-and-white devices. However, now that eInk readers like Kindle Paperwhite also support KF8, they also use the CSS specified under @amzn-kf8, which means it is not possible to target CSS for the tablet readers and provide graceful degradation for eInk. See the screenshots below, which show the same syntax-highlighted code example side-by-side on Kindle Fire (left) and Kindle Paperwhite (right).
I’d love to see support added for @media queries such as @amzn-kindlefire, @amzn-kindlepaperwhite, and so on, so that Kindle developers are better able to tailor Mobi content to the unique capabilities of each ereader. (This would be an equally welcome feature for other ereader platforms that encompass both eInk and tablet devices—e.g., NOOK, Kobo.)
5. Add a “View Source” option to Kindle Previewer
Kindle Previewer is an excellent emulator that allows you to quickly review how a Mobi file will display on all major Kindle platforms (see screenshot below).
But one thing you can’t do in Previewer is inspect the underlying HTML/CSS source code to debug any rendering oddities that may be present. There are tools available, such as mobiunpack, which you can use to crack open a Mobi file and see the source, but they are neither especially convenient nor user-friendly. Having “View Source” functionality built into Kindle Previewer would be a huge timesaver.
What features are on your 2013 Kindle developer wishlist? Hit the comments and share your requests.