I’ve been doing a fair bit more reading on my Android phone, although recently I’ve switched from FBReaderJ to Aldiko. Each new release of FBReaderJ has gotten better, but Aldiko includes an actual CSS-based renderer1 and presently provides a much smoother reading experience2. I feel a little guilty using a piece of commercial software when a free-as-in-freedom solution exists, but not yet guilty enough to try hacking on FBReaderJ.
Guilt aside, reading more on a smaller screen has had me thinking again about the tension between book creator and reader in e-book formatting and layout. EPUB on the mobile phone highlights this tension more than e-ink devices if for no other reason than that a phone screen even less resembles a book page than an e-ink screen does. One conclusion I’ve come to is that it’s somewhat unfortunate that Adobe has thus far been the biggest contributor to EPUB as a commercial e-book format.
On the one hand, someone had to do it, and it’s good that someone has done it. Even the DRM thing, to some degree – most publishers aren’t ready to do without it, and at least Adobe had the good grace to use an easily circumventable system. The major concern I have is with some aspects of the apparent mindset behind Adobe Digital Editions.
At present, Digital Editions is the EPUB viewer to beat – I have no idea what the actual usage figures look like, but it’s the only viewer one can legally use for all those commercially-sold Adobe-DRMed EPUB books, so one has to imagine that DE commands the lion’s share of the market. Adobe represents Digital Editions as being more than just an EPUB viewer. The advertising copy on the DE web site touts it as “offer[ing] an engaging way to view and manage eBooks and other digital publications.” To this end, DE supports not only EPUB, but also the document format much more central to Adobe’s business – PDF. And because PDF is so much more important to Adobe, DE caters to PDF at the expense of EPUB.
It’s no surprise to the average e-book enthusiast that PDF’s fixed-page nature makes it a poor e-book format. The most obvious reason is that PDF files can’t be cleanly reflowed to alternative page sizes. A perhaps less obvious corollary is that PDF leaves little room for user control of basic formatting parameters such as font size, line height, text alignment, and paragraph marking. But via one or more chains of causality, because PDF rendering does not allow user-control of these properties, Adobe DE doesn’t allow setting them for EPUB either. This yields an EPUB viewer where the reader has control over only the font size and page size. And even then only partial control! – DE will not rescale any size a book specifies as an absolute size, and DE allows books to provide “page template” files which control how the available screen area is divided into text regions and body columns.
The most generous interpretation of this decision is interface consistency. As long as Adobe is attempting to present PDF as an e-book format and provide a viewer which handles “digital publications” regardless of format, it only complicates that viewer’s interface to provide options which apply to some formats but not others. Somewhat less charitably, Adobe’s focus on PDF may have led to an unconscious bias toward creator control of document formatting, to the extent of perhaps not even considering placing control beyond font size (a.k.a. “zoom”) in the readers’ hands. And way over on the conspiracy-theory side of the fence, perhaps it represents a conscious decision on the part of Adobe to limit the usefulness (and adoption) of EPUB by making it only a small improvement over PDF even for the documents most suited to reflowable formatting.
So for whatever reason, the most popular EPUB viewer on the market has limitations which severely restrict the usefulness of the format. But EPUB is an open standard, which means other, better viewers are free to compete with Digital Editions and supplant it, right? Except they aren’t really, because of DRM.
As I mentioned above, it seems that most publishers are not yet ready to do without DRM, despite the lesson of the music industry. The overwhelming majority of commercially-sold books are encumbered with DRM, and all of the DRM-encumbered EPUB books sold use Adobe’s ADEPT DRM. It would be technically possible for a competitor to begin offering a different EPUB DRM scheme, but I can only imagine the degree of confusion mutually incompatible “EPUB” books would cause among average consumers. So any successful EPUB viewer device or application needs to license the ADEPT DRM technology from Adobe.
To facilitate this, Adobe has begun offering the “Adobe Reader Mobile 9 SDK.” The SDK is available by license agreement only4, so we can but speculate from the marketing copy on the capabilities and interfaces it provides. The “features” list in the SDK FAQ focuses entirely on features of the “Reader Mobile document rendering engine,” suggesting that SDK primarily/only provides a rendering engine. If this is the case, then Adobe is not expecting – or potentially allowing – other vendors to write competing ADEPT-compatible EPUB renderers. Instead, all the available and announced EPUB reader apps/devices using the Adobe SDK5 will simply repackage the Adobe renderer and the paucity of options for user control it provides.
One example in support of this theory is Amazon’s PDF support in the Kindle DX. Although not widely advertised, Amazon is apparently using the Adobe SDK, just integrating only the PDF renderer. Notably missing in the DX’s PDF support vs. all the Kindles’ Mobipocket support is the ability to add annotations to documents. It seems to me that this would be a “must have” feature, not only for parity with Mobipocket support, but also for the target market as a device for textbooks and technical documents. To me the most obvious explanation for this feature’s lack is that there isn’t an easy way to add it while still using the SDK to allow rendering of DRMed PDFs. There are plenty F/OSS PDF renderers to which Amazon could have (comparatively) easily added annotation support, which suggests that the Adobe SDK’s DRM support is an implicit part of the included renderer, and that SDK licensees cannot use the SDK to read DRMed documents independently of the renderer.
Another interesting angle is to compare the Adobe approach with how other book formats/viewers handle the creator-reader tension.
The desktop version of MSReader allows setting only the font size, but a significant number of users seem to regard it as still the best desktop e-book viewer available. A major component of this seems to be very well-chosen defaults for properties like line-height, and the infrequency with which books alter those properties. I have seen much more mixed reactions to the Mobile version, perhaps because on the smaller screens of mobile devices tuning the line-height, margins, etc to an individually comfortable size is much more important. Perhaps a commenter could fill me in?
The various Mobipocket viewers support differing assortments of user-controlled properties. Most support setting font-size, line-height, and paragraph alignment. Interestingly, Mobipocket’s treatment of these properties demonstrates all three possible resolutions of the creator-reader formatting tension. Line-height may be set by the reader, but not by the book creator – the format simply provides no way to specify it. The font-size may be set by the book creator, but only in terms of a size relative to the reader-selected base size. And paragraph alignment may be specified by either the book creator or reader, but the creator’s setting overrides the reader’s when specified.
Correspondingly, paragraph alignment is the subject of one of Mobipocket’s most forceful formatting recommendations: “alignment must NOT be set if it is not strictly needed.” In contrast, the EPUB specification documents contain little resembling formatting guidelines (beyond an admonition against using absolute positioning). The one purely formatting recommendation in Adobe’s “EPUB Best Practices Guide” is “use spacing that looks more like a book,” suggesting including CSS rules to eliminate default space around block-level elements. It does contain some sensible recommendations e.g. against using tags in most contexts, but otherwise the “Guide” documents Adobe’s EPUB extensions and DE’s quirks more than actual “best practices.” Which means that EPUB combines the most extensive e-book formatting capabilities with the fewest guidelines for producing actually readable books. And this is something of a challenge for authors of EPUB viewers.
Coming full circle to the beginning of this post, the Aldiko EPUB viewer does allow the user to set some basic formatting properties, including margins, font, font-size, and line-height6. The first three work seamlessly, but line-height somewhat less so. Aldiko handles books which don’t specify their own line-height fine, but any book-specified line-height “wins.” Which isn’t intended as a slight on Aldiko – this is a difficult problem to solve.
Something like page margin can really only be set via CSS in one “most
sensible” way7, and thus is easy to override coherently and consistently in a
viewer. Font-size is potentially trickier, but the most obvious ways of
specifying font sizes (relative sizes and the CSS named absolute sizes) make a
simple solution fairly straightforward. Properties like line-height
unfortunately lack such a solution – all the allowed relative values for the
CSS line-height property are interpreted as relative to the font-size, not the
line-height of the parent element. This means that the font-size solution of
“change the base and respect subsequent relative changes” doesn't work for
line-height. Without doing some sort of layout analysis, all a viewer can do is
either ignore all book-specified line heights or respect all book-specified
line heights.
Solution? I’m not sure. One possible solution would be for book producers and viewer author to agree on guidelines which allow viewers to consistently override some set of formatting properties. Most of these could be fairly simple, like Mobipocket’s “alignment must not be set” rule. Another solution would be for e-book reader apps to do some sort of pre-rendering layout analysis which allows them to automatically produce a per-book user stylesheet. I like hands-off technological solutions, but I’m not sure how feasible that will be on mobile devices.
Other ideas?
1 To my surprise, a good enough one to handle the max-width property on
images.
2 Quite literally, in the case of the page-turn animation.
4 Probably to stop people from reverse-engineering the DRM system.
5 The ones I’m currently aware of: the Sony Reader, Lexcycle Stanza, the Bookeen Cybook, and the Elonex ebook.
6 Not paragraph alignment yet, but via e-mail the author has said it’ll probably be added soon.
7 One could set left and right margins on every block level element, but hopefully no one actually does that.