What was the matter with PDF?
timpromptu.com
timpromptu.com
Simply put, PDF is a format designed to allow me to give you a document where you can be sure (with certain well defined exceptions that I can work around anyway) that you see what I intended you to see. That works brilliantly if I want you to see a letter-sized 3-color document, or an A5 booklet, or a funky 3" x 9" flyer, or whatever other size I want.
This doesn't work with e-book readers, because my e-book reader isn't A4 or 8" x 6" or whatever other format the book is in. Epub, mobi, LRF etc. give the e-book reader the ability to format the text (if it's pure text, and not, as OP complains, pre-formatted with assumptions the e-book reader can't match) for the screen or for my options wrt. zooming and font size.
I say all of this as both an avid PDF user (I write lots of documentation), and an avid e-book user. You use the right tool for the job. If you're complaining about PDFs on your e-book reader, you're doing it wrong.
Well put. When I buy technical books, I always look for a PDF format. I want a copy of the book that is the same as the printed one and that's exactly the reason why I like PDF. Plus, things like diagrams and graphs are in vector graphics, and not raster as they are in EPUB/MOBI.
I've made the mistake of buying a couple of technical EPUB eBooks that contained graphs, and in all cases it was a complete abomination. The publishers seem to want to produce the smallest files they can, so what used to be vector graphics, become highly compressed and low resolution raster images. Trying to zoom in on a graph on your tablet gives you a resized blurry image.
I don't like this trend where some technical ebook publishers offer a PDF version of the book in addition to an EPUB, and the PDF ends up being a mere conversion from the EPUB version, having all the cons I mentioned above. This happened to me on InformIT when I bought "The Mythical Man-Month", and they ended up giving me a refund.
What surprises me about this conversation is how sad it makes me. Displaying documents accurately was a solved problem in 1985 at Xerox. They had a lot of folks who were to document display what web designers are to web page display. They would go on and on and on and on and on about the kerning or the way this ligature in this language had to have this sort of thing in order to be 'correct'. They had fights with Imagen whom they considered the "GeoCities" of document display. Don Knuth got so fed up with how poorly computer formatted documents looked that he wrote his own formatter, and part of that included a representation (dvi) which was designed to be a high fidelity source that could render to the 'best possible' form on the device. These guys generally fought over printers because display terminals were 25 lines of 80 characters for the most part (unless you had a Xerox D-machine).
The thing that makes me sad is that we haven't been able to capture any benefit from that war. Everything patented then has expired, whether it was the special 'hinting' Xerox used on fonts or the way they maximized the fidelity of the half toning on two color printers. Sigh.
Also, it's much less complex than PDF.
But publishing a book in HTML would require some genuine effort, as opposed to just exporting the book typeset for paper as a PDF, often not even trimming the margins which eat precious e-reader screen space.
Kindle books have truly terrible formatting and editing in general. Some are riddled with what look like OCR errors; in others, blockquotes and italicized regions start and end in the wrong places. Images are in awkward places. Sometimes just paging left and then paging right causes the page boundary to move.
The main reason, I've heard, is that even if the Kindle format and reader app are reasonable (and I can't vouch for them), it's on publishers to put their books in the right format. They have no idea how to do this, so they outsource it. Some publishers probably don't care about or dislike the Kindle platform.
I find it really, really sad and bizarre to read books with so many errors. Maybe you haven't come across a really bad one yet, but since it varies by publisher (and I'm talking about big, mainstream publishers), just wait, you will.
I'm all for high-tech, and do lots and lots of reading online, but....I like my books the old-fashioned way.
This is the real source of the problem. Publishers have every reason to suspect that Amazon will eat their profits and would be stupid to help Amazon accomplish its goal.
If the publisher doesn't give a fig about ebooks, their PDFs will also come out with misspellings.
I'll bite. I could have written this, and have said similar things here and there several times. The vitriol directed against PDF and me for recommending it has been quite surprising.
PDF doesn't reflow and a PDF formatted for a book-sized page will not be usable on your phone. No kidding! So write a script to run your LaTeX source (for example) multiple times for normal and large-type editions for, say, four canonical screen geometries.
This is akin to terrible apps on any App Store. It's up to the App Store guidelines to raise the standards and only allow certain books of quality.
Here is my experience based on building ebook-related products:
Amazon: Will allow almost any book of any kind, any formatting. Their singles publishing program is a little stricter since you're giving an exclusive to them and they plan to use those for marketing.
Apple: Strictest store in the business. Humans review every submittal and will kick back your book even if they deem the subject 'not wide enough for a large audience'. IF your book is 51% French, 49% english content but submitted in English, it'll get kicked back and so on.
I don't agree with Apples purview that you can only submit books that are for a large audience - who are they to judge that? Therefore people head to the wild world of Amazon and fight it out at the free or 0.99 level.
You also end up with users trying to open some dynamic form PDF with scripting and whatnot enabled, and of course your portable device balks because it doesn't support it, so now it gets kicked back to the device MFG because the PDF reader is "broken".
I don't think this is a question of formats; I think it's a question of "How do we show legible code samples on a 7" screen?".
I'd love a 10" kindle for reading technical books, can't see it happening though.
I presume he meant just using a bog standard computer/laptop but I could be wrong...
Yes, totally agree with you. I don't own an Kindle/iPad/Tablet, but tend to read my tech books on my laptop for this very reason.
PDF is for layout -- it is actually more of a graphic format than a text format. Contiguous text may be scattered around in the internal data representation, so long as the location of each character on the page is expressed. This is good for tables, formulas, and other items requiring precise layout.
EBooks are for a smooth reading experience, including wrapping. This will naturally disrupt layout.
I think that with some technical effort, it is possible to build an eBook that flows -- while still allowing precise layout where needed.
In a word, reflow.
For code, that's just not easy.
Lines in code samples do have to get wrapped fairly often on the Nook, but it's done in a sensible manner and there's a nice text editor style arrow icon to indicate which lines were wrapped.
What you really want to do is go with reflowable content that is formatted correctly (proper HTML/CSS), and if the content breaks across the page, changing the font size should help rectify.
(spoken from too many years of ebook + tech book experience)
I've read ebooks (ePUB) on my Nexus 7, but it's only usable for serious reading because I can increase the fonts without having horizontal scrolling (in vertical orientation). Without this, I'd probably need an e-paper based reader but even that might unusable for typical A4/letter formatted PDFs.
0: https://play.google.com/store/apps/details?id=udk.android.re...
ezPDF does have a persistent crop feature, and you can even set different crops for even/odd pages (which I understand is a killer feature of goodreader). ezPDF's UI gets really weird wrt page turning and scrolling while cropped though.
I just discovered that Mantano Reader has an awesome crop feature for PDF. The UX is really good. It does not have the even/odd thing though. This is my current leader for an ebook reading platform.
https://play.google.com/store/apps/details?id=com.mantano.re...
Just use a decent PDF reader such as GoodReader. It lets you ignore the margins so that you get the best experience.
Cropping is applied to all pages in the document, so once you use the handles to eliminate excessive margins, you've got nothing but the text. I find it indispensable, to the point where I prefer reading PDFs on the iPad to reading them anywhere else.
GoodReader's UI is a bit of a mess, but that's just a reflection of how many truly useful features it has. And the systematic elimination of margins - including the ability to handle left and right pages differently - makes technical manuals and papers actually readable.
Not having GoodReader was easily one of the worst problems I faced when I switched to Android - there's just nothing like it.
However, most PDFs don't work at all well on ebook readers.
If you make a monochrome PDF with minimal margins, with a sensible font size, for a 6 or 7" screen, it will be attractive and readable on a that screen. It can - if you do it right - have better wrapping, widow/orphan control, and fonts than a normal ebook, too. I have an old Sony Reader PRS-505. The screen's the same as a Kindle, but the processor is slow, and paginating its native format takes ages. Nonetheless, it can display PDFs very rapidly. Before I got a Kindle, I used to convert books from text into small PDFs, with attractive embedded fonts, and read them on the Sony that way.
However, if you try to read an A4 PDF, with two columns and massive margins, on a 7" screen, you're going to have a bad time.
The downside to using PDF is that you lose the ability to reflow. But that's the upside too, at least if you have complex content that's not amenable to reflowing; many technical books fit into this category.
Not sure if I have a higher tolerance for bad formatting or if the Kindle version has some formatting issues.
Zooming in and out just doesn't cut it.
Of course, you could write a different text with different diagrams for different viewport sizes, but besides spending more time writing your documents, it also becomes a referencing hell.
Or, stated differently, think about how information is represented best on different devices (device groups).
For example, I've built an interactive computer simulation connected to a graphing component to enable students to explore rate of change. On a computer screen the simulation and graph are thus positioned that there is a direct link between what happens in the graph and in the simulation. It doesn't fit on a smartphone. I can (automatically) change the setup to put the graph after (below) the simulation, but if the student cannot see the graph and the simulation simultaneously, they miss out on the support for learning the concept of change in the original configuration.
Another example, I taught a course on regular expressions and that included a unit on deterministic finite automatons. For non-trivial examples these automatons aren't comprehensible on small screens. Zoom and pan doesn't work to get a picture of the whole. On the other hand, I can think of a simulation of an automaton that would give a better picture on a small screen how a particular automaton works by using a simplified track representing the whole and focusing on a local state and input to see the effect of connections in the track. However, this would mean two different approaches to learning automatons that aren't necessarily compatible, especially in an introductory course. Students will have different questions and problems with the different representations. They will construct different ideas about automatons that might make communicating in class about automatons troublesome as students don't understand each other while talking about the same thing. But it goes further than that, these representation will need different introductions, different exercises, maybe even a different structured learning trajectory to build a similar understanding of automatons.
For example, with your interactive simulation, could the entities change colour or shape to show rate of change?
With your automatons, I would have thought it wise to try to separate the different groups and then step through each group. Understanding each group in order for me would be the best way to learn it than nitpicking at different parts of the whole system.
When MobiPocket (the basis for Kindle format) and ePub were specced, the world looked like this:
>>>I can read a PDF on my laptop, desktop
Expensive hardware with powerful CPUs. Kindle/ePub were designed for weak CPUs that could basically handle text (K/ePub -- tarted-up text files) well. Back then, these were PDAs.
It's only been really recently -- with iPad 4 -- that monster PDFs, such as those from Google Books (scans of original book/magazine pages), can be read without wanting to toss the hardware against the wall.
Don't blame the format - blame the publisher!
I might be talking nonsense here, but I swear there is a niche market for some kind of affordable (<$100) tablet specifically designed for PDFs.
What would differentiate the hardware from current tablets to make that price possible?
And then what kind of PDF do you mean? Something squirted from a word processing/page-layout file that permits reflow or a collection of image scans (see Google Books) that are static? It's not that easy.
I know I'm being ridiculous. I'm just bummed that I can't read some of these really awesome books with the same leisure that I can a Kindle book or a physical book. First world problems, etc. I have to get over being phenomenologically appalled at the idea of reading a book in the same space I read message boards. There's a weird mental block there.
Ebooks eliminate any typographical support (good) books can deliver.
Can we have this conversation without resorting to highly gendered stereotypes for trivial-media-that-I'm-not-interested-in examples?
Of course, HTML presents the same stupefying array of possibilities, except in the form of visual output...which is why I guess we needed PDF in the first place.