<story><title>PDF: Still unfit for human consumption, 20 years later</title><url>https://www.nngroup.com/articles/pdf-unfit-for-human-consumption/</url></story><parent_chain><item><author>jcrawfordor</author><text>Any complaint about the PDF format tends to be hard to address because the PDF format is so complicated and so flexible---except, of course, for the argument that the PDF format is too complicated and flexible, which tends to be the one enduring criticism since it has lead to a history of various security, compatibility, and performance issues related to PDFs.&lt;p&gt;The major attempts to replace PDF have largely failed, though. DjVu is relatively limited in scope. Postscript (as a document display format) has never been well-supported on Windows and is increasingly poorly supported on Linux due to rarity. XPS is perhaps the most direct &amp;quot;PDF replacement&amp;quot; but is nearly equally complicated (being based on the MS Office OOXML formats, giving it a similar cursed heritage to PDF&amp;#x27;s basis in the Photoshop PSD format), and there was never really a compelling argument to switch to it.&lt;p&gt;What I don&amp;#x27;t get is the suggestion that PDF should be replaced by HTML. The purposes of the two formats are basically orthogonal and replacing one with the other is doomed to failure. The author&amp;#x27;s argument seems more akin to &amp;quot;print-layout documents should be replaced by hypertext,&amp;quot; and perhaps this is true in some cases, but it&amp;#x27;s definitely a different matter and one that the author&amp;#x27;s arguments don&amp;#x27;t really support that well.&lt;p&gt;In my opinion, hopefully more humble than the author&amp;#x27;s, PDF&amp;#x27;s main downside is the remarkable unevenness of the quality of the creation and reading tools, considering its supposedly &amp;quot;reads everywhere&amp;quot; nature. The &amp;quot;reference implementation&amp;quot; is a commercial product and supports a huge list of features that are rarely or never supported by third-party commercial or open-source implementations. The Linux toolchain still widely used with PDF (e.g. Ghostscript) is decidedly outdated and hard to work with, but there&amp;#x27;s not a lot of momentum towards development of more modern tools. All of these issues are likely rooted in the basic fact that the PDF format is extremely complicated, and so thoroughly implementing it is a massive undertaking.&lt;p&gt;The author&amp;#x27;s complaints about performance in particular reflect the flexibility and complexity of the format. Web browsers have mostly switched over to using pdf.js to render PDFs, which is completely satisfactory for documents that consist of text or images (like scanned documents), but can be absolutely unusable when dealing with extremely vector-heavy PDFs like GIS exports.&lt;p&gt;Even printing PDFs can become rather frustrating as the complexity of the format means that parse-related printing issues are relatively common. Even Acrobat, for a long time, would munge certain characters when printing due to some sort of inconsistency with how different generators and readers implemented font embedding leading to Acrobat not being able to locate the embedded character font. This seemed most common with the letter &amp;quot;l&amp;quot; but maybe I&amp;#x27;m imagining that... but also maybe it reflects some frightening detail of the format or implementation behavior.&lt;p&gt;One of the most common issues around PDF consistency comes down to file size... different PDF generators are prone to create representations of the same document that are significantly different sizes. Scanners are often an extreme example, some combination of not &amp;quot;knowing the tricks&amp;quot; for PDF optimization and a probably very low-performance compression implementation means that low-end network scanners often produce PDFs that are hilariously large. Opening them in Acrobat and using the &amp;quot;optimize file&amp;quot; tool can reduce file size by 90% without apparent visual impact... the whole fact that Acrobat has an &amp;quot;optimize&amp;quot; tool (and that Acrobat Distiller used to exist) speaks to the scale of this problem. Inspecting PDFs that are &amp;quot;optimized&amp;quot; by Acrobat can be an alarming experience, as well. You may remember that this played a strange role in Obama&amp;#x27;s birth certificate some years back, as Acrobat seems to normally split PDFs into all kinds of different layers and apply strange transformations to them when it &amp;quot;optimizes.&amp;quot; It&amp;#x27;s hard to know how much of this is actually &amp;quot;best practice&amp;quot; versus just a result of Acrobat accumulating decades of eccentricities.&lt;p&gt;So the bottom line is... PDF is too complicated for its own good, but then so are a great deal of other formats in widespread usage, like modern webpages which require complex parsing of multiple formats to render, and a great deal of historic cruft brought along with them. I&amp;#x27;m not sure that there&amp;#x27;s any sound technical argument that PDF or web pages are a &amp;quot;better format,&amp;quot; it&amp;#x27;s all a matter of opinion over whether you prefer print-format documents or hypertext, and that&amp;#x27;s going to be very application-specific.</text></item></parent_chain><comment><author>Thorentis</author><text>&amp;gt; PDF&amp;#x27;s main downside is the remarkable unevenness of the quality of the creation and reading tools&lt;p&gt;Funny enough, I think one of the reasons PDF became so popular, is because it was originally seen as a &amp;quot;difficult &amp;#x2F; impossible to modify file that can be downloaded as a file and read in a static way&amp;quot;. The lack of editing tools in the most popular PDF reader for a long time (Acrobat Reader) was the reason it became such a widely used format. Especially compared to distributing a .doc or .docx where the user can easily accidentally change something.</text></comment>
<story><title>PDF: Still unfit for human consumption, 20 years later</title><url>https://www.nngroup.com/articles/pdf-unfit-for-human-consumption/</url></story><parent_chain><item><author>jcrawfordor</author><text>Any complaint about the PDF format tends to be hard to address because the PDF format is so complicated and so flexible---except, of course, for the argument that the PDF format is too complicated and flexible, which tends to be the one enduring criticism since it has lead to a history of various security, compatibility, and performance issues related to PDFs.&lt;p&gt;The major attempts to replace PDF have largely failed, though. DjVu is relatively limited in scope. Postscript (as a document display format) has never been well-supported on Windows and is increasingly poorly supported on Linux due to rarity. XPS is perhaps the most direct &amp;quot;PDF replacement&amp;quot; but is nearly equally complicated (being based on the MS Office OOXML formats, giving it a similar cursed heritage to PDF&amp;#x27;s basis in the Photoshop PSD format), and there was never really a compelling argument to switch to it.&lt;p&gt;What I don&amp;#x27;t get is the suggestion that PDF should be replaced by HTML. The purposes of the two formats are basically orthogonal and replacing one with the other is doomed to failure. The author&amp;#x27;s argument seems more akin to &amp;quot;print-layout documents should be replaced by hypertext,&amp;quot; and perhaps this is true in some cases, but it&amp;#x27;s definitely a different matter and one that the author&amp;#x27;s arguments don&amp;#x27;t really support that well.&lt;p&gt;In my opinion, hopefully more humble than the author&amp;#x27;s, PDF&amp;#x27;s main downside is the remarkable unevenness of the quality of the creation and reading tools, considering its supposedly &amp;quot;reads everywhere&amp;quot; nature. The &amp;quot;reference implementation&amp;quot; is a commercial product and supports a huge list of features that are rarely or never supported by third-party commercial or open-source implementations. The Linux toolchain still widely used with PDF (e.g. Ghostscript) is decidedly outdated and hard to work with, but there&amp;#x27;s not a lot of momentum towards development of more modern tools. All of these issues are likely rooted in the basic fact that the PDF format is extremely complicated, and so thoroughly implementing it is a massive undertaking.&lt;p&gt;The author&amp;#x27;s complaints about performance in particular reflect the flexibility and complexity of the format. Web browsers have mostly switched over to using pdf.js to render PDFs, which is completely satisfactory for documents that consist of text or images (like scanned documents), but can be absolutely unusable when dealing with extremely vector-heavy PDFs like GIS exports.&lt;p&gt;Even printing PDFs can become rather frustrating as the complexity of the format means that parse-related printing issues are relatively common. Even Acrobat, for a long time, would munge certain characters when printing due to some sort of inconsistency with how different generators and readers implemented font embedding leading to Acrobat not being able to locate the embedded character font. This seemed most common with the letter &amp;quot;l&amp;quot; but maybe I&amp;#x27;m imagining that... but also maybe it reflects some frightening detail of the format or implementation behavior.&lt;p&gt;One of the most common issues around PDF consistency comes down to file size... different PDF generators are prone to create representations of the same document that are significantly different sizes. Scanners are often an extreme example, some combination of not &amp;quot;knowing the tricks&amp;quot; for PDF optimization and a probably very low-performance compression implementation means that low-end network scanners often produce PDFs that are hilariously large. Opening them in Acrobat and using the &amp;quot;optimize file&amp;quot; tool can reduce file size by 90% without apparent visual impact... the whole fact that Acrobat has an &amp;quot;optimize&amp;quot; tool (and that Acrobat Distiller used to exist) speaks to the scale of this problem. Inspecting PDFs that are &amp;quot;optimized&amp;quot; by Acrobat can be an alarming experience, as well. You may remember that this played a strange role in Obama&amp;#x27;s birth certificate some years back, as Acrobat seems to normally split PDFs into all kinds of different layers and apply strange transformations to them when it &amp;quot;optimizes.&amp;quot; It&amp;#x27;s hard to know how much of this is actually &amp;quot;best practice&amp;quot; versus just a result of Acrobat accumulating decades of eccentricities.&lt;p&gt;So the bottom line is... PDF is too complicated for its own good, but then so are a great deal of other formats in widespread usage, like modern webpages which require complex parsing of multiple formats to render, and a great deal of historic cruft brought along with them. I&amp;#x27;m not sure that there&amp;#x27;s any sound technical argument that PDF or web pages are a &amp;quot;better format,&amp;quot; it&amp;#x27;s all a matter of opinion over whether you prefer print-format documents or hypertext, and that&amp;#x27;s going to be very application-specific.</text></item></parent_chain><comment><author>chipotle_coyote</author><text>&amp;gt; What I don&amp;#x27;t get is the suggestion that PDF should be replaced by HTML. The purposes of the two formats are basically orthogonal and replacing one with the other is doomed to failure.&lt;p&gt;Isn&amp;#x27;t &amp;quot;the purposes of the two formats are basically orthogonal&amp;quot; actually the entire point the article is making? Literally the first line of the summary:&lt;p&gt;&amp;gt; Research spanning 20 years proves PDFs are problematic for online reading. Yet they’re still prevalent and users continue to get lost in them.&lt;p&gt;From the second paragraph:&lt;p&gt;&amp;gt; The [PDF] format is intended and optimized for print. It’s inherently inaccessible, unpleasant to read, and cumbersome to navigate online.&lt;p&gt;The bolded statement in the second paragraph that&amp;#x27;s clearly meant to be the One Important Thing to Take Away:&lt;p&gt;&amp;gt; Do not use PDFs to present digital content that could and should otherwise be a web page.&lt;p&gt;Your comment here is eloquent, but the article&amp;#x27;s argument is not &amp;quot;print-layout documents should be replaced by hypertext,&amp;quot; it&amp;#x27;s &amp;quot;print-layout documents are a poor fit for reading on screen-layout devices.&amp;quot; When you conclude:&lt;p&gt;&amp;gt; It&amp;#x27;s all a matter of opinion over whether you prefer print-format documents or hypertext, and that&amp;#x27;s going to be very application-specific.&lt;p&gt;Aren&amp;#x27;t you essentially restating the article&amp;#x27;s thesis?&lt;p&gt;I don&amp;#x27;t want to read an article online that&amp;#x27;s a PDF for largely the same reason that I don&amp;#x27;t want to print the web version of the same article rather than a PDF. It&amp;#x27;s generally going to be clunky. The print page size and dimensions are not going to be my screen&amp;#x2F;window size and dimensions. I certainly don&amp;#x27;t want to read two- or three-column text on screen, which may require zooming in and out and scrolling back and forth on the same &amp;quot;print&amp;quot; page. And God help me if I&amp;#x27;m trying to do that on my phone or iPad mini.&lt;p&gt;The article isn&amp;#x27;t saying &amp;quot;PDF is terrible and nobody should ever use it&amp;quot;; it&amp;#x27;s saying &amp;quot;PDFs were meant for specific applications and in nearly all circumstances, online reading is not it.&amp;quot;</text></comment>