I love PDF for the advanced layout options and beautiful font handling. Design-heavy media (magazines, sheet music, some poetry, comics, maps, some novels) often have no other option for any remotely faithful representation. The cute thing is Adobe’s tight control means there is always a reference implementation to follow if the spec is inconsistent or vague. Just “do what Adobe Reader does”. PDF is Virtual Paper and it is pretty darn good at it, coming from a fine Postscript heritage.

OF course, that’s part of the problem. PDF sucks for portability and usability on any device that doesn’t have a huge, high res screen. Even then almost all PDF readers are obnoxious. Some aren’t stable. Many non Adobe products have missing features. Almost all can’t allow for reformatting, converting, or even printing the contents under certain conditions. Oh, and I know about tagged PDFs. This is one of the more clever things Adobe bolted onto the spec. Guess what? Generating this metadata requires careful oversight and editing to get RIGHT. We might as well be using XML! Oh, wait….

I love XML+CSS formats for heritage and usefulness. For pure text content it cannot be beaten. Not to mention that it is designed to be infinitely extended, so any kind of craziness can be slid in. Since it is based on open standards, no single company’s whims are law. Careful users of XML formats can even create self-documenting documents. Structure is the core of good XML and whatever metadata isn’t THERE can be inferred easily. And for integration with Content Management Systems and databases? They luv XML. Simply, PDF specifies EXACTLY what and where everything is rendered, while XML only describes the content and lets the clients (and users) determine how to process it. Which leads to the flaws.

The problems are mainly with design. Precise layout adjustments using CSS are a series of approximations, with every engine having different interpretations of the standards. Assuming they actually follow them at all. Font and layout support have improved greatly (at least in web browsers) but many ebook readers have yet to leverage these improvements. Converting paper books takes time and care to do right, because XML thrives on structure and organization. Without it, there is only bland tag soup. Standards bodies have tried their best to improve things (SVG, MathML, CSS3), but bolting Postscript/PDF onto XML makes about as much sense as bolting XML onto PDF.

In a perfect world, both formats would not compete. They would do what they are good at (PDF as virtual paper, XML as Content und Structure über alles) until some super format could absorb them both. Wait, no, that could be bad. I imagine some crazy serialization of PDF into an XML schema that could take precise layout instructions in an external file. Now I imagine these instructions to be in some magical Dr. Frankenstein language combining CSS, XPath and/or bits of Postscript and JavaScript. This is either the Best or Worst thing ever.

Alas, PUBLISHERS need to learn about tagged PDFs, not readers. There was a recent thread on rec.arts.sf.written about the free e-book version of Scott Sigler’s “Infected”. It was only offered in untagged PDF formatted for hardcover-sized pages. This made it unusable on a lot of e-book reading devices, which tend to be PDAs or dedicated readers with smaller screens. This happens a lot.

As it happens, Mobipocket’s latest version will convert the file into a useable prc file, rendering it readable in other formats. The conversion did, however, introduce some font and formatting problems.

In general, I wouldn’t bother to take the time to discover the conversion at all, and Mr. Sigler would lose my attention, falling back into the hordes of authors who suffer from “too many books, too little time.” In this case, since my interest was piqued for other reasons, I did a little bit of legwork.

PDFs, in my experience, are a warning flag for the general run of e-book readers. Until authors and publisher learn how to cope with this, PDFs will discourage many people from reading e-books in that format. Readers, like myself, generally won’t bother with the extra time and effort. We’ll just read something else.

Regards,
Jack Tingle

If I can’t print a passage of text, can’t copy a passage of text, or even annotate the PDF I reading, this makes the ebook almost useless for study purposes. I really believe that the people making these decisions either don’t have a clue about how people need to use their ebook, or they just don’t care, as long as they have your money.

I imagine that a DRM’d .epub file could be set to have the same limitation (can someone who has produced such a file confirm?).

————-

I doubt you’re going to get anyone to confirm this, as DRM is not in the current epub spec. Apparently, Adobe has implemented some form of DRM to use with epub in their Digital Editions reader software. I don’t know any more about it, however.

I don’t have to worry about optimizing the Mobi and .epub files for a particular machine, the way Todd has been doing with PDF.

I assume you mean that you don’t have to worry about optimization as a *consumer* of e-books — and, of course, you shouldn’t have to. The *publisher* should worry about this for you, as, for example, the nice folks at “manybooks.net” have done; just go to the page for the title in which you’re interested, select the appropriate device from a pulldown menu, et voilà. This is the sort of publishing environment in which the toolkit I’m developing would be potentially useful; these are not end user tools.

Is it possible that PDF works out better on Macs than on PCs?

Quite possibly. Mac OS is very PostScript oriented and uses Display PostScript extensively in the UI (the dock icons, for example, are PDF images, not bit-mapped images, which explains why they scale so nicely when you roll the mouse over them.)

Mac OS also provides native ability to print to a PDF file from any application (a feature which many Windows users envy), and the Preview utility provides a perfectly acceptable, lightweight image browser with PDF support that most Mac users prefer to Acrobat Reader.

I hope the defenders will pay attention to Ficbot’s complaints about Adobe software crashing browsers.

This has absolutely nothing to do with PDF as a file format, and has everything to do with poor quality application software. IMHO Ficbot would be wise to explore alternative PDF browser plug-ins, or to consider configuring the machines in her classroom to use an external PDF browser.

I can’t comment on Acrobat Reader (I’m not a big fan of Adobe software myself, and I use it only when absolutely necessary), but I can attest to the fact that Adobe is capable of writing perfectly atrocious software. The absolute, rock-bottom, worst application software I have ever used in my life was a video editing abomination called Adobe Premier. Even though I paid close to $1K for it, I replaced it with a competing product in less than a year.

Ficbot writes:

PDF documents are very hard to edit.

Once again, this is a case of the wrong tool for the job. PostScript and PDF were designed for page-oriented, printed output and were never intended as editable formats. Since the specs for these formats are published, it’s *possible* to write an application that allows them to be edited, but just because it’s possible doesn’t necessarily mean it’s a good idea. If editable content is the goal, PDF is certainly not the best tool for the job.

I imagine that a DRM’d .epub file could be set to have the same limitation (can someone who has produced such a file confirm?).

But I guess that’s really more of a scanning versus OCRing. But if nothing else, Acrobat Reader has been the clunkiest, slowest program to open up on the school computers. I replaced it with Foxit Reader on my own compy, and while that has made dealing with pdfs less painful, I still would prefer to have a more flexible format for dealing with everything.

[Moderator: Ballantine Hall, shown in photo below from bloomingpedia, is at Indiana University. That's the "IU" mentioned above. - DR]

That said, I think I hope the defenders will pay attention to Ficbot’s complaints about Adobe software crashing browsers. I doubt that publishers will agree with her wish to be able to modify files. But look, what if there were a way of changing things within PDF while flagging these changes and allowing people to revert to the original version and even tracking the changes? I might do a separate post on that. With HTML-style flexibility and more, clearly, the content would be much more useful in K-12.

As for the problems with screen size, that remains. Gerry, even on my desktop machine, I have trouble figuring out the right size for Wowio books. And this is true not just with my regular Adobe reader but also within Digital Editions. With alternatives like Mobipocket and .epub, by contrast, I fire up the files and they just work. I don’t have to worry about optimizing the Mobi and .epub files for a particular machine, the way Todd has been doing with PDF. Hey, each to his/her own. That’s just my take.

In her reply to my post, Kate raises excellent questions about page numbering and locations of specific items. but I would hope these could be addressed through workarounds within HTML and, longer term, through .epub standards. If there could be ways to coordinate online page-numbering with the paper variety, that would be wonderful.

Also let me ask yet another question. Is it possible that PDF works out better on Macs than on PCs? Some of the most passionate PDF defenders are Mac people. Of course, the real reason could be that the Mac has more than its share of fans among publishers, who enjoy the amount of control that PDF gives them over a document’s appearance. My own priorities, by contrast, even though I’m a writer, are those of a reader, a user.

Answering Rob, I wonder if PDF is popular among many users because they’re printing out files, or because that’s what their systems come with.

Finally I’ll conclude with a reminder that the TeleBlog is for PDF haters and lovers. We need both/all viewpoints here, and I’m really glad that pro-PDF people are around, so that we HTML and .epub types can be more aware of the deficiencies of our favorites and address them—one reason why I think Sophie in great for .epub, in terms of reminding the IDPF of features missing from the standard. Similarly, I hope that we skeptics’ complaints about PDF will be helpful to those who believe in it. We have visitors from Adobe and I’m sure they’ll be following this debate very closely.

Thanks,
David

PDF, as I see it, is a toxic to e-books—given all the scrolling and other hassles it creates for me when I use it on small screens.

What on earth does this mean, David? If a book contains 500 pages, you still have to turn 499 pages regardless of whether the book is published in PDF or another format, don’t you?

If you’re trying to read a PDF document formatted for an 8.5 x 11 page on a handheld device, that’s another matter — the wrong tool for the job, if you will. If, on the other hand, the PDF file has been properly formatted for the device on which you read it, I don’t understand your objection.

PDF’s page orientation can be both a strength and a weakness. As my first effort to produce custom content for my iRex iLiad, I tediously formatted the text of a play using a word processor to produce a PDF file. Next I marked up the text of the play as an XML file and used XML-based tools to produce an HTML version of the same play.

I like to have a header on each page that contains the name of the work and a chapter/act/scene number just to help me keep my bearings in the book as I read it. This was easily accomplished in the PDF version, but not the HTML version. There’s also the matter of the blank line between blocks of text (paragraphs, lines in a play, etc.) The manual production of the PDF version allowed me to make sure that these never appeared at the top of a page, but I have no control over this in the HTML version. Widows are a problem in HTML, too; I put the name of the character who speaks a line of dialog in a play on the line preceding the dialog, and these are often separated when viewing the play in HTML format.

My XML-based tools depend on a library of CSS stylesheets to handle the vagaries of various specific devices, so matters like page and font sizes aren’t a problem. The visual formatting of the automatically flowed HTML text, however, remains a problem that I have yet to resolve. Some of these will be resolved by HTML 5.0, but I’m not going to hold my breath waiting for browser support.

My future plans for this toolkit are to make it possible to convert an XML file into multiple PDF files (rather than HTML files) optimized for specific devices, but this will require me to dip my toes into the murky waters of something called XSL-FO, an adventure I’m saving for the summer, when I’ll have more time to devote to the project.

Bottom line: from where I sit, PDF is superior to HTML for this type of application as well as the best format currently available.

I offer PDF because customers seem to like it. As a big eBook reader myself, I prefer other formats.

Rob Preece
Publisher, http://www.BooksForABuck.com

I’m not familiar with annotation features on PDF. Perhaps that is available only for people who bought the converter?