The eBook Wars
By Kas Thomas
The next few months or so should be very telling, because in that short period of time, some clear trends should start to emerge with regard to that much-debated portion of the virtual publishing world known as eBooks. One of the things we should be able to discern by year's end is how PDF will fare vis-a-vis things like XML and the Open eBook (OEB) standard. The stakes are high, because if Microsoft has its way (as is sometimes known to happen), PDF will play little or no role in the megabuck eBook market; and if PDF becomes "deprecated" in that market, it will probably be relegated (by publishers at least) to a specialty role as a prepress format for the crushed-tree part of the business. PDF's dominance as a document interchange standard will certainly be hurt if PDF is "cut out of" the eBook market. The only question is to what degree.
As things stand now, PDF faces a serious challenge from OEB and the constantly shifting rules of the eBook biz. Microsoft Reader (the alternative to Acrobat Reader currently being offered by the Redmond contingent as a way of viewing OEB-formatted titles on the Pocket PC) indirectly incurred a setback as the Wall Street Journal panned the Pocket PC. But don't count the Pocket PC out just yet. The real verdict will be decided by consumers.
PDF enters this battle from a position of weakness vis-a-vis hardware. Acrobat Reader doesn't run on any of the current eBook reader devices. This fact alone is disturbing enough. But there are other dimensions to the problem that portend trouble for PDF.
ClearType vs. CoolType: All Hype?
Text antialiasing (which for some reason no one gives a damn about in the HTML world) will be a Big Deal in the eBook wars, since readability plays a key role in the eBook experience. One might even say it's a limiting factor.
Microsoft has, of course, made a BD (Big Deal), or one might even say a BFD, out of its ClearType technology, which supposedly increases legibility 300% on a tiny LCD screen. It's essentially a type of RGB-domain antialiasing, which works best on color LCD displays. You can see a sample of ClearType at http://grc.com/cleartype.htm. Is it such a big deal? The market will have the final say.
Adobe's comeback is something called CoolType, which is a variation on the ClearType RGB/AA scheme. Unlike ClearType, which Microsoft (with characteristic arrogance) says it will apply only to TrueType fonts, CoolType rendering will apply to Type 1 fonts as well as TrueType (and I suspect, many other font types). Like ClearType, its main use will be on LCD displays.
How will PDF fare in the text-legibility wars? My guess is that Microsoft is banking on PDF's continuing to have a poor showing. Acrobat is notoriously awful at antialiasing serifed fonts below 14 points. Most eBook body copy will probably use a modified sans-serif font (for legibility), but you can bet that the eBook "samples" that Microsoft and its allies trot out at Comdex shows will be designed to make PDF look like crap. Which won't be hard to do.
Now would be a good time for someone (Adobe?) to give Reader a new feature: adjustable "type gamma" on a window-by-window basis. Granted, legibility isn't strictly a matter of contrast or gamma, but giving the user some degree of control (ANY degree of control!) over the crispness of the text shown in a PDF page would be a great thing to do...and relatively trivial to implement. (On the Mac, every window record has its own jump table to "bottleneck procs" for drawing into the window. Just hook into the "BitsProc" bottleneck with a custom routine. Control it with a gamma slider in the window's drag bar. Do the whole thing as a custom WDEF so that it doesn't impact core-app code at all.) Acrobat already gives you a pref for turning AA on/off, but that's an all-or-nothing approach that solves nothing.
Text That Reflows
Microsoft's assault on PDF will trade heavily on the fact that PDF is (in Microsoft's words) "static" and unable to reflow text when the user wants an instant "large type edition" of a book. At first blush, this would seem to be an empty challenge, since Acrobat Reader lets the user zoom in or zoom out to any magnification, on the fly. What's the big deal? Who needs reflowed text?
The reality is that there are times when reflowed text would be a nice thing to have in a PDF file. Consider the "large type edition" problem. Currently, with Acrobat Reader, the vision-challenged user of a small-screen device is limited to two choices: increase the zoom factor and scroll horizontally to read text across page-spans, or try to read the doc at a size where the whole page fits into the window's available width. For a vision-impaired person, the second option is not even an option. But the first option (increasing the page magnificaton) is not an option either, because you simply cannot sit there and scroll a page laterally in order to read lines of type that go past the window edges. (You can, but it becomes tiresome after ten seconds or so.)
Score one point for Microsoft Reader.
Adobe needs to think about getting text to reflow on PDF pages (in particular: simple, one-column book pages). This doesn't have to mean repaginating the document or reworking the Page tree, which would introduce enormous complications. All that's needed is to reflow however much text exists on the page in question...then start the problem all over again on the next page.
Since Microsoft Reader relies on Open eBook (OEB) technology, which is built on HTML and XML, reflowing text is a natural, built-in ability of MS Reader (as with HTML browsers). Microsoft boasts that its Reader will perform high-end typesetting on the fly, with "correct" word spacing, kerning, and character positioning (something I've personally not yet witnessed in any Microsoft product). Here again, Adobe has an opportunity to show off its true talents. No one knows high-end typography better than Adobe. If Adobe ever does decide to do on-the-fly text-reflowing in PDF docs, it has the potential to look much better than anything you're apt to see in MS Reader.
But we're not there yet.