PDF vs LRF etc

[Valloric]

Originally Posted by HarryT

Mobi and IMP, too. That's why it's so easy to convert between LIT, Mobi, and IMP - they are all implementations of the OEB (Open eBook) standard.

Epub is more advanced then OEB, and OEB is not simply a subset of OPS (Open Publication Structure, what epub uses... along with OPF and OCF). You could call these three standards "the next level".

[sealbeater]

Originally Posted by HarryT

PDF should, however, be avoided if at all possible. It was never intended to be a book format and has all sorts of issues which make it a very poor choice.

I think you have a little bias on this one Harry. There's nothing wrong with using pdf for say manga and comics which in my opinion render the image much more cleanly than LRF, it's a real standard and cross-platform. I agree that it's not a good choice for text only, on the various readers but properly done, present no problem for image only books.

Quick note, the pdf limitations page is mostly what not to do to your pdf which honestly, is just keep it simple.

[HarryT]

Originally Posted by sealbeater

I think you have a little bias on this one Harry. There's nothing wrong with using pdf for say manga and comics which in my opinion render the image much more cleanly than LRF, it's a real standard and cross-platform. I agree that it's not a good choice for text only, on the various readers but properly done, present no problem for image only books.

Never having encountered such a book, I am happy to accept your word for that .

[UncleIvor]

Which raises the question - why can't more of the ereaders cope with vanilla html? It seems to be the obvious choice for ebooks, with convenient formatting, space for meta tags, and so on.

[sealbeater]

Originally Posted by UncleIvor

Which raises the question - why can't more of the ereaders cope with vanilla html? It seems to be the obvious choice for ebooks, with convenient formatting, space for meta tags, and so on.

I agree! I smell a conspiracy. Can't have too open a format, what?

[HarryT]

That's pretty much what ePub is - HTML with all the referenced images, etc, packaged up in a ZIP file.

[sealbeater]

So are you saying I can explode a .lit, zip it back up and rename it .epub (I'm assuming) and the PRS505 can handle it? Interesting, if so, I will try.

[Valloric]

Originally Posted by sealbeater

So are you saying I can explode a .lit, zip it back up and rename it .epub (I'm assuming) and the PRS505 can handle it? Interesting, if so, I will try.

No, you can't. An epub file is much, much more than just XHTML. You can get the specifications that define epub files (the Open Publication Structure, Open Packaging Format and Open Container Format) here.

And epub files don't have to be based on XHTML at all. You can use DTBook.

[sealbeater]

Originally Posted by Valloric

No, you can't. An epub file is much, much more than just XHTML. You can get the specifications that define epub files (the Open Publication Structure, Open Packaging Format and Open Container Format) here.

And epub files don't have to be based on XHTML at all. You can use DTBook.

That doesn't sound like vanilla HTML to me.

[Valloric]

Originally Posted by sealbeater

That doesn't sound like vanilla HTML to me.

Good. Because it's not.

[kovidgoyal]

Originally Posted by sealbeater

That doesn't sound like vanilla HTML to me.

Almost all EPUB files you will encounter in the wild are vanilla HTML plus about 50 lines of XML to describe the book metadata. The EPUB standard certainly supports more than vanilla HTML, but if you want to use it for archival, there is no reason to use anything other than vanilla HTML

[HarryT]

Originally Posted by Valloric

And epub files don't have to be based on XHTML at all. You can use DTBook.

They don't have to be, but in reality, they are.

[Valloric]

Originally Posted by kovidgoyal

Almost all EPUB files you will encounter in the wild are vanilla HTML plus about 50 lines of XML to describe the book metadata. The EPUB standard certainly supports more than vanilla HTML, but if you want to use it for archival, there is no reason to use anything other than vanilla HTML

Please let's not equate XHTML and HTML. Building an XHTML parser is trivial, whereas for HTML, it becomes ridiculously complex.

The epub standard does not support "vanilla" HTML at all.

[kovidgoyal]

Originally Posted by Valloric

Please let's not equate XHTML and HTML. Building an XHTML parser is trivial, whereas for HTML, it becomes ridiculously complex.

The epub standard does not support "vanilla" HTML at all.

Actually building HTML parsers is trivial since almost every language has ready made open source HTML parsing libraries. And I dont know of a single ebook viewing application that will not read HTML in an EPUB container. So lets not get too religuous about standards.

[Valloric]

Originally Posted by kovidgoyal

Actually building HTML parsers is trivial since almost every language has ready made open source HTML parsing libraries.

So you're saying it's easy to create an HTML parser because there are a lot of open source HTML parsers out there?

Do I need to respond to that? Or do you see how silly that sentence is?

Originally Posted by kovidgoyal

And I dont know of a single ebook viewing application that will not read HTML in an EPUB container. So lets not get too religuous about standards.

But you have to take into account the complexity involved with a full-fledged HTML parser. Portable device makers would really love it if they could just expect XHTML content in epub documents (and they should, because basic HTML is not supported by OPS) because then they could just use a lean, fast, lightweight parser. It would require less memory, CPU and power.

It's this "lets not get too religious about standards" attitude that makes that less likely to happen. So at the very least, don't recommend to other people that they flat-out ignore the standard and put HTML in source documents. XHTML is not that difficult to produce, and Tidy can convert the majority of HTML into conforming XHTML.