Publishing 2.0 and the Architecture of Participation

In a Publishers Weekly piece the indefatiguable David Rothman writes about Razing The Tower Of e-Babel. I agree with his main points – we have to make digital reading simple and compelling for end users, and the plethora of proprietary eBook formats has created consumer confusion. Where I disagree is that I see the answer at hand.
First, for paginated final-form “ePaper” there is no Tower of e-Babel – PDF is the answer, it’s game over. PDF is highly proliferated, its ecosystem extends far beyond Adobe, even to Adobe’s competitors. PDF is now very open, with PDF a full ISO standard. Microsoft is pushing their alternative XPS but (trying to put my Adobe hat aside) there is just no rational reason for the industry to reinvent PDF, much less to buy in to letting the monopolists in Redmond do it. So David’s attempts to beat up on PDF are way off the mark: when pages is what you’ve got, PDF – open, widely adopted – is just the ticket. There are many kinds of digital editions of print content for which this kind of ePaper representation is, at least for now, the best that can be done. Highly composed technical books, textbooks, and childrens books for example. Or when you have scanned a physical book or a print-based workflow and it’s simply not economic to do human-assisted OCR to get full text. David argues that eBooks aren’t taking off; the fact that Pragmatic Programmers is making close to 40% of their revenue from selling PDF-based technical eBooks shows that in some segments, that’s simply not true.
But as David is wont to point out, final-form paginated content is not always a great solution for digital editions. Paperbacks are not just shrunken version of a hardback’s pages, and when reading on a small screen, or a larger font size is desired, users deserve pages formatted to the viewable area, not a “pan and zoom” experience. Many kinds of books are better represented in a reflow-centric representation, which doesn’t preserve a particular composed page set but instead supports dynamic pagination. PDF can support reflow but that’s not its strong suit. In the reflow-centric domain lies the Tower of eBabel and it’s an acute problem – you have Microsoft .LIT, eReader.com PalmDoc, Mobipocket PDB, Sony BBEB, ZIP-packaged web pages, etc. It’s uneconomic for content publishers to distribute in all these formats, and confusing as heck for consumers.
Yet this problem is now being rapidly and effectively addressed by the IDPF. Publishers, vendors (including Adobe), and library and educational groups have come together in IDPF to create the open standards that will end the Tower of eBabel.
David Rothman’s main criticism of the IDPF work seems to be his desire that publishers stay out of this process and adopt a “Cargo Cult” mentality in which some nebulous set of “techies” (presumably David and his OpenReader cohorts) will do all the technical work specific to publishing reqiurements (later to be rubber-stamped by an IT-generalist group like OASIS), whilst publishers stay focused on “trade association matters” and just wait for the solutions to arrive.
Well, I think this is elitist, egocentric nonsense that hasn’t a prayer of working. No doubt it’s messier to have publishers, competing vendors, and nonprofits all coming together. True, not every publisher has industry-leading technologists on staff. But many do, and this kind of participative process is part of building successful (by which I mean broadly adopted) solutions. RSS for example with its many dialects is technically a mess – I wish there had been a few more techies involved in its creation – but it was created by and for the content publishing community and has gotten rapid adoption therein. OASIS is great as a general IT standards group (Adobe is a member) but its wheels grind slowly, and with a Board composed of the likes of GM, Oracle, SAP, and IBM OASIS can’t be expected to put much focus and attention on catalyzing “Publishing 2.0”.
I believe that we’re all a lot better off with publishing industry working together in an architecture of participation, and IDPF is where this is happening now. The results of this, including the IDPF OCF container format standard, are already bearing fruit and the Tower of e-Babel that plagues reflow-centric eBook formats will start falling down over the coming months. There’s always room for more contributors in the IDPF.
Meantime, when anyone tells you that their self-anointed “techies” are going to give you the answer ex cathedra, in the form of some new and incompatible eBook format of their own devising, ask them why – if they really want to help tear down the Tower of e-Babel – they seem to be headed on a path likely to just make it worse. I just don’t get it, but then again I don’t get why LInux is shooting itself in the foot with incompatible windowing toolkits. Perhaps – as with most cathedrals – it all comes down to egos. As for me – I hope to see you in the IDPF bazaar.

One Response to Publishing 2.0 and the Architecture of Participation

  1. Bill:You wrote:

    PDF can support reflow but that’s not its strong suit.

    PDF reflow would be much closer to the mark but for two issues (both of which I’d love to see Adobe address).The first is that, sadly, few people know about this feature.The second, related, issue is that PDF reflow occurs only when the reader of the document initiates it. While the PDF document must, of course, first have the necessary structure to allow reflow, nothing happens until the person viewing the document elects to initiate it. In other words, reflow is considered to be an attribute of the Acrobat viewing application rather than an attribute of the document.But that’s not right, is it? The author of the document should be able to say, “This is reflowable document” or “This is a fixed page layout document” and that should be the default behavior of the document. The reader, of course, should be able to override the selection if he or she chooses, but the default behavior should be that of the author’s intention.This would also neatly resolve the first issue. The reason people are unfamiliar with PDF reflow is that they’ve never seen it. But if they opened up PDF files and some reflowed and some didn’t, this feature would become obvious.There are a few other related issues that I’d also like to see addressed — Web capture (which could be a great source of reflowable PDF documents) needs to be updated to correctly handle pages that use CSS-based layout, and PDF’s page size options could be enhanced to better support reflow options. But these are minor points. The main feature that would, I think, get reflow off the ground would be to allow authors to determine the default reflow behavior for the document.