4 ms·

It feels like a bit of doomed a project simply bc browsers don't open EPubs. You can link a PDF and while it's a bit of a context switch, the browser will open

by geokon 3y ago

It feels like a bit of doomed a project simply bc browsers don't open EPubs. You can link a PDF and while it's a bit of a context switch, the browser will open and display it Since as described EPubs are basically HTML its kinda dumb browsers don't open them - but good luck convincing the Chrome/Mozilla bureaucrats 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 My personal interim compromise solution is embedded everything (CSS, svgs, scripts and base64 images) into an HTML file. It's similar to an EPUB. It's a bit bloated and ugly but with a bit of care it works and naturally browsers (and by extension basically every user) can open it Unfortunately a user has no way to really know "oh I can download and store this web page offline". It'd be nice to have some thing like a .htmls extension that indicates it's an HTML but it doesn't have any external resources.

zerof1l 3y ago
> 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.
- geokon 3y ago
  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
  - BlueTemplar 3y ago
    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.
  - Shorel 3y ago
    > 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.
- rchaud 3y ago
  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.
- int_19h 3y ago
  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.
leoedin 3y ago
> 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.
- crabmusket 3y ago
  > 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.
jbverschoor 3y ago
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...
- foofie 3y ago
  > 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.
  - mapreduce 3y ago
    > "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.
    - foofie 3y ago
      > 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?
eviks 3y ago
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
- geokon 3y ago
  What are you referring to?
  - eviks 3y ago
    to the format supported by this extension https://github.com/gildas-lormeau/SingleFileZ https://github.com/gildas-lormeau/SingleFileZ
    - geokon 3y ago
      Oh woah! Fascinating. Thanks for that
foofie 3y ago
> 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.
baq 3y ago
> 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 :)
jasomill 3y ago
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.
Shorel 3y ago
> 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.

by geokon 3y ago

zerof1l 3y ago

> 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.

geokon 3y ago
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
- BlueTemplar 3y ago
  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.
- Shorel 3y ago
  > 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.
rchaud 3y ago
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.
int_19h 3y ago
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.

leoedin 3y ago

> 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.

crabmusket 3y ago
> 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.

jbverschoor 3y ago

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...

foofie 3y ago
> 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.
- mapreduce 3y ago
  > "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.
  - foofie 3y ago
    > 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?

eviks 3y ago

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

geokon 3y ago
What are you referring to?
- eviks 3y ago
  to the format supported by this extension https://github.com/gildas-lormeau/SingleFileZ https://github.com/gildas-lormeau/SingleFileZ
  - geokon 3y ago
    Oh woah! Fascinating. Thanks for that

foofie 3y ago

> 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.

baq 3y ago

> 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 :)

jasomill 3y ago

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.

Shorel 3y ago

> 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.