Farce
The questions Christine asked me are in italics.
1. You mention that a standardised DRM loses adaptability - could you please expand on this further. Are there any other reasons against standardised DRM?
It’s not just standardised DRM that sacrifices adaptability—all DRM has that effect.
A lack of adaptability isn’t caused by any one feature of DRM but is a side-effect of its complexity and purpose.
First of all, the purpose of DRM is to limit what people can do with the files. By definition that is a loss of adaptability and flexibility right there. We can’t keep talking as if the readers aren’t a part of the publishing system: they are the point and purpose of publishing. Without them, books are nothing. Their needs are important.
An ebook ecosystem bound by DRM prevents the growth of loosely integrated ebook services. Those happen to be the exact kind of services that were the foundation of the web’s economy. Many such services would require some copying or excerption which would violate the limitations imposed by DRM. And DRM limits experimentation with ereaders since anybody interested in trying new things would have to not only implement their innovations but also have to worry about integrating DRM support as well. Or, if they don’t implement DRM support they will find that their poor selection of supported titles makes acquiring readers a struggle.
Second, any increase in complexity compromises flexibility and adaptability. An epublishing infrastructure in a world without DRM could be built entirely on the exchange of standardised files (JSON, even) over HTTPS. The systems would be based largely on existing HTTP verbs (GET, PUT, POST, DELETE) and almost everything could built using commodity open source software.
Once you require DRM you impose a set of conditions on every level of the publishing industry. The requirement puts limits not just on what everybody can do, but also on how they do it. Every system that’s put in place needs to not only serve the business needs of the company but also whatever requirements imposed by the need of DRM. The software needed to support and enable most business processes becomes more complex.
That’s without getting into the opportunity cost. There are too many problems that need to be fixed and sorted out in publishing. The money put into implementing DRM would be better spent elsewhere.
Obviously, not all complexity limits flexibility and adaptability. The addition of traffic lights, for example, increases the complexity of the overall traffic system but makes it easier and safer for drivers and pedestrians trying to navigate the system.
DRM, of any kind, is not this kind of complexity. DRM, of any kind, does not simplify life for anybody involved.
2. You argue that e-books require standardisation, do you mean format wise, e.g. all publishers should switch to ePub?
All publishers have pretty much already switched to EPUB2. Most ebooks today are authored as EPUB, even those submitted to Amazon, who provides a conversion tool called Kindlegen that creates Amazon MOBI files from EPUBs.
Unfortunately, publishers are the only ones who have actually standardised on EPUB2 (for better or for worse), everybody else is in their own corner, doing their own thing, giving standardisation about as much time and respect as a hipster gives to Twilight fandom.
No two modern EPUB reading systems are compatible unless you redefine compatible to mean something other than “able to exist or occur together without problems or conflict”.
No reading system today renders an EPUB without major problems, not unless your book sticks to plain text, a few italics, and maybe a header or two. Anything more ambitious – anything that preserves design as a meaningful part of the book – is impossible because in actual practice there is no such thing as an EPUB standard.
Fun fact: many of the most influential people in ebooks today outright reject the idea that design makes a substantial contribution to a book’s meaning.
Even something as simple as lists can’t be done without inconsistent rendering from platform to platform—sometimes even within platforms. Kobo and B&N, e.g., can’t maintain a consistent rendering within their own platform, across their many devices.
Sure, there are the documents that the IDPF publishes, which are nice as abstract concept pieces or modernist texts – computer science reinterpretations of Kafka’s Metamorphosis, sans eloquence and wit, but retaining the deep sense of self-loathing and helplessness – but the only reading system in common use that comes close to implementing EPUB, HTML, CSS, etc. tolerably is iBooks. And even Apple has filled it with all sorts of oddities, overrides, and inconsistencies that turn the whole ‘standardisation’ into a bit of a joke. All of the ‘good stuff’ is happening in their proprietary fork of EPUB3; what they call ‘multi-touch ebooks’.
So, when I say standardisation I don’t just mean a facile adaptation of surface elements of the standard followed by a nice big logo on the website saying “EPUB supported! Yay!”. Standardisation should mean a reasonably standard rendering across all platforms. Standardisation should mean that you could author a basic ebook using the specification as your only guide and have it render the same across all platforms. Standardisation should mean that you wouldn’t have to worry about some platforms overriding your link colours (or anything else), rendering most of your links unreadable because they have an idiotic, non-contextual, understanding of what is readability. Standardisation should mean that taking a web page authored in the very same HTML and CSS standards that EPUB is built on and turning it into an EPUB would be simple and easy and straightforward, instead of the torturous exercise in self-lobotomising dumbing down that it is now.
EPUB readers today don’t support HTML and CSS, period. Anybody who says different is trying to sell you something. And an EPUB reader that doesn’t support HTML and CSS isn’t an EPUB reader but a twisted mutant offshoot of the original.
Standardisation is not what we’ve got.
Sure, I can accept some variation from ereader to ereader and I’m resigned to the fact that that complex designs might break. But we can’t even do relatively simple ebooks reliably.
It’s a farce and I’m tired of it.
The argument for standardisation is simple: it makes everything cheaper for everybody involved.
Production costs are lower. Tools become easier to use and learn. Prices to consumers drop. Solutions become economical.
A classic example, made by Paul Romer in one of his papers on endogenous growth theory, is the disposable coffee cup. I’m paraphrasing here from memory, but the argument went something like this:
Before disposable coffee cups became a standardised commodity, any coffee shop that wanted to sell coffee to go had to make a massive investment to set up a custom production of paper cups. This meant that only large national chains could offer the feature.
After they became a standardised commodity, any coffee shop that wanted to could order a box of paper cups and offer coffee to go. The cups cost less. The coffee shops can offer better service for less. The makers of disposable cups earn more. Everybody makes more money and consumers have more buying power.
Standardisation introduces economic efficiencies that lead to economic growth. Companies couldn’t use this specific feature to differentiate themselves anymore, but the efficiencies standardisation introduces more than make up for the loss and result in more profit overall for everybody.
(Even if you disagree with both the argument and implications of Paul Romer’s growth theory, his papers are well worth reading. And the paper he cowrote with Akerlof on looting in the financial system(PDF) should be required reading for anybody of voting age. That’s without getting into Akerlof’s own work which is also well worth reading.)
3. With the launch of ePub3, what will change regarding DRM? Does it have any impact on DRM?
In theory, EPUB3 should be completely orthogonal to DRM. Except of course that it isn’t. Much in the same way as EPUB should, in theory, just be a collection of standard XHTML, XML, and CSS files, but in practice it isn’t. Those files behave very differently from their web-equivalents.
(Theory and practice in the ebook world are not just separated, they’re setting each others stuff on fire, throwing clothes out onto the lawn, taking sledgehammers to the Porsche, and communicating only through divorce lawyers and thinly veiled death threats.)
Adobe’s DRM system is the EPUB world’s DRM system of choice and it doesn’t support EPUB3. Until it does, or until something else changes, the impact of EPUB3 will be limited.
Adobe’s system isn’t likely to support EPUB3 for a long while, which means that EPUB3 support is on hold for most players on EPUB side of the ebook world. The only exceptions are for the book genres and types that Adobe’s system doesn’t support anyway, like Fixed Layout ebooks (an abomination that shreds every capability, strength, and flexibility of HTML; an insane caricature of a web page; it’s what the web would look like if web standards were written by a deranged print designer high on meth and bath salts).
Fixed Layout Ebooks: Just like PDF, except you get the privilege of writing the goddamn code out by hand because cross-platform support and reliability is a joke.
Again, IDPF’s FXL specification is a concept art piece with inconsistent support and no goddamn books. And it’ll remain so unless both Amazon and Apple roll out support for it in their ereader apps and devices.
Aside
(This wasn’t in my original answer.)
I can’t emphasise too much just how bad of an idea fixed layout ebooks are.
Whoever at Apple had the bright idea of taking HTML+CSS, discard its strengths (adaptability, multi-device support, etc.) and focus on its weaknesses (limited and complex layout systems) should have their computer privileges revoked.
Web layouts are more flexible than the nightmare that dominates reflowable ebooks but are much more limited than the layout models that are at the heart of, say, PDFs.
The reason why we put up with some of the layout nonsense web browsers are saddled with is the flexibility that comes with it. Even before phones with capable web browsers were released we were supporting a wide range of window sizes and screen resolutions. With media queries, the web’s capability for adaptation and flexibility has become even greater. Fixed layout ebooks take all of that away.
Apple itself had introduced media queries a couple of years before they launched fixed layout ebooks so there’s no technical reason why they did what they did.
What Apple could have – should have – done is to introduce responsive layout ebooks. By default they would have adapted to whatever rendering space they were in but would have had the option of setting a fixed dimension.
But, no…
For a while I thought that IDPF’s FXL specification was different, that it opened ebooks up to the full capabilities of the web (all positioning capabilities, media queries, scrolling if you wanted, etc.), especially given how prominent the media queries example was in the spec.
But implementors disagree. And, given that the spec requires fixed dimensions, I have to admit that it is probably much more limited than I expected. Especially given how it is being implemented.
So, the FXL spec does not let me create ebooks where I can drop in an occasional page that has a more involved web-based layout (say title pages, chapter pages, illustrations, the ebook equivalent of a foldout, etc.) and have that layout adapt itself to whatever screen size the reader is using.
Instead it’s just another fixed layout spec among many and one with few major implementations and no books.
Ahem… Where was I? Ah, yes:
The other major markets that will need EPUB3 are publishing markets that need vertical writing, like Japan. Even then there’s a risk that reading system vendors will just implement support for those parts of EPUB3 that are relevant to Asian languages and ignore the rest.
For EPUB3 support to grow beyond these niches within a reasonable timeframe we need to have a sea change in the industry. Either publishers need to drop the DRM requirement or the various platform vendors need to deemphasise and migrate away from Adobe’s EPUB platform.
That could happen. However, I have no faith in the ability of these companies to implement usable EPUB3 support that lets ebooks be as expressive as websites. HTML and CSS support in ebooks will continue to be a nightmare for years to come.