Hacker News Reader

Comment by sxp | Hacker News Reader

This is something I've always wanted for virtual textbooks. A single .html file with all the JS, CSS, images as inline data blobs, etc. For most physics, math, CS, etc books, this should be possible. It would make it trivial to download the book for offline use and share it with others. Other than the raster images, the entire content of these types of books would probably fit in a couple MB of text. The use of #anchors or other smart URL manipulation would also make it easy to share internal hyperlinks if you want to tell a friend to look at chapter/section #foo_bar of the book.

View on HN

I think you've just described an EPUB?

I thought epub files were basically zip archives of all the required files

You could make an ePub of a single HTML file with all the binary blobs embedded.

ePub, as with PDF, is a container-file format. (A ZIP file with a specified structure.)

If you want to consider that single or multiple files ... quickly veers into semantics.

An epub is indeed a zip file containing HTML, CSS, font, image, and metadata files.

I'd argue that that's not meaningfully different to OP's suggestion of a HTML file with all the content inlined, though. It's still a single file grouping everything required together and can be easily edited and read practically anywhere. It has a few advantages over the inlined-content HTML file, too:

- You can read the compressed file directly, an epub being typically half the size of the uncompressed files (going by a quick test of 30 randomly-selected files I had on hand).

- Storing the actual JPEG, PNG, OTF, etc files inside the zip is more efficient than inlining them as base64 and then making the browser decode them, in terms of both speed and filesize.

- While reading an epub, different sections can be a different HTML files, and only one needs to be loaded into memory at a time. This can be irrelevant for smaller things but it can make a big difference sometimes--with pages that include many charts and tables, documentation for graphics libraries that include images and animations for each documented function, etc.

- Epub files have native support for highlighting and bookmarking, to keep your place in long documents and share the file with your highlights attached.

Keep in mind that single integrated book formats are highly viable now.

It's in the interest of publishers not to offer them, however.

A chief example that comes to mind is the Feynman Lectures in Physics series, which are available online but only in a chapter-by-chapter basis in HTML format. (Quite beautifully formatted, FWIW.) If you want to glue those together into a single integrated whole, you'll have to do that yourself.

PDFs and ePubs afford the single-file format.

It makes sense from a DRM standpoint - PDFs and ePub are easy to crack if you offer it at all, so the only way to fix this is to go web-only and assume nobody will want to dig into turning that into a sharable PDF. Bonus points if you make it a SaaS test platform and get universities to buy into it, forcing every student to purchase the 'book' to receive grades.

The multi-page format makes access all the more inconvenient.

In practice, the question's moot as the Feynman Lectures are available via LibGen, ZLib, and similar resources.

> Bonus points if you make it a SaaS test platform and get universities to buy into it

Surely this exists already? It's good and obvious an idea to not be taken already.

Multiple times over, yes, which is what the poster was alluding to.

You're describing PDF files, but unfortunately Adobe didn't invest much time or money into making them interactive with a scripting language.

PDF has a limitation: it defines page size and the layout of everything fixed to this page, and thus can't do responsive layout like HTML can (reorganizing stuff in the page to match the screen size)

I wouldn't call that a limitation. In fact that is one of the major selling points of the PDF format. The document looks as intended* by the creator on all platforms whether display or print media.

* Yes, I know, PDF doesn't -always- do this, but a well designed PDF generally does.

It is a limitation. Anyone who's ever tried to read a PDF journal article on their phone has experienced it. (and don't even get me started on Unicode copy/paste...)

HTML can be styled in a fixed layout if desired, and reflowed by a reader mode if needed. PDF can't be styled in a responsive way, and there's no (easily accessible) reader mode equivalent for PDFs.

HTML is a far better document format than PDF.

A significant advantage of the two column journal format (although still they end up feeling pretty clunky on a phone).

> there's no (easily accessible) reader mode equivalent for PDFs.

It’s called Liquid Mode in Reader, and it is, in fact, easily accessible.

> HTML is a far better document format than PDF.

HTML is better for some things, PDF for others. That's why PDF is widely used on the web when HTML is available.

Liquid mode only works we for a subset of PDF files. And sometimes it doesn't work at all.

Reader mode only works well for a subset of HTML files, too.

Yes, of course.

True, but the rigid layout is what makes PDF unsuitable for some use cases. It’s main use is to represent a printed page of a very specific size. Anything outside that just requires too much flexibility.

Feature.

The dimensioning problem isn't PDFs. The dimensioning problem is computer displays.

Get yourself an e-ink display of 10" or 13" (standard dimensions offered by the patent-monopoly vendor across multiple OEMs), and discover that online reading of PDFs is 1) quite pleasant (so long as the underlying PDF formatting itself is sane) and 2) vastly preferable to either HTML or "fluid" ePub or Mobi file formats.

Book formats developed over about 500 years largely guided by the capabilities and limitations of human eyes and hands. Typical mass-market books range in size from roughly 6" to 12" diagonal measure. Yes, there are smaller and larger formats, these are deviations from the norm and impose compromises for other concerns (portability for smaller formats, resolution for larger ones, typically pictoral or graphical in nature).

A 5" or 6" mobile device presents less display area than an index card. Laptop displays are too short to display a portrait-mode document one page at a time, and in almost all cases too small to present a 2-page up display.

(You can verify this yourself trivially at the Internet Archive using its BookReader, e.g., https://archive.org/details/UnderstandingPhotoTypesetting/pa...)

When wedding PDFs with an appropriate display technology, the frustrations fixed-proportion PDF display disappear.

This does rely on the PDF being dimensioned for a typical book size, though there's considerable flexibility here, and any dimensions from ~6" to well over 12" will tend to be readable, there's no need for precisely matching device to document size.

I'm saying this as someone who's long railed against PDFs for documentation. My mind's been changed.

>Get yourself an e-ink display of 10" or 13" (standard dimensions offered by the patent-monopoly vendor across multiple OEMs), and discover that online reading of PDFs is 1) quite pleasant (so long as the underlying PDF formatting itself is sane) and 2) vastly preferable to either HTML or "fluid" ePub or Mobi file formats.

Notably this is not the standard size for most e-ink devices though, on which pdfs are a pain to read. Mobi/epub files, in contrast, are fantastic on my kindle (and on my phone, and on desktop).

If your argument has to boil down to "this file format is great if you just buy a specific device for viewing them, and eschew viewing them on any of the other devices you already own and use more frequently", I'd say your argument provides more evidence for the counterpoint than for the one you're arguing.

I'm happy you found a good way to consume a fundamentally outdated format, but PDFs are a bad format for the majority of use cases.

Oddly enough, my purchase decision was driven specifically by considerations of size, resolution, and suitedness to task.

Again: at 8", e-ink is pretty broadly useful. If you're frequently reading scanned-in journal articles, the 10" or 13" devices shine, though these can be accessed on smaller screens using in-page zoom-and-scroll. (Onyx BOOX has several settings for this in its NeoReader app.)

Note-taking, which was not a use I anticipated using, also happens to be really well-suited.

Yes, you can read on a smaller device if you must. However you're making the same sacrifices for mobility that are present in pocket-sized printed books, and the format is best suited to largely unformatted text (e.g., prose). Diagrams, tables, and other layout translate quite poorly, and this is intrinsic to the display itself.

The one task to which the tablet format seems best suited is precisely e-book reading. So I've ditched the "smartphone" (a pocket snoop) and settled on laptop / desktop (productivity) + tablet (ebooks), and dedicated devices for specific other applications, most especially capture (audio, images, video).

"The Case Against Tablets"

https://joindiaspora.com/posts/880e5c403edb013918e1002590d8e...

Think about how much worse PDF exploits would be if they did!

The problem with PDF's has always been the layman can't create them without some expensive Adobe program.

This is categorically false.

There have always been other tools for producing PDF (E.g. TeX) and there are also tons of free converters, print-to-PDF drivers, etc.

I have never seen anyone I would remotely describe as a layman using TeX.

macOS hasn’t had this problem in 20 years.

Yes, it's literally just Print dialogue -> Save as pdf.

Also worth noting that the PDF preview on the Mac has very nice simple editing capabilities to combine pages, delete pages, crop etc.

Any modern office suite (MS Office, Libreoffice, Google Apps) has PDF export. Many image editing applications can do it too.

> but unfortunately Adobe didn't invest much time or money into making them interactive with a scripting language.

Yes, they did. (Non-Adobe readers often don't support JS, though some do, but Adobe definitely built the support for interactivity.)

Also 3D content and a lot of other things most people probably aren't aware of, because they are peripheral to the common use cases of PDF.

Emphatically no.

HTML can be responsive, like an electronic document should.

PDF was designed to faithfully represent paper, and it has all the fluidity and customizability of a stack of printed paper. It's also completely anti-semantic: it has no document structure beside pages, and each page just describes how to put ink onto paper.

I think that the principal application area of PDF is just that: to represent paper, for printing purposes. For everything else, it's not exactly great.

> Adobe didn't invest much time or money into making them interactive with a scripting language.

yes they did. JavaScript, though I have no idea if there is a DOM or anything like it. pdf is kinda messed up in ways like that.

PDFs actually have some support for javascript! I don't know any serious use for it and some PDF viewers refuse to support it (ex: Apple's Preview app), but it does exist.

Form verification for instance, if I remember correctly.

PDF would have probably been better without it but Adobe couldn't resist adding new features so they could flog more copies of Acrobat.

Yes, maybe something like https://portable.fyi/#2021-01-02-pocket-web-books.

You can even embed images with a src converted to base64.

This method even works well with the back/forward browser buttons, something that a naive show/hide JavaScript solution wouldn’t.

Or even store the whole page as a self-extracting zip file. This page is a zip file: https://gildas-lormeau.github.io/

MHT did this 20 years ago and got all but abandoned (probably for good reasons).

Interestingly, the support for mht/multipart is still there in Chrome and Firefox; or at least it was relatively recently. However it only works for files and not when accessing an mht file over http. The format itself is relatively simple.

Yeah it's pretty much the MIME email format as a container for a webpage.

A lot of the issues "solved" in modern frameworks could have been addressed by using this, but instead things went a different path.

Web bundles is supposed to replace it, cf. https://web.dev/web-bundles/

That could easily be made into a PWA that people could save and view offline. I've been doing this with create-react-app and markdown files (muuuch bulkier solution) but it's an offline docs-like SPA people can click around with interactive examples and shareable links etc. Seems like offline availability was not a priority for other docs-making tools like docosaurus etc (last time I checked)

Please, don't make me run React to read your document, and don't make my device parse Markdown and generate HTML on each visit. This is wasteful. I and the planet should not suffer because you decided to author your book using Markdown (which is a fine format, but my browser does not understand it natively). A virtual book is best served as plain old static HTML pages. Shareable links is indeed an impressive feature, but it has been a given on the Web since 1991, I think we don't need to be impressed by it in 2021.

You can add some JS here and there for the few really interactive elements of the document but my browser already has all the features to render documents and links perfectly fine. People have been able to "click around" since 1991 and we never needed to download, parse and execute 2MB of JS for this.

Your book is probably big, and I'm probably not reading it in one go, so if it includes images and videos, downloading it all is probably unnecessary and the book is probably best split in several HTML pages. If you want to allow me to consult it offline, that's very kind and noble. Just put a zip file somewhere I can download.

Sorry for the rant, but I'm a bit fed up by having to download run megabytes of Javascript I can't control (and even read, because yay, bundles!!) to browse the web, just because.

> If you want to allow me to consult it offline, that's very kind and noble. Just put a zip file somewhere I can download.

To play devil's advocate: a majority of web traffic is on phones and tablets now, especially for long-form content where you will frequently see people request a page on a desktop, then request it two minutes later from a phone or tablet where they can read it more comfortably. 99% of mobile users will be happier when a text-heavy site is a PWA that caches itself, rather than a static HTML site that asks them to download a zip file, install an app to work with zip files on their device, unzip it to a folder of hopefully-relevantly-named HTML files, and then browse those, in the process breaking link sharing, link navigation (depending on OS), cross-device reading and referencing of highlights/notes, site search, and so on. Not to mention the limitations imposed on file:/// URIs, like browser extensions not working on them by default, which is a real problem for users relying on them for accessibility (e.g. dyslexia compensation, screen reader integration, stylesheet overrides). A lot of times that won't even be possible on a dedicated reading devices; my ereader will cache PWAs but will not download arbitrary files, if you make your site a PWA I can read it during my commute, if you make it static HTML with a zip file I can't. These are features most users appreciate a lot more than not having to load a 60k JS bundle (current size of React gzipped).

You want offline viewing?

Chrome: File > Save Page As... > Webpage, Complete

Safari: File > Safe As... > Web Archive

My god, it's just text files and images, you don't need JavaScript.

And images can be also embedded. These days you can fake a real URL completely on a fronted side.

I absolutely hate it when people do this.

What do you mean by faking a real URL on frontend side? I'm genuinely interested.

Isn't that what .epub is for?

That would be perfect for books, but I rather they take advantage of the medium and make the examples interactive: I rather see how the results change when I change the inputs than have it all in one file.

I don't see why you couldn't handle images with base64 data urls...

Reply on news.ycombinator.com