3 ms·

I don't think epub is just HTML/CSS, there's something in the way it's being processed by readers. I have tried a lot of browser extension based and standalone

I don't think epub is just HTML/CSS, there's something in the way it's being processed by readers. I have tried a lot of browser extension based and standalone readers in the past and they all render things differently with different bugs. Something doesn't add up.

capableweb 6y ago
> I don't think epub is just HTML/CSS It's XHTML to be precise, and that doesn't change no matter what processing is done by readers, it's still (just) XHTML. The format is literally described in the submission :) > they all render things differently with different bugs Just like HTML did in the beginning.
- johnchristopher 6y ago
  > > they all render things differently with different bugs > Just like HTML did in the beginning. ePub wasn't born yesterday. It's revision 3, first released ~2006/7. XHTML was proposed to correct and prevent the kind of problems html4 had because of how it organically grew, specifically relying on its XML root (no pun intended). Epub should definitely not suffer from bugs like HTML had in the pre-XHTML and pre-HTML5 era. I sometimes have bugs like: - whole book is black - some pages can't be loaded/read so I have to skip them - some toc and back link don't work like they should (probable bad markup) There's also some readers oddities: - completely inconsistent line-height - aligned setting not working at all etc. Anyway, there's a reason XHTML2 didn't happen and we got HTML5 instead. Either ePub has some extensions that are not trivial to implement or most readers are buggy. Or both.
  - richeyryan 6y ago
    I've worked on a ePub parser and renderer and the issues you're describing sound pretty familiar. The three main components of the ePub (aside from the actual pages) are the TOC, the spine and the manifest. The manifest basically tells you where everything is, the TOC is the table of contents which can link to various pages and the spine gives you the traversal order. Some mistakes I've seen are using the TOC to traverse the book. Using the spine to traverse the book but not handling hidden pages properly. Not handling two page spread properly. So yeah the spec is nuanced and it would be easy to make a reader that worked with a lot of books but then had weird issues on another set of books that aren't particularly different. We ended up writing our own parser because we kept finding issues with the main open source ones. I recall using this repo (https://github.com/IDPF/epub3-samples https://github.com/IDPF/epub3-samples) to test specific functionality to make sure it was in line with the spec.
    - johnchristopher 6y ago
      Thanks for the explanation.
jrimbault 6y ago
You can use 7z to decompress and view an epub contents. Typically : a table of content `toc.xhtml` file, some `chapterXX.xhtml` files, maybe a few css and images files. (I don't remember the archival format epub use, probably zip, but 7z will guess for you)
- frosted-flakes 6y ago
  You can also just rename it to have a .zip extension and open it in the OS file explorer.
kcartlidge 6y ago
Structurally it's a renamed ZIP file containing a pre-defined collection of XHTML, XML, NCX, OPF, and HTML/CSS content files. So it's not quite just HTML/CSS when packaged up, but it is just HTML/CSS when it comes to the actual text content. Other than getting the various constituent files zipped up, with their interrelated contents synced, the only other oddity is that the renamed ZIP must always start with an uncompressed 'mimetype' file. The IDPF maintain the standard. The easy one is v2 (http://idpf.org/epub/201 http://idpf.org/epub/201) but that is now deprecated. Unfortunately v3 allows more interactivity and scripting - and we all know how bad the tech industry is at keeping that kind of stuff secure.
- johnchristopher 6y ago
  Now that you mention it I am pretty sure v3 is not entirely backward compatible with v2. Which could explain some oddities on older e-readers or out-of-date software.

capableweb 6y ago

> I don't think epub is just HTML/CSS It's XHTML to be precise, and that doesn't change no matter what processing is done by readers, it's still (just) XHTML. The format is literally described in the submission :) > they all render things differently with different bugs Just like HTML did in the beginning.

johnchristopher 6y ago
> > they all render things differently with different bugs > Just like HTML did in the beginning. ePub wasn't born yesterday. It's revision 3, first released ~2006/7. XHTML was proposed to correct and prevent the kind of problems html4 had because of how it organically grew, specifically relying on its XML root (no pun intended). Epub should definitely not suffer from bugs like HTML had in the pre-XHTML and pre-HTML5 era. I sometimes have bugs like: - whole book is black - some pages can't be loaded/read so I have to skip them - some toc and back link don't work like they should (probable bad markup) There's also some readers oddities: - completely inconsistent line-height - aligned setting not working at all etc. Anyway, there's a reason XHTML2 didn't happen and we got HTML5 instead. Either ePub has some extensions that are not trivial to implement or most readers are buggy. Or both.
- richeyryan 6y ago
  I've worked on a ePub parser and renderer and the issues you're describing sound pretty familiar. The three main components of the ePub (aside from the actual pages) are the TOC, the spine and the manifest. The manifest basically tells you where everything is, the TOC is the table of contents which can link to various pages and the spine gives you the traversal order. Some mistakes I've seen are using the TOC to traverse the book. Using the spine to traverse the book but not handling hidden pages properly. Not handling two page spread properly. So yeah the spec is nuanced and it would be easy to make a reader that worked with a lot of books but then had weird issues on another set of books that aren't particularly different. We ended up writing our own parser because we kept finding issues with the main open source ones. I recall using this repo (https://github.com/IDPF/epub3-samples https://github.com/IDPF/epub3-samples) to test specific functionality to make sure it was in line with the spec.
  - johnchristopher 6y ago
    Thanks for the explanation.

jrimbault 6y ago

You can use 7z to decompress and view an epub contents. Typically : a table of content `toc.xhtml` file, some `chapterXX.xhtml` files, maybe a few css and images files. (I don't remember the archival format epub use, probably zip, but 7z will guess for you)

frosted-flakes 6y ago
You can also just rename it to have a .zip extension and open it in the OS file explorer.

kcartlidge 6y ago

Structurally it's a renamed ZIP file containing a pre-defined collection of XHTML, XML, NCX, OPF, and HTML/CSS content files. So it's not quite just HTML/CSS when packaged up, but it is just HTML/CSS when it comes to the actual text content. Other than getting the various constituent files zipped up, with their interrelated contents synced, the only other oddity is that the renamed ZIP must always start with an uncompressed 'mimetype' file. The IDPF maintain the standard. The easy one is v2 (http://idpf.org/epub/201 http://idpf.org/epub/201) but that is now deprecated. Unfortunately v3 allows more interactivity and scripting - and we all know how bad the tech industry is at keeping that kind of stuff secure.

johnchristopher 6y ago
Now that you mention it I am pretty sure v3 is not entirely backward compatible with v2. Which could explain some oddities on older e-readers or out-of-date software.