Originally Posted by charleski
Unfortunately, people are convinced that the money lies in developing ever flashier shinies in order to beguile the customers, rather than in fixing fundamental problems or ensuring true cross-platform compatibility. Anyone who believes that ePub 2 address all the problems with creating static text should try creating an ePub that displays everything locked to a baseline grid (a pretty basic approach in typography for a very long time).
ePub 3 contains a lot of things that might
make it easier to produce good-looking books that are easy to navigate. But it fails to be prescriptive enough to ensure that these documents work in much the same way across all ePub 3 devices. We already have the problem with people having to tweak ePubs differently for the iPad opposed to ADE, and these differences sometimes go very deep.
The primary job of a standard is to be a standard
and the spec uses the word 'should' all too often - which means
, 'this is the way we'd like things to happen, but you can ignore it as long as you can think up an excuse'. For instance, the handling of oeb-page-head/foot has had the language "Neither should
be simply presented as if it were inline or block." for years, and it's exactly the same in ePub 3, yet ADE 1.8 still presents these elements as blocks in the same flow as the rest of the text. And they can get away with it, because that's what the standard allows.
Sell the sizzle, not the steak. That's the ever-inceasing problem that we run into as commercial ebook producers. I get requests for the fixed-format layout constantly, and I feel bad because I have to charge an arm and a leg--and I'm not that crazy about it, firstly, and secondly, the marketplace for it (on iBooks) is pretty damned narrow bandwidth.
The ADE-iBooks schism is increasingly a problem; as is the ever-growing divergence from "basic" ADE by usage...as an example, Nook's "new" hyphenation issues now cause books that were perfectly fine a year ago to hyphenate absurdly, because they're not wrapped in specific CSS to prevent it. I had a book rejected by frakking Lulu today because "Your ebook has been rejected for missing, incomplete, unreadable, or inaccurate Table of Contents. The NCX must be accurate."
Now, the bloody NCX is accurate, the book validates in every validator on the planet, there's naught missing, incomplete, unreadable or inaccurate. That's their entire error message. So, purely passing epubcheck is now an imaginary goalpost, as it is with Apple. And, like Apple, the "error," however imaginary, is suitably vague so that, no matter what the issue is, you can't find it to fix it, and it has NAFT to do with epub2 or 3. /rant
The essential problem is, as always, money. It's not as though anyone with any authority is standing up and saying that this can't/won't be done; Apple gets what Apple wants; Nook gets what Nook wants, Amazon gets Mobi/prc, and those of us making the actual frakking books are stuck in the middle, wading in increasingly-deep offal, beset by clients who, like crows, want the latest shiny pretty thing
. /sorry, mo' rant.
I don't think that there's any solution...because nobody but the folks in the trenches think there's a problem
. If ThreePress is making a "magic book" with ePUB3 interactivity, well, bygod, we'll all be stuck with it shortly. We still won't be able to make a freaking dropcap that works in both iBooks and Nook...but bygod, we'll make ships sail across the device. In the meantime, any possibility of using XML as a carrier to make life easier will sail right out the window...
Sorry...you know what? I took one look at that article and my head exploded. I shouldn't be raving. Long day, too much caffeine, too little sleep. Leaving now.