Quote:
Originally Posted by anamardoll
I could not disagree more, but I suspect it's because I use PDFs very differently from how you do.
PDF is valuable because if you need a certain page layout, PDF can guarantee that layout. It's a freeze on the information contained in the document, as it relates to all the other information.
I have many graphics-heavy books (i.e., comic books) that are in PDF. I would be extremely upset if eReader manufacturers just announced they weren't going to support them because of an ideology about what is/isn't a true eReader format.
Saying "render it in HTML" does not fix the issue in all cases where PDF is necessary. Heck, I don't think it would fix the issue in MOST cases.
(Reminds me of those arguments that a color eReader isn't a REAL eReader because it's not in eInk. Pffft.  ) |
Your requirement for "a certain page layout" is paper-thinking. That's not how the digital world is supposed to work. Of course we see the same thing every day on the web, sites with fixed-width, fixed-font size layouts (or worse, Flash-based layouts. Ugh) attempting to get a pixel-perfect representation of a paper design that simply doesn't work on the web where end users have control over rendering and can have different browser sizes, different font faces and sizes, different browsers with different-but-valid interpretations of specifications, different plugins like greasemonkey or Stylish that allow the user to directly modify web pages, etc. The web (and ebooks as an extension of that) is not a world where designers can have pixel-perfect control, nor should it be, and designers who attempt to shoehorn a paper design into the digital world are Doing It Wrong(tm). Users/readers should have control over rendering, and the designer's layout should only be an initial guideline.
As for comic books, those are all images. They should be in image-based comic book formats like CBR or (preferably) CBZ. More ereaders should support at least CBZ (support CBR has licensing issues, since it uses RAR for compression which is not an open spec), but unfortunately the Nook doesn't.
That is the kind of thing that ereader developers should work on, rather than trying to support the unsupportable PDF.
And "render[ing] it in HTML"
can fix the issue, if you redefine the issue. Rather than asking for a paper-like layout, ask what is it that you really need -- tabular data, indexable data, linkable data, etc. And then ask why that can't be done with HTML (hint: it can). I can't say I've ever seen a PDF that couldn't have been better-written as HTML.