Hacker News Reader

> It feels like a bit of doomed a project simply bc browsers don't open EPubs.

Not that long time ago, browsers could not open PDFs as well. Now all browsers come with PDF reader written in ASM/JS. I see nothing that prevents browsers doing the same for EPUBs. There exist browser extensions that do exactly this already. Its a matter of EPUB format gaining popularity.

I think Google is actively against offline data. It's not aligned with their business interests

My mental analogy is, you can also have offline apps on Android. You can specify this in app manifest. But internet access isn't exposed to the user as a permissions.

Like the author says, Google already injects online fonts into the EPubs they generate. Meanwhile PDF is a battle they've already lost

Indeed, and I would add that there's no reason for browser to be able to open PDFs : this sounds as yet another attempt for Google to wrestle with Microsoft over the control of the OS (by having everything happen in the browser instead).

And also probably why we still have to rely on 3rd party hacky browser extensions to be able to save web pages as a single file.

> Like the author says, Google already injects online fonts into the EPubs they generate.

I didn't notice that before, but now I will actively avoid Google generated EPUB files.

Epubs usually are not accessed/downloaded in a browser. PDFs definitely are, as they are freely shared online, whereas epubs are usually DRM'ed and not freely shared.

This already happened once with the original Edge browser (the one with its own engine). In fact, it was even the default app to open .epub files in Win8.

Unfortunately, that feature got killed when Edge became a Blink-based browser. But Edge Canary got a new implementation of that feature a few months ago, so it should land in stable eventually.

You know.. HTML used to be hyper text. Some links. Add some figures/images, tables.

But then we 'needed' magazine-like design/layout. Still, it was document based, so actually pretty good.

After that, we tried to shoehorn HTML to an application distribution platform. Current css layouts are (finally) more like traditional layout engines for applications.

The last 20 years i.m.o. was pretty much a waste of effort because there was no proper way to distribute (cross-platform) applications, well besides java...

> You know.. HTML used to be hyper text. Some links. Add some figures/images, tables.

It still is.

> But then we 'needed' magazine-like design/layout. Still, it was document based, so actually pretty good.

Styling is not handled by HTML. It's a separate concern assigned to CSS. For convenience HTML offered default styling.

> After that, we tried to shoehorn HTML to an application distribution platform.

It's not shoehorned. It's the use case: render documents. A document is a tree of ui elements. It's the same with GUI frameworks like Qt or WPF.

> "It still is."

It still is but you are missing the point of the thread. HTML still is hypertext, some links, some images, some tables. No doubt about that. But HTML is also so much more than that. The spec is a beast. Anyone who wants to implement an HTML based reader has a mammoth task in front of them. It's like "go implement a new browser" like someone said in this thread above.

> "Styling is not handled by HTML. It's a separate concern assigned to CSS."

Missing the point again. We know styling is not handled by HTML. The point of the thread was to tell how big of a task it is to create your own HTML based reader. If you want to create your reader like it or not you have to implement support for CSS too and that too is a mammoth spec.

So our only options are: A. Go implement a new browser. B. Use something like Webkit. C. Implement a small subset of the HTML and CSS specs.

> The spec is a beast. Anyone who wants to implement an HTML based reader has a mammoth task in front of them.

That's true for basically any non-trivial document rendering format. For example, take a look at the PDF spec. Even basic things like parsing the document format is a formidable task. HTML in comparison is a trivial format. The same goes for technologies like TeX or even Microsoft's own Word format, which Microsoft famously had lots of problems supporting. It is a hard problem for all formats, not just HTML.

> The point of the thread was to tell how big of a task it is to create your own HTML based reader.

You're confusing some things. A document format is one thing, but a renderer with specific capabilities is an entirely different thing. You're commenting on the document format and the styling and layout system, and now you're shifting the conversation to what it takes to implement a renderer.

Debates on document formats are entirely separate and orthogonal to debates on how to implement renderers. Renderers for the most trivial things are tremendously complex. There are a myriad of good reasons why we're seeing GUI frameworks built on top of webviews in spite of all the complains about the formats that webviews support, and in spite of the myriad low-level rendering frameworks already available.

To understand the poiny, try to think through the requirements list to implement a renderer for Markdown. It's a document format with a half dozen of features. Would you call it trivial?

> You're confusing some things. A document format is one thing, but a renderer with specific capabilities is an entirely different thing. You're commenting on the document format and the styling and layout system, and now you're shifting the conversation to what it takes to implement a renderer.

If you follow the comment you replied to the discussion was about implementing a renderer. So no, I am not shifting the conversation to implement a renderer. The conversation is about implementing a renderer. That it is incredibly difficult to do today with the modern specs is the point.

What about option D. Use a WebView. This is exactly what the author did. The point of the proposal is identify which features of a WebView can be used (and which must not) if the goal is to produce nice text layouts in multiple form factors. But the rendering of HTML and CSS, and the execution of Javascript are solved problem.

> Styling is not handled by HTML. It's a separate concern assigned to CSS. For convenience HTML offered default styling.

It in-fact was, and to some degree still is. I assure you we achieved a hell of a lot of styling before css existed, and for some time after it did but before most of us were using it (much), using features of HTML, some of which were explicitly there to support styling.

> It feels like a bit of doomed a project simply bc browsers don't open EPubs.

I guess that's why the article is actually an epub opened with a WASM epub viewer :)

> I think another discouraging aspect is HTML CSS are so huge and bloated at this point that few people can implement a "reader" for EPUB/HTML. It's basically "go implement a new browser". It makes one think a easy-to-parse markdown (like Djot) with some extra rendering bells and whistles would be a more likely long term solution

This feels like the biggest hurdle to me. The author says "Portable HTML generation principle: when possible, systems that generate portable EPUBs should output portable HTML.". I don't think this is going far enough. If the goal is for this format to be everywhere and repeatable then it needs to be standardised and easy to implement a new rendering engine. Relying on webviews doesn't feel like the way forward. The beauty of PDF is that it is incredibly reliable - a PDF from a decade ago still renders the same today as it used to.

I suspect if an effort like this is to get off the ground, the scope of the document needs to be scaled right back. The subset of XHTML allowed should be very limited. The ability to render a document that looks the same everywhere should be prioritised - fixed layout at a fixed page size first, reflowable second. It needs a standard with a comprehensive test suite of documents + render outputs.

> The ability to render a document that looks the same everywhere should be prioritised

IMO actually this is the question the whole effort hinges on.

If the goal is to replace PDF for the uses that require pixel-perfect rendering on every client just as the designer intended, then this approach is dead-on-arrival.

But if that's not the goal, then that has to be extremely well-communicated by the project, so that people who need that know they need to stick with PDF. Indeed, the project needs to explicitly say that it's not a goal, and that clients should be free to make reasonable rendering decisions within certain specified bounds.

It feels like a bit of doomed a project simply bc browsers don't open EPubs.

While browsers don't provide a convenient UI for opening EPUBs, they should have no problem rendering the chapter HTML files contained within.

In the absence of browser support, writing a server-side EPUB-to-browsable site proxy that adds chapter navigation controls and simple layout options shouldn't be too difficult.

Incorporating the necessary DRM support required to view the majority of commercial ebooks through such a proxy would very likely be legally problematic, of course.

Come to think of it, any form of publisher-approved DRM EPUB browser support sounds like it'd be about half a technical step away from DRM support for web pages in general, which is a horrifying prospect.

> It feels like a bit of doomed a project simply bc browsers don't open EPubs.

If you read the article, then you just did open an EPUB.

There is an singlefile extension that can save a page in a single self-extracting zipped html where you don't need to waste base64 anything, and can unzip to a folder and view images as is without the page

What are you referring to?

to the format supported by this extension https://github.com/gildas-lormeau/SingleFileZ

Oh woah! Fascinating. Thanks for that

> I think another discouraging aspect is HTML CSS are so huge and bloated at this point that few people can implement a "reader" for EPUB/HTML. It's basically "go implement a new browser".

I don't think that's true. In the very least, you can use a WebView and feed it regular HTML. If the whole industry uses webviews for GUIs, it's hardly a stretch to use one to render Epub docs.