epubveri 0.8.5 released.
@Doitsu — your blockquote case was real, and the audit it prompted found a second one nobody had reported. Both are EPUB 2 only; EPUB 3 is unchanged.
1. blockquote is block-level in EPUB 2. XHTML 1.1 gives it the same content model as <body>, so an inline element, a <br/> or loose text inside one is an error, and an empty one is "incomplete". Your test case now draws all five of the errors EPUBCheck draws, where it previously drew none.
2. So is <noscript>. Instead of fixing just the reported case I extracted the content model of every element in the 25 XHTML 1.1 modules EPUBCheck's EPUB 2 schema includes. Exactly three use that model: <body> (already right), <blockquote>, and <noscript> — which had the same gap and was in nobody's report. Fixed too, so this closes the class rather than the case.
3. <math> is no longer accepted in an EPUB 2 document. Out of your post sideways: in the "expected one of ..." list, ours named "math" and EPUBCheck's names "ns:svg" and no math. OPS 2.0.1 has no MathML at all, so EPUBCheck reports <math> there as RSC-005 and we were silently accepting it. If you have an EPUB 2 book carrying MathML, expect this to be loud — EPUBCheck says the same.
One leftover, so you do not have to find it: <map> takes block content plus <area> in XHTML 1.1, and ours is still the permissive HTML5 model — the only row of that table I did not match, since <map> is close to extinct in real EPUBs.
None of this was findable from my side: EPUBCheck's own corpus and a 65-book shelf are byte-identical before and after all three fixes. So — thank you, and the standing ask remains: when the two tools disagree on a book, both outputs as two text files is the most useful thing you can post.
Download:
https://github.com/veripublica/epubv...ses/tag/v0.8.5 Binaries for Linux, macOS and Windows on x86_64 and ARM; the Linux musl builds are static. No JVM required.