[ATDrake]

Originally Posted by DuckieTigger

As for TOC (clickable), that is another weak point of epub, as it does not require your to have it, but mobi does. So you would not have to worry about having to ADD a TOC when editing a mobi.

Actually, often you do, because while Amazon says that a Mobi submitted to them should have both an HTML and and NCX TOC, quite often with commercial works it doesn't, whereas the ePub version does (I collect a lot of the publisher promo freebies, which often show up in multiple stores so I have the files to compare).

As far as I can tell, the lack of the latter is often due to poor specification of the NCX TOC in the OPF, so that Amazon's conversion tools miss out on it and that's something I have to fix manually by tweaking the ePub, if I can be bothered.

Originally Posted by fjtorres

Methinks you put too much faith in epub's annointment as a "standard".

Whether or not ePub has been anointed as a "standard" in your view is irrelevant. It was created to be an open standard interoperable royalty-free format by the IDPF, and is documented as one, such that people know how it should behave and how to implement tools that work with it. And multiple parties do in fact currently use it as one when creating and distributing and readily create tools to go along with it.

Now, maybe it might languish and end up being one of those abandoned standards replaced by something else as the W3C's XHTML 2.x proposal has been superseded by HTML5 or that advanced XLink thing that went no further than the simplest linking functionality.

But the point remains that I can create and edit an ePub using nothing more than a plain text editor and a zip utility and I expect to be able to keep doing that in the future, and DRM considerations aside, be able to easily extract the textual innards to convert into the next-generation format using only a zip utility and a plain text editor.

And that puts it a step above Mobi, on which you're dependent upon whatever tools and docs Amazon provides, and whatever tools and docs anyone else can reverse-engineer, which I'm quite grateful for and use on a weekly basis, but it would be nice to be able to do without.

Originally Posted by fjtorres

Believe as you will, about the value of epub as a "standard", but don't be surprised if by this time next year, the current four-way DRM splintering of epub becomes a five-way forking of the internal plumbing.

I did mention that I mainly get DRM-free books, did I not? And for the purposes of usage, yes, the DRM-free people stick to the standard proposed spec, or reasonably closely enough. And even underneath the DRM, B&N and Adobe and even Kobo's books do mostly conform with the spec when it comes to the actual text and organization of it.

One might as well argue that Mobi is an equally if not more-so moving target in this area, as Amazon keeps messing with the DRM and changing the way the PID/kinfo works in conjunction with the device/software apps to decrypt the files. Not to mention KF8 and Topaz.

Provided you can get at it, it's what's underneath that counts, and the amount of work it takes to keep the unofficial Mobi helper tools up to date can be seen in the efforts to understand the changes made to the wrapper of the new default KF8+ output of the new version of KindleGen, so that the mobiunpack and kindlestrip tools can be used with it, which currently run to +5 pages combined.

Amazon, of course, seem to have removed entirely from download availability the old version of KindleGen which would have created Mobi only (well, actually Mobi+all your source files stuffed after it), although one can still use Mobipocket Creator if one is on a Windows computer, or Calibre which relies on such reverse-engineered findings.