tools VS epub3-samples

This violates the "One Tool" constraint that OP requested, but the Standard Ebooks tool chain is available on Github for anyone interested: https://github.com/standardebooks/tools

The code is GPL-3 and the templates are CC0: https://github.com/standardebooks/tools/blob/master/LICENSE....

Feel free to ask on the mailing list if you have any questions, more likely to be picked up there than in a random HN thread :)

I'll give a shoutout to some other excellent software.

The first is the "Standard Ebooks"[1] toolset, which is a suite of Python scripts to create, process, and build ebooks in all common formats. The results on the Standard Ebooks site speak for themselves. They're impeccable in every way, and far better than many big name, commercially produced efforts.

GitHub: https://github.com/standardebooks/tools

This question comes up a lot. The source to our production pipeline is GPLed and freely available,[1] but the biggest part of why we produce good work is that we have a high quality manual of style.[2] Unfortunately, that second part is very specific to English, and that’s the difficult part to replicate for other languages.

[1] https://github.com/standardebooks/tools/

[2] https://standardebooks.org/manual/

With MathML epubs can look decent. For example take a look at the sample MathML epub "A First Course In Linear Algebra" [0] (in a reader that supports MathML of course). It looks pretty good. The problem is Amazon STILL doesn't support MathML, so publishers just churn out a gross version where all the equations are images and so then it doesn't scale properly with the text and the book becomes 300+ MB because of it. And they can't be bothered to make two versions for readers like Kobo that do support MathML.

[0]: https://github.com/IDPF/epub3-samples/releases/download/2017...

For example, if you want to open epub files like https://github.com/IDPF/epub3-samples/releases/download/20170606/accessible_epub_3.epub inside Brave, you will have to install an epub reader extension then instead of downloading it will open inside Brave, if you want to change that behavior you have to disable the extension or limit the extension's domain list, or you right click and "save link as file", but unless the extension has the settings, there is no way to tell Brave to use extension or download manager depending on extensions, unless the extension gets disabled. And if you have an external epub reader, well, you can automatically open the extension when you tell Brave to do it as well.

I've worked on a ePub parse 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.

I recall using this repo (https://github.com/IDPF/epub3-samples) to test specific functionality to make sure it was in line with the spec.