I'd say modern websites are worse. PDFs don't keep moving under your feet while the javascript is loading. PDFs can be straightforwardly saved on your computer. PDFs don't blank out if you lose connection because of ajax. PDFs don't embed malware from third parties.
which is better / worse: DOM or PDF? I was until recently of the opinion that the DOM has led to more and more complex HTML and document layouts requiring demanding browsers to render the content and reflow the layout, and that on balance, this was a Bad Thing.
On the one hand, this DOM setup is crazy. Surely a more dynamic architecture would be better where decoders are downloaded on-demand as the user goes from site to site, coming across content types not yet seen. This of course raises security questions, as to the provenance of the decoder and less so of the content.
On the other, having come to the realization that the next logical step on the path to this scenario is WebASM, where the content and decoder are completely opaque to the user one can envision a world where there are a million different types of PDF, each with their own decoder, each trivially but crucially different. It's not a pretty thought.
My favorite fix for modern websites is firefox's "reader" mode. Pretty ironic that to make many webpages readable you need a reader mode, after all without reader mode you are supposed to ... do what?
One way to get the best of both worlds would be to have a normal webpage, but have the "Print this page" button generate a PDF that is nicely laid out. Often webpages are a mess to print.
I wonder how difficult it would be to write a tool that can turn a PDF into a usable webpage.
In theory CSS has specific controls for laying out the "print" format of page page so your browser's print action should do the right thing.
However in practice many websites don't put any effort into this, which is probably an indication that they wouldn't put any effort into a custom solution either.
> I wonder how difficult it would be to write a tool that can turn a PDF into a usable webpage.
I was looking into this but it is basically impossible. Since PDF is basically a collection of images (with some "fancy" stuff on top) you can get the basics, such as text and headings, however you won't be able to do much for semantics or layout. All web-based PDF viewers I have seen just render each page to an image and put invisible text on top for copy-paste support.
Seems like that's more and more the case nowadays.
One of the things I absolutely despise about the rise of JS is that many many modern sites won't display anything (just the white BG) unless I allow 3rd party scripts. Is displaying simple blogposts and other textual information with the occasional image or video embed so hard that one needs to load often multiple MBs of JS from multiple external sites?
I'm pretty sure that at least Okular does not support enough to make the animation with the latex animate package work. But maybe I held it wrong. I'm pretty sure I also tried Foxit and MuPDF for the same thing.
I'll have another look. While I despise frame transition animations etc, for some stuff some nice animations are really helpful in explaining concepts.
Thanks!
Nice, works with my okular 1.9.3 too, after asking whether it should show forms. The PDF-X I have on windows asks also (I think they use the same engine, poppler?), but then shows a blue rectangle if I enable them. I'm pretty sure that was what my experience was generally when I looked at it the last time (2 years ago), so probably some updates in the engine which made it work now.
You can also (and really ought to) switch off the JavaScript engine completely in Acrobat reader. There isn't a legitimate reason to run Javascript during the viewing of a PDF.
If there were lots of people like you, soon there'd be publishers inventing the "ad background", the "ad paragraph" and the "cookie consent cover page"
2-column PDFs are fine when printed, or on a tall full-size screen. But on a 16:9 screen, smartphone, or small tablet they're annoying, since you have to zoom in to read the text and then do a weird diagonal scroll between columns every page. For all of these cases single-column half-width with twice as many pages would generally be better.
Uh, yeah, they have some big limitations, but they generally work well for me. It'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.
Isn't it true that every software project -- and indeed every project -- falls short of what people may want?
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.
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's the browser trying to fit things the way they should on a page and it generally looks horrible.
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.
Bear is good at producing nicely formatted PDFs from markdown. Styling options are (very) limited, but I like using it as the documents always look good.
> Positioning elements coded in marked language into a page is actually a tricky thing.
This is almost impossible to do right. Even browsers can't produce a PDF that looks exactly the same as a web page.
If you want to programmatically produce a PDF from a web page, the best bet is to load up a full browser implementation just for that purpose as any other simpler solutions would certainly break the results pretty often.
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.
PDFs for printing are great, and they make a nice portable envelope for my vector originals, but I despise them as online or eBook formats.
For eBooks, I've settled on reflowable EPUB. I guess, in some cases, we may want fixed format, where PDFs might be useful.
For online, I prefer HTML, usually as a continuous page, and with "pretty print" (@media print) CSS. I find it annoying that the page-break-% CSS rule seems to be ignored by just about every browser, or at least, interpreted badly.
I really have gotten a lot out of the NNG folks; in particular, Don Norman, but they do like to kick anthills.
EPUB is a non-starter for me as most e-readers haven't bothered to implement decent math support. We've had LaTeX math for decades now, come on people! Any HTML-based format like EPUB should be using KaTeX at a bare minimum, but instead I often see an ungodly mess of poorly-spaced notation in an inappropriate font, much like those old manuscripts from the 1960s produced on typewriters.
Until these issues are fixed, I'll keep enjoying my beautiful LaTeX PDFs, thank you!
Reflowable PDFs were the Correct Answer. Since the beginning.
IMHO Adobe has been a terrible steward of PDF. I have no idea why. (Source: Used to write print production software in the 90s. Some of my team went to Adobe. One was bored so banged out a PostScript clone hooked up to the newer image library in a few weeks. They all said the PDF libraries were garbage, everyone was afraid to breathe on them, no one was motivated to do anything better.)
Re NNG: Agree. +1 Don Norman, whereas Nielsen and Tog haven't said anything interesting in ages.
One needful use case was (is?) variable data printing, allowing mass customization, like direct mail. Pretty much the same technical progression that happened in user interfaces going from absolute coords and static layout to dynamic layout managers.
The fix was so easy. Just retain some of the source document's meta data, eg this group of glyphs are a "paragraph". The PDF object model was explicitly designed for exactly this kind of extension.
IIRC Some specialty vendors had some goofy work-arounds, like a post process tool for manually marking paragraphs.
I've yet to find an EPUB reader that would give me scrolling without page breaks. So far, it seems all of them believe that if I scroll past the end of the chapter it's because I've read it all and want to see the new one, not because I want the chapter's last lines to be in the middle of the screen, for easier reading. Argh! And every single PDF viewer, even the shitty built-in mobile ones, have continuous scrolling!
I disagree, PDFs provide a consistent, as intended layout from the author/publisher/editor. EPUBs are great for novels and text-heavy literature, but they're awful for anything that has pictures, code snippets, etc. I usually prefer to buy O'Reilly books in PDF format because they're extremely well formatted and designed - just as if you're reading a physical book.
In addition, typography and style are poorly adapted in EPUB format whereas with PDF - it can be read instantly on any device, any where and usually without installing a reader or fonts. There is so much inconsistency between Windows/Linux and Mac, iPhone, Android when reading an EPUB book.
I do a ton of academic research, and whenever I find a source in EPUB I have to convert it to PDF first, just so I can do highlighting, circling, etc.
True, EPUB applications generally allow you to highlight, but those highlights are stored in the application. They don't live in the file. You can't export them to import them in another reader program. With PDF, all my annotations stay in the PDF itself, and appear in all fully-featured PDF software.
If you don't need formatting, then yes pdfs may be forcing a burden on you you don't need - especially on small screens that cannot display a full page without microscopic fonts.
But when you need the formatting, PDF is wonderful.
The problem with HTML is that it's a moving target.
For PDF vs Epub, I have recently seen the combination of traits of both, in a very devastating way.
The characters were overlapping, no matter which reader I use, what margin/line/character spacing I set, until I adjusted the font size to two points smaller, and everything was right.
It turns out that whoever made the epub, turned every word into a single html element, with a fixed position!
So, it was like PDF in a sense that every thing has a position on the page. But it was like epub in the sense that everything's size can be changed (albeit within the "div" element). And the default size doesn't event work for the book.
I cringed so fiercely that I nearly deleted the book.
> 4. Stuffed with fluff. PDFs tend to lack real substance, compared to regular web pages.
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/or clickbaity fluff.
They then go on about how in web sites the content can be better structured and navigated. Unless I'm misunderstanding the word in English, what has that to do with whether the content has substance?
> [...] This leads to overwhelmingly long and inane PDFs
I had a capstone project in university where the clearest way to generate a better grade was to generate more pages.
We put all sorts of rubbish in the report to make sure it made a "thunk" sound when we handed it in. It was nearly 300 pages when it should have been 90.
The problem is, plenty will judge a report on its thickness. "It is thick, so it must be comprehensive." What percent of government reports are read cover to cover and what percentage are just ctrl+f through?
If reports are often ctrl-F'd through for relevant information, it seems likely that many people consuming it are reading far fewer than 90 pages in total - and wouldn't have read the full shorter report.
Perhaps it is better to be comprehensive in government reports than concise, to accommodate a variety of readers who want to drill into different aspects of the report.
(Of course, a PDF may not be the best structure for this! A well-formatted HTML reference with appropriate hyperlinks may be much more useful.)
Yeah, but who is actually going to read a 7000 page report on torture or surveillance? (Assuming these reports were actually published, which they were not)
I ran into a similar situation, but decided to submit a short report anyhow. It earned one of my best grades in university. When I asked about the grade, since I ignored multiple guidelines, the response was that I said a lot more than most people even though I wrote less. It probably had something to do with my admiration of concise writing. It is something that I wish that I could accomplish more often.
Good for your professor. I always refused to impose length requirements, but I would say what a typical length for the assignment would be (always in number of words, never “pages”). If you did the job in significantly fewer words, that earned you extra points. If you went long, but every word counted, you also got extra points. But any padding, wasting my time with unnecessary words, meant a penalty.
Honestly, that's just silly. If they'd use html instead of pdf, you'd still have the same content. pdf is a format. It has nothing to do with the content.
The constraints and expectations of the medium strongly influence the content.
If I had an idea and wanted to communicate it, then I did so by recorded video, by live video, by blog post, by Twitter thread, and by HN comment, the same idea would be presented in very different ways.
In the same way, a writer who publishes something by HTML (blog post, etc.) will produce a very different document than if they intend to publish it by PDF (ebook, etc.). They tailor their message to the constraint and expectations of the medium.
That's exactly what the parent is criticizing. The problem with save page is that the HTML you save still contains tons of links to server resources, particularly CSS and JS. Of course those links will work if you look at the saved page immediately after you save it. The problem is that if you come back later, sometimes even just the next day, they no longer work. A lot of JS file names are auto-generated random numbers, produced by packaging systems rather than humans, which change whenever the developers edit their JS. They aren't designed to be stable.
There are tools that try to fetch those links and update the HTML to point to the local copy. But those tools can only go so far. JS is allowed to fetch new files dynamically, and there's no reliable way to look at a piece of code and automatically figure out what it's going to fetch when you run it.
> JS is allowed to fetch new files dynamically, and there's no reliable way to look at a piece of code and automatically figure out what it's going to fetch when you run it.
You've diverged from the context and are no longer doing an apples-to-apples comparison. The things you're describing are all opt-in and amount to having to deal with an adversarial input. There's nothing inherent to the medium that requires those things.
In other words, a person publishing a PDF is already abstaining from certain things. (Namely, the sorts of things you're bringing up that would make for a pathological case.) If the person who publishes a PDF does a straightforward translation into a web page, then you end up with something that doesn't exhibit any of the downsides you're discussing.
No, most browsers will save the resources as well and rewrite the HTML to reference them. You can have problems with dynamically loaded things but I have found that it works very well in practice. I have had maybe one page that was significantly broken saving from Firefox over the years.
Absolutely, depending on how much I care about the content, I either print it directly from the reader mode (which gives pretty bland results) or I touch up the page itself with things like "column-count: 2" and a few changes to headlines, to give it the look of a proper print article. Either way, printing to PDFs is a great way to archive/save web content for later.
It's funny that you mention wikipedia, since one of my favorite wikipedia features is the "download as PDF" link, by which you can obtain any article in a beautiful and readable form.
Not all html pages - what about hackernews? It's mostly tables with minimal CSS (a bit of padding and font*/color), I bet it continues to be perfectly rendered practically indefinitely. At least snapshots on archive.org from 2007 still look perfect.
Content is often written to a predefined length, no matter how it is going to be published. E.g. some news papers even if there is no print version anymore still decide how long a story is going to be upfront. And food bloggers, will fluff up an basic oatmeal recipe with 3 pages worth of childhood stories before getting to the point.
Even if verbose, those PDF are often still the only place where the relevant substance is together. The websites referring to them then cherry pick from it. I spend a whole lot of time sifting trough goverment PDFs over the last couple months because it was the only way to get to the information I needed.
It would be much easier if the content were available in different formats.
I think that's less on the format and more on the intent. For reports and what is traditionally viewed as "written form", reader is expected to have high tolerance for length and boilerplate.
I see it as the pendant of the "younger generations can't read anymore" critic, where lenghty, rambling and diluted prose is becoming harder and harder to parse and focus on.
On the other side page load speed and attention grabbing metrics are thoroughly studied for web pages and people value terseness, to the point of loathing click baits and endless listicles.
Neilsen group has clearly chosen their opinion and then found evidence that supports it. It is a shame too. If they discarded their bias, maybe they could take some of the real problem points about PDFs and make a solid persuasive argument why we should try to fix those problems.
Couldn't agree more! I've yet to see a PDF that has animated ads, pops up a subscribe-to-our-newsletter modal halfway through, or even autoplays video a few seconds after you've started reading it.
I mean I suppose you could do all that with embedded JS, in theory, but one of the nice things about PDF is it mostly works absolutely fine with scripts turned off.
> 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/or clickbaity fluff.
That's entirely cultural crap, and has little to do with either format. Or do you think that this HN comments page would be better distributed in PDF form?
I'm not saying one format is better than the other, or it having to do anything with the format.
The word "Unfortunately" is there on purpose. I often have to sift trough PDFs were it doesn't make sense to have the information only there.
What I'm disagreeing with is that PDFs unlike web pages lack substance. In my opinion the substance is often in the PDFs not because of the format, but how the information is produced.
E.g. within a government or enterprise the content could come from anywhere within the org structure, often multiple intermediaries away from the people putting stuff on the website. Everyone knows basic MS Word. On-boarding potentially hundreds or thousands of employees to a CMS and send them to a "how to craft effective digital content" which is what the Nielson article is ultimately selling is not always feasible. Only select pieces get a web treatment the rest gets summarized if not just linked. News papers have pipelines from Word to digital publishing tools to print / online because of this. But also this setup is not easy.
I just recently needed some specific information about traveling to and quarantine in Switzerland. The news sites where useless, the linked government web page was useless. Only the original PDF at the end of the link chain contained the information.
I'd prefer having this information more easily accessible/searchable. But as it stands, the substance is often in the PDFs, not the web pages.
yeah I want to see what internet the author is browsing because for the last 5 years all I could see if vacuum on the web. headers footer side-ads privacy-popups massive-intro-photo and somewhere lost in all of this, a paragraph. Quite often the content could fit in a tweet.
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.
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.
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.
I have to admit, after a decade of tablets, I am back to printing some PDFS, reading, making notes, and scanning back if I want. It's actually cheaper than continually upgrading the iPad ;-p I still have the tablet but its not my first choice always.
Surely the technology exists to get all the things you mentioned without an insane spec that Adobe allowed to bloom out of control.... I mean... right!?
Please remember that PDFs are absolutely capable of running code and do to deploy the advertising / tracking you listed as an issue with webpages.
If you are part of Adobe's premier advertising / tracking club (whatever it's called), and the user is viewing with Acrobat, you can see what people printed, where they highlighted, how long they stayed on a page, where they accessed, etc etc.
That's more of a problem with Adobe than PDF itself (never use Acrobat!), but that's hardly a rare theme when it comes to Adobe.
I'd like to see you try to have a conversation on a tech & startup news aggregator built in PDF, see how quickly your reader loads it then. You're talking about PDF like the only documents you've seen are printed from LaTeX / Chrome, but PDF supports forms, javascript, 3D models and more.
PDF is an atrociously bad format, and I don't know what "multi-hundred page PDF loads in the blink of an eye" for you but even a 100 blank page PDF takes nearly a second to fully load on my beefy rig (I did the test a few months back to prove a point). [Edit: Other commenters made the clarification below, but single page render time is not the same as document render time]
Clearly extracting text from a PDF is nearly as difficult as extracting it from a photo. Digitally extracting information from PDFs in general is awful, which makes the format awful for the various things it's used for.
Not to mention that many uninformed users today still install the garbage / malware PDF readers such as Acrobat because they don't know any better.
> I don't know what "multi-hundred page PDF loads in the blink of an eye" for you but even a 100 blank page PDF takes nearly a second to fully load on my beefy rig (I did the test a few months back to prove a point).
The manual for PGF/TikZ [1] is a huge PDF I frequently open. It's more than 1300 pages and has lots of graphics. It opens and navigates in the blink of an eye on my 3 year old laptop (with the Okular reader). PDFs aren't perfect, but they sure feel spiffy compared to modern webpages.
I do agree with some of the article's complaints, but not this one.
Okular [1]. It's strange; I'm a KDE user and big fan of the core DE, but I find almost all the KDE software outside of that core DE nearly unusable. Except Okular – it's by far the best PDF reader I know. I guess credit goes to Poppler for the heavy lifting [2].
That is created using LuaTeX and I'm sure the sources behind that PDF document are carefully crafted and LuaTeX works really well. But if you would do the same document with the same amount of images in Microsoft Word and create a PDF document is would be much much bigger and it won't load that quickly.
I will take the last part back, if someone can prove that I'm wrong about Word and PDF documents.
In that case it sounds like a problem with Word and not with PDF.
I wouldn't know – most PDFs I consume are generated by some variant of TeX. I gave a random 300-page datasheet I have lying around a go. It says it was made with Acrobat Distiller and "C2 Rendition". Feels just as spiffy as the PGF/TikZ manual.
The speed depends a lot on how the PDF is structured. If you export a complex CAD drawing you may have a ridiculous amount of detail that has to be fully rendered before the page can be viewed. Or you can have very simple PDFs that are just a few images.
weird, my Alfa Romeo user manual is 270 pages filled with graphics (literally, they are jpeg scanned to a pdf) and loads instantly even on my mobile phone
The first page is rendered instantly you mean. PDF, at least when generated by a sane generator, can be parsed pagewise. HTML cannot, you always have to parse everything in a page to do layout, because later objects can change or overlay earlier ones.
Is PDF still unstreamable? AFAIK, the TOC (catalog?) in a PDF was located at the end of the file, meaning the whole PDF had to come down in order to parse the PDF. (With the exception of the first page, as you say — some aspect of the PDF spec allowed for a self-contained page 1.)
> HTML cannot, you always have to parse everything in a page to do layout, because later objects can change or overlay earlier ones.
HTML is progressively rendered by default. This has been a feature since Netscape 1.0! It is only if you use certain types of layout this is not possible. For example an adaptive table have to be fully loaded before the width of the columns can be calculated.
Even PDFs can be inexplicably bloated. This cropped up on HN discussion a week ago. There was an 11MB bloated PDF, and a 500KB PDF, of the same article, with no visible difference between the two.
> No auto-play animations, no animations at all, no bizarre hijacking of scrolling
HackerNews commits neither of these sins. They aren't universal to the modern web, even if they're annoyingly prevalent. Given sufficient incompetence, both PDFs and websites can be bloated monstrosities.
I don't think reflow is really "fixable" in PDF. PDF's model is fundamentally based on absolute coordinates and transforms for everything, as it's descended from a language for printers. Adding client-side layout to that radically alters the entire design in ways that would make it not PDF anymore.
When you say "a multi-hundred page PDF loads in a blink of an eye compared to a advertising tracker-loaded web page", consider why that is. The basic reason is that every page in PDF can be rendered individually. (In fact, the top-level grouping in PDF is the physical page instead of the semantic model of HTML.) This is only possible because PDF has no layout! When you introduce client-side layout, the client must lay out every page to render any of them, because the locations of page breaks depend on characteristics of the client device, creating a sequential dependency. If you were to somehow add layout to PDF, the sequential dependency would be there too; there's nothing magical about PDF that would prevent it from inheriting the problems of HTML.
Finally, PDF does have animations and scripting (with multiple JavaScript engines). In fact, it even has 3D (old-school VRML-style 3D, not the flexible immediate-mode GPU APIs browsers have). You'd be amazed how bloated PDF is!
PDF is the ultimate WYSIWYG print substitute format. My mom in her 70s can create PDFs from OpenOffice/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.
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.
Finally, PDF works great as a native format that my office printer/scanner understands how to write to. I can scan those annoying tax documents sent to my office to PDF and archive on the NAS/cloud backup as I deal with it and know that I have my documents digitized so I can shred the paper.
This article was about people posting her PDFs online where they are intended to be read by a user encountering them with a browser. The authors seem to agree that PDF is a print substitute format.
I disagree that my statement was off topic. The author in summary states that PDF is "unfit for digital-content display". I gave a specific counter example of a type of regularly reviewed digital content that is beneficial to archive (in this case financial documents that may be necessary for tax purposes).
While this is just one use case of PDF framed in a browser, it still stands as one. I have also in my years regularly needed to archive the contents of a page - such as a receipt of a payment or a report on something.
In that case, printing the PDF seems to be one of the better practices. Saving as a Web archive (or whatever the format is called) is an alternative, but that is slightly harder to then print/fax or otherwise send to someone at a future date.
> I gave a specific counter example of a type of regularly reviewed digital content that is beneficial to archive (in this case financial documents that may be necessary for tax purposes).
How is that a counter example? If instead of PDFs your bank had given you an HTML file encoding the same content, then it would satisfy the same purposes and have the other benefits that the linked article lays out.
> 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.
I don't have a problem with PDFs myself, but surely it would be better if your bank gave you these in text form so that you can actually easily and reliably process them?
The transaction exports in Quickbooks or Quicken format that can be imported GnuCash or whatever is helpful. However, if at some point there is an audit nothing beats the usability of easy for the auditor to understand visual format that is a date/time stamped record.
Also put in for a mortgage or mortgage refinance. What does the underwriter want to see? Two to three years of tax returns (PDF) and two months of bank statements (PDF) to prove the source of your down payment funds.
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'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't use them.
However, PDFs on the Paperwhite don'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's a tool which I use.
By comparison, I check EPUBs out from the library and they are surprisingly pleasant to read on the Paperwhite.
Yeah, the article is about the web and I'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.
BTW, on my MacBook I use Skim which is much better than Reader.
One thing PDF's have going for them is that they are standalone files, so you can download and collect them. The advantages are similar to MP3's for music. HTML doesn't qualify since not even the images are included in the file.
I'm wondering what other file formats might work better, and why aren't they more popular? Epub maybe?
Lately I've been wondering what ever happened to XPS.
My understanding is that it's basically just a zip file with XML markup and any other assets like images. It's both human-readable and machine-readable, which is great for everything from version control to search to conversion between formats.
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'd literally rendered the print version as PDF, and reading that on an iPad was nearly impossible.
Only after hours of linting. If you don't do preflight, colors will be off, some objects won't render, transparencies will be solid and maybe fonts will be missing. PDF is by no means idiot-proof in this regard. I've been burned more than once.
However, PDFs are still better than everything else.
Agreed! Designers spend tons of time on creating a document for printing. I can only imagine if the print house devcided to change the aspect ratio or size of the final output randomly, or lower the printer resolution.
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/dynamic content, but web pages (sites) are also cumbersome for a non-technical user to download for offline use with all elements intact.
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.
It's not true that PDFs are only for print. In fact, MacOS display technologies are based (at least the first iterations) on PDF. PDF for screen can work very well, the problem is that the industry never standardized this aspect of the technology. The result is that viewing PDF nowadays is far from optimal. I truly believe that PDF could have been a much better technology than HTML for modern websites. Instead HTML, which started as a semantic technology, was shoehorned into what we have today.
First, the article makes a claim about PDFs problems for the web, when read online, which is a lot less clickbait-y than "unfit for human consumption".
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.
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&D likely skews my preferences in the direction of paper as an ideal interface :)
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're trying to present information or an article I'd take a beautifully typeset PDF any day over some website with so many trackers and javascript it takes seconds to load.
Not to mention on a tablet PDFs are much, much nicer to read.
PDFs exist to emulate paper (a need which won'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.
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.
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.
In this hypothetical world, the PDF viewer would then decide whether to render it in faithful-to-paper mode or in online-friendly mode.
371 comments
[ 4.9 ms ] story [ 311 ms ] threadOn the one hand, this DOM setup is crazy. Surely a more dynamic architecture would be better where decoders are downloaded on-demand as the user goes from site to site, coming across content types not yet seen. This of course raises security questions, as to the provenance of the decoder and less so of the content.
On the other, having come to the realization that the next logical step on the path to this scenario is WebASM, where the content and decoder are completely opaque to the user one can envision a world where there are a million different types of PDF, each with their own decoder, each trivially but crucially different. It's not a pretty thought.
One way to get the best of both worlds would be to have a normal webpage, but have the "Print this page" button generate a PDF that is nicely laid out. Often webpages are a mess to print.
I wonder how difficult it would be to write a tool that can turn a PDF into a usable webpage.
However in practice many websites don't put any effort into this, which is probably an indication that they wouldn't put any effort into a custom solution either.
> I wonder how difficult it would be to write a tool that can turn a PDF into a usable webpage.
I was looking into this but it is basically impossible. Since PDF is basically a collection of images (with some "fancy" stuff on top) you can get the basics, such as text and headings, however you won't be able to do much for semantics or layout. All web-based PDF viewers I have seen just render each page to an image and put invisible text on top for copy-paste support.
One of the things I absolutely despise about the rise of JS is that many many modern sites won't display anything (just the white BG) unless I allow 3rd party scripts. Is displaying simple blogposts and other textual information with the occasional image or video embed so hard that one needs to load often multiple MBs of JS from multiple external sites?
It's infuriating.
I'll have another look. While I despise frame transition animations etc, for some stuff some nice animations are really helpful in explaining concepts.
Give me a link... I might visit it in a browser.
I have a book, and I'd like to display video clips. AIUI, that requires that the viewer has JS.
But I get your point. PDF are not optimal for sure. And personal mileage may vary, I'm very sensitive to having proper text spacing and so on.
Isn't it true that every software project -- and indeed every project -- falls short of what people may want?
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's the browser trying to fit things the way they should on a page and it generally looks horrible.
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.
This is almost impossible to do right. Even browsers can't produce a PDF that looks exactly the same as a web page.
If you want to programmatically produce a PDF from a web page, the best bet is to load up a full browser implementation just for that purpose as any other simpler solutions would certainly break the results pretty often.
And so alas it all sucks.
For eBooks, I've settled on reflowable EPUB. I guess, in some cases, we may want fixed format, where PDFs might be useful.
For online, I prefer HTML, usually as a continuous page, and with "pretty print" (@media print) CSS. I find it annoying that the page-break-% CSS rule seems to be ignored by just about every browser, or at least, interpreted badly.
I really have gotten a lot out of the NNG folks; in particular, Don Norman, but they do like to kick anthills.
Until these issues are fixed, I'll keep enjoying my beautiful LaTeX PDFs, thank you!
IMHO Adobe has been a terrible steward of PDF. I have no idea why. (Source: Used to write print production software in the 90s. Some of my team went to Adobe. One was bored so banged out a PostScript clone hooked up to the newer image library in a few weeks. They all said the PDF libraries were garbage, everyone was afraid to breathe on them, no one was motivated to do anything better.)
Re NNG: Agree. +1 Don Norman, whereas Nielsen and Tog haven't said anything interesting in ages.
Agree. EPUB is a fairly half-baked solution. Reflowable PDF might have been good, but, I guess there was never any support for it.
One needful use case was (is?) variable data printing, allowing mass customization, like direct mail. Pretty much the same technical progression that happened in user interfaces going from absolute coords and static layout to dynamic layout managers.
The fix was so easy. Just retain some of the source document's meta data, eg this group of glyphs are a "paragraph". The PDF object model was explicitly designed for exactly this kind of extension.
IIRC Some specialty vendors had some goofy work-arounds, like a post process tool for manually marking paragraphs.
But Adobe could never be bothered.
The Books app on iOS can do this.
I know Foliate does continuous scrolling, but it's only on *nix platforms.
In addition, typography and style are poorly adapted in EPUB format whereas with PDF - it can be read instantly on any device, any where and usually without installing a reader or fonts. There is so much inconsistency between Windows/Linux and Mac, iPhone, Android when reading an EPUB book.
EPUB = Great for text only literature.
PDF = Great for pretty much everything else.
I do a ton of academic research, and whenever I find a source in EPUB I have to convert it to PDF first, just so I can do highlighting, circling, etc.
True, EPUB applications generally allow you to highlight, but those highlights are stored in the application. They don't live in the file. You can't export them to import them in another reader program. With PDF, all my annotations stay in the PDF itself, and appear in all fully-featured PDF software.
But when you need the formatting, PDF is wonderful.
The problem with HTML is that it's a moving target.
The characters were overlapping, no matter which reader I use, what margin/line/character spacing I set, until I adjusted the font size to two points smaller, and everything was right.
It turns out that whoever made the epub, turned every word into a single html element, with a fixed position!
So, it was like PDF in a sense that every thing has a position on the page. But it was like epub in the sense that everything's size can be changed (albeit within the "div" element). And the default size doesn't event work for the book.
I cringed so fiercely that I nearly deleted the book.
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/or clickbaity fluff.
They then go on about how in web sites the content can be better structured and navigated. Unless I'm misunderstanding the word in English, what has that to do with whether the content has substance?
> [...] This leads to overwhelmingly long and inane PDFs
You mean something akin to a book?
Government reports, or those prepared by consultants, are often the worst offenders.
We put all sorts of rubbish in the report to make sure it made a "thunk" sound when we handed it in. It was nearly 300 pages when it should have been 90.
The problem is, plenty will judge a report on its thickness. "It is thick, so it must be comprehensive." What percent of government reports are read cover to cover and what percentage are just ctrl+f through?
Perhaps it is better to be comprehensive in government reports than concise, to accommodate a variety of readers who want to drill into different aspects of the report.
(Of course, a PDF may not be the best structure for this! A well-formatted HTML reference with appropriate hyperlinks may be much more useful.)
http://media.metro.net/about_us/vision-2028/report_metro_vis...
If I had an idea and wanted to communicate it, then I did so by recorded video, by live video, by blog post, by Twitter thread, and by HN comment, the same idea would be presented in very different ways.
In the same way, a writer who publishes something by HTML (blog post, etc.) will produce a very different document than if they intend to publish it by PDF (ebook, etc.). They tailor their message to the constraint and expectations of the medium.
Didn't anyone notice that it's basically impossible to save an html page today and have it load and render correctly and offline tomorrow?
There are tools that try to fetch those links and update the HTML to point to the local copy. But those tools can only go so far. JS is allowed to fetch new files dynamically, and there's no reliable way to look at a piece of code and automatically figure out what it's going to fetch when you run it.
You've diverged from the context and are no longer doing an apples-to-apples comparison. The things you're describing are all opt-in and amount to having to deal with an adversarial input. There's nothing inherent to the medium that requires those things.
In other words, a person publishing a PDF is already abstaining from certain things. (Namely, the sorts of things you're bringing up that would make for a pathological case.) If the person who publishes a PDF does a straightforward translation into a web page, then you end up with something that doesn't exhibit any of the downsides you're discussing.
[0] https://github.com/Tade0/emergency-poncho
Even if verbose, those PDF are often still the only place where the relevant substance is together. The websites referring to them then cherry pick from it. I spend a whole lot of time sifting trough goverment PDFs over the last couple months because it was the only way to get to the information I needed.
It would be much easier if the content were available in different formats.
I see it as the pendant of the "younger generations can't read anymore" critic, where lenghty, rambling and diluted prose is becoming harder and harder to parse and focus on.
On the other side page load speed and attention grabbing metrics are thoroughly studied for web pages and people value terseness, to the point of loathing click baits and endless listicles.
> and boring to read.
Not only is that subjective, but how is that relevant?
That stuff is thorough as hell and you even get schema definitions for all of it.
I'd pick that over poorly explained or 'discoverable' alternatives.
I mean I suppose you could do all that with embedded JS, in theory, but one of the nice things about PDF is it mostly works absolutely fine with scripts turned off.
That's entirely cultural crap, and has little to do with either format. Or do you think that this HN comments page would be better distributed in PDF form?
The word "Unfortunately" is there on purpose. I often have to sift trough PDFs were it doesn't make sense to have the information only there.
What I'm disagreeing with is that PDFs unlike web pages lack substance. In my opinion the substance is often in the PDFs not because of the format, but how the information is produced.
E.g. within a government or enterprise the content could come from anywhere within the org structure, often multiple intermediaries away from the people putting stuff on the website. Everyone knows basic MS Word. On-boarding potentially hundreds or thousands of employees to a CMS and send them to a "how to craft effective digital content" which is what the Nielson article is ultimately selling is not always feasible. Only select pieces get a web treatment the rest gets summarized if not just linked. News papers have pipelines from Word to digital publishing tools to print / online because of this. But also this setup is not easy.
I just recently needed some specific information about traveling to and quarantine in Switzerland. The news sites where useless, the linked government web page was useless. Only the original PDF at the end of the link chain contained the information.
I'd prefer having this information more easily accessible/searchable. But as it stands, the substance is often in the PDFs, not the web pages.
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.
Please remember that PDFs are absolutely capable of running code and do to deploy the advertising / tracking you listed as an issue with webpages.
If you are part of Adobe's premier advertising / tracking club (whatever it's called), and the user is viewing with Acrobat, you can see what people printed, where they highlighted, how long they stayed on a page, where they accessed, etc etc.
That's more of a problem with Adobe than PDF itself (never use Acrobat!), but that's hardly a rare theme when it comes to Adobe.
PDF is an atrociously bad format, and I don't know what "multi-hundred page PDF loads in the blink of an eye" for you but even a 100 blank page PDF takes nearly a second to fully load on my beefy rig (I did the test a few months back to prove a point). [Edit: Other commenters made the clarification below, but single page render time is not the same as document render time]
Clearly extracting text from a PDF is nearly as difficult as extracting it from a photo. Digitally extracting information from PDFs in general is awful, which makes the format awful for the various things it's used for.
Not to mention that many uninformed users today still install the garbage / malware PDF readers such as Acrobat because they don't know any better.
The manual for PGF/TikZ [1] is a huge PDF I frequently open. It's more than 1300 pages and has lots of graphics. It opens and navigates in the blink of an eye on my 3 year old laptop (with the Okular reader). PDFs aren't perfect, but they sure feel spiffy compared to modern webpages.
I do agree with some of the article's complaints, but not this one.
[1] http://mirrors.ctan.org/graphics/pgf/base/doc/pgfmanual.pdf
[1] https://okular.kde.org/
[2] https://poppler.freedesktop.org/
I will take the last part back, if someone can prove that I'm wrong about Word and PDF documents.
I wouldn't know – most PDFs I consume are generated by some variant of TeX. I gave a random 300-page datasheet I have lying around a go. It says it was made with Acrobat Distiller and "C2 Rendition". Feels just as spiffy as the PGF/TikZ manual.
Sure. I agree we shouldn’t replace interactive web apps with PDF.
https://news.ycombinator.com/item?id=24093273
You can see it mentioned in the v1.4 spec at https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/pd... [follow the link from the contents].
I rest my case
HTML is progressively rendered by default. This has been a feature since Netscape 1.0! It is only if you use certain types of layout this is not possible. For example an adaptive table have to be fully loaded before the width of the columns can be calculated.
As annoying and obnoxious as animations and scrolljacking are, I prefer them to things like embedded viruses and SMB attacks that PDFs with embedded JS will happily run. https://www.sentinelone.com/blog/malicious-pdfs-revealing-te...
https://news.ycombinator.com/item?id=24035955
> No auto-play animations, no animations at all, no bizarre hijacking of scrolling
HackerNews commits neither of these sins. They aren't universal to the modern web, even if they're annoyingly prevalent. Given sufficient incompetence, both PDFs and websites can be bloated monstrosities.
I've never needed an ad blocker for a PDF. But I also don't have a good pdf reader for all of my devices.
When you say "a multi-hundred page PDF loads in a blink of an eye compared to a advertising tracker-loaded web page", consider why that is. The basic reason is that every page in PDF can be rendered individually. (In fact, the top-level grouping in PDF is the physical page instead of the semantic model of HTML.) This is only possible because PDF has no layout! When you introduce client-side layout, the client must lay out every page to render any of them, because the locations of page breaks depend on characteristics of the client device, creating a sequential dependency. If you were to somehow add layout to PDF, the sequential dependency would be there too; there's nothing magical about PDF that would prevent it from inheriting the problems of HTML.
Finally, PDF does have animations and scripting (with multiple JavaScript engines). In fact, it even has 3D (old-school VRML-style 3D, not the flexible immediate-mode GPU APIs browsers have). You'd be amazed how bloated PDF is!
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.
Finally, PDF works great as a native format that my office printer/scanner understands how to write to. I can scan those annoying tax documents sent to my office to PDF and archive on the NAS/cloud backup as I deal with it and know that I have my documents digitized so I can shred the paper.
While this is just one use case of PDF framed in a browser, it still stands as one. I have also in my years regularly needed to archive the contents of a page - such as a receipt of a payment or a report on something.
In that case, printing the PDF seems to be one of the better practices. Saving as a Web archive (or whatever the format is called) is an alternative, but that is slightly harder to then print/fax or otherwise send to someone at a future date.
How is that a counter example? If instead of PDFs your bank had given you an HTML file encoding the same content, then it would satisfy the same purposes and have the other benefits that the linked article lays out.
I don't have a problem with PDFs myself, but surely it would be better if your bank gave you these in text form so that you can actually easily and reliably process them?
However, PDFs on the Paperwhite don'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's a tool which I use.
By comparison, I check EPUBs out from the library and they are surprisingly pleasant to read on the Paperwhite.
Yeah, the article is about the web and I'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.
BTW, on my MacBook I use Skim which is much better than Reader.
I'm wondering what other file formats might work better, and why aren't they more popular? Epub maybe?
My understanding is that it's basically just a zip file with XML markup and any other assets like images. It's both human-readable and machine-readable, which is great for everything from version control to search to conversion between formats.
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'd literally rendered the print version as PDF, and reading that on an iPad was nearly impossible.
However, PDFs are still better than everything else.
Using PDFs to distribute content online instead of web pages is the real issue.
Same problem with trying to use a hammer with screws.
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.
Simplified syntax, defined structure, not locked to physical form factor.
Still has warts, but a pretty good compromise.
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.
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&D likely skews my preferences in the direction of paper as an ideal interface :)
To get decent typography, one needs TeX, and TeX produces PDFs, not web pages.
Not to mention on a tablet PDFs are much, much nicer to read.
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.
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.
In this hypothetical world, the PDF viewer would then decide whether to render it in faithful-to-paper mode or in online-friendly mode.