Possible replacement for EPUBCHECK - Page 10

Kayadelenium · 07-28-2026, 06:07 AM

epubveri 0.8.2 released

Everything in this one came from reports in this thread.

Fixed

- An attribute selector inside a grouping at-rule is no longer reported as a CSS syntax error. `@media print { a[href^="http"] { … } }` drew CSS-008: the code walking the at-rule's block treated the "[…]" of a selector as a rule body and read its contents as declarations. Doitsu reported it with a namespaced selector, but the namespace was incidental — every attribute selector in that position was affected.

- NAV-001 is no longer emitted. If you validated an EPUB 2 book carrying a navigation document and saw "the navigation document is not supported in EPUB 2", that error was ours and epubcheck does not make it. The ID is unreachable in epubcheck: its only call site needs an EPUB 2 book whose manifest item carries "properties", and only the EPUB 3 handler parses that attribute. Such a book is still reported here — through the content model, where <nav> is not part of XHTML 1.1, which is how epubcheck reports it.

- epub:type and meta@charset are now rejected in EPUB 2 documents. Both are EPUB 3 spellings; the EPUB 2 branch had been reusing the EPUB 3 attribute lists.

- An EPUB 2 package document is now checked against the EPUB 2 shapes: a <meta> needs "name" and "content" and must be empty, and "properties" is not an attribute of <item> or <itemref>. That grammar had no version switch at all, so an EPUB 2 package was being held to EPUB 3's rules.

- An EPUB 2 <body> must hold at least one block element, so a document whose every child is rejected now says so, instead of listing only the children.

- Attributes are named in full in the output. epub:type was reported as attribute "type", which on an <a> element points at an attribute that is perfectly legal there.

Added

- ADV-004 (advisory, requires --advisory): a package document that declares EPUB 2 but is written in EPUB 3. It does not detect anything the other checks miss — such a book already draws a pile of accurate findings — it names the one cause behind them, listing the EPUB 3 constructs it counted in the package document.

With thanks

- Doitsu, for the CSS report.
- DNSB, for posting epubcheck's output next to epubveri's on the same book. Four of the five fixes above are from that comparison, including the NAV-001 removal, which nothing in my own test suite could have found. Most of the difference on that book is closed as of this release; what is left is tracked as issue #65.
- JSWolf, for the version-detection suggestion behind ADV-004.

Download: https://github.com/veripublica/epubv...ses/tag/v0.8.2
Binaries for Linux, macOS and Windows on x86_64 and ARM; the Linux musl builds are static. No JVM required.

Kayadelenium · 07-28-2026, 06:52 AM

epubveri 0.8.3 released.

Six attributes XHTML 1.1 has and epubveri was wrongly rejecting in EPUB 2 documents: style@media, meta@scheme, base@target, head@profile, html@version and q@cite. <style type="text/css" media="screen"> is the one you are likely to have hit.

No report behind these — they came from diffing my EPUB 2 attribute lists against epubcheck's own XHTML 1.1 modules, which is where the two attributes in 0.8.2 should have come from too.

https://github.com/veripublica/epubv...ses/tag/v0.8.3

Doitsu · 07-29-2026, 06:18 AM

@Kayadelenium

I've found some minor issues:

EPUB2:

epubveri does not flag <html> class attributes. E.g.

<html class="calibre" xmlns="http://www.w3.org/1999/xhtml">

EPUBCheck reports:

ERROR(RSC-005): Error while parsing file: attribute "class" not allowed here; expected attribute "dir", "lang", "version" or "xml:lang"

EPUB3:

If a content document contains MathML tags, epubveri does not complain about missing mathml opf properties. E.g.

<p class="math"><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>λ</mi><mo>=</mo><mfrac><mi>v</mi><mi>f</mi></mfrac></math></p>

EPUBCheck reports:

USAGE(ACC-009): MathML should either have an "alttext" attribute or "annotation-xml" child element.
ERROR(OPF-014): The property "mathml" should be declared in the OPF file.

EPUBCheck does not like <image> alt attributes. E.g.

Code:

<body>
  <div style="height: 100vh; text-align: center; padding: 0pt; margin: 0pt;">
    <svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 600 800" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
      <image alt="cover image" width="600" height="800" xlink:href="../Images/book_cover.png"/>
    </svg>
  </div>
</body>

It reports:

USAGE(RSC-025): Informative parsing error: attribute "alt" not allowed here;

Kayadelenium · Yesterday, 02:19 PM

Thanks — all three were real, and all three are fixed in 0.8.4 (crates.io, npm, and pre-built binaries for 8 platforms on the releases page (https://github.com/veripublica/epubv...ses/tag/v0.8.4)).

1. class on <html> in EPUB 2 — now RSC-005, and wider than class. XHTML 1.1 builds html, head and title from I18n.attrib alone (dir, lang, xml:lang, plus version on html and profile on head), not from Common.attrib — so class, id, style and title are all errors on those three. Expect it to be loud: this is calibre's own output, and one book on my test shelf went from 66 findings to 127.

2. Missing mathml property — now OPF-014, and the opposite direction OPF-015. mathml was already accepted in the manifest, so it never drew OPF-027; it was simply the one item property that neither half of the used/declared check looked at. ACC-009 was already firing, so that part of your output matched.

3. alt on SVG <image> — now USAGE(RSC-025). We had an element vocabulary for SVG subtrees but no attribute vocabulary, so anything HTML-shaped inside <svg> passed silently.

One honest limitation on that last one: it's a flat vocabulary, not a per-element table, so an attribute that is real SVG used on the wrong element still passes. If you hit a case where epubcheck flags an attribute and we don't, please post it.

And a general ask: if epubveri disagrees with epubcheck, the most useful thing you can post is what DNSB did a few pages back — both tools' output for the same book, as two text files. That one comparison resolved four issues, including a false positive of ours no test fixture would have caught.

Doitsu · Yesterday, 03:59 PM

@Kayadelenium

One more EPUB2 issue:

Code:

<body>
  <blockquote id="filepos159" class="calibre_9">
    <a href="#filepos159">lorem ipsum</a>
    <br class="calibre2"/>
    <span class="italic">LOREM IPSUM</span> 
    DOLOR AMET
  </blockquote>
</body>

EPUBCheck does not like inline tags, <br /> or text in blockquotes.

ERROR(RSC-005): Error while parsing file: element "a" not allowed here; expected element "address", "blockquote", "del", "div", "dl", "h1", "h2", "h3", "h4", "h5", "h6", "hr", "ins", "noscript", "ns:svg", "ol", "p", "pre", "script", "table" or "ul" (with xmlns:ns="http://www.w3.org/2000/svg")
ERROR(RSC-005): Error while parsing file: element "blockquote" incomplete; expected element "address", "blockquote", "del", "div", "dl", "h1", "h2", "h3", "h4", "h5", "h6", "hr", "ins", "noscript", "ns:svg", "ol", "p", "pre", "script", "table" or "ul" (with xmlns:ns="http://www.w3.org/2000/svg")
ERROR(RSC-005): Error while parsing file: element "br" not allowed here; expected element "address", "blockquote", "del", "div", "dl", "h1", "h2", "h3", "h4", "h5", "h6", "hr", "ins", "noscript", "ns:svg", "ol", "p", "pre", "script", "table" or "ul" (with xmlns:ns="http://www.w3.org/2000/svg")
ERROR(RSC-005): Error while parsing file: element "span" not allowed here; expected element "address", "blockquote", "del", "div", "dl", "h1", "h2", "h3", "h4", "h5", "h6", "hr", "ins", "noscript", "ns:svg", "ol", "p", "pre", "script", "table" or "ul" (with xmlns:ns="http://www.w3.org/2000/svg")
ERROR(RSC-005): Error while parsing file: text not allowed here; expected element "address", "blockquote", "del", "div", "dl", "h1", "h2", "h3", "h4", "h5", "h6", "hr", "ins", "noscript", "ns:svg", "ol", "p", "pre", "script", "table" or "ul" (with xmlns:ns="http://www.w3.org/2000/svg")

epuveri does nof flag this.

PeterT · Yesterday, 08:11 PM

Just wondering if maybe we should have this thread retitled and moved to a more appropriate forum?

DNSB · Today, 02:00 AM

Personally, since it very relevant to ePubs, I think this is a good thread for it.

Kayadelenium · Today, 04:49 AM

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.

07-29-2026, 06:18 AM	#138
Doitsu Grand Sorcerer Posts: 5,861 Karma: 24222221 Join Date: Dec 2010 Device: Kindle PW2	@Kayadelenium I've found some minor issues: EPUB2: epubveri does not flag <html> class attributes. E.g. <html class="calibre" xmlns="http://www.w3.org/1999/xhtml"> EPUBCheck reports: ERROR(RSC-005): Error while parsing file: attribute "class" not allowed here; expected attribute "dir", "lang", "version" or "xml:lang" EPUB3: If a content document contains MathML tags, epubveri does not complain about missing mathml opf properties. E.g. <p class="math"><math xmlns="http://www.w3.org/1998/Math/MathML"><mi>λ</mi><mo>=</mo><mfrac><mi>v</mi><mi>f</mi></mfrac></math></p> EPUBCheck reports: USAGE(ACC-009): MathML should either have an "alttext" attribute or "annotation-xml" child element. ERROR(OPF-014): The property "mathml" should be declared in the OPF file. EPUBCheck does not like <image> alt attributes. E.g. Code: <body> <div style="height: 100vh; text-align: center; padding: 0pt; margin: 0pt;"> <svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 600 800" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink"> <image alt="cover image" width="600" height="800" xlink:href="../Images/book_cover.png"/> </svg> </div> </body> It reports: USAGE(RSC-025): Informative parsing error: attribute "alt" not allowed here;

Yesterday, 03:59 PM	#140
Doitsu Grand Sorcerer Posts: 5,861 Karma: 24222221 Join Date: Dec 2010 Device: Kindle PW2	@Kayadelenium One more EPUB2 issue: Code: <body> <blockquote id="filepos159" class="calibre_9"> <a href="#filepos159">lorem ipsum</a> <br class="calibre2"/> <span class="italic">LOREM IPSUM</span> DOLOR AMET </blockquote> </body> EPUBCheck does not like inline tags, <br /> or text in blockquotes. ERROR(RSC-005): Error while parsing file: element "a" not allowed here; expected element "address", "blockquote", "del", "div", "dl", "h1", "h2", "h3", "h4", "h5", "h6", "hr", "ins", "noscript", "ns:svg", "ol", "p", "pre", "script", "table" or "ul" (with xmlns:ns="http://www.w3.org/2000/svg") ERROR(RSC-005): Error while parsing file: element "blockquote" incomplete; expected element "address", "blockquote", "del", "div", "dl", "h1", "h2", "h3", "h4", "h5", "h6", "hr", "ins", "noscript", "ns:svg", "ol", "p", "pre", "script", "table" or "ul" (with xmlns:ns="http://www.w3.org/2000/svg") ERROR(RSC-005): Error while parsing file: element "br" not allowed here; expected element "address", "blockquote", "del", "div", "dl", "h1", "h2", "h3", "h4", "h5", "h6", "hr", "ins", "noscript", "ns:svg", "ol", "p", "pre", "script", "table" or "ul" (with xmlns:ns="http://www.w3.org/2000/svg") ERROR(RSC-005): Error while parsing file: element "span" not allowed here; expected element "address", "blockquote", "del", "div", "dl", "h1", "h2", "h3", "h4", "h5", "h6", "hr", "ins", "noscript", "ns:svg", "ol", "p", "pre", "script", "table" or "ul" (with xmlns:ns="http://www.w3.org/2000/svg") ERROR(RSC-005): Error while parsing file: text not allowed here; expected element "address", "blockquote", "del", "div", "dl", "h1", "h2", "h3", "h4", "h5", "h6", "hr", "ins", "noscript", "ns:svg", "ol", "p", "pre", "script", "table" or "ul" (with xmlns:ns="http://www.w3.org/2000/svg") epuveri does nof flag this.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
EPUBCheck v4.2.6	jhowell	ePub	0	06-30-2021 03:49 PM
EPUBCheck v4.2.5	jhowell	ePub	0	03-23-2021 09:45 AM
EPUBCheck v4.2.4	jhowell	ePub	3	06-24-2020 09:51 AM
EPUBCheck v4.1.1	Doitsu	ePub	2	03-18-2019 10:39 AM
Web-based epubcheck upgraded to epubcheck 1.0.5	kjk	ePub	4	02-09-2010 09:53 PM

07-28-2026, 06:07 AM	#136
Kayadelenium Enthusiast Posts: 40 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	epubveri 0.8.2 released Everything in this one came from reports in this thread. Fixed - An attribute selector inside a grouping at-rule is no longer reported as a CSS syntax error. `@media print { a[href^="http"] { … } }` drew CSS-008: the code walking the at-rule's block treated the "[…]" of a selector as a rule body and read its contents as declarations. Doitsu reported it with a namespaced selector, but the namespace was incidental — every attribute selector in that position was affected. - NAV-001 is no longer emitted. If you validated an EPUB 2 book carrying a navigation document and saw "the navigation document is not supported in EPUB 2", that error was ours and epubcheck does not make it. The ID is unreachable in epubcheck: its only call site needs an EPUB 2 book whose manifest item carries "properties", and only the EPUB 3 handler parses that attribute. Such a book is still reported here — through the content model, where <nav> is not part of XHTML 1.1, which is how epubcheck reports it. - epub:type and meta@charset are now rejected in EPUB 2 documents. Both are EPUB 3 spellings; the EPUB 2 branch had been reusing the EPUB 3 attribute lists. - An EPUB 2 package document is now checked against the EPUB 2 shapes: a <meta> needs "name" and "content" and must be empty, and "properties" is not an attribute of <item> or <itemref>. That grammar had no version switch at all, so an EPUB 2 package was being held to EPUB 3's rules. - An EPUB 2 <body> must hold at least one block element, so a document whose every child is rejected now says so, instead of listing only the children. - Attributes are named in full in the output. epub:type was reported as attribute "type", which on an <a> element points at an attribute that is perfectly legal there. Added - ADV-004 (advisory, requires --advisory): a package document that declares EPUB 2 but is written in EPUB 3. It does not detect anything the other checks miss — such a book already draws a pile of accurate findings — it names the one cause behind them, listing the EPUB 3 constructs it counted in the package document. With thanks - Doitsu, for the CSS report. - DNSB, for posting epubcheck's output next to epubveri's on the same book. Four of the five fixes above are from that comparison, including the NAV-001 removal, which nothing in my own test suite could have found. Most of the difference on that book is closed as of this release; what is left is tracked as issue #65. - JSWolf, for the version-detection suggestion behind ADV-004. Download: https://github.com/veripublica/epubv...ses/tag/v0.8.2 Binaries for Linux, macOS and Windows on x86_64 and ARM; the Linux musl builds are static. No JVM required.

07-28-2026, 06:52 AM	#137
Kayadelenium Enthusiast Posts: 40 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	epubveri 0.8.3 released. Six attributes XHTML 1.1 has and epubveri was wrongly rejecting in EPUB 2 documents: style@media, meta@scheme, base@target, head@profile, html@version and q@cite. <style type="text/css" media="screen"> is the one you are likely to have hit. No report behind these — they came from diffing my EPUB 2 attribute lists against epubcheck's own XHTML 1.1 modules, which is where the two attributes in 0.8.2 should have come from too. https://github.com/veripublica/epubv...ses/tag/v0.8.3

Yesterday, 02:19 PM	#139
Kayadelenium Enthusiast Posts: 40 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	Thanks — all three were real, and all three are fixed in 0.8.4 (crates.io, npm, and pre-built binaries for 8 platforms on the releases page (https://github.com/veripublica/epubv...ses/tag/v0.8.4)). 1. class on <html> in EPUB 2 — now RSC-005, and wider than class. XHTML 1.1 builds html, head and title from I18n.attrib alone (dir, lang, xml:lang, plus version on html and profile on head), not from Common.attrib — so class, id, style and title are all errors on those three. Expect it to be loud: this is calibre's own output, and one book on my test shelf went from 66 findings to 127. 2. Missing mathml property — now OPF-014, and the opposite direction OPF-015. mathml was already accepted in the manifest, so it never drew OPF-027; it was simply the one item property that neither half of the used/declared check looked at. ACC-009 was already firing, so that part of your output matched. 3. alt on SVG <image> — now USAGE(RSC-025). We had an element vocabulary for SVG subtrees but no attribute vocabulary, so anything HTML-shaped inside <svg> passed silently. One honest limitation on that last one: it's a flat vocabulary, not a per-element table, so an attribute that is real SVG used on the wrong element still passes. If you hit a case where epubcheck flags an attribute and we don't, please post it. And a general ask: if epubveri disagrees with epubcheck, the most useful thing you can post is what DNSB did a few pages back — both tools' output for the same book, as two text files. That one comparison resolved four issues, including a false positive of ours no test fixture would have caught.

Yesterday, 08:11 PM	#141
PeterT Grand Sorcerer Posts: 14,046 Karma: 83121446 Join Date: Nov 2007 Location: Toronto Device: Libra H2O, Libra Colour	Just wondering if maybe we should have this thread retitled and moved to a more appropriate forum?

Today, 02:00 AM	#142
DNSB Bibliophagist Posts: 53,432 Karma: 181843001 Join Date: Jul 2010 Location: Vancouver Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos	Personally, since it very relevant to ePubs, I think this is a good thread for it.

Today, 04:49 AM	#143
Kayadelenium Enthusiast Posts: 40 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	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.