I read it on my phone. I then clicked an external link at the end and then hit my browser back button. I had to wait for the PDF to re-load and was unhappy when I found myself back at the top of the document.
PDF is not a web format and you’re wasting effort trying to shoehorn print content and a print format for display on the web. Just use HTML and don’t update it, it’s probably easier.
It would be better if they just used that subset and just published it directly instead of needlessly repackaging it, but if that's what was meant then sure. Maybe we need a better name for simple, semantic HTML and basic CSS.
The point of it is to be a self-contained package. You still need hardware to read it, but not a server. In theory at least, once you have it, it's yours. (of course the commerical ebook vendors are trying to spoil that.)
EPUB is an under-appreciated format that I think can serve as a short to mid-term storage for human knowledge. Can reasonably re-flow itself when necessary, no language run-time required, just a full Unicode support at least at the level of the time the file was published.
That's the Internet of knowledge I'd love to see: things organized in EPUB's, searchable and downloadable.
It's pretty amazing that the basic HTML that I learned 20 years ago still works - it even displays fine on devices like tablets and phones that did not even exist 20 years ago. I understand the author's sentiment but PDF is an overreaction. Just write static boring HTML.
Indeed, there's a lot of irony packed into the first page:
Featured is a quote from LWN indicting the "software industry" and its "brittle dependencies". What's ironic about this? It's squarely about the parts of the software industry that deal in things that are _not_ meant to be painted in the browser.
If you want a solution to the (perceived) churn, it's funnily enough right in the quote from Mark Pilgrim: "I've migrated to HTML 4". HTML is almost certainly not going to end up drifting in such a way that DJB's qhasm bibliography page[1] is ever going to break. HTML and the Web standards in general are, with extremely rare exceptions, cumulative. It's pretty frightening how many technical people don't understand this; the Web is intentionally engineered to serve as "the infrastructure for handling humanity's publishing needs indefinitely"[2]. More frightening is that the biggest threat to this are people like the author here who treat the Web as if it's like any other thing that the computing industry puts out—i.e., already perennially broken. This is dangerous because it anachronistically cedes power to folks who'd try to argue at some point in the future that the things about the Web that they'd like to break (and might be in a position to break e.g. due to browser monopoly) are justified and no big deal, really.
The author goes on to call out the Web ("of rubbish") as "user-hostile". Shortly afterward, he or she writes that "PDF makes a stand against the churn". More accurately, PDF makes a stand against the user, by prioritizing authors' creative whims over the reader's needs. This happens again later in their remarks about PDFs being page-oriented: "you are fundamentally not in control of the reading experience." The "you" here is not you, the actual reader. The control they refer to is, once again, the author's.
You get other poor arguments—that PDFs are "offlineable" "files" that can be distributed "decentralized", none of which are accurate criticisms against what HTML lacks—unless those Java documentation zipballs that seemingly every university student enrolled in a CS program in the early 2000s was made to download are a collective hallucination.
And it gets worse from there. Cute stunt to grab attention and all, but the arguments are fundamentally bankrupt.
> it even displays fine on devices like tablets and phones that did not even exist 20 years ago
It would display perfectly if mobile browsers didn't have broken defaults (to work around broken websites) that you need to disable using <meta name="viewport" content="width=device-width, initial-scale=1">.
It's not a browser format (though browsers can render it), but that isn't the same not being a web format. The web is just the ability to retrieve files from other people's servers, that may themselves reference other files on yet other people's servers. As long as a file format supports hyperlinks, then it's suitable for the web. If you don't care about being able to actually click the hyperlink to activate your desktop system's uri schema handler, then even plain text works fine.
In all browsers that I use that is only true if the server sends a Content-Disposition header with its value set to “attachment” (optionally with a file name), or maybe also in the case where the server specifies incorrect or unspecific Content-Type (such as simply “application/octet-stream” instead of “application/pdf”).
Definitely less freedom. On html I the reader can change the size of text or even the font and the text will reflow so you don't need scroll horizontally to read each line. How do you do that to a pdf?
I certainly get the argument, but using something like hugo or gatsby or jekyll when you want to avoid the "churn" also seems like a perfectly valid solution.
The only thing I like about PDF compared to HTML is that with PDF, I know for a fact that no web requests are made in the background. That means no fingerprinting, no analytics etc.
With HTML, I have to trust that some random entity does what they state in their privacy policy, and they regularly don't. Sure, I can disable JS, but then 95% of the web doesn't work anymore.
Other than that PDF is quite clearly a less accessible format.
When I click a link you mean? Definitely true, but that way they only have access to my IP and user agent, which is still better than all the WebGL, Font library, display calibration settings, mouse movement etc. that they use otherwise.
I often use Tor, although I'm pretty sure that even then, a good analytics lib can see it's me based on scroll behaviour, mouse movement, time of day, and of course what I browse.
That's not the PDF spec is it? That is a spec for Adobe Acrobat, which is not allowed to make any web requests thanks to my application firewall (Little Snitch).
Pretty sure a PDF opened in the browser can't run any JS, but not completely sure. So you're right: I don't really know it for a fact. Poor choice of words.
The spec is ISO 32000, and it’s expensive and closed, so difficult to reference. But according to Wikipedia at least, JavaScript is normative in it. No idea if SOAP / Web Services is part of it though.
Are you sure? I was under the impression that PDFs can reference web resources, and this is why there are more stringent standards for archiving (PDF/A and friends)
> With HTML, I have to trust that some random entity does what they state in their privacy policy, and they regularly don't. Sure, I can disable JS, but then 95% of the web doesn't work anymore.
If you only allow PDF, then 99.9999% of the web doesn't work anymore.
I'm all for getting sites to be static, but PDF doesn't fix that because the problem has never been the technology used to build the site.
The author addresses this pretty well. Because you can embed whatever you want, static site generators aren't really static. In particular, Jekyll blogs and what not still pretty commonly include comment sections.
Of course, pdfs aren't necessarily static, either, but that is why Lab6 is choosing to use pdf/a, an actually static format intended specifically for long-term archiving of immutable files. This way you can sign the file and guarantee it stays the same forever and everyone's copy is identical.
I'm kind of surprised at the response to this. The author seems well aware of how terrible pdf is as a format and this isn't some treatise of why we should want to use it. It's an unfortunate compromise that, given the requirements they're aiming to meet, of generating a file that supports rich formatting and hyperlink embedding, but which can guarantee immutability and long-term archiving directly in the spec, pdf/a is all there is, so in spite of being a terrible format with a lot of shortcomings, it's what they're using.
Why don't they just use a static subset of HTML? You don't have to include comments sections, just like you don't have to include 3D CAD models and videos in your PDFs (yes you can do both of those, in theory anyway).
> The author addresses this pretty well. Because you can embed whatever you want, static site generators aren't really static. In particular, Jekyll blogs and what not still pretty commonly include comment sections.
But just like you can choose to use PDF/A, you can also choose to have a completely static and self-contained (e.g. using data URLs for images) HTML page.
Nobody is requiring you to use PDF/A. No mainline browser (that I'm aware of) requires it.
So what is being solved? When I click on a PDF on the web, I don't know if it's using PDF/A, I don't know if it's embedding or linking its fonts. So it's the same situation, nothing has changed.
Telling people to use PDF/A when most clients do not enforce it and when there's no indication to users before they click on a link whether or not the link is following the spec -- it is exactly the same as telling them to use a subset of HTML; the author is doing the same thing they complain about.
You can't just say that PDF/A exists. That's not enough, how will you get people to restrict themselves to that format when 99% of their users will never notice the difference and no client is enforcing it?
While this may be extreme, I do notice that it is becoming harder and harder to print webpages to PDF/paper. Is there a good approach for this besides the standard print dialog?
For sites without print-specific media queries (so basically all websites) I use dev tools to delete all the DOM nodes I don’t want to appear in print.
While I appreciate the sentiment, I don't think PDF is the way, at least in the way you're currently doing it. PDF maybe supported by browsers, but they're not intended for it, it's secondary feature. Same for search engines. Same for mobile.
Most browsers have Print to PDF. If you want people to be able to download an immutable version of your content, then just have a simple static version of your page with a valid print css, better yet, leave everything default.
There are also other lightweight alternatives. The Gopher protocol has a small, but disturbed following : http://gopher.muffinlabs.com/gopher.floodgap.com (you can actually use netcat as your gopher client). Gemini is a more modern gopher-inspired protocol https://gemini.circumlunar.space/. Personally, I'd be pleased to see a text-first approach gain adoption. I don't think anyone looks at the thick-client model browsers have evolved into and sees an optimal solution.
I think evangelistic energy should probably be directed at complaining to organizations that share content through JS-framework monstrosities. Getting rank-and-file web-devs excited about lean websites doesn't hurt, but clients and CTOs have real decision making power.
Well, sort of. Can't HTML contain script tags with external references (xmlHttpRequest or any async fetch) that a simple crawler/browser may not save to disk?
They could, but if he's the one create the file, he can choose. And if he's just hosting the file, I'm sure there are tools that will inline all the external resources.
Maybe the author doesn't realize how difficult PDF is to work with. In PDF it's ambiguous whether any two spans of text belong together in the same sentence or paragraph. It can even be unclear where are spaces between words. PDF also allows "optimizing" font usage that makes text unreadable without OCR-ing the custom font. The messy hacks go on and on:
OTOH it's totally possible to make a self-contained HTML page without using a JS framework of the day. It's going to be way easier to consume than a PDF.
Case in point: copy-pasting a paragraph from his PDF-website adds line breaks everywhere. It also loses formatting (bold/italics) and the footnote superscript doesn't translate.
PDF is an open standard, which is freely available2, and stable. It has a
version number and many interoperable implementations including
free and open source readers and editors.
I think ease of copy-pasting is one of the coolest things about the document-centric roots of the web (along with the back button and hyperlinks; in other words, hypertext rules), although the modern web does break it (along with the back button and hyperlinks) in many places, so I can see where he is coming from. PDFs aren't the answer, though.
> OTOH it's totally possible to make a self-contained HTML page without using a JS framework of the day.
I'm basically in agreement, but the author has a good point that PDF is obviously self-contained and self-contained HTML pages are not necessarily distinguishable from those that aren't. Perhaps we might have to revisit MHTML or embrace Web bundles as an alternative to PDF.
Wait, why?!? When does it render? Who's supposed to have a js engine to do that? What version? How does it load dependencies? Is HTML and DOM carried along with it? So many questions.
Dependencies? Hah, no such luck. You're stuck with ES5 and Adobe's crufty JS library. There is no HTML and DOM, there are however some pretty thorough PDF document bindings.
Why - because scripting is useful. A big use of PDFs is translating paper forms into digital forms without needing to make a web app out of them. JS is used for client side validation, same reason it was put into browsers. Acrobat can handle this along with many other features that most PDF readers can't handle properly.
Basically in the PDF world, Acrobat Reader is Chrome and everything else is, like, Konqueror or something. Don't be fooled into thinking PDF is a small spec. It's not.
On the other hand, there's nothing stopping you from using a double-barrelled file extension for denoting this sort of thing, e.g. "memex-opus.pub.html"; so long as it ends with something recognizable, double-clicking should still open it in the browser across all the usual platforms, AFAIK.
(I'm fond of using "xyzzy.app.htm" myself to take advantage of this trick for distributing simple, self-contained programs that are designed run in the browser.)
The author addresses this: “We choose to switch to PDF in this decade, not because it easy, but because it is hard”
– John F. Warnock, September 12th 1962"
The author is obviously making a statements, exploring ideas... not searching for an actual solution to his use case.
Yeah, it's kinda embarrassing that the one quote that gets pulled out in the HN commentary is the one that contains a typo. It's OK: Issue 1[0] contains a patch to fix the issue.
> it's totally possible to make a self-contained HTML page without using a JS framework of the day. It's going to be way easier to consume than a PDF.
Completely agree. For instance, NASA's APOD site[1] is a good example of something that'd be nontrivial using both an offline PDF and modern lightweight alternatives like Gemini, but works really well even without fancy modern design. Under 300kB including the image (HTML's under 6 kB) before gzipping.
I do realize how ugly PDFs are to work with (I wrote my own PDF/A generator for issue 2[2]). This is a Tagged PDF though, so you can extract text using standard tools.
To understand the mindset, have a read of the Gemini FAQ[0], specifically the answer to why not use a subset of HTML - and then read Issue 2[2] which is a hybrid Gemini+PDF polyglot, for people who don't like reading PDFs, which is apparently everyone on this thread :)
Issue 1[1] also moves beyond PDF, to try addressing some of the accessibility shortcomings by (a) prepending the content as plain text, and (b) recording myself reading the whole thing out and arranging the file as a polyglot MP3 and PDF file that can be played in an audio player as well as viewed in a PDF reader as well as a text editor.
A mini-FAQ to address some points elsewhere in the thread:
* No, it's not going to replace your blog or the web in general.
* Yes, it's an experimental art project / longitudinal CTF forensics tournament / weirdo personal blog.
> The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume only that kind of content in only that kind of way. It's impossible to know in advance whether what's on the other side of a https:// URL will be within the subset or outside it. It's very tedious to verify that a website claiming to use only the subset actually does, as many of the features we want to avoid are invisible (but not harmless!) to the user
But I don't really know that your PDF website doesn't use some evil invisible PDF feature.
And I have to use a special Gemini browser to access Gemini pages. (Since an HTTPS bridge misses the point)
So why not use Dillo as my "Sane subset of HTML"? It is not hard to hand-write HTML that looks great in Lynx, Dillo, and Firefox.
> It is not hard to hand-write HTML that looks great in Lynx, Dillo, and Firefox.
Actually, it is. I love Dillo, but it's very limited. I like to make my images "fluid" using max-width and max-height attributes, and Dillo will not support those in any foreseeable future.
> would do almost nothing to create a clearly demarcated space
How do you create that demarcated space where PDF/A, PDF 2.0, and all other PDF versions can be mingled together, and there's no easy way to distinguish them?
I think the idea of PDFs opens up many new possibilities, and your work is quite an eye opener. Design is largely missing from websites - it’s the same design over and over when it comes to optimizing for clicks.
Designers would thrive in a PDF environment instead of handing their designs over to implementation as it is now.
Maybe PDF is just the beginning and maybe a similar format can be thought up that addresses some of the concerns expressed here, and move over in time.
I don't like reading PDFs and probably wouldn't read much of your website like that... but I appreciate the intervention drawing our attention to the advantages of PDFs in the disadvantaged present environment, which I think are real and worth thinking about. It seems almost like an artistic project. I'm not mad at you, and am not sure what makes some people seem to be so mad here (probably means you were succesful at something)... but I'm still not gonna read it, PDFs are a mess to read!
I've spent entirely too much time "printing" sites and articles to PDF to save them to read or reference later. Your PDF style was perfect! No need to fuss with anything just save it!
I use a terminal pager with PDFs quite frequently. It works surprisingly well. Even something you wouldn't expect, like a pay stub, renders fine in the terminal.
This is true, but I do think a PDF is just conceptually simpler and requires less technical knowledge. Especially in a situation where technical users are scarce.
IMO most people have a mental model of a PDF as being a digital document, whereas a HTML file is somewhat more amorphous.
I have done it with a couple of PHP libraries (fpdf and mpdf), but they are primitive, compared to desktop PDF generators. I know that you can use Java (never done that), or even...ugh...XSL (also never done that).
Most desktop operating systems offer a print-to-PDF functionality. It's long been an add-on for Microsoft, but that's really a historical accident / deliberate choice of that platform.
PDFs can be trivially created from Markdown or using LaTeX templates if you're looking for a programmatic solution. Pandox and XeLaTex are helpful, the poppler libraries as well. Again, these are generally and widely available at no charge.
> PDFs are universally understood by most people and can be read on phones, desktops, laptops, and eBook readers.
PDFs need a proprietary app to use, most of which are loaded with spyware & trackers. I may be mistaken in this but MacOS/iOS are the only OSes I know of that read them natively? There's absolutely nothing universal about the format.
HTML is truly universal: not only does every OS come with a built in HTML viewer, but it's a plain text file. You can read the source using anything.
> Once you’ve downloaded a local PDF version of the site, there is no risk that it can be changed or removed by the host.
Once you've downloaded a local HTML version of the page there's no risk that it can be changed or removed by the host. Yes, there's caveats to both: people can create PDFs with remote embeds or HTML sites with ajax content but both of these are the fault/responsibility of the individual author. It's as easy to make good downloadable HTML as downloadable PDF.
The so called "churn" is the responsibility of the individual HTML author. If you're making bad HTML, the fix is to start making good HTML. Not to switch to a closed inaccessible format.
PDF is an open format, with multiple FOSS reader implementations. You could argue that a subset of niche features can only be used in Acrobat Reader, but AR is far from the only PDF reader out there.
And the churn is part of the zeitgeist, not really a responsibility of anyone in particular. Individuals are suckered into it, companies are supplying it, and governments are allowing it. We're all part of it. Not new either: I'm hearing it since the 90s how the modern life is rushed, and that's just my limited experience.
I said it wasn't universal, which is somewhat different to the vague idea of being "open", and yes, PDF is technically an "open format" depending on how you define "open". The ISO 32000 spec. costs in the region of ~200 USD/EUR.
What that "openness" translates into in the real world is that there are zero non-Adobe viewers that support all of PDF's features, and even less PDF editors. The standard PDF editor costs ~200 USD/EUR (annual subscription).
This is before we even get into the nightmarish world of PDF parsing. Or PDF accessibility.
PDF is a great format if you're sending a document to someone for them to print immediately. It has no other valid uses imo.
I set up my blog so that the page source would consist of the original markdown and as little markup as possible to make that render. You can read it with telnet and the experience isn't so much worse than using a browser.
(The actual part that makes this work is a pile of opaque javascript doing all sorts of nasty things at runtime, but such is the way of web pages in today's browsers, I don't worry too much about it).
Using xelatex, I got only the text, no pushbutton. Using pdflatex, I got a pushbutton, but it was not a hyperlink, just an image. What engine do you use to get this to work?
In a sea of cynicism, I gotta say.. bravo. This genuinely put a smile on my face. It has a lot of problems, sure, but it's a creative use of the Web and would surely work for some use cases. It's certainly no worse than using Flash ever was.
It reminds me a bit of a "newsletter" I'm subscribed to called, ironically, "Not a Newsletter" (http://notanewsletter.com/). You get an email from the author each month and it just points to a Google Doc where he puts the actual content. Why's this good? The content can't set off any spam filters, he can edit the issue after it's "sent" if there are mistakes or broken links..
The content can be censored arbitrarily by google, and when you click on mobile web with the docs app installed, it logs your logged in google account identity (maybe for work?) with the view when it switches to the app.
If the author was concerned about getting censored by Google or feeding their data empire, they could set up a self-hosted Google Docs-like, like NextCloud.
The readers would still need to trust the author's not doing anything nefarious with their IP addresses, but I guess there's a degree of implicit trust when subscribing to a newsletter.
I would just put it on my own server. Are people really worried about clicking a private link and having their IP address logged? Just opening an email with a tracking pixel triggers that already, and you have to assume clicking a link will log your IP whether with Google or Constant Contact or any other mass email provider.
Google Docs are still files. It's just up to the author (or even the readers) to keep copies outside of Google's servers. Unless Lab6 owns their own servers, whoever is hosting these pdfs can delete them as well. At least, in both cases, static files are much easier to backup and copy than entire three-tier dynamic applications. And readers can keep their own copies separate from the original, which isn't possible with an application at all.
Yup. Another way to say it is Google will release a file format the day offline computing drops dead. It should probably amount to an antitrust case or at least a major class action claim at this point. That said, even with PDF specs it's freakin impossible to read/write that format in an intelligible way, if the person creating the document used even the barest amount of block alignment. Adobe started with an innovative notion about layout, but ended up making content extremely hard to parse, and actually tried to open source the engine. Google started with an idea of trapping everyone's data in a format they'd never make fully available, and then charging for the privilege of storing it.
I don't agree with author's choices (yes, I'm disciplined enough not to add irrelevant elements to my content), but it's really sad that things got to the point where someone actually suggests PDF as an alternative to the web.
I just opened your website on mobile and it's very user friendly, I got to scroll in many directions to read the content.
We build our own website with gatsby and only use js if it's really needed (when you click interactive links, we're still trying to improve a bit. We customized Gatsby because doesn't support this out of the box) that gets 100 score on mobile on Google page speed: https://marxcommunications.com/
I just ran your PDF through an accessibility checker and it failed magnificently. For this reason alone, suggesting people make more use of PDFs instead of well-formatted HTML is a total non-starter for me (and should be for everyone).
Heck, even PDFs produced by Word (or comparable FOSS editors) are so much better (except if you've done it incorrectly by "printing" it) than this particular one.
424 comments
[ 5.1 ms ] story [ 333 ms ] threadI would get a much better experience with html.
PDF is not a web format and you’re wasting effort trying to shoehorn print content and a print format for display on the web. Just use HTML and don’t update it, it’s probably easier.
That's the Internet of knowledge I'd love to see: things organized in EPUB's, searchable and downloadable.
Featured is a quote from LWN indicting the "software industry" and its "brittle dependencies". What's ironic about this? It's squarely about the parts of the software industry that deal in things that are _not_ meant to be painted in the browser.
If you want a solution to the (perceived) churn, it's funnily enough right in the quote from Mark Pilgrim: "I've migrated to HTML 4". HTML is almost certainly not going to end up drifting in such a way that DJB's qhasm bibliography page[1] is ever going to break. HTML and the Web standards in general are, with extremely rare exceptions, cumulative. It's pretty frightening how many technical people don't understand this; the Web is intentionally engineered to serve as "the infrastructure for handling humanity's publishing needs indefinitely"[2]. More frightening is that the biggest threat to this are people like the author here who treat the Web as if it's like any other thing that the computing industry puts out—i.e., already perennially broken. This is dangerous because it anachronistically cedes power to folks who'd try to argue at some point in the future that the things about the Web that they'd like to break (and might be in a position to break e.g. due to browser monopoly) are justified and no big deal, really.
The author goes on to call out the Web ("of rubbish") as "user-hostile". Shortly afterward, he or she writes that "PDF makes a stand against the churn". More accurately, PDF makes a stand against the user, by prioritizing authors' creative whims over the reader's needs. This happens again later in their remarks about PDFs being page-oriented: "you are fundamentally not in control of the reading experience." The "you" here is not you, the actual reader. The control they refer to is, once again, the author's.
You get other poor arguments—that PDFs are "offlineable" "files" that can be distributed "decentralized", none of which are accurate criticisms against what HTML lacks—unless those Java documentation zipballs that seemingly every university student enrolled in a CS program in the early 2000s was made to download are a collective hallucination.
And it gets worse from there. Cute stunt to grab attention and all, but the arguments are fundamentally bankrupt.
1. http://cr.yp.to/qhasm/literature.html
2. https://news.ycombinator.com/item?id=27368632
It would display perfectly if mobile browsers didn't have broken defaults (to work around broken websites) that you need to disable using <meta name="viewport" content="width=device-width, initial-scale=1">.
Most churn comes in two flavors:
* analytics and spyware
* convenience code for insecure developers
Same as someone else, to read on mobile I have to download and open a pdf so i just cancelled the download and ignored the link
On top of that the end result is not very readable on mobile, the font is too small.
> On top of that the end result is not very readable on mobile, the font is too small.
Agreed on both counts. Was only commenting about browsers saving PDFs.
PDF is not a comfortable format for reading on a screen. Nor a comfortable format to extract text or data from.
It’s like my Pi who just does one thing really well, and allows me to tinker on every level if I so choose.
If I ask a designer to design a website, he has to send it of for implementation, or is confined by html breakpoint/accessibility options.
PDF can go straight from designer to document and do everything in a program like designer, indesign and so on.
It’s a designer first paradigm.
I certainly get the argument, but using something like hugo or gatsby or jekyll when you want to avoid the "churn" also seems like a perfectly valid solution.
With HTML, I have to trust that some random entity does what they state in their privacy policy, and they regularly don't. Sure, I can disable JS, but then 95% of the web doesn't work anymore.
Other than that PDF is quite clearly a less accessible format.
I often use Tor, although I'm pretty sure that even then, a good analytics lib can see it's me based on scroll behaviour, mouse movement, time of day, and of course what I browse.
But yeah, you make a good point.
You might not be a unique fingerprint, but at best you are part of a group of somewhere between 3 and 1000 similar users.
Not to be a downer, but when I webscraped I learned that big corporations can spend money to fingerprint you.
(It looks like at least some PDF readers have provided support for automatically displaying external images, for example)
Pretty sure a PDF opened in the browser can't run any JS, but not completely sure. So you're right: I don't really know it for a fact. Poor choice of words.
JavaScript is allowed, but not in PDF/A, which is what I use.
The PDF 2.0 spec is damnably not public.
If you only allow PDF, then 99.9999% of the web doesn't work anymore.
I'm all for getting sites to be static, but PDF doesn't fix that because the problem has never been the technology used to build the site.
Or a plug-in to Wordpress so you can keep the GUI/dynamic for the less technical employees:
* https://wordpress.org/plugins/simply-static/
Of course, pdfs aren't necessarily static, either, but that is why Lab6 is choosing to use pdf/a, an actually static format intended specifically for long-term archiving of immutable files. This way you can sign the file and guarantee it stays the same forever and everyone's copy is identical.
I'm kind of surprised at the response to this. The author seems well aware of how terrible pdf is as a format and this isn't some treatise of why we should want to use it. It's an unfortunate compromise that, given the requirements they're aiming to meet, of generating a file that supports rich formatting and hyperlink embedding, but which can guarantee immutability and long-term archiving directly in the spec, pdf/a is all there is, so in spite of being a terrible format with a lot of shortcomings, it's what they're using.
But just like you can choose to use PDF/A, you can also choose to have a completely static and self-contained (e.g. using data URLs for images) HTML page.
Nobody is requiring you to use PDF/A. No mainline browser (that I'm aware of) requires it.
So what is being solved? When I click on a PDF on the web, I don't know if it's using PDF/A, I don't know if it's embedding or linking its fonts. So it's the same situation, nothing has changed.
Telling people to use PDF/A when most clients do not enforce it and when there's no indication to users before they click on a link whether or not the link is following the spec -- it is exactly the same as telling them to use a subset of HTML; the author is doing the same thing they complain about.
You can't just say that PDF/A exists. That's not enough, how will you get people to restrict themselves to that format when 99% of their users will never notice the difference and no client is enforcing it?
It's not ideal, but in a non-ideal world where the big boys have ruined the web, I tip my hat to this effort with a large dose of empathy.
Cheers,
Most browsers have Print to PDF. If you want people to be able to download an immutable version of your content, then just have a simple static version of your page with a valid print css, better yet, leave everything default.
If you want to fight churn with PDF, just have a simple HTML website with a link to download a versioned PDF of your issue. Your website can be as simple as https://motherfuckingwebsite.com/ or https://bettermotherfuckingwebsite.com.
I think evangelistic energy should probably be directed at complaining to organizations that share content through JS-framework monstrosities. Getting rank-and-file web-devs excited about lean websites doesn't hurt, but clients and CTOs have real decision making power.
There are tons of pdf viewers to choose from, so if you don't like an App, there are more available.
I like that mine remembers the last opened doc and page. I can copy text from pdf too.
Although this isn't a comparison of ebook to pdf, it's html to pdf.
https://filingdb.com/b/pdf-text-extraction
OTOH it's totally possible to make a self-contained HTML page without using a JS framework of the day. It's going to be way easier to consume than a PDF.
I'm basically in agreement, but the author has a good point that PDF is obviously self-contained and self-contained HTML pages are not necessarily distinguishable from those that aren't. Perhaps we might have to revisit MHTML or embrace Web bundles as an alternative to PDF.
Note that PDFs can contain JS too.
That's why he says to use PDF/A, which can't contain JS.
Wait, why?!? When does it render? Who's supposed to have a js engine to do that? What version? How does it load dependencies? Is HTML and DOM carried along with it? So many questions.
Who? The PDF viewer.
When? Since about 2000 in PDF format version 1.3.
Dependencies? Hah, no such luck. You're stuck with ES5 and Adobe's crufty JS library. There is no HTML and DOM, there are however some pretty thorough PDF document bindings.
Basically in the PDF world, Acrobat Reader is Chrome and everything else is, like, Konqueror or something. Don't be fooled into thinking PDF is a small spec. It's not.
On the other hand, there's nothing stopping you from using a double-barrelled file extension for denoting this sort of thing, e.g. "memex-opus.pub.html"; so long as it ends with something recognizable, double-clicking should still open it in the browser across all the usual platforms, AFAIK.
(I'm fond of using "xyzzy.app.htm" myself to take advantage of this trick for distributing simple, self-contained programs that are designed run in the browser.)
The author is obviously making a statements, exploring ideas... not searching for an actual solution to his use case.
The actual quote was from JFK iirc regarding the Apollo missions...
[0] https://www.lab6.com/1
> “But it’s just as easy to write self-contained HTML pages!”
> Sure, but if you’re going to hide CTF forensics challenges in your publication, a coverdisk allows you to do it in style!
I think it's not meant to be taken extremely seriously
Completely agree. For instance, NASA's APOD site[1] is a good example of something that'd be nontrivial using both an offline PDF and modern lightweight alternatives like Gemini, but works really well even without fancy modern design. Under 300kB including the image (HTML's under 6 kB) before gzipping.
[1] https://apod.nasa.gov/apod/astropix.html
I do realize how ugly PDFs are to work with (I wrote my own PDF/A generator for issue 2[2]). This is a Tagged PDF though, so you can extract text using standard tools.
To understand the mindset, have a read of the Gemini FAQ[0], specifically the answer to why not use a subset of HTML - and then read Issue 2[2] which is a hybrid Gemini+PDF polyglot, for people who don't like reading PDFs, which is apparently everyone on this thread :)
Issue 1[1] also moves beyond PDF, to try addressing some of the accessibility shortcomings by (a) prepending the content as plain text, and (b) recording myself reading the whole thing out and arranging the file as a polyglot MP3 and PDF file that can be played in an audio player as well as viewed in a PDF reader as well as a text editor.
A mini-FAQ to address some points elsewhere in the thread:
* No, it's not going to replace your blog or the web in general.
* Yes, it's an experimental art project / longitudinal CTF forensics tournament / weirdo personal blog.
* Yes, I'm serious anyway.
[0] https://gemini.circumlunar.space/docs/faq.gmi
[1] https://lab6.com/1
[2] https://lab6.com/2
But I don't really know that your PDF website doesn't use some evil invisible PDF feature.
And I have to use a special Gemini browser to access Gemini pages. (Since an HTTPS bridge misses the point)
So why not use Dillo as my "Sane subset of HTML"? It is not hard to hand-write HTML that looks great in Lynx, Dillo, and Firefox.
Actually, it is. I love Dillo, but it's very limited. I like to make my images "fluid" using max-width and max-height attributes, and Dillo will not support those in any foreseeable future.
But again, I still love Dillo.
How do you create that demarcated space where PDF/A, PDF 2.0, and all other PDF versions can be mingled together, and there's no easy way to distinguish them?
Designers would thrive in a PDF environment instead of handing their designs over to implementation as it is now.
Maybe PDF is just the beginning and maybe a similar format can be thought up that addresses some of the concerns expressed here, and move over in time.
- PDFs are universally understood by most people and can be read on phones, desktops, laptops, and eBook readers.
- Once you’ve downloaded a local PDF version of the site, there is no risk that it can be changed or removed by the host.
- File size is predictable ahead of time, which is useful if your connection is limited or slow.
- PDFs are designed for printing (moreso than most sites) which may be useful in situations where electricity is in low supply.
External content, like images, can be inlined, thus you would only have to distribute one single .html file.
I'm not sure how would file2file linking work in the realm of pdf files. With html files, it's easy even without any web server.
Plus, html can be even digested through a terminal interface. That cannot be said about the binary nature of pdf documents.
Typically one would view a PDF with a dedicated viewer (xpdf, zathura, kpdf, Okular, Evince, ...), or by converting to text (pdftotext).
less can be extended with hooks (lesspipe) to read a wide range of file types on the console.
Some console file managers can also translate PDFs to text (mc, ranger).
IMO most people have a mental model of a PDF as being a digital document, whereas a HTML file is somewhat more amorphous.
I have done it with a couple of PHP libraries (fpdf and mpdf), but they are primitive, compared to desktop PDF generators. I know that you can use Java (never done that), or even...ugh...XSL (also never done that).
PDFs can be trivially created from Markdown or using LaTeX templates if you're looking for a programmatic solution. Pandox and XeLaTex are helpful, the poppler libraries as well. Again, these are generally and widely available at no charge.
Truly absurd, this whole thread is churn.
PDFs need a proprietary app to use, most of which are loaded with spyware & trackers. I may be mistaken in this but MacOS/iOS are the only OSes I know of that read them natively? There's absolutely nothing universal about the format.
HTML is truly universal: not only does every OS come with a built in HTML viewer, but it's a plain text file. You can read the source using anything.
> Once you’ve downloaded a local PDF version of the site, there is no risk that it can be changed or removed by the host.
Once you've downloaded a local HTML version of the page there's no risk that it can be changed or removed by the host. Yes, there's caveats to both: people can create PDFs with remote embeds or HTML sites with ajax content but both of these are the fault/responsibility of the individual author. It's as easy to make good downloadable HTML as downloadable PDF.
The so called "churn" is the responsibility of the individual HTML author. If you're making bad HTML, the fix is to start making good HTML. Not to switch to a closed inaccessible format.
And the churn is part of the zeitgeist, not really a responsibility of anyone in particular. Individuals are suckered into it, companies are supplying it, and governments are allowing it. We're all part of it. Not new either: I'm hearing it since the 90s how the modern life is rushed, and that's just my limited experience.
What that "openness" translates into in the real world is that there are zero non-Adobe viewers that support all of PDF's features, and even less PDF editors. The standard PDF editor costs ~200 USD/EUR (annual subscription).
This is before we even get into the nightmarish world of PDF parsing. Or PDF accessibility.
PDF is a great format if you're sending a document to someone for them to print immediately. It has no other valid uses imo.
- PDFs require a reader, HTML a browser. I wouldn't argue that there are more PDF readers installed than browsers.
- Downloaded static HTML works the same
- File size can be included in the HTTP response: in the Content-Length header
- Printing is nice, but reflowable text is even nicer, since we target a multitude of rendering targets.
(The actual part that makes this work is a pile of opaque javascript doing all sorts of nasty things at runtime, but such is the way of web pages in today's browsers, I don't worry too much about it).
It reminds me a bit of a "newsletter" I'm subscribed to called, ironically, "Not a Newsletter" (http://notanewsletter.com/). You get an email from the author each month and it just points to a Google Doc where he puts the actual content. Why's this good? The content can't set off any spam filters, he can edit the issue after it's "sent" if there are mistakes or broken links..
Files have none of these problems.
The readers would still need to trust the author's not doing anything nefarious with their IP addresses, but I guess there's a degree of implicit trust when subscribing to a newsletter.
No they're not? You literally can't have a google doc as a file in a first-class way - you can export it to a file, but that's a lossy process.
We build our own website with gatsby and only use js if it's really needed (when you click interactive links, we're still trying to improve a bit. We customized Gatsby because doesn't support this out of the box) that gets 100 score on mobile on Google page speed: https://marxcommunications.com/
Proof: https://imgur.com/a/N4IJoEk
Or run it yourself: https://developers.google.com/speed/pagespeed/insights/?url=...
It's possible but takes some work.
While it's possible to royally mess up accessibility in HTML, too, the chances of getting something usable are at least somewhat better.