Mobipocket vs ePub: Why worse is better in ebook formats

[kovidgoyal]

Oh I'm waaay to lazy to re-implement the HTML rendering wheel. I just use WebKit in calibre to do my HTML rendering for me

[Lbooker]

So in the end who was right?
Tuna or kovidgoyal?
Right now I guess that kovidgoyal must be right because the other programmers who chose to implement epub decoders that way must have done so for good reasons.

[Tuna]

Originally Posted by Lbooker

So in the end who was right?
Tuna or kovidgoyal?
Right now I guess that kovidgoyal must be right because the other programmers who chose to implement epub decoders that way must have done so for good reasons.

Laughing here - there isn't a right way, just the way that best suits your needs. As Korvid says above, for his needs (a viewer on a PC that is a supplement to the main functionality of Callibre), he uses a standard renderer library 'off the shelf'. On the whole he doesn't need to obsess about memory footprint, rendering speed and so on. For most purposes there are many libraries that are good enough to do the job and as he rightly says, what's the point in re-inventing the wheel?

As for other programmers, the decisions they make will have been based on many trade offs - what requirements had been drawn up, what libraries were conveniently available to them, how much time and money they had, what their specialities were and so on. For many operations, something that's "good enough" is, well, good enough.

However, consider that web browsers have been around for 15 years or so now and Javascript nearly as long, yet something like Chrome can come along and demonstrate massive performance improvements by taking a fresh approach to the problem. In areas like this, one or two guys who have the time and enthusiasm for starting from scratch can make a real difference.

[netseeker]

Originally Posted by kovidgoyal

Oh I'm waaay to lazy to re-implement the HTML rendering wheel. I just use WebKit in calibre to do my HTML rendering for me

Arghh...that was clever, you lazy one!!!

[DaleDe]

Originally Posted by HarryT

Yes. That is, I imagine, what the ePub programs for mobile phones, PDAs, etc, actually true.



True, but the reading application does.

True, which is why I said it was the reader who performed the magic of being able to read where you left off, not the format. By the way, mobi's reader is pretty sophisticated while the format is pretty terrible. One thing that the reader does is keep a side file with all the data it needs to pick up where it left off or find a bookmark with all the context it needs to read the data. ePUB readers could certainly squirrel away enough context data to provide similar capabilities to start quickly and make bookmarks quick, however arbitrary jumps are tougher and mobi doesn't do so good on them either.

Dale

[Peter Sorotokin]

Well, the author of the article worries about wrong things. It is not loading into memory which limits viable chapter (or "chunk") size, it's layout speed. Compressed XML parses blazingly fast - much faster than all, but the most carefully designed binary formats. EPUB is more complex to process, but the only reason why it would be slower or require more memory than, say, mobipocket for a file of the same complexity is that developers who write EPUB viewer have too much stuff to do and too little time to do it . Of course, if you include a bunch of tables and complex vector graphics, it will be slower (but still good for any reasonable content) - but other formats simply won't be able to capture that kind of stuff at all.

[llasram]

Aww, I missed all the discussion my post provoked! I realize I'm a bit late to the party, but a few points anyway:

@netseeker: Sibling selectors mean that you need to keep the whole parse tree around to figure out the CSS rules which apply to a particular element. That's the big benefit of LIT's simplified selectors -- that the renderer can pick up at any arbitrary point given only the parent elements, access to which the container directly provides.

@Peter Sorotokin: By the time I got to the EPUB bit of the post I was running out of metaphorical breath. I did have in mind mostly the complexity of rendering and producing the layout of complex markup with complex styling (hence the contrast with Mobipocket), although the lack of seekable decompression in the ZIP format definitely does impose a size limit -- however large in practice -- which does not exist in formats which do have seekable decompression.

[netseeker]

Originally Posted by llasram

@netseeker: Sibling selectors mean that you need to keep the whole parse tree around to figure out the CSS rules which apply to a particular element.

No, definitly not for siblings in general. I guess you mean adjacent sibling selectors because the CSS 2.1 specification contains nothing about "sibling selectors". Adjacent sibling selectors mean that you need to know at least the current node and it's predecessor.

[llasram]

Originally Posted by netseeker

No, definitly not for siblings in general. I guess you mean adjacent sibling selectors because the CSS 2.1 specification contains nothing about "sibling selectors". Adjacent sibling selectors mean that you need to know at least the current node and it's predecessor.

Oops. I could have sworn the general sibling selector ('~') was part of CSS 2.1, but you're right -- it's just in the current CSS 3 draft. My error.

[netseeker]

Originally Posted by llasram

Oops. I could have sworn the general sibling selector ('~') was part of CSS 2.1, but you're right -- it's just in the current CSS 3 draft. My error.

No problem. It's really in the CSS 3 draft? That's good to know anyway because it might be that a future version of ePub will add support for those selectors.

[cjcherryh]

As a creator of e-books, I find mobi easier to work with: you don't have to stitch and paste huge files and then discover you got something in the wrong order. Much easier to edit, and you can do a partial and test the result to see if something works correctly, or if your flowing text actually displays right.

With ePub you have to just close your eyes, push the button, and hope. And wipe it and go work with another software to prep it, then try again.

I like both formats and use them, but mobi is my favorite for ease of use.

[JSWolf]

ePub is the best format for future compatibility. And it's going to be the best format for reading across different devices.

[Tuna]

So much will depend on the tools.

If you look at the old Microsoft Word internal format, it's a complete nightmare. The vast layers of software that sit on top of it hide that from the end user, and it does the job required of it.

I'm not advocating formats like Word's .doc, but the point is that a format is only as good as the software above it.

[tompe]

Originally Posted by Tuna

So much will depend on the tools.

If you look at the old Microsoft Word internal format, it's a complete nightmare. The vast layers of software that sit on top of it hide that from the end user, and it does the job required of it.

I'm not advocating formats like Word's .doc, but the point is that a format is only as good as the software above it.

But how good the tools will become nearly always depend of how good the format is.

[Teddman]

Originally Posted by JSWolf

ePub is the best format for future compatibility. And it's going to be the best format for reading across different devices.

I don't like the ragged right tho.