PDF vs LRF etc - Page 3

kovidgoyal · 02-25-2009, 01:09 PM

Quote:

Originally Posted by Valloric

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?

Do I really need to point out the difference between parsers and parsing libraries to you?

Quote:

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.

Umm in a standard that has support for SVG images and XHTML rendering you're worried about the overhead of HTML parsing? And just to make it clear note I said *rendering* and not parsing.

Valloric · 02-25-2009, 01:26 PM

Quote:

Originally Posted by kovidgoyal

Do I really need to point out the difference between parsers and parsing libraries to you?

No.

My point is that those libraries contain code, and that code has it's own level of complexity. You're not diminishing complexity by using someone else's code, you're just diminishing the amount of work you as the programmer need to perform. And I'm not worried about the work involved, but the resources consumed.

Quote:

Originally Posted by kovidgoyal

Umm in a standard that has support for SVG images and XHTML rendering you're worried about the overhead of HTML parsing? And just to make it clear note I said *rendering* and not parsing.

SVG is a good point. That I concede.

But supposing one creates an XHTML parser + renderer that doesn't support SVG, one could support the vast majority of epub books out there (I'm not saying this in and of itself is a good thing). Lenient HTML parsing is non-trivial.

And it's not just the resources. Do we really need the agony of different rendering with different Reading Systems if people start using HTML? Look at the modern web. You know that any designer worth his salt has to check each any every goddamn browser out there for incompatibilities, quirks etc. And it's not just because of IE. Do we really want that for ebooks?

How about we stick to the prescribed standard for once? Let's try that out and see how it goes. And to get there, the mentality has to change. People need to start caring about standard compliance.

Let's at least try to.

llasram · 02-25-2009, 01:31 PM

Quote:

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.

Almost... Digital Editions only handles OPF 2.0, so you need to update the OPF from 1.0.x to 2.0. You also need a 'META-INF/container.xml' file which points to where in the ZIP file the OPF file is and a 'mimetype' file (as the first file in the archive, uncompressed) containing the EPUB mimetype. To be actually compliant with the spec, all the HTML content also needs to be valid XHTML, but none of the currently-available reader apps are actually enforcing that so you should be fine. (Unfortunately -- doomed we are again to another 10 years of tag soup.)

-Marshall

llasram · 02-25-2009, 01:33 PM

Quote:

Originally Posted by Valloric

Do we really need the agony of different rendering with different Reading Systems if people start using HTML?

Unfortunately we're already there. Digital Editions doesn't choke on invalid XHTML and thus none of the commercially-published EPUB books I've looked at come close to validating.

Valloric · 02-25-2009, 01:36 PM

Quote:

Originally Posted by llasram

Unfortunately we're already there. Digital Editions doesn't choke on invalid XHTML and thus none of the commercially-published EPUB books I've looked at come close to validating.

THANK YOU!

My point exactly.

If it did, a lot more epubs would be standards-compliant.

=X= · 02-25-2009, 01:58 PM

Quote:

Originally Posted by UncleIvor

Most of my stuff on the 505 has been converted from plain text. It's tempting to convert to some format like LRB, but instead, I've made a template in Open Office with correct page size, font size, margins, para indent, space after para, etc, and converted to pdf with fonts embedded.
That way I have full control over appearance, and to me the biggest issue is readability.
One of the problems with LRB etc is that the small font seems too small, and the medium too large (particularly with wide margins).
The downside is, of course, file size - but since I've now added a 2Gb sd card for the flashing, I'd have to have an awful lot of books on the reader to even make a small dent in the memory available.
The 505 doesn't handle pdfs very well, but if the formatting is correct in the first place, that's not an issue.
What do others think?

[Originally posted elsewhere, and it was suggested that it might make a more general thread]

You'll most defiantly get the best results creating a PDF that is made specifically for the 505, though how much better is very subjective. I've done this numerous times and tend to like the way PDF looks vs LRF. This is especially true if your document contains charts, tables, graphics.

I tend to create LRF because it is less effort to LRF file from a LIT/MOBI, where as the PDF files seem to take some time.

=X=

kovidgoyal · 02-25-2009, 02:23 PM

Umm You can write a perfectly good HTML parser in about 1500 lines of code. If you regard that as complexity then I'm sorry, but we are just going to have to disagree on that.

As for the difference in browser behavior, that comes primarily from differences in the way browser render different (X)HTML elements, not from using HTML instead of XHTML. Insisting on strict XHTML instead of HTML would resolve only a few of the more minor issues with cross browser rendering. Far more important the HTML vs XHTML is proper support for the box rendering model of CSS. For example ADE has al sorts of bugs with rendering HTML that exist whether the input is HTML or perfectly valid XHTML.

Indeed XHTML vs. HTML is such a triviality that I would regard it as a non-issue. Ebook viewing software if it is going to be successful *will* accept HTML input. The only place it matters is in ebook conversion/creation software which should go the extra mile to ensure its output is as close to XHTML as possible.

And as for insisting that epub viewers only accept strict XHTML, that would have killed epub even before it got off the ground. Standards are well and good, but growth doesn't come from standards, standards come from growth. Strict adherence to standards would kill growth. At the same time it is important to try to adhere to standards *as much as possible*.

kovidgoyal · 02-25-2009, 02:24 PM

Quote:

Originally Posted by Valloric

THANK YOU!

My point exactly.

If it did, a lot more epubs would be standards-compliant.

If it did, there wouldn't be any epubs.

Valloric · 02-25-2009, 03:06 PM

Quote:

Originally Posted by kovidgoyal

If it did, there wouldn't be any epubs.

Sadly, this is quite possibly true.

kovidgoyal · 02-25-2009, 03:14 PM

Yeah from a programmers perspective it would be *so* nice if everyone just agreed to play by the rules and stick to the standards as religuously as possible. Unfortunately, that never seems to happen in the real world

Valloric · 02-25-2009, 03:23 PM

Quote:

Originally Posted by kovidgoyal

Yeah from a programmers perspective it would be *so* nice if everyone just agreed to play by the rules and stick to the standards as religuously as possible. Unfortunately, that never seems to happen in the real world

Joel has a very nice post on standards-compliance. I read it some time ago, but I remember it was very good.

UncleIvor · 02-25-2009, 07:17 PM

So, if an ePub is HTML packaged up in a ZIP file, why can't the Sony read HTML files direct?

kovidgoyal · 02-25-2009, 07:23 PM

Quote:

Originally Posted by Valloric

Joel has a very nice post on standards-compliance. I read it some time ago, but I remember it was very good.

He seems to be all for the practical point of view.

Valloric · 02-26-2009, 09:13 AM

Quote:

Originally Posted by kovidgoyal

He seems to be all for the practical point of view.

Unless I read that article very incorrectly, he seems to be neutral.

Quote:

Originally Posted by Joel

You see? No right answer.

As usual, the idealists are 100% right in principle and, as usual, the pragmatists are right in practice. The flames will continue for years. This debate precisely splits the world in two. If you have a way to buy stock in Internet flame wars, now would be a good time to do that.

Obviously, I'm the idealist, and you're the pragmatist. So let's agree to disagree and that's that.

kovidgoyal · 02-26-2009, 01:12 PM

Quote:

Originally Posted by Valloric

Unless I read that article very incorrectly, he seems to be neutral.

Obviously, I'm the idealist, and you're the pragmatist. So let's agree to disagree and that's that.

Cool

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
LRF to PDF	pikoman	Calibre	0	12-08-2009 07:59 AM
PDF to LRF or EPUB help...	Spit	Calibre	0	08-14-2009 04:10 PM
.pdf versus .lrf	popa	Introduce Yourself	6	07-14-2009 12:32 PM
PDF - LRF	VanillaEps	Sony Reader	7	05-11-2009 12:34 PM
How to convert PDF to LRF	silkcom	Sony Reader	18	03-12-2009 06:26 AM

02-25-2009, 02:23 PM	#37
kovidgoyal creator of calibre Posts: 45,271 Karma: 27111060 Join Date: Oct 2006 Location: Mumbai, India Device: Various	Umm You can write a perfectly good HTML parser in about 1500 lines of code. If you regard that as complexity then I'm sorry, but we are just going to have to disagree on that. As for the difference in browser behavior, that comes primarily from differences in the way browser render different (X)HTML elements, not from using HTML instead of XHTML. Insisting on strict XHTML instead of HTML would resolve only a few of the more minor issues with cross browser rendering. Far more important the HTML vs XHTML is proper support for the box rendering model of CSS. For example ADE has al sorts of bugs with rendering HTML that exist whether the input is HTML or perfectly valid XHTML. Indeed XHTML vs. HTML is such a triviality that I would regard it as a non-issue. Ebook viewing software if it is going to be successful will accept HTML input. The only place it matters is in ebook conversion/creation software which should go the extra mile to ensure its output is as close to XHTML as possible. And as for insisting that epub viewers only accept strict XHTML, that would have killed epub even before it got off the ground. Standards are well and good, but growth doesn't come from standards, standards come from growth. Strict adherence to standards would kill growth. At the same time it is important to try to adhere to standards as much as possible.

02-25-2009, 03:14 PM	#40
kovidgoyal creator of calibre Posts: 45,271 Karma: 27111060 Join Date: Oct 2006 Location: Mumbai, India Device: Various	Yeah from a programmers perspective it would be so nice if everyone just agreed to play by the rules and stick to the standards as religuously as possible. Unfortunately, that never seems to happen in the real world

02-25-2009, 07:17 PM	#42
UncleIvor Enthusiast Posts: 36 Karma: 1510058 Join Date: Dec 2008 Device: Various Kobo readers, Sony readers from the past.	So, if an ePub is HTML packaged up in a ZIP file, why can't the Sony read HTML files direct?

Advert

Advert