Funny enough, I think one of the reasons PDF became so popular, is because it was originally seen as a "difficult / impossible to modify file that can be downloaded as a file and read in a static way". The lack of editing tools in the most popular PDF reader for a long time (Acrobat Reader) was the reason it became such a widely used format. Especially compared to distributing a .doc or .docx where the user can easily accidentally change something.
In a way a locked tampersealed document is a pretty decent template for parsing data as well. It is messy as PDFs always are but a decent lib and a consistent source with sealed docs can be used for decently verifiable scraping.
For instance some sort of license, certification or official document like tax forms, it can be generated with a common output, tampersealed and then reliably parsed after verification.
Isn't "the purposes of the two formats are basically orthogonal" actually the entire point the article is making? Literally the first line of the summary:
> Research spanning 20 years proves PDFs are problematic for online reading. Yet they’re still prevalent and users continue to get lost in them.
From the second paragraph:
> The [PDF] format is intended and optimized for print. It’s inherently inaccessible, unpleasant to read, and cumbersome to navigate online.
The bolded statement in the second paragraph that's clearly meant to be the One Important Thing to Take Away:
> Do not use PDFs to present digital content that could and should otherwise be a web page.
Your comment here is eloquent, but the article's argument is not "print-layout documents should be replaced by hypertext," it's "print-layout documents are a poor fit for reading on screen-layout devices." When you conclude:
> It's all a matter of opinion over whether you prefer print-format documents or hypertext, and that's going to be very application-specific.
Aren't you essentially restating the article's thesis?
I don't want to read an article online that's a PDF for largely the same reason that I don't want to print the web version of the same article rather than a PDF. It's generally going to be clunky. The print page size and dimensions are not going to be my screen/window size and dimensions. I certainly don't want to read two- or three-column text on screen, which may require zooming in and out and scrolling back and forth on the same "print" page. And God help me if I'm trying to do that on my phone or iPad mini.
The article isn't saying "PDF is terrible and nobody should ever use it"; it's saying "PDFs were meant for specific applications and in nearly all circumstances, online reading is not it."
(If you're using PDFs for precisely-scaled engineering drawings, I expect you're well aware of this and have a workflow that avoids scaling, but I see people trip over it all too often.)
Good for you, but that doesn't change that most of the uses of PDF on the web aren't for applications like that.
[0] http://www.throwcase.com/2014/12/21/that-five-monkeys-and-a-...
PDF format is perfectly capable of holding structured text and other machine-readable/accessibility data, alongside the print-ready representation. Ask the developers of document authoring tools (starting with MS Office) and the various PDF generation libraries why they don’t include all that data as standard.
One can argue the appropriateness of a print-derived format in a constantly fluid digital world, but it does what it was designed to do and does it pretty well, and it could provide a lot more if developers and users could be bothered to do it.
And yes, HTML is its own exercise in awfulness that is equally bad at everything. I’d rather set my feet on fire that propagate that horror further.
Honestly, what we really need is a 21st-century Donald Knuth. I only wish she’d hurry up.
However, it is possible to turn HTML5 into statement-of-record documents (Not PDF's),and make them immutable, encrypted and authenticated. A HTML5 document can have the features we need from PDF (immutability, encryption, authentication, pixel perfect print, etc.) while still allowing the resulting document to be interactive and responsive (work well mobile & web) in nature.
Effectively the best of both worlds.
What I don't get is the authors' assumption that replacing with HTML means replacing with HTML that correctly uses "color, contrast, document structure, tags, and much more", leaves users in "a familiar context", is not "excruciatingly slow to load both on desktop and mobile", correctly employs "chunking, using bullets, subheadlines, anchor links, and accordions", and "show[s] a standard navigation", as opposed to … all that stuff that's actually out there. I don't know about the authors, but, if you give me a choice between a typical web site's idea about the flashy, JavaScript-heavy, animated, ad-laden way that I want to consume information on one hand, and a PDF on the other hand, then I'll take the PDF every time.
That's how I want it. I'm tired of new formats and new frameworks and new tools releasing every single year that pretend they're better. The best thing about PDF is that it doesn't change. Yes, whatever, Adobe adds new features, but any PDF ebook I download has nothing to do with that, nor that PDF scientific paper I downloaded this morning. I don't want random authors to be able to dictate how I interact with a medium, because the vast majority of them are, frankly, idiots when it comes to this domain and they have no sense of good user interface design.
You can, and I do, hope for this, and it's often what you get, but it's not at all guaranteed by the format. For example, PDF allows JavaScript: https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdf... . I think most readers other than Acrobat probably don't support it (which, of course, Adobe spins as a feature of Acrobat!), and not too many PDFs require it—although I do find that fillable PDFs, including from hopefully capable authors like the IRS, can be very finicky in anything other than Acrobat—but I fear it's only a matter of time until it becomes as difficult to "browse the PDF without JavaScript" as it currently is to browse the web without it.
> I don't want random authors to be able to dictate how I interact with a medium
On this score you're out of luck even now—if the author, intentionally or unintentionally, did a bad job creating the PDF, you're out of luck. This is one area where I'll give HTML the win: it is, or can be, good at things like dynamic reflow, whereas PDF not only isn't but, I believe, effectively can't be.
I'm not sure what you mean. I've never had an ebook or paper have any influence on how my PDF reader works or how I interact with it.
I was responding to a quote which I think, in retrospect, I misread:
> > I don't want random authors to be able to dictate how I interact with a medium
To me, random authors of PDF files do dictate how I interact with the content of the PDF file—I'm not sure whether or not to call that "the medium"—because they lay it out, and there is very little that I can do after the fact if, for example, I don't like their line breaks or their text layout, or if I want to be able to do a proper full text search, or cut and paste, etc. etc.
However, on re-reading (including your response above), it seems clear that what you meant, and what I should have understood, was not about being locked into the author's presentational choices, but about the UI of the PDF reader itself. I agree that what I said is irrelevant to this.
Improving the tooling will make PDFs load faster and (possibly) be easier to navigate. (Unless they're JPEGs stitched together in a booklet, in which case they're pretty much hopeless from a navigation standpoint in any event.) It won't, however, address the core concern, which you touch on here:
> What I don'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's argument seems more akin to "print-layout documents should be replaced by hypertext," and perhaps this is true in some cases, but it's definitely a different matter and one that the author's arguments don't really support that well.
I mostly agree with you:
I think the arguments support it well enough: PDFs are sized for print, laid out for print, and fundamentally do not flow. HTML, despite the best efforts of some, is still malleable enough you can have a single page which gracefully resizes itself to a range of screens, a minor technical miracle the march of UX progress still hasn't fully taken from us.
My response to the author is this:
PDF looks the same on the screen as it does on the page. That is its blessing. That is its curse. Some people absolutely demand that as a hard requirement, and will not brook anything which adapts to different environments. If they didn't have PDFs, they'd go back to making websites where all of the content is in a series of JPEG images scaled to look right on their screens. I've seen it happen. Therefore, replacing PDF with HTML is not socially viable. It doesn't solve the "soft" problem, which is a harder constraint than any technical problem.
The meta-UX point is that a fixed layout allows you to use spatial relationships to indicate how fields are related. This is such an intuitive thing even inexperienced or amateur designers tend to do it by default.
Reflow doesn't allow this, and with some forms, reflow can literally make the layout - and the content - incomprehensible. There are workarounds, but it's often impossible to create a dynamic design that has the same mix of information density and spatial hinting as a static layout.
I can't help but think that HTML's third downside is the remarkable unevenness of the its quality.
The second downside is the remarkable unevenness of the quality of the CSS that is used with it.
The primary downside is the remarkable dangerousness of much of the JavaScript that is found bound to the HTML, that if turned off means that you often see a message that this site requires you turn on our dangerous JavaScript. At the best you end up back with the second and third downsides moving up a level.
on edit: perhaps a little facetious, but given the problems with quality found with websites that probably most of us are aware of it seems a bit much to complain about the quality of PDF. Maybe this is just some silly whataboutism on my part though.
Are you aware that PDF format has also featured JavaScript support (and related vulnerabilities) for a long time now [1]?
Just to clarify, the issue with the compression algorithm used by the scanner, not with the PDF format itself.
There a few videos of David Kriesel explaining the bug for the curious: https://www.youtube.com/watch?v=c0O6UXrOZJo
As far as I know, Firefox is the only browser that uses pdf.js. Chrome uses PDFium, Safari uses the macOS system pdf libraries, and Edge probably does what Chrome does.
I guess the extension to use pdf.js with Chrome is pretty popular.
Really though I might not be using the best term, esp. with the definition of hypertext being one of those things that's a little historic now. I'm mostly just comparing between print formats and formats where layout is done by the viewer to reflect user preferences (which is kind of a dead concept with HTML anyway, but...)
Is that really so? PSDs are through and through binary, while PDFs smell more like PostScript with extras...
It also has some optimisations for it's specific use case, such as that individual pages are completely described independently, whereas in PostScript the code generating any page can affect the content of any succeeding page. This is why in PDF files you can easily re-order pages or efficiently jump directly to and render any page.
The real advantage of PDF is that the images which are used inside the document are bundled into the same file... Whereas HTML has historically required the image files to be loaded from elsewhere which made it not portable. That said, now with HTML, you can define images with base64 data, so it could in fact replace PDF.
PDFs are treated that way, but it isn't really true. Due to the complexity of the format, there are many PDFs that will display differently in different viewers.
I don't see a problem with giving the document creator the option to go with a fluid or fixed layout and make the software default to fixed layout.
HTML and CSS theoretically have these properties, but if you asked someone in the publishing industry to layout a book with them they would either quit on the spot or hate you until their dying breath. That or they're a masochist and want to see if they could actually do it because it is theoretically possible.
What are some good WYSIWYG vector standards, including the font department? It could be useful for a GUI markup standard also so that we can have platform-neutral GUI's and GUI's over HTTP.
The server side may still have a dynamic/flow layout engine, but calculated coordinates are sent to the client, keeping the client simpler and more predictable.
Except pdf.js is not satisfactory. Every now and then I come across a PDF file where text is invisible, because Firefox uses a blank font instead of an external font.
If it is a limited subset, I am okay with it. With increasing ubiquity of mobile devices, reflowing PDF is hard. I rather like EPUB these days. Which consists of XHTML. And reader support is also fairly ubiquitous with many Open Source software supporting Epub.
http://www.ecma-international.org/publications/standards/Ecm...
It doesn't help that nobody in Adobe could say no to every new feature that might possibly help to sell another upgrade to Acrobat.
Altough, for most people a non wysiwyg editor is too cumbersome.
I have yet to find an Android scanner that doesn't make pdfs that weight less than 350K per page. I have tried MS Lens, CamScanner, and a few others I cannot recall at this time.
Has anyone had success in this arena?
As far as a I know the svg format has comparable capabilities for graphics, all that is missing is a "page model" for html which would have to be invented.
But another barrier is that browsers refuse to support SVG fonts. One supposed reason for this, the lack of hinting support in SVG fonts, is less relevant now with high DPI displays - macOS no longer does hinting at all I believe. The additional effort to support SVG fonts is really minimal [2], so it seems strange that it's intentionally omitted.
[1] https://github.com/styluslabs/ulib/blob/master/miniz_gzip.h
EPUB. It's already zipped HTML and supports fixed layout.
Or, perhaps more simply, maybe just HTML + paged.js.
> all that is missing is a "page model" for html which would have to be invented.
CSS paged media is already a thing. What else do you need?
EPUB3 uses an XML packaging document, and the XML serialization of HTML5, so it doesn't really use lots of XML as opposed to HTML.
The world has also gotten more international and a PDF designed for US Letter Size doesn't fit A4 paper used in many other countries.
PDFs is left over from the early 90s when print was still the main way we communicated. We didn't yet email each other, at least not the masses. We didn't have lots of different devices. Our screens were low-res so it was much easier to read paper than screens (some people might still find that true). Heck, when PDF came out in 93 most PCs still ran DOS.
Now-a-days though does nothing bet get in the way. Sure, some rare PDFs can be reflowed but basically PDF wasn't designed for that and it's certainly not used that way. We need a format that re-flows for all the various devices we might be reading something on. For the most part HTML seems to fit that bill. Maybe a version with better image/diagram embedding would be good but we arguably do not need something brand new from scratch.
TL:DR; the world changed. PDF is designed for the the world from 30yrs ago. May it rest in peace.
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 "PDF replacement" but is nearly equally complicated (being based on the MS Office OOXML formats, giving it a similar cursed heritage to PDF's basis in the Photoshop PSD format), and there was never really a compelling argument to switch to it.
What I don'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's argument seems more akin to "print-layout documents should be replaced by hypertext," and perhaps this is true in some cases, but it's definitely a different matter and one that the author's arguments don't really support that well.
In my opinion, hopefully more humble than the author's, PDF's main downside is the remarkable unevenness of the quality of the creation and reading tools, considering its supposedly "reads everywhere" nature. The "reference implementation" 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'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.
The author'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.
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 "l" but maybe I'm imagining that... but also maybe it reflects some frightening detail of the format or implementation behavior.
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 "knowing the tricks" 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 "optimize file" tool can reduce file size by 90% without apparent visual impact... the whole fact that Acrobat has an "optimize" tool (and that Acrobat Distiller used to exist) speaks to the scale of this problem. Inspecting PDFs that are "optimized" by Acrobat can be an alarming experience, as well. You may remember that this played a strange role in Obama'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 "optimizes." It's hard to know how much of this is actually "best practice" versus just a result of Acrobat accumulating decades of eccentricities.
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'm not sure that there's any sound technical argument that PDF or web pages are a "better format," it's all a matter of opinion over whether you prefer print-format documents or hypertext, and that's going to be very application-specific.