3 ms·

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

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

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.