PDF: Still unfit for human consumption, 20 years later

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.<p>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 &quot;PDF replacement&quot; but is nearly equally complicated (being based on the MS Office OOXML formats, giving it a similar cursed heritage to PDF&#x27;s basis in the Photoshop PSD format), and there was never really a compelling argument to switch to it.<p>What I don&#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&#x27;s argument seems more akin to &quot;print-layout documents should be replaced by hypertext,&quot; and perhaps this is true in some cases, but it&#x27;s definitely a different matter and one that the author&#x27;s arguments don&#x27;t really support that well.<p>In my opinion, hopefully more humble than the author&#x27;s, PDF&#x27;s main downside is the remarkable unevenness of the quality of the creation and reading tools, considering its supposedly &quot;reads everywhere&quot; nature. The &quot;reference implementation&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&#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.<p>The author&#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.<p>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 &quot;l&quot; but maybe I&#x27;m imagining that... but also maybe it reflects some frightening detail of the format or implementation behavior.<p>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 &quot;knowing the tricks&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 &quot;optimize file&quot; tool can reduce file size by 90% without apparent visual impact... the whole fact that Acrobat has an &quot;optimize&quot; tool (and that Acrobat Distiller used to exist) speaks to the scale of this problem. Inspecting PDFs that are &quot;optimized&quot; by Acrobat can be an alarming experience, as well. You may remember that this played a strange role in Obama&#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 &quot;optimizes.&quot; It&#x27;s hard to know how much of this is actually &quot;best practice&quot; versus just a result of Acrobat accumulating decades of eccentricities.<p>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&#x27;m not sure that there&#x27;s any sound technical argument that PDF or web pages are a &quot;better format,&quot; it&#x27;s all a matter of opinion over whether you prefer print-format documents or hypertext, and that&#x27;s going to be very application-specific.

Although I agree that PDFs (and screens in general) are not the best for reading, the PDF file format is a minor miracle. It is a thing of beauty, combining text and graphics to preserve the author&#x27;s design.<p>I have built a business on PDF. I develop graphics software, enabling my customers to create large charts (36&quot; x 96&quot; and bigger) in PDF format, which they can take to the print shop for printing on large-format plotters and printers.<p>The sharp crispness of PDF text and vector graphics allows unlimited zooming while never pixellating (except the photos, of course).<p>If you are familiar with the technical specifications of PDF (1,300 pages 2006 ed.), you will appreciate the sophistication and power of the internal structure of PDF.<p>As an exchange medium, PDF has made huge contributions to commerce, technology and culture.

&gt; 4. Stuffed with fluff. PDFs tend to lack real substance, compared to regular web pages.<p>The exact opposite is the case in my experience. Unfortunately the actual substance is often in a PDF and all the web pages pointing to it are superficial, copy and pasted and&#x2F;or clickbaity fluff.<p>They then go on about how in web sites the content can be better structured and navigated. Unless I&#x27;m misunderstanding the word in English, what has that to do with whether the content has substance?<p>&gt; [...] This leads to overwhelmingly long and inane PDFs<p>You mean something akin to a book?

Incorrect. Modern web pages are garbage and PDFs are far better. No auto-play animations, no animations at all, no bizarre hijacking of scrolling, etc. a multi-hundred page PDF loads in a blink of an eye compared to a advertising tracker-loaded web page.<p>Screen size-adaptability and reflow remains a problem. It would be better to fix that on the PDF end than to move those uses over to inferior web technologies.

Hard disagree. Also the author is arguing against a strawman.<p>Normal PDF&#x27;s are simple, reliable, and interoperable.<p>In contrast to webpages which are <i>actually</i> more often the &quot;clunky&quot;, &quot;slow&quot;, &quot;stuffed with fluff&quot;, and &quot;disorienting&quot; (with scroll hijacking) alternative.<p>But the strawman is people creating PDF content as an alternative to HTML. Practically nobody is doing that. Virtually every PDF out there is designed to be a printable document <i>first</i>, that is <i>then</i> made available on the web. <i>Nobody</i> is saying &quot;how should we architect our new site -- I know, let&#x27;s make all our pages PDF&#x27;s!&quot;<p>What a truly bizarre article.

PDF is the ultimate WYSIWYG print substitute format. My mom in her 70s can create PDFs from OpenOffice&#x2F;LibreOffice without much hassle. Ask her to create a web site of any type is going to be a problem. Now imagine the tons of business people who can navigate programs perfectly capable of creating PDFs.<p>PDF also works GREAT as an archival format. I log into financial accounts regularly and save PDFs for each statement period. Makes reconciling a snap. And provides a locally archived document history for audits from taxing authorities etc. I never have to resort to finding paper.<p>Finally, PDF works great as a native format that my office printer&#x2F;scanner understands how to write to. I can scan those annoying tax documents sent to my office to PDF and archive on the NAS&#x2F;cloud backup as I deal with it and know that I have my documents digitized so I can shred the paper.

PDFs for printing are great, and they make a nice portable envelope for my vector originals, but I <i>despise</i> them as online or eBook formats.<p>For eBooks, I&#x27;ve settled on reflowable EPUB. I guess, in some cases, we may want fixed format, where PDFs might be useful.<p>For online, I prefer HTML, usually as a continuous page, and with &quot;pretty print&quot; (<i>@media print</i>) CSS. I find it annoying that the <i>page-break-%</i> CSS rule seems to be ignored by just about every browser, or at least, interpreted badly.<p>I really have gotten a lot out of the NNG folks; in particular, Don Norman, but they do like to kick anthills.

Here is Hello World in PDF: a single letter page PDF displaying the string &quot;Hello World&quot; at font size 48pt. You should be able to copy&#x2F;paste that into a text editor, and save it as a .pdf file. Chrome can open it. It is fully compliant with the PDF spec (I believe). No unnecessary optional object is present.<p><pre><code> %PDF-1.2 1 0 obj &lt;&lt; &#x2F;Type &#x2F;Catalog &#x2F;Pages 2 0 R &gt;&gt; endobj 2 0 obj &lt;&lt; &#x2F;Type &#x2F;Pages &#x2F;Kids [ 3 0 R ] &#x2F;Count 1 &#x2F;MediaBox [ 0 0 612 792 ] &gt;&gt; endobj 3 0 obj &lt;&lt; &#x2F;Type &#x2F;Page &#x2F;Parent 2 0 R &#x2F;Resources 4 0 R &#x2F;Contents 6 0 R &gt;&gt; endobj 4 0 obj &lt;&lt; &#x2F;ProcSet[&#x2F;PDF&#x2F;Text] &#x2F;Font &lt;&lt; &#x2F;F1 5 0 R &gt;&gt; &gt;&gt; endobj 5 0 obj &lt;&lt; &#x2F;Type &#x2F;Font &#x2F;Subtype &#x2F;Type1 &#x2F;BaseFont &#x2F;Times-Roman &gt;&gt; endobj 6 0 obj &lt;&lt; &#x2F;Length 51 &gt;&gt; stream BT &#x2F;F1 48 Tf 50 400 Td (Hello World)Tj ET endstream endobj trailer &lt;&lt; &#x2F;Root 1 0 R &gt;&gt;</code></pre>

I&#x27;d rather read a well set, two-column PDF online than having to deal with pop-ups, ads, dark patterns, javascript problems etc.

All the journals in my field (oceanography) show papers as HTML, with a link to get the PDF. I go for that link if a three-second glance makes me think the paper might be of interest. I am certainly not alone in this; I have never heard anyone state a preference for the HTML view.<p>This is not just for one journal; it&#x27;s for the dozen or so journals that I look at regularly.<p>The mathematics looks terrible in HTML, and great in PDF.<p>Figures usually look terrible in HTML, and quite often when you click on the action to zoom them, you get a choice of just one zoom factor. Plus, the caption disappears so it&#x27;s easy to get lost. With PDF, you can select your zoom factor and maintain context.<p>PDF has fixed page numbers, so you can refer to material in the paper easily.<p>The fixedness of PDF aids memory. I can look at a paper I&#x27;ve not consulted in 30 years, and know that something I want is (say) at the top of the right-hand column just past the figure showing such-and-such. With HTML, I basically get lost in a stream that changes if I zoom the text (often required to try to decode poorly formatted mathematical symbols) or even change the geometry of my viewing window.<p>I can highlight PDFs, and add comments to them. This is enormously valuable in research work.<p>(La)tex-generated PDF files can offer mathematical representations that are not just clear, but elegant, and in a form that matches historical convention. HTML representations vary from journal to journal (which is bad enough in and of itself) and almost never match what the reader expects from standard textbooks and classic papers.<p>I suppose HTML has the benefit that it can be set up to adjust to the viewing platform, so I can try to read a paper on my mobile phone. Not that doing so makes any sense at all.<p>For me, it&#x27;s an easy decision.

The advantage is that tools have been developed to make perfect positioning of elements (text and images). So pdf authors never have to worry about different reader form factors.<p>And, when reading a Pdf, you can print it and get exactly what we see on the screen. So the tooling is very straightforward for the reader, just click print. With other Web content, it&#x27;s the browser trying to fit things the way they should on a page and it generally looks horrible.<p>Positioning elements coded in marked language into a page is actually a tricky thing. Until we have the tooling to magically make any markdown content (with images) fit nicely in a page, pdf will prevail. Any hint on a tool that can take my markdown and print out beautiful pages, without having to tweak a dozen params, please show me.

PDF&#x27;s predecessor was PostScript. PostScript was a Forth-like programming language that contained excellent 2D graphics primitives, including bezier curves, 2D transforms and most importantly, support for scalable fonts. PostScript was ground-breaking for its time and is the reason for Apple&#x27;s early success. If it wasn&#x27;t for PostScript and laser printers the Mac would not have been successful.<p>PostScript was implemented in laser printers and printer drivers output PostScript language programs when you printed from an application like Notepad in Windows. High-end illustration and DTP programs output their own custom programs instead of being limited by the program output by the printer driver.<p>Over time it became obvious that the programming language features of PostScript were not being used very much. Printer drivers typically output a fixed header containing some function definitions then they use these functions over and over for drawing the content of the page. What if these function definitions could be built in? Then the programming language capabilities such as loops and conditionals could be left out and we would still be able to do everything we&#x27;re doing with PostScript. In fact the resulting technology would be even more useful because rendering a page can be done without implementing a programming language interpreter. Thus PDF was born.<p>PDF made perfect sense in the early 90&#x27;s when it was designed. Page Description Languages didn&#x27;t need to be burdened with a programming language because no one was taking advantage of the language features. But then came the World Wide Web. PDF was the wrong tech for the Web, and PostScript would have been perfect. PostScript has all the capabilities of PDF, but it is also a programming language, which means you can dynamically alter how you render the page based on where you are rendering it. Alas, Adobe&#x27;s direction was already set, PDF was going to be the future and PostScript is obsolete.<p>In summary, PostScript was invented at a time when nobody needed dynamic features, and PDF was invented for a static world but then the world suddenly changed and needed dynamic features.

I think there are good and bad uses for PDFs just as there are good and bad uses for webpages, but you need a hot take like &quot;unfit for human consumption&quot; to get clicks I guess.<p>For example, Agner Fog&#x27;s instruction tables are something I look at from time to time, and hate browsing that PDF file for the information I need. Similarly, software manuals as PDFs are really annoying to use - and I&#x27;ve written them!<p>But for research that needs to be referenced through other research in a bibliography, having concrete reference points relative to the length&#x2F;start of the content is actually much more reliable than having semantic links to headings or a URL. I&#x27;ll frequently find deadlinks in bibliographies, or missing webpages, or webpages completely altered and unable to parse from an illegible URL. Versus a page number, which may be in exact or slightly wrong, but is a good starting point rather than a dead end.

Its insane to me that Neilson&#x2F;highly opinionated contrarians get any attention for this. Browse <a href="https:&#x2F;&#x2F;arxiv.org" rel="nofollow">https:&#x2F;&#x2F;arxiv.org</a> for 30 seconds and tell me PDFs are &quot;unfit for human consumption.&quot;<p>While its annoying to go to sites using PDFs that should clearly be a webpage, its obvious that PDF is good at solving some class of problems for certain people. The scientific community for instance has been slowly moving towards formats that can generate both HTML + PDF, but for many reasons related to its legacy of print publication PDF is king.<p>To come in and just tell these people they&#x27;re wrong is the height of obnoxious design hubris. Between that and the boastful self-accolades, delivered in 3rd person no less, its hard for me to take this seriously.

First, the article makes a claim about PDFs problems for the web, when read online, which is a lot less clickbait-y than &quot;unfit for human consumption&quot;.<p>On the technical claims: while I agree that PDFs are not ideal for many uses on the web, especially for current attention-span-of-a-fly web usage, they are great for things where I am willing to dedicate more time for an in depth look at the subject. For those cases the complaints that authors list about PDFs (linear access to information, lack of advanced navigation options, optimized for print (i.e., look best on a large monitor)) are not limiting and in fact beneficial.<p>And some complaints (slow to load, stuffed with fluff, jarring user experience) are just as, if not more applicable to most of the web. My 2c -- work in R&amp;D likely skews my preferences in the direction of paper as an ideal interface :)

The title is clickbait: the article is (mostly) about how PDFs are not suitable for reading on-screen. (Which is mostly true.)<p>Further, the arguments the article makes are gibberish:<p>&quot;<i>4. Stuffed with fluff. PDFs tend to lack real substance, compared to regular web pages. When you’re building out a web page, you can visibly see how long it’s getting and how far users will have to scroll to consume the content. Methods of structuring and formatting digital content such as chunking, using bullets, subheadlines, anchor links, and accordions help users efficiently skim and scan sections that may contain the answers they seek amid long-form copy. However, in PDFs, those techniques aren’t always used and content creators tend to favor quantity of content over quality and formatting. This leads to overwhelmingly long and inane PDFs.</i>&quot;<p>&quot;PDFs tend to lack real substance, compared to regular web pages.&quot; Really? Really? That&#x27;s the argument Jakob Nielsen is going with? HTML is magically better?<p>&quot;However, in PDFs, those techniques aren’t always used and content creators tend to favor quantity of content over quality and formatting.&quot; In <i>HTML</i>, those techniques aren&#x27;t always used! They often aren&#x27;t used. And HTML somehow enforces quality of content?

The article is about online or for me, on laptop, but I also have a 32GB Kindle Paperwhite on to which I download a ton of PDFs, mostly papers but some books. For example, I concatenated Onur Mutlu&#x27;s Architecture lecture slides into a one GB PDF file. I like that that the papers look like papers and that the fonts and graphics are rendered correctly. Links work but I don&#x27;t use them.<p>However, PDFs on the Paperwhite don&#x27;t make for easy reading. I could and have converted papers to EPUB which is much easier for reading but less good for studying, and the purpose of these PDFs is studying. Yeah, I can grouse about PDFs but it&#x27;s a tool which I use.<p>By comparison, I check EPUBs out from the library and they are surprisingly pleasant to read on the Paperwhite.<p>Yeah, the article is about the web and I&#x27;m answering about the Paperwhite. Maybe they have a point about browsing on the web. But for content meant to be read, for academic content, PDFs are pretty good.<p>BTW, on my MacBook I use Skim which is <i>much</i> better than Reader.

This is so, so wrong. Yeah, OK if you have an interactive website (a chat or message board feature) then you have no choice. If you&#x27;re trying to present information or an article I&#x27;d take a beautifully typeset PDF <i>any day</i> over some website with so many trackers and javascript it takes seconds to load.<p>Not to mention on a tablet PDFs are much, much nicer to read.

The problem is that PDF targets the printed page, while HTML targets screens. PDF does a better job with respect to printing then HTML does for screens, because HTML has been largely repurposed for creating GUIs. Unfortunately PDF are not easily scripted, and HTML has essentially no support for proper printing.<p>And so alas it all sucks.

PDFs are great for typesetting for print, where you know the paper size and adjust everything pixel perfect to it. Nothing beats PDF when it comes to complex typesetting for print. Web pages are meant to reflow and much better for reading on smaller screens. Also modern web technologies can go far beyond a PDF when it comes to interactive&#x2F;dynamic content, but web pages (sites) are also cumbersome for a non-technical user to download for offline use with all elements intact.<p>But I suspect HTML will eventually win this. While HTML can be printed, PDFs will always struggle with changing device sizes. Plus the web is becoming more of an app as time passes while PDFs will probably remain dumb content due to security reasons, so their applicable niche is growing smaller as the Web creeps in scope.

Maybe I&#x27;m a weirdo or something, but I love PDFs.<p>I basically disagree with 80% of what this website says.<p>&quot;PDFs tend to lack real substance, compared to regular web pages.&quot; made me chuckle. I don&#x27;t know what kind of PDFs this person reads, but my copy of &quot;Computer Networks: A Systems Approach&quot; sure as hell has more substance and quality than a Twitter feed or whatever the author considers a &quot;regular&quot; web page.

The design goal of PDFs is display on any device, not a platform for e-books, so this makes sense.

Um no. LaTeX + PDF = awesome. All tech docs in PDF are great.<p>Look, web pages to the degree PDF is bad, is worse because it&#x27;s riddled with adds and waits for servers you didn&#x27;t intend to bother that,<p>- &quot;help you&quot; - &quot;give you info you might be interested in viz adds - all other manner of social media nonsense - and to pay the domain owner $$$$<p>Maybe the OP should stop getting PDFs from NYPOST, Vanity Fair, Mad Magazine, Graphics Designers Guild dot com, or Madison 5th Ave S&amp;Mrkting.com

I think the real problem here is usage. PDFs make more sense for printing.<p>Using PDFs to distribute content online instead of web pages is the real issue.<p>Same problem with trying to use a hammer with screws.

Its interesting how many of these complaints about PDFs also apply to modern websites.

The underlying problem isn&#x27;t PDF, but the fact that HTML is still completely unsuited for long-form content. Really basic stuff like a proper markup-based TOC isn&#x27;t a thing in a HTML. And on the browser side there are just as much problems, you can&#x27;t bookmark your scroll position and basic scrollbars are a terrible user interface for long HTML content anyway. There are other really basic problems like not being able to link arbitrary HTML content unless the author of the HTML put an anchor in the document.<p>ePub, mobi and such were developed to work around those limitation and make more usable book formats, but no web browser has native support for them (Edge had some support, not sure if that still there after the Chrome switch). Despite being HTML-based, those formats aren&#x27;t really part of the WWW.<p>PDF does what PDF was designed to quite well, it&#x27;s virtual paper. But the WWW has kind of failed to evolve into becoming a platform where you can publish long-form documents on, so PDF still continues to dominate.

One thing PDF&#x27;s have going for them is that they are standalone files, so you can download and collect them. The advantages are similar to MP3&#x27;s for music. HTML doesn&#x27;t qualify since not even the images are included in the file.<p>I&#x27;m wondering what other file formats might work better, and why aren&#x27;t they more popular? Epub maybe?

Uh, yeah, they have some big limitations, but they generally work well for me. It&#x27;s rare for one to fail to do what was intended which is to display a document as it might be printed. Fonts and all.<p>Isn&#x27;t it true that every software project -- and indeed every project -- falls short of what people may want?

PDFs exist to emulate paper (a need which won&#x27;t totally go away), but maybe it would be nice if the format and authoring tools supported a sort of alternate rendering mode that is online-friendly.<p>So for example, a word processor may be set to produce two-column text, and for paper that makes sense ergonomically. But it is horrible in combination with scrollbars. The same goes for margins at the top and bottom of pages.<p>A typical word processor allows you to easily switch text to one-column mode or adjust the page margins, so with just a few changes it could render your document in a more online-friendly way. So when you save as PDF, it would be neat if it could include both renderings into the same document.<p>In this hypothetical world, the PDF viewer would then decide whether to render it in faithful-to-paper mode or in online-friendly mode.

They seem to be specifically talking about the case where you&#x27;re on a web page, you click a link to go to what ought to be another web page, but instead you&#x27;re in a PDF in your browser. I get it, PDFs are documents and not web pages, and dumping a visitor into a longish PDF when a concise web page with the answers they&#x27;re looking for would be better.<p>So, use web pages for presenting information best presented in a web page, and use PDFs for presenting information best presented in a PDF, and don&#x27;t use a PDF when a web page would be better and don&#x27;t use a web page when a PDF would be better. But that doesn&#x27;t seem to be the point they&#x27;re making for some reason.

Despite all the many problems with PDFs (frequent lack of internal navigation, too much or too little or just plain wrong metadata, inherently static) they&#x27;re still great precisely because they print out the same way they look on screen (which is often something you want for a long or highly technical document) and because they don&#x27;t slide around and constantly throw up modal dialogs.<p>Don&#x27;t get me wrong, I find many aspects of PDFs hugely frustrating. But many websites are just <i>horrendous</i> and a complete misery to interact with. If it&#x27;s more than a couple of thousand words I tend to start looking for a pdf version.

The purpose of a PDF is to have a document that can be viewed and printed as designed and laid-out by the creator. HTML doesn&#x27;t do that. The experience of an embedded PDF viewer is still pretty horrible (even new browsers have a pretty bad experience, and well, even Adobe Acrobat&#x27;s UI is just... bizarre).<p>PDF supported embedded type, vector graphics, and many other features long before the web browser could. Honestly, the issue with pdf is how documents are created (often via fake printer drivers that often compile&#x2F;translate whatever you are printing to some pretty gnarly postscript).

Great attention grabbing headline, but it ignores the typical user scenarios where PDFs are created. So how is your typical Office worker who is probably using Word going to create this awesome web page? It&#x27;s simply not realistic to expect that office workers are going to use HTML, and it&#x27;s been tried for years and years. Nielsen may as well go after Powerpoint next. Same criticisms and human limitations apply. Yes, better formats exist in the ideal, but ignoring the user&#x27;s real context and limitations goes against the principles of User Centered Design.

A big mistake is that people still consider PDF as a &quot;document&quot; format. In reality, it&#x27;s just a convoluted image format. Because it&#x27;s an image, it doesn&#x27;t have any logical structure and reformatting them is pain. Worse yet, its syntax is the worst of two worlds - a mixture of text and binary. It&#x27;s horrible to parse, display, and modify. As if it&#x27;s like that programming language that everyone hates (and I don&#x27;t want to name). But really, it&#x27;s a burden of the future generation. We should eradicate it. End of rant.

Let&#x27;s not forget that the reference PDF reader, Adobe Acrobat, has turned into a pile of shit about 15-20 years ago, with &quot;plugins&quot; and stuff making its load time surpass that of browsers at the time, and severe security issues going unfixed, that PDFs frequently use text in non-semantic text order or even as stored bitmaps, with the deficiencies in searching and linking within PDFs that goes with it. Also, Adobe found it necessary to include JavaScript execution from PDF, and also dysfunctional PDF forms&#x2F;signing and interactivity features such as linking which more often than not pose a problem rather than solution on the rare occasions where I&#x27;ve encountered their use. AFAICS, valid (?) use cases for PDFs (apart from sending out a document to a print shop) include e-books (incl fingerprints), academical publishing, user manuals, formal business and legal statements, and personal archival (PDF&#x2F;A with prerendered layout and embedded fonts). Even as a critic of CSS complexity, I believe all these use cases except academic publishing should use markup+CSS instead, and if there are deficiencies in browsers, they can and should be addressed and fixed. I find it particularly painful that .mht, .warc, or other HTML-based archival format hasn&#x27;t gained trust (and probably won&#x27;t work well with today&#x27;s JavaScript-heavy sites, many of which don&#x27;t have a reason to use JavaScript except for lock-in, analytics, and plain incompetence).

This article is incredibly biased with completely unscientific claims seeming to stem from personal opinion. PDF is a great format due to the fact that the document will look exactly as it was intended and how you would perceive the document in real life. Using it for scientific papers, CVs or similar reinforces trust and that the author actually invested time to create a well formatted document. Additionally it is difficult to modify which also reinforces the authenticity of the contents.

Data communicated as PDFs when it shouldn&#x27;t be has frequently been a pain. Recently, I needed banking data that was _only_ available as bank statements in PDFs or an unpredictable web ui.<p>Consuming banking data as PDFs is a nightmare. The bank I was working with seemed to have spent _some_ money on its website (Regions Bank in the US, if anyone wants to know, but just so happens to provide .ofx exports for 19.95&#x2F;month starting from the month you sign up, but not generated for previous months, although that&#x27;s tangential). Meanwhile, my local bank that at first glance from its website seems like it&#x27;s in the stone age provides a PDF statement that looks like it was made in the 80s (all monospaced font, no graphics), but they also provide a .csv export for transactions with seemingly no limits on date.<p>The latter bank approach signals to me that data is in the format it should be in. No more, no less. The former suggests The PDF and a pretty web UI is the de facto standard for communicating tabular data when it shouldn&#x27;t be.<p>I get that PDFs online are a great alternative as a document that was originally meant to be printed and mailed, but it is a poor substitute for consumable banking data.

Well here are some reasons why .pdfs are better:<p>1. They are a flat format. Why is this good? When you text search for something it can be found, vs. in HTML where you can search only a single web page instead of a hypertext graph- I mean what would a complete search even mean in HTML?<p>2. They are also hierarchical. I can print a hierarchical schematic and navigate through it by clicking on sheet-blocks.<p>3. You can view 3d renderings in them. Someone can save their solidworks document as a .pdf, and I can open it and zoom and rotate the view in acrobat reader. There is certainly no standard way to do this in HTML.<p>4. There are no ads.<p>5. I can send somebody the complete thing as a single file. For a web-site I would have to send them a zip file that they then would have to extract- it&#x27;s just not as nice somehow, though in theory it should be OK. This shows up in microcontroller documentation for example. Usually the chip TRM is a 1000 page pdf, but the software is a bunch of HTML files (a web-site really). It&#x27;s inevitably easier to get the chip TRM than it is the software documentation.<p>Actually in this particular case there is more- the software documentation is generated as extracted comments from source code by doxygen and it is usually crap. Pdf documentation someone actually wrote, so it tends to be better.<p>When you get HTML documentation, there is often not an index.html file. If there isn&#x27;t one, which document do you open first?<p>6. Every documentation as a web-site system has their own navigation method, whereas .pdfs have acrobat reader or whatever. Even on web documentation that has something like a go to next page or section button, it&#x27;s hit or miss if it works well. For example, the placement of the next button will vary from page to page, so you can&#x27;t easily just page through it.

While I&#x27;m not particularly enamored of PDFs, they are streets ahead of the previous widespread document format, the Microsoft Word DOC.<p>The Word DOC format had the problem of becoming unreadable every few years until you managed to splash out and buy the latest and greatest Microsoft Word and its associated version of Windows.<p>At least the PDFs remain legible pretty much indefinitely.

I wish MHTML had more recognition as well as a chance to play the role of a &quot;portable document format&quot;. For one, it&#x27;s easy to open (everyone has a browser on whatever device they&#x27;re using), easy to work with either for creators or consumers and can automatically adapt the screen it&#x27;s been read on.

Highly disappointed there was no mention of the pain of annotating PDFs. The only way I&#x27;ve been able to reliably annotate a PDF with writing that I&#x27;ve downloaded on Linux is to use WINE or install a bunch of KDE dependencies just for Okular. PDF is a document format intended for consumption but so many institutions insist om giving you a PDF with no form elements and expect you to edit it and send it back. A web-based solution that would have a form that autogenerates the finished PDF would work so much more, but PDF is apparently easier for them to send and expect back an answer. As a result I dread PDF when using it as a format that&#x27;s intended to be edited. I feel like this is a misuse of what PDF is supposed to be, as people believe that since it looks like printed paper then you ought to be able to write on it like printed paper.

Paper is a vastly different medium compared to computers. The ignorance large companies(digital book distributors) show when dealing with humans(by only focusing on ebook sales and nothing more) is really annoying. Take Adobe Reader for example, it is really awkward in how dozens of researchers are unable to grasp the most basic feature of computers: dynamism. These people&#x27;s minds are still stuck in Gutenburg era and they fail to notice how powerful computers are. Having had headaches with pdfs(I read lots of books) and the way knowledge is buried in this format, I started a project to inject some dynamism into our book reading.<p>Please check it out if you are interested.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;rezahsnz&#x2F;readaratus" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rezahsnz&#x2F;readaratus</a>

I prefer PDFs on the web for serious reading. They have the least probability of having disruptive background processes and jarring graphics. It’s a pleasure when I’m alerted to a lawsuit dropping on Twitter, and I can find the actual pdf.<p>I couldn’t disagree more with most of the assertions in this article.

At least PDF books and papers are mostly self-contained and easily accessible in their pristine condition. This piece looks very inflammatory and appears to say &quot;PDF is bad because PDF is not web&quot; in too many words.

The durability of PDFs are one of the main reasons why they&#x27;re one of the core methods of archiving websites in ArchiveBox.io.<p>Despite being &quot;clunky&quot;, they render much more reliably than HTML on the decades timescale.

This is just Android&#x27;s problem, but I sometimes very hard to copy PDF&#x27;s URL:<p>Chrome for Android doesn&#x27;t support to load PDF so it automatically downloads and opens in another PDF app. Reading PDF in app is fine but I can&#x27;t copy url from app because it&#x27;s already downloaded. Normally I can just copy url from link but some site like Google and Twitter uses link jumper so I unable to copy url.<p>Yes it&#x27;s same as other file types that can&#x27;t be opened by browser, but other file types are rarely directly linked. PDF shouldn&#x27;t be first-class citizen in web.

I don&#x27;t know if anyone can suggest some tools, but my minor problem with PDFs is that any kind of data table gets absolutely mangled&#x2F;unusable for cut&#x2F;paste purposes after creation.<p>It&#x27;s like somehow the PDF generation process randomizes the order in which it populates tables, such that selecting by a user later is generally impossible.<p>Maybe it needs to be interpreted &#x2F; extracted from the PDF source itself, but average user graphical selection of a table is out the window.

Today I tried to get a blank PDF. I&#x27;ve created a blank docx file using official Word and used official Adobe Acrobat to convert it to PDF. On the first try I&#x27;ve received a message saying there was an error while sending the file. On the second and subsequent tries I&#x27;ve received a message saying that there was an error converting the file. So, after 23 years of development if a case of converting a blank document is not supported...

I just wish iOS Safari supported opening its regular document view for PDFs embedded on web pages in &lt;object&gt; tags. It treats them like an &lt;img&gt; and displays just the first page of the PDF with a transparent background letting the page show through. Of course there&#x27;s no good way to shrink that UI into an arbitrarily-sized box on the page, but I&#x27;d prefer a button to open the regular fullscreen view over the current behavior.

Also relevant:<p><a href="https:&#x2F;&#x2F;www.sans.org&#x2F;reading-room&#x2F;whitepapers&#x2F;malicious&#x2F;paper&#x2F;33443" rel="nofollow">https:&#x2F;&#x2F;www.sans.org&#x2F;reading-room&#x2F;whitepapers&#x2F;malicious&#x2F;pape...</a><p><a href="https:&#x2F;&#x2F;digital-forensics.sans.org&#x2F;media&#x2F;analyzing-malicious-document-files.pdf" rel="nofollow">https:&#x2F;&#x2F;digital-forensics.sans.org&#x2F;media&#x2F;analyzing-malicious...</a><p>Malicious PDFs are still around, even today

&gt; Do not use PDFs to present digital content that could and &gt; should otherwise be a web page.<p>To get decent typography, one needs TeX, and TeX produces PDFs, not web pages.

Pdf is a format; the content is a choice of the author.

The article deeply resonates with me. I have been annoyed so often by a website splitting content into PDFs that would have been perfectly fine as HTML. I suppose this happens because the content department makes nicely (sometimes) layouted documents first to print and give someone to review _and then_ someone decides to throw them up on the website as an afterthought.

If the alternative is epub i will take pdf any day.

The author seems to want CHM...<p>For all the PDF hate, 99% of the time the rendering is better than most web pages, and it actually works properly. I don&#x27;t have scaling issues with it on hi-dpi displays&#x2F;etc.<p>I&#x27;ve also yet to see a browser do proper sgml&#x2F;svg graphics scaling of high density (thing multiple hundreds of MB) maps&#x2F;etc that are common in PDFs.

The British Government also published two years ago they reasons against using PDF <a href="https:&#x2F;&#x2F;gds.blog.gov.uk&#x2F;2018&#x2F;07&#x2F;16&#x2F;why-gov-uk-content-should-be-published-in-html-and-not-pdf&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gds.blog.gov.uk&#x2F;2018&#x2F;07&#x2F;16&#x2F;why-gov-uk-content-should...</a>

At least PDF doesn&#x27;t bombard me with click walls and cookie disclamers so that I can actually read and scroll.

&gt; PDFs tend to lack real substance, compared to regular web pages.<p>I am seriously wondering which universe this person is from.

I usually prefer HTML content, but for long-form technical documentation, I actually prefer PDF because it&#x27;s always written to be read &quot;cover to cover&quot; rather than randomly hyperlinked. I do bail as soon as I see two-column output, though - too painful to deal with on a computer.

There is one thing about PDFs that makes them OK: it&#x27;s one file, with everything needed, so it works offline. That&#x27;s not nothing. The Web N.0 is not offline-friendly, and while most of the time that&#x27;s not a problem, when it is a problem, it&#x27;s a nasty problem.

<i>Sized for paper, not screens</i><p>Yeah! This year I decided to support Indie journalism and help the environment by not having the paper edition mailed to me. Big mistake. They&#x27;d literally rendered the print version as PDF, and reading that on an iPad was nearly impossible.

PDFs are horrendous but they work in their horrendous context. Most people are not tech saavy and want universal visual and printable. I so wish people could exchange text + svg but you need to educate and modify workplaces. Until then PDF it will be.

Part of what makes the PDF experience so abysmal is the Adobe reader most people use. Apple Preview (and Quicklook!) is so much faster and more stable that I can forget how miserable the experience is for Windows users.

&gt; 1. Linear and limiting<p>Perfect for information discovery. Rich annotations and hypermedia features (external links, document-internal links, TOC) in PDF fix pretty much all issues stemming from this. All searchable (if the PDF has been constructed properly). Permanent, static structure vs everchanging, confusing messes of websites. The web is NOT QUOTABLE and unusable without advanced full-text search. Barely an URI remains stable.<p>&gt; 2. Jarring user experience. PDFs look completely different from typical web pages.<p>Typesetting on the web is a clusterfuck. Subpar microtype. Font rendering issues galore, tens of versions of popular fonts purchased at different points in time from different vendors with differently messed up CSS font configuration settings. Fonts are not embedded, but hyperlinked. I want a maximum fidelity reading experience for large portions of text and classic formats, because familiarity aids navigating a complex document. There is no need for fancy styles and whatnot.<p>&gt; 3. Slow to load.<p>Renderers differ in quality and speed. PDFs render lightning fast at acceptable settings and if you wanna tune for maximum quality, you can do so at the expense of slower rendering. Besides, it took 2.401ms to load the web page these points are writteen on, excluding content blocked by ublock origin. This point is delusional. A 700 page beautifully typeset PDF opens and renders in &lt;&lt;1s on my 7 year old laptop, and my reader will prerender pages to speed up navigation even more.<p>&gt; 4. Stuffed with fluff.<p>The entire paragraph is invalid because PDF has all those features.<p>&gt; However, in PDFs, those techniques aren’t always used and content creators tend to favor quantity of content over quality and formatting.<p>The same goes for most web content put out today.<p>&gt; 5. Cause disorientation. Because PDFs aren’t web pages, they don’t show a standard navigation like a website would.<p>Document structure is clearly presented in tree on the right side if the PDF is properly annotated&#x2F;hyperlinked and the reader has a TOC view (productivity tooling should have this). Websites lack this discoverability almost always, and if they have it, it looks different and works differently everywhere, creating disorientation.<p>&gt; 6. Unnavigable content masses.<p>This has nothing to do with PDF and everything to do with the reader in use. A semantic desktop would index all file content, allow cross-linking between files using file:&#x2F;&#x2F; or other protocols, and generally expose all content to a local or internet search engine. Google search indexes PDFs just fine! (Again, a badly constructed PDF may not contain text at all or broken text, but that&#x27;s a generation problem.)<p>&gt; 7. Sized for paper, not screens.<p>This is correct, and an advantage, because the web and most other screen content lack the fidelity of typesetting systems like LaTeX, ConTeXt, InDesign etc which each incorporate decades of digital best practice, and several decades more of typesetting knowledge.<p>It is an disadvantage in special settings, like on mobile, but even then, PDF text can be reflowed with appropriate software.<p>&gt; Users Strongly Dislike PDFs<p>It&#x27;s my favourite format for archiving documents, knowledge, and even website printouts.

PDF is great, especially for books and papers. Really the only proper choice for a digital technical book. Of course, you should read it on a device large enough, like an iPad Pro 12.9 inch.

The distinction should be made between fixed layout formats like PDF and reflowable text formats like HTML. In a RESTful sense, these should be two representations of the same resource.

As non-English native, Translating PDF is pain especially two col layout like thesis. Don&#x27;t use fixed layout for web content, Please! (Seriously it&#x27;s a11y problem)

PDF format is useful if you want a hard copy.<p>But do any of you know how to use Pandoc (or some open source or command line tool) to convert a PDF to something easily readable on a Kindle?

I don&#x27;t see how users hate pdfs? They&#x27;re perfect for sending to print houses, so we know what we send is exactly what ends up on paper!

I have to disagree. I love consuming content through PDF format, even books, especially when paired with a great PDF reader.

I really like PDFs. It is a portable way to render something not design for a web browser.

Nope they are quite alright and much better than the PS tooling that they replaced.

I way prefer a PDF to most modern advert-infested, javascript-laden website.

&gt; Linear and limiting<p>When I&#x27;m trying to learn something that is not short and simple, linear is good.<p>Far too often when someone tries to present a long and complex subject via HTML, they don&#x27;t provide an easy way to go through the entire thing in an order that is pedagogically sound.<p>It doesn&#x27;t <i>have</i> to be that way...but it usually is. I&#x27;m not sure why.<p>Instead, they provide each page with a sidebar that links to other pages, turning the whole collection into a directed graph of pages full of dead ends and regions that have no links to other regions.<p>You reach some page where the sidebar links to X, Y, and Z, which are all things that depend on what you learned on that page and you are now ready to learn. If you follow the X link, you may end up learning all about X but may never again see the links to Y and Z unless you remember that a dozen pages back you saw them and purposefully seek them out. It&#x27;s very easy to not even realize that you missed a whole major subtopic.<p>In a linear format, such as an actual book, a PDF, an EPUB, or even a plain text file, the author or editor makes a decision on how X, Y, and Z should be ordered. Maybe they decide X, followed by Y, followed by Z. Maybe they decide X, then Y, then things that depend on both X and Y, then Z, then things the use X, Y, and Z.<p>Different authors might pick a different ordering, but they point is they have to choose something. Whatever they choose, you just keep turning the page and you&#x27;ll hit it all.<p>For a big subject, maybe you don&#x27;t want to hit it all. I&#x27;ve seen math books address this by having a list or diagram in the front giving you alternate orders to go through a subset of the book if you just want to learn just a subset of the subject.<p>In theory, HTML should be great for this, especially HTML with JavaScript. You could have a page that lets you select from different learning paths, and then the JavaScript would put &quot;Next&quot; and &quot;Previous&quot; buttons on each page that take you through all the pages on your selected learning path. You could still have the sidebar links, but if you follow one the JavaScript could add a &quot;Return to Learning Path&quot; button so you can always get back on track.<p>But until more HTML authors put in the effort to provide a linear path through the material that books&#x2F;PDF&#x2F;EPUB&#x2F;text formats force their authors to provide, PDF and to a lesser extend EPUB will remain the best option for most people trying to learn a long and complex subject online.<p>(I give PDF the nod over EPUB because most EPUBs do not have mathematical notation that looks as good as it does in PDF. I don&#x27;t know if this is a technical limitation of EPUB itself, or of the EPUB readers I&#x27;ve used, or of the authoring tools used to create the EPUBs, or simply the authors didn&#x27;t know how to do it right).<p>A good example of HTML authors putting in the effort is &quot;The Feynman Lectures on Physics&quot; online edition [1]. That shows you can make a website that presents a long and complex technical subject that works as well as a book or PDF, yet adjusts well to a variety of different screen sizes.<p>[1] <a href="https:&#x2F;&#x2F;www.feynmanlectures.caltech.edu&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.feynmanlectures.caltech.edu&#x2F;</a>

And even worse for manipulating with code.

PDFs are for printing, they come out almost every printer the way they are suppose to, there are other formats like txt, office and html that are better suited for direct consumption.

While the comprehensive ranking of file extension reliably by Munroe 2013 does not contain .htm or .html, one can infer by the related file formats, that html content would rank below pdf&#x27;s.<p>Randal Munroe, &quot;File Extensions&quot;; xkcd.com, 1301, 2013-12-09.

Ok, boomer.

I find that claim rather ironic, because I feel like the primary reason that PDFs are &quot;unfit for human consumption&quot; is a formatting issue, not as much a technical or practical issue. The reason they are unfit to read on line is that they are formatted using past formatting standards that are meant for print … not inline reading.<p>There are of course some technical limitations to PDF that would prevent them from being mad &quot;digital first&quot;, but even just changing page layout and adjusting margins and spacing and font for horizontal display (as most of our screens are) vs vertical layout as one would read a printed sheet of paper, would make huge differences.<p>I for one actually compensate for that in that I have a dedicated monitor that is vertically oriented in order to read PDF documents. Better yet if you can do it on a very high dpi screen. But even that is not ideal because although I actually like print formats, standards, and conventions (like margins, spacing, and structure), it&#x27;s simply not relevant or applicable in digital until we get A4&#x2F;Letter formatted tablets or desktop screens that emulate physical paper … albeit even that, inadequately. Nothing can really replace the advantages of paper, at least not until we get paper thin displays that have zero measurable response times on pen inputs … i.e., likely never.

I disagree with almost every point in this article.

I LOVE PDF

What will you do after printing the pdf document, send it to legal? Lawyers are not humans, right? I agree to it&#x27;s good for paper not for screen, everything else is just phony.