Our great sponsors
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
zotero
Zotero is a free, easy-to-use tool to help you collect, organize, annotate, cite, and share your research sources.
-
einkbro
A small, fast web browser based on Android WebView. It's tailored for E-Ink devices but also works great on normal android devices.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Gemini sites are not terminal-only and the renderer can make it look beautiful (depending upon one's definition of beautiful). One example is Lagrange:
https://github.com/skyjake/lagrange
It depends on the Content-Disposition header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co....
There are extensions that let you intercept this header, e.g. https://addons.mozilla.org/en-GB/firefox/addon/no-pdf-downlo... which per https://github.com/MorbZ/no-pdf-download/blob/c924d657f33398... detects the content-type and if it’s PDFy replaces the content-disposition header with “inline”.
(Clicking on a link that has the download attribute set also affects things: https://developer.mozilla.org/en-US/docs/Web/API/HTMLAnchorE....)
>HTML can easily be offline-able. Base64 your images or use SVG, put your CSS in the HTML page, remove all 2-way data interaction, basically reduce HTML to the same performance as PDF and allow it to be downloaded.
I built a tool for this exact purpose[0] since the HTML specification and modern browsers have a lot of nice features for creating and reading documents compared to PDF (reflow and responsive page scaling, accessibility, easily sharable, a lot of styling options that are easy to use, ability for the user to easily modify the document or change the style, integration with existing web technologies, etc.). In general I would rather read an HTML document than the PDF document since I like to modify the styling in various ways (dark theme extensions in the browser for example) which may be hard to do with a PDF, but its more of a personal preference. Some people will prefer that the document adjusts to the screen size of the device (many HTML pages), and others will prefer the exact same or similar rendering regardless of the screen size (PDF).
Either way, kind of a fun idea making a website using just PDFs. Not the most practical choice, but fun none-the-less.
[0] https://github.com/chowderman/hyperfiler
Like the parent commenter, my actual (non-hypothetical) solution is saving to the Wayback Machine. Right now I'm probably saving things at a rate of half a dozen a day. For those who are paranoid and/or need offline availability, there's Zotero <https://www.zotero.org>. (As a side note I've mentioned it before on HN, but the Zotero build process which amounts to downloading and repacking the Firefox binaries is a truly clever way to handle the problem of producing cross-platform production that doesn't resort to using Electron; you could call it an example of an Electron application done right—in large part because it's using Gecko for XUL instead). Zotero uses Gildas's SingleFile for taking snapshots of web pages, not PDF. As it turns out, Zotero is pretty useful for stowing and tracking any PDFs that you need to file away, too, for documents that are originally produced in that format. But there's no need to (clumsily) shoehorn webpages into that paradigm.
If you do the print-to-PDF workflow outlined earlier in the thread, you'll realize it doesn't scale well, requiring too much manual intervention and discipline (including taking care to make sure it's filed correctly; hopefully you remember the ad hoc system you thought up last time you saved something), that it's destructive, and that it ultimately gives you an opaque blob. SingleFile-powered Zotero mostly solves all of this, and it does it in a way that's accessible in one or two clicks, depending on your setup. If you ever actually need a PDF, you can of course go back to your saved copy and produce a PDF on-demand, but it doesn't follow that you should archive the original source material in that format.
My only reservation is that there is no inverse to the SingleFile mangling function, AFAIK. For archival reasons, it would be nice to be able to perfectly reconstruct the original, pre-mangled resources, perhaps by storing some metadata in the file that details the exact transformations that are applied.
Long sympathetic with the Jacob Nielsen / PDF bad camp ... I've had some recent changes of heart. Not a full convert, but PDF is often superior to HTML, especially for longer-form and complex noninteractive content.
Books are an artefact whose design has evolved over the centuries to accommodate human-scale ergonomics: font size, paper and ink colour, words per line, lines per page, pages per volume, overall weight and dimensions. Standard-sized books are all larger than the largest current mobile phones, with diagonal measures of about 9--12 inches. There are smaller and larger books, but those are compromises either to portability (pocketbooks) or to large-format resolution and detail ("coffee table" books, atlases, and the like). Magazines tend to run even larger (about 13"), broadsheet newspapers larger yet. Most criticisms of PDFs are actually criticisms of the devices and displays used to read them.
Poor resolution, incorrect aspect ratios, and small display sizes (especially mobile devices) are the key problems.
Reading PDFs on a tablet, especially a larger e-ink device, is a game-changer. I now actively avoid HTML, or at least launch it in a browser designed with e-ink in mind (EInkBro: https://github.com/plateaukao/browser). Otherwise, my large (13.3") high-DPI (200+) B&W ebook reader is an excellent long-form immersive reading tool.
The key requirement of a mobile phone is that it fit in a pocket, handbag, or purse. They are too small for reading, and aren't designed for that purpose. Current devices feature screen sizes of roughly 5--7 inches (diagonal measurement). At the lower end, that's smaller than a 3x5 index card (6"), and the largest barely the size of a 4x6 card (7").
On desktops, the first display that offered what I felt was a truly comfortable two-pages-up PDF reading experience was the 27" Retina iMac. Its 5K display (itself an oddball size) suits document work well. Even not fully maximised, most books are highly readable (leaving screen space for other tasks), and at full maximisation, details really stand out especially from scans of historical editions. (Such details aren't always relevent, but often are.)
PDF also provides capabilities HTML either cannot or does not by default (and few seem to be persuaded to offer), especially pagination, formulae, and a spatially-persistent layout (if you have a spatial memory, this is very valuable).
PDFs can though often do not include internal navigation (chapters, sections, etc.), search (if full text is included), and most critically, metadata (at a minimum, author, title, date, and publisher, see the full Dublin Core metadata specification for what should be required).
PDFs can also be published directly to device sizes (or to a set of form factors encompassing typical devices), as several others note.
Some of the issues aren't entirely intrinsic, and my feeling is that wider use of PDFs for online content would lead to a proliferation of PDF annoyances to match present-day Web annoyances. In each case, the fundamental problem is that publishers rather than readers have final say over presentation. An alternative, of distributing raw minimum markup and formatting that to user specifications following a set number of templates ... might help.
It's ironic that the article here embodies a number of PDF annoyances:
- The shaded background renders quite poorly on a B&W e-ink reader (though can be eliminated with a watermark-removal setting).
- The filename provides no clues as to contents or provenance, and is likely to collide with other content.
- I'm a fan of serif fonts, not sans serif, for high-DPI reading.
- Internal and external hyperlink support is ... variable. At times utterly missing, at others, inconsistent or inconvenient.
- PDFs are not trivially directly editable, which means both authors and readers can change errors or address issues.
- Many PDFs lack internal structure, even where the document they encompass do. The number of books lacking PDF table-of-contents support is ... large.
- Metadata standards and practices are abysmal. See the Dublin Core standards.
- Naming conventions similarly. "Report", "Resume", "Project", or "0.pdf" are names which should never be used. Describe author, content, and date, as a minimum, if possible.