Best of TOC, 3rd Edition O’Reilly TOC Team Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo Special Upgrade Offer If you purchased this ebook directly from oreilly.com, you have the following benefits: DRM-free ebooks—use your ebooks across devices without restrictions or limitations Multiple formats—use on your laptop, tablet, or phone Lifetime access, with free updates Dropbox syncing—your files, anywhere If you purchased this ebook from another retailer, you can upgrade your ebook to take advantage of all these benefits for just $4.99 Click here to access your ebook upgrade Please note that upgrade offers are not available from sample content Chapter Introduction 2012 was quite a year for change in the publishing industry Throughout the year we used the TOC community site to provide insightful analysis of the latest industry developments And since ours is a community site, the articles we publish aren’t just from the TOC team; we also feature perspectives from many of the top innovators and publishing experts It wasn’t easy, but we hand-picked the most noteworthy articles from 2012 for inclusion in this Best of TOC collection We think you’ll agree that the more than 60 pieces featured here represent some of the most thought-provoking dialog from the past year We’ve arranged the articles by category, so whether you’re most interested in marketing, revenue models, production or innovation in general you’ll find something to get your creative juices flowing And since we’re all about fostering community at TOC we hope this collection will encourage you to add your voice to the discussion Since each of these articles is taken from our website you can add your comments by searching for the headline on toc.oreilly.com Chapter Innovation How Agile Methodologies Can Help Publishers By Jenn Webb Agile methodologies originated in the software space, but Bookigee CEO Kristen McLean (@ABCKristen) believes many of the same techniques can also be applied to content development and publishing workflows She explains why in the following interview What is an agile methodology? Kristen McLean: An agile methodology is a series of strategies for managing projects and processes that emphasize quick creative cycles, flat self-organizing working groups, the breaking down of complex tasks into smaller achievable goals, and the presumption that you don’t always know what the finished product will be when you begin the process These types of methodologies work particularly well in any situation where you are trying to produce a creative product to meet a market that is evolving — like a new piece of software when the core concept needs proof from the user to evolve — or where there needs to be a very direct and engaged relationship between the producers and users of a particular product or service Agile methodologies emerged out of the software development community in the 1970s, but began to really codify in the 1990s with the rise of several types of “lightweight” methods such as SCRUM, Extreme Programming, and Adaptive Software Development These were all rolled up under the umbrella of agile in 2001, when a group of developers came together to create the Manifesto for Agile Software Development, which set the core principles for this type of working philosophy Since then, agile has been applied outside of software development to many different kinds of systems management Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project At the end of the day, it’s about getting something out there that we can test and learn from How agile methodologies apply to publishing? Kristen McLean: In relation to publishing, we’re really talking about two things: agile content development and agile workflow Agile content development is the idea that we may be able to apply these methodologies to creating content in a very different way than we are traditionally used to This could mean anything from serialized book content to frequent releases of digital content, like book-related websites, apps, games and more The discussion of how agile might be applied to traditional book content is just beginning, and I think there’s an open-ended question about how it might intersect with the deeply personal — and not always quick — process of writing a book I don’t believe some of our greatest works could have been written in an agile framework (think Hemingway, Roth, or Franzen), but I also believe agile might lend itself to certain kinds of book content, like serial fiction (romance, YA, mystery) and some kinds of non-fiction The real question has to with what exactly a “book” is and understanding the leading edge between knowing your audience and crowdsourcing your material Publishing houses have been inherently hierarchical because they’ve been organized around a manufacturing process wherein a book’s creation has been treated as though it’s on an assembly line The publisher and editor have typically been the arbiters of content, and as a whole, publishers have not really cultivated a direct relationship with end users Publishers make Users buy/read/share, etc Publishers need to adapt to a radically different way of working For example, here’s a few ways agile strategies could help with the adaptation of a publishing workflow: Create flat, flexible teams of four to five super-talented individuals with a collective skill set — including editorial, marketing, publicity, production, digital/design, and business — all working together from the moment of acquisition (or maybe before) These teams would need to be completely fluent in XHTML and would work under the supervision of a managing publisher whose job would be to create the proper environment and remove impediments so the team could its job An original creative voice and unique point of view will always be important in great writing, but those of us who produce books as trade objects (and package the content in them) have to stop assuming we know what the market wants and start talking to the market as frequently as possible Use forward-facing data and feedback to project future sales Stop using past sales as the exclusive way to project future sales The market is moving too fast for that, and we all know there is a diminishing return for the same old, same old [This interview was edited and condensed.] Taking a Page Out of ESPN’s Playbook By Joe Wikert If you missed this recent BusinessWeek article about ESPN you owe it to yourself to go back and read it ESPN is so much more than just a sports network and their brilliant strategy offers plenty of lessons for publishers Here’s just one important indicator of their success: While the average network earns about 20 cents per subscriber each month ESPN is paid $5.13 That’s more than 25 times the average! Pay for one, access all Of course ESPN isn’t just one channel It’s a family of channels (e.g., ESPN, ESPN2, ESPNU, ESPN Classic, etc.) If you’re a subscriber to any one of those channels you’re able to watch all of them online via the free WatchESPN app That means no matter where I am I can catch anything on the ESPN network on my tablet, even those channels I don’t get via cable Think about that for a moment That would be like buying one ebook but getting access to the entire series it’s part of That’s unheard of in book publishing It’s also pretty unusual in network broadcasting but ESPN is ahead of its time When I stream those channels on WatchESPN they’re commercial-free; a static logo appears during commercial breaks That’s because ESPN hasn’t sold the advertising rights to the streaming broadcasts … yet They’re willing to stream everything now, even without advertising income, to build a nice solid base to lure those advertisers to the table Smart Building talent franchises The article talks about Bill Simmons and how the network has turned him into a superstar So when Simmons had the idea to create Grantland he brought the concept to ESPN to see what they thought Rather than watching Simmons go off on his own and create something that might compete with them they launched Grantland with him using their ESPN Internet Ventures arm When this scenario plays out in the publishing world it usually ends with the author taking the idea somewhere else, often to a self-publisher It’s clear ESPN is willing to take more risks than the typical book publisher, even if it might lead to cannibalization As the saying goes though, it’s better to eat your own young than to let someone else it Memorable quotes This article is loaded with plenty of interesting observations but my favorite quotes are the following: I have friends who work at Google, and they are beating their chests ESPN, they never feel like they are at the mountaintop They’re always thinking they can something bigger He stresses ESPN’s multi-platform advantage: print, radio, broadcast television, cable television, Internet, mobile applications To date there are no competitors who have assets in all those media I don’t think you’ll find a lot of hubris here Or complacency I don’t think there’s any sense of trying to protect what we’ve got We’re going to try new things Meanwhile, most book publishers today seem content with high growth rates (off small bases) for what’s nothing more than quick-and-dirty print-to-e conversions There’s certainly not much happening in the multi-format, multi-channel world ESPN is pioneering Think this advice only applies to the world of television? If so, look at how Rosenfeld Media is reinventing and repositioning itself for the future What’s your opinion? Do we need to think more like ESPN? And can you name any publishers who are breaking away from the pack and creating some really innovative, multi-channel products? Perceptive Media: Undoing the Limitations of Traditional Media By Jenn Webb Recent research indicates a clear desire for interactive engagement in storytelling on the part of audiences Researchers at the BBC are pioneering the concept of engagement and content personalization with their Perceptive Media experiment The Next Web’s managing editor Martin Bryant took a look at Perceptive Media and its first incarnation Breaking Out earlier this summer He describes the experiment’s concept: Essentially, it’s media — either video or audio — that adapts itself based on information it knows about individual viewers So, if you were watching a game show that you’d never seen before, it might show you an explanation of the rules in detail, while regular views are shown bonus, behind-the-scenes footage instead … Other smart ideas behind Perceptive Media include the idea that TV hardware could automatically recognize who was watching and tailor the content of TV to them automatically I reached out to BBC R&D researcher Ian Forrester to find out more about Perceptive Media and the potential for the concept Our interview follows How does Perceptive Media work, and are there privacy concerns? Ian Forrester: Perceptive Media takes storytelling and narrative back to something more aligned to a storyteller and audience around a fire However, it uses broadcast and Internet technologies in combination to achieve a seamless narrative experience Our Breaking Out audio play at futurebroadcasts.com takes advantage of advanced web technologies [to adapt the content], but it’s only one of many ways we have identified [Editor’s note: BBC writer Sarah Glenister wrote about her experience working on the Breaking Out audio play experiment here.] The path we took means there are no privacy or data protection issues Other paths may lean toward learning from what’s being customised (rather then personalised) using a more IP-based solution The BBC has a rich history in this field, with the likes of BBC Backstage, which I was the head of for many years Big data is the trend right now, but in R&D, I’m more interested in implicit data that comes from us and everything we What driving factors are pointing to the success of this kind of storytelling platform? Ian Forrester: As an R&D department, its very hard to say for the broadcasting industry, and we have even less experience in the publishing industry However, our research on people’s media habits tells us a lot about people in the lean back and learn forward states We use that research and what we have seen elsewhere to gauge market acceptance At the BBC, we don’t look at advertising, but every other company we’ve seen interested in this type technology/experience/media is thinking adverts and product placement In the early days, Perceptive Media is being applied to broadcast technology What potential applications for Perceptive Media you envision in the publishing industry? Ian Forrester: We have only scratched the surface and not know what else it can be adapted toward In BBC R&D, we watch trends by looking at early innovators It’s clear as day that ebook reading is taking off finally, and as it moves into the digital domain, why does the concept of a book have to be static? Skeuomorphism is tragic and feels like a massive step back But Perceptive Media is undoing the limitations of broadcast It certainly feels like we can overcome the limitations of publishing, too [This interview was lightly edited and condensed.] Kindle Fire vs iPad: “Good Enough” Will Not Disrupt By Jenn Webb With its recent release of the new Kindle Fire HD tablets, some have argued that Amazon has or defaults into account Reading apps clearly ignore the rules of the cascade Standardising their behaviour is preferable to the current wild west that dominates the ebook reading app landscape What features are covered by the override stylesheets? (This applies to both minimal and the more thorough vendor styles.) It isn’t uncommon for some vendors to override both text colours and background colours But some (I’m looking at you Kobo) tend to only override one or the other, often resulting in invisible text and unusable links The current behaviour of CSS overrides frequently results in a much worse result: unreadable text, unusable links, and broken designs This behaviour needs to be normalised and standardised so that publishers know what to expect And vendors need to properly think about how their overrides interact with existing designs so they don’t actually make the book much worse than it would have been without overrides Of course, none of this matters when vendors keep adding design features that are only enabled through server-side munging Which means that the only way publishers can test books is by actually publishing them (I hope I don’t have to explain how much of a quality assurance disaster this trend is.) Things that wold be nice to standardise How detailed is the vendor stylesheet? Publishers need to know what cases are and aren’t covered by the vendor stylesheet so that they can avoid them in books that have to behave properly on platforms where vendors are overly aggressive Override opt-outs It would be interesting to see if vendors are open to standardising a way for publishers to opt out of overrides, much like how iBook’s specified-fonts options toggle works Annotations There is no interoperability between ebook annotations systems today If you’re lucky, you might encounter a vendor that lets you export your annotations as simple HTML, which usually discards a lot of the original context, metadata, and styles Annotations are, however, a big part of editorial work and the writing process In the absence of interoperable annotations, publishers (self- or traditional) are forced to use PDFs if they want to read and annotate drafts on a device or a tablet (And when I say editorial work, I don’t just mean publishing Almost every modern business needs to review and edit text every single day If you want EPUB to compete with PDF and other document formats then this needs to be addressed.) There are two ways of addressing this: Specify a detailed and lossless format for exporting annotations and hope that vendors will implement support Specify a way of embedding bookmarks, highlights, and annotations in a DRM-free EPUB and wait for niche vendors to come out with EPUB reading apps with specialised editing and annotation features The first route would be ideal if we could actually expect it to work If all ebook reading apps were full of proprietary export formats then it would be the path I recommend But no ebook reading app to date even tries to feature-complete, lossless, annotations import and export Standardising a file format for a feature nobody is interested in implementing seems futile The second route is, IMO, likelier to succeed as the plurality of PDF readers with specialised annotation features demonstrate This might be one of those niches where vendors can actually charge for their reading apps Especially if they integrate features that tie into the workflows of most businesses Modularised EPUB EPUB is a sprawl of a specification It’s full of complex crap that is extremely problematic to author and support I’ve heard from a couple of people that the IDPF is interested in standardising a stripped down, simple, version of EPUB I think that’s an excellent idea I also think it should be the first step in modularising the EPUB spec You’d have the core EPUB features as the core spec epub:switch? Separate spec epub:case? Separate spec epub:trigger? Separate spec Scripting? Put all of that in a separate spec Bindings? Metadata? Media Overlays? CFI? All separate specs with their own groups, editors, and timetable Or you could always aggregate all of the dead-end features into a single trashcan spec that everybody can safely ignore Staying out of CSS Nothing good can ever come from forking CSS and, make no mistake, any attempt on behalf of the IDPF to add ebook-specific features to CSS is going to result in a fork Ebooks already behave too differently from the browser baseline as it is Anything that increases that deviation is going to increase costs and the complexity of publishing ebooks So I propose that the IDPF give up on its efforts to standardise CSS extensions for EPUB and focus on advising the CSS WG on what ebooks need from CSS Graceful degradation for Fixed Layout Both reflowable EPUB books and fixed layout EPUBs support media queries Both of them support a wider range of CSS design features than you find in EPUB systems There is no easy way of creating a fixed layout EPUB that uses features such as positioning, backgrounds, colours, etc and degrades gracefully in EPUB reading apps that don’t support the fixed layout spec This is a problem especially for mixed-mode EPUB 3’s that include fixed layout pages in otherwise reflowable books These pages often look incredibly ugly or are simply rendered blank in reading apps that don’t fully support the fixed layout spec, such as the recently released iBooks 3.0 Figuring out some mechanism for graceful degradation in this context would be nice … unless, of course, everybody thinks that mixed-mode EPUB 3’s are a dead end that will never be widely implemented anyway What else? There are a lot of things that should be standardised if we could reasonably expect them to be supported at all in the ebook industry But those issues should not take priority over normalising and standardising existing reading system behaviour InDesign vs CSS By Adam Hyde The explosion in web typesetting has been largely unnoticed by everyone except the typography geeks One of the first posts that raised my awareness of this phenomenon was From Print to Web: Creating Print-Quality Typography in the Browser by Joshua Gross It is a great article which is almost a year old but still needs to be read by those that haven’t yet come across it Apart from pointing to some very good Javascript typesetting libraries Joshua does a quick comparison of InDesign features vs what is available in CSS and JS libs (at the time of writing) It’s a very quick run down and shows just how close things are getting In addition Joshua points to strategies for working with baselines using grids formulated by JavaScript and CSS Joshua focuses on Hugrid but also worth mentioning is the JMetronome library and BaselineCSS These approaches are getting increasingly sophisticated and of course they are all Open Source It brings to our attention that rendering engines utilising HTML as a base file format are ready to cash in on some pretty interesting developments However it also highlights how rendering engines that support only CSS are going to lose out in the medium and long term since they lack JavaScript support JavaScript, as I mentioned before, is the lingua franca of typesetting JS libs enable us to augment, improve, and innovate on top of what is available directly through the browser Any typesetting engine without JavaScript support is simply going to lose out in the long run Any engine that ignores JavaScript and is proprietary loses out doubly so since it is essentially existing on a technical island and cannot take advantage of the huge innovations happening in this field which are available to everyone else Once again, this points the way for the browser as typesetting engine; HTML as the base file format for web, print, and ebook production; and CSS and Javascript are the dynamic duo lingua franca of typesetting All that means Open Source and Open Standards are gravitating further and faster towards the core of the print and publishing industries If you didn’t think Open Source is a serious proposition it might be a good idea to call time-out, get some JS and CSS wizards in, have a heart-toheart talk about the direction the industry is heading in Correction: The latest release of PrinceXML has limited beta Javascript support Thanks to Michael Day for pointing this out.* [This and all posts by Adam Hyde are CC-BY-SA.] Math Typesetting By Adam Hyde Typesetting math in HTML was for a long time one of those I can’t believe that hasn’t been solved by now! issues It seemed a bit wrong — wasn’t the Internet more or less invented by math geeks? Did they give up using the web back in 1996 because it didn’t support math? (That would explain the aesthetic of many home pages for math professors.) MathML is the W3C-recommended standard markup for equations — its like HTML tags for math While MathML has a long history and has been established in XML workflows for quite some time, it was only with HTML5 that mathematics finally entered the web as a first-class citizen This will hopefully lead to some interesting developments as more users explore MathML and actually use it as creatively as they’ve used plain text However the support in browsers has been sketchy Internet Explorer does not support MathML natively, Opera only supports a subset, and Konqueror does not support it WebKit’s partial support only recently made it into Chrome 24 and was held back on Safari due to a font bug Firefox wins the math geek trophy hands down with early (since FF 3) and best (though not yet complete) support for MathML What’s the hold up? It seems that equation support is underwhelmingly resourced in the browser development world WebKit’s great improvements this year (including a complete re-write + the effort to get it through Chrome’s code review) have been due to a single volunteer, Dave Barton Frédéric Wang plays the same heroic (and unpaid) role for Firefox The question is: Why is this critical feature being left to part-time voluntary developers? Aren’t there enough people and organisations out there that would need math support in the browser (think of all the university math departments just for starters … ) to pay for development? As a result we have no browser that fully supports MathML While you cannot overstate the accomplishments of the volunteer work, it’s important to tell the full story Recent cries that Chrome and Safari support MathML can give the wrong impression of the potential for MathML when users encounter bad rendering of basic constructs The combination of native MathML support, font support and authoring tools (more on this in a later post) makes mathematical content one of the most complex situations for web typesetting There have been some valiant attempts to fix this lack of equation support with third-party math typesetting code (JavaScript), notably Asciimath by Peter Jipsen with its human-readable syntax and image fallbacks, jqmath by Dave Barton (same as above), and MathQuill However by far the most comprehensive solution is the MathJax libraries (JavaScript) released as Open Source While MathJax is developed by a small team (including Frédéric Wang above) they are bigger than most projects, with a growing community and sponsors MathJax renders beautiful equations as HTML-CSS (using webfonts) or as SVG The mark up used can be either MathML, Asciimath or TeX That means authors can write (ugly) mark up like this: J_\alpha(x) = \sum\limits_{m=0}^\infty \frac{(-1)^m}{m! \, \Gamma(m + \alpha + 1)}{\left({\frac{x} {2}}\right)}^{2 m + \alpha} into an HTML page and it will be rendered into a lovely looking scalable, copy-and-past-able equation You can see it in action here So why is this really interesting to publishing? Well … While EPUB3 specifications support MathML this has not made it very far into ereader devices However MathJax is being utilised in ereader software that has JavaScript support Since many ebook readers are built upon WebKit (notably Android and iOS apps, including iBooks) this strategy can work reasonably effectively Image rendering of equations in ebook format is another strategy, and possibly the only guaranteed strategy at present, however you can’t copy, edit, annotate or scale the equations and you cannot expect proper accessibility with images The only real solution is full equation support in all browsers and ereaders either through native MathML support or through inclusion of libraries like MathJax We can’t anything to help the proprietary reader developments get this functionality other than by lobbying them to support EPUB3 (a worthwhile effort) but since more and more reading devices are using the Open Source WebKit we can influence that directly The publishing industry should really be asking itself why it is leaving such an important issue to under-resourced volunteers and small organisations like MathJax to solve Are there no large publishers who need equation support in their electronic books that could step forward and put some money on the table to assist WebKit support of equations? Couldn’t more publishers be as enlightened as Springer and support the development of MathJax? You don’t even have to be a large publisher to help — any coding or financial support would be extremely useful It does seem that this is a case of an important technological issue central to the development of the publishing industry being left to others I have the impression that it is because the industry as a whole doesn’t actually understand what technologies are at the center of their business Bold statement as it is, I just don’t see how such important developments could go otherwise untouched by publishers It could all be helped enormously with relatively small amounts of cash Hire a coder and dedicate them to assist these developments Contact Dave Barton or MathJax and ask them how your publishing company can help move this along and back that offer up with cash or coding time It’s actually that simple [Many thanks to Peter Krautzberger for fact checking and technical clarifications All posts by Adam Hyde are CC-BY-SA.] WYSIWYG vs WYSI By Adam Hyde Since HTML is the new paper and the new path to paper online editing environments are becoming much more important for publishing Dominant until now has been the WYSIWYG editor we all know and … err … love? However the current WYSIWYG paradigm has been inadequate for a long time and we need to update and replace it Producing text with a WYSIWYG editor feels like trying to write a letter while it’s still in the envelope Let’s face it … these kinds of online text editors are not an extension of yourself, they are a cumbersome hindrance to getting a job done Apart from huge user experience issues the WYSIWYG editor has some big technical issues Starting with the fact that The WYSIWYG editor is not ‘part of the page’ it is instead its own internally nested world In essence it is an emulator that, through Javascript, reproduces HTML As a walled/emulated garden it is hard to operate on the objects in the garden using standard Javascript libraries and CSS All interactions must be mediated by the editor The ‘walled garden’ has little to with the rest of the page — it offers a window through which you can edit text, but it does not offer you the ability to act on other objects on the page or have other objects act on it Thankfully a new era of editors is here and maturing fast Still in search of a clearly embraced category name they are sometimes called inline editors or HTML5 editors This new generation takes a large step forward because they enable the user to act on the elements in the page directly through the HTML5 contenteditable attribute That allows ‘the page’ to be the editing environment which in turn opens up the possibility for the content to be represented in a variety of forms/views By changing the CSS of the page, for example, we can have the same editable content shown as multicolumn (useful for newspaper layout), as a ‘Google docs type’ clean editing interface, in a semantic view for highlighting paragraphs and other structural elements (important for academics) as well as other possibilities… Additionally it is possible to apply other javascript libraries to the page including annotation softwares like AnnotateIt or typographical libraries like kern.js This opens up an enormous amount of possibilities for any use case to be extended by custom or existing third-party Javascript libraries It is also possible to consider creating CSS snippets and apply them dynamically using the editor This in effect turns the editor into a design interface which will open the path for in-browser design of various media including, importantly, ebooks and paper books There are various attempts at the HTML5 editor, which might also be called a WYSI (What you see is) editor The most successful are Mercury, Aloha and the recent fork of Aloha called WYSIWHAT Each of these are treading their own path but things are really opening up As an example and with reference to the last post I made about Math in browsers, the WYSIWHAT group is making some giant strides in equation editing Their equation plugin which was first built by Mihai Billy Balaceanu at the September WYSIWHAT hack meet in Berlin has since been improved and extended by the Connexions team and the good people at OERPUB (including the talented trio of Phil Schatz, Kathi Fletcher and Marvin Reimer) The plugin was made by including MathJax in the page and allowing the editor to interact with that This was not easily possible with previous WYSIWYG editors The progress on the equation front is looking very good but what this shows more than anything is that by using WYSI editors the entire page is available for interaction by the user or Javascript Anything you can think of that Javascript can you can bring to the editing environment, and that is quite a lot … [Coda: if you are brave and have Chrome 23 installed try visiting BookJS.net, follow the instructions and then visit this demo (it enables content editing of a book and dynamic CSS editing via contenteditable) All posts by Adam Hyde are CC-BY-SA.] A Kindle Developer’s 2013 Wishlist By Sanders Kleinfeld 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: 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 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 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) Figure 13-6 Two probability equation images rendered on Kindle Paperwhite, the bottom equation shrunk more than the top equation 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! 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 Compare the rendering of the code block below on Kindle Paperwhite with Publisher Fonts turned on (left) and Publisher Fonts turned off (right): Figure 13-7 The same code listing displayed 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 Add more granularity to @media query support One of the best CSS features added to KF8 was support for two specific @media queries: @amznkf8 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 syntaxhighlighted code example side-by-side on Kindle Fire (left) and Kindle Paperwhite (right) Figure 13-8 Rendering of syntax-highlighted code listing on the four-color Kindle Fire tablet (left) and the eInk Kindle Paperwhite (right) I’d love to see support added for @media queries such as @amzn-kindlefire, @amznkindlepaperwhite, 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.) 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) Figure 13-9 Kindle Previewer for Mac in Paperwhite Mode But one thing you can’t 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 I’d love to have put “EPUB support on Kindle” at the top of my wishlist, but sadly I don’t see that being a realistic request Special Upgrade Offer If you purchased this ebook from a retailer other than O’Reilly, you can upgrade it for $4.99 at oreilly.com by clicking here Best of TOC, 3rd Edition O’Reilly TOC Team Editor Mac Slocum Revision History 2013-2-12 First release Copyright © 2013 O’Reilly books may be purchased for educational, business, or sales promotional use Online editions are also available for most titles (http://my.safaribooksonline.com) For more information, contact our corporate/institutional sales department: (800) 998-9938 or corporate@oreilly.com Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks Where those designations appear in this book, and O’Reilly Media, Inc was aware of a trademark claim, the designations have been printed in caps or initial caps While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein O’Reilly Media 1005 Gravenstein Highway North Sebastopol, CA 95472 2013-01-28T10:35:04-08:00