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 · 07-30-2026, 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 · 07-30-2026, 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 · 07-30-2026, 08:11 PM

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

DNSB · 07-31-2026, 02:00 AM

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

Kayadelenium · 07-31-2026, 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.

Kayadelenium · 07-31-2026, 08:05 AM

epubveri 0.8.6 released.

No bug reports behind this one — it is a spec item and an audit.

EPUB 3.4: image/avif and image/jxl are now Core Media Types. Both are in 3.4's core media types table (added Oct 2025 and Jan 2026), so a manifest item declaring either no longer needs a fallback, and an <img> pointing at one is no longer an error.

This ships ahead of EPUBCheck, which has an open issue for AVIF and none for JXL, so please know what that means before you compare the two: a book targeting 3.3 that uses AVIF gets a fallback error from EPUBCheck and none from epubveri. That is deliberate — it is the direction that cannot invent an error on a valid book — but it is a real difference and I would rather you hear it from me than find it. 3.4's audio additions (Opus in MP4, and the codec-bearing type for AAC LC) needed no change; they already passed.

Unknown property names are now reported (OPF-027) in four more places. Manifest item properties were always checked; these were not:

meta property= the 16 unprefixed names, plus pageBreakSource
meta property= under the media: prefix (4 names)
itemref properties= page-spread-left/right, plus the 18 rendition: overrides
link rel= the 9 defined keywords

So a typo like belongs-to-colection used to pass in silence. The lists come from EPUBCheck's own vocabularies rather than from what books happen to contain.

A prefixed name is deliberately left alone: an author-declared prefix carries a vocabulary epubveri cannot know, and an undeclared prefix is a different message (OPF-028). The deprecated link keywords stay members of their vocabulary, so they keep drawing their existing deprecation warning and do not gain a second error on top.

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

As always: if epubveri and EPUBCheck disagree on a book, both tools' output as two text files is the most useful thing you can post.

Kayadelenium · Today, 01:05 PM

epubveri 0.9.2 — six ways a book could crash the validator, and large books no longer crawl

Since 0.8.6 there have been three releases. Two of them matter to you; the third is internal only, and I'd rather say so than pad the list.

0.9.0 — a validator that could be killed by the file it was validating

This one is a confession rather than a feature. Six ways an ordinary .epub could kill the epubveri process, or make it lie:

Deeply nested XML aborted it — from a 1.1 KB file. The XML tokenizer recurses per level, so depth costs stack. On a 2 MiB worker thread (which is what an embedded/browser build actually gets) about 4,000 levels was enough.
A compressed entry could be inflated without bound — a 400 KB .epub drove 1.3 GB of memory, and then reported the book VALID. That last part is the worse half: no crash, no warning, just a wrong answer.
Deeply nested CSS aborted it in four different shapes, each from a ~1.2 KB stylesheet. (That is the six: one XML shape, one zip shape, four CSS s

In Rust a stack overflow is a hard abort, not something a calling program can catch — so if you had embedded epubveri, nothing you wrote could have defended against it. It had to be fixed here.

Will this reject your books? It shouldn't. Both limits were sized from real books rather than picked by taste: the depth limit is 256 against a deepest-real-book of 24 (median 8) across 65 real books, and the entry limit is 64 MiB against the largest single entry in those same books, 2.1 MB. If a resource ever is refused you get told — a new LIM-001 message says a resource went unchecked. It is never a silent skip, because a book with real errors reporting "clean" is the one failure you cannot notice.

Worth being straight about how these were found: not by the test corpus, and not by my shelf of real books. Both stayed completely green through all six. Both of them only ever answer "what verdict do we give a well-formed book", and none of these inputs is one. I had to sit down and write hostile files by hand.

0.9.1 — validation is now linear in the size of the manifest

The worst real book on my shelf (1,951 manifest items): [B]9.4 s -> 2.1 s[ (4.5x)
A synthetic 4,000-item package document: 42.6 s -> 0.52 s (82x — bu that is a stress test, not a book you own; the real-world figure is the one above)
Scaling is now linear — 1,000 / 2,000 / 4,000 / 8,000 items cost 0.13 / 0.26 / 0.52 / 1.02 s, i.e. double the book, double the time.

Three quadratic loops, of which one (an SVG-reference lookup that rescanned the whole manifest for every image reference, and re-normalized every path each time) was essentially all of it. If you have a large fixed-layout book or a comics/manga title with thousands of images, this is the release you want.

Zero behaviour change in that work — every finding is identical to 0.9. which is exactly what made it safe to do: the corpus output stayed byte-for-byte identical and every book on the shelf reported the same thing.

0.9.2 — internal only

Nothing user-facing. Tooling moved off Python and onto Rust, and the release pipeline lost its last scripting dependency. Listed only for completeness.

What has NOT changed

No new checks in this range, so nothing about what your books report has changed. Coverage is still 189 of 196 live epubcheck checks (~96%), and th per-message-ID matrix with every gap listed is in the repo (docs/COVERAGE.md).

Getting it

Pre-built binaries for 8 platforms (Linux x86_64/aarch64 in gnu and static musl, macOS Intel and Apple Silicon, Windows x86_64/aarch64): https://github.com/veripublica/epubveri/releases/latest

Or try it without installing anything — drag an .epub onto the browser demo, the file never leaves your machine:
https://veripublica.github.io/epubveri/

Install notes, first-run security prompts and a walkthrough of the output: https://github.com/veripublica/epubv.../docs/USAGE.md

Thanks, and a request

The bugs above I found myself, so I can't credit the thread for them. But that is not where most fixes come from: the false-positive reports in this thread remain by far the best source of real defects — the corpus and my own tests we green through every single one of them, because neither can see epubveri complaining about markup that is actually fine.

So if epubveri reports something on a book that epubcheck accepts, please do p it. And the single most useful thing you can attach is both outputs as plain text — epubcheck's and epubveri's for the same file. One such pair recentl resolved into three separate causes plus a false positive I would have had no other way of finding.

Doitsu · Today, 04:14 PM

@Kayadelenium

I noticed one more EPUB2/EPUB3 false positive:

<link href="stylesheet.css" media="all" rel="stylesheet" type="text/css"/>

epubveri:ERROR RSC-005: attribute "media" is not allowed here

EPUBCheck: no error message

07-29-2026, 06:18 AM	#138
Doitsu Grand Sorcerer Posts: 5,865 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;

07-30-2026, 03:59 PM	#140
Doitsu Grand Sorcerer Posts: 5,865 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.

Today, 01:05 PM	#145
Kayadelenium Enthusiast Posts: 42 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	epubveri 0.9.2 — six ways a book could crash the validator, and large books no longer crawl Since 0.8.6 there have been three releases. Two of them matter to you; the third is internal only, and I'd rather say so than pad the list. 0.9.0 — a validator that could be killed by the file it was validating This one is a confession rather than a feature. Six ways an ordinary .epub could kill the epubveri process, or make it lie: Deeply nested XML aborted it — from a 1.1 KB file. The XML tokenizer recurses per level, so depth costs stack. On a 2 MiB worker thread (which is what an embedded/browser build actually gets) about 4,000 levels was enough. A compressed entry could be inflated without bound — a 400 KB .epub drove 1.3 GB of memory, and then reported the book VALID. That last part is the worse half: no crash, no warning, just a wrong answer. Deeply nested CSS aborted it in four different shapes, each from a ~1.2 KB stylesheet. (That is the six: one XML shape, one zip shape, four CSS s In Rust a stack overflow is a hard abort, not something a calling program can catch — so if you had embedded epubveri, nothing you wrote could have defended against it. It had to be fixed here. Will this reject your books? It shouldn't. Both limits were sized from real books rather than picked by taste: the depth limit is 256 against a deepest-real-book of 24 (median 8) across 65 real books, and the entry limit is 64 MiB against the largest single entry in those same books, 2.1 MB. If a resource ever is refused you get told — a new LIM-001 message says a resource went unchecked. It is never a silent skip, because a book with real errors reporting "clean" is the one failure you cannot notice. Worth being straight about how these were found: not by the test corpus, and not by my shelf of real books. Both stayed completely green through all six. Both of them only ever answer "what verdict do we give a well-formed book", and none of these inputs is one. I had to sit down and write hostile files by hand. 0.9.1 — validation is now linear in the size of the manifest The worst real book on my shelf (1,951 manifest items): [B]9.4 s -> 2.1 s[ (4.5x) A synthetic 4,000-item package document: 42.6 s -> 0.52 s (82x — bu that is a stress test, not a book you own; the real-world figure is the one above) Scaling is now linear — 1,000 / 2,000 / 4,000 / 8,000 items cost 0.13 / 0.26 / 0.52 / 1.02 s, i.e. double the book, double the time. Three quadratic loops, of which one (an SVG-reference lookup that rescanned the whole manifest for every image reference, and re-normalized every path each time) was essentially all of it. If you have a large fixed-layout book or a comics/manga title with thousands of images, this is the release you want. Zero behaviour change in that work — every finding is identical to 0.9. which is exactly what made it safe to do: the corpus output stayed byte-for-byte identical and every book on the shelf reported the same thing. 0.9.2 — internal only Nothing user-facing. Tooling moved off Python and onto Rust, and the release pipeline lost its last scripting dependency. Listed only for completeness. What has NOT changed No new checks in this range, so nothing about what your books report has changed. Coverage is still 189 of 196 live epubcheck checks (~96%), and th per-message-ID matrix with every gap listed is in the repo (docs/COVERAGE.md). Getting it Pre-built binaries for 8 platforms (Linux x86_64/aarch64 in gnu and static musl, macOS Intel and Apple Silicon, Windows x86_64/aarch64): https://github.com/veripublica/epubveri/releases/latest Or try it without installing anything — drag an .epub onto the browser demo, the file never leaves your machine: https://veripublica.github.io/epubveri/ Install notes, first-run security prompts and a walkthrough of the output: https://github.com/veripublica/epubv.../docs/USAGE.md Thanks, and a request The bugs above I found myself, so I can't credit the thread for them. But that is not where most fixes come from: the false-positive reports in this thread remain by far the best source of real defects — the corpus and my own tests we green through every single one of them, because neither can see epubveri complaining about markup that is actually fine. So if epubveri reports something on a book that epubcheck accepts, please do p it. And the single most useful thing you can attach is both outputs as plain text — epubcheck's and epubveri's for the same file. One such pair recentl resolved into three separate causes plus a false positive I would have had no other way of finding.

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

07-30-2026, 02:19 PM	#139
Kayadelenium Enthusiast Posts: 42 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.

07-30-2026, 08:11 PM	#141
PeterT Grand Sorcerer Posts: 14,050 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?

07-31-2026, 02:00 AM	#142
DNSB Bibliophagist Posts: 53,512 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.

07-31-2026, 04:49 AM	#143
Kayadelenium Enthusiast Posts: 42 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.

07-31-2026, 08:05 AM	#144
Kayadelenium Enthusiast Posts: 42 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	epubveri 0.8.6 released. No bug reports behind this one — it is a spec item and an audit. EPUB 3.4: image/avif and image/jxl are now Core Media Types. Both are in 3.4's core media types table (added Oct 2025 and Jan 2026), so a manifest item declaring either no longer needs a fallback, and an <img> pointing at one is no longer an error. This ships ahead of EPUBCheck, which has an open issue for AVIF and none for JXL, so please know what that means before you compare the two: a book targeting 3.3 that uses AVIF gets a fallback error from EPUBCheck and none from epubveri. That is deliberate — it is the direction that cannot invent an error on a valid book — but it is a real difference and I would rather you hear it from me than find it. 3.4's audio additions (Opus in MP4, and the codec-bearing type for AAC LC) needed no change; they already passed. Unknown property names are now reported (OPF-027) in four more places. Manifest item properties were always checked; these were not: meta property= the 16 unprefixed names, plus pageBreakSource meta property= under the media: prefix (4 names) itemref properties= page-spread-left/right, plus the 18 rendition: overrides link rel= the 9 defined keywords So a typo like belongs-to-colection used to pass in silence. The lists come from EPUBCheck's own vocabularies rather than from what books happen to contain. A prefixed name is deliberately left alone: an author-declared prefix carries a vocabulary epubveri cannot know, and an undeclared prefix is a different message (OPF-028). The deprecated link keywords stay members of their vocabulary, so they keep drawing their existing deprecation warning and do not gain a second error on top. Download: https://github.com/veripublica/epubveri/releases/tag/v0.8.6 Binaries for Linux, macOS and Windows on x86_64 and ARM; the Linux musl builds are static. No JVM required. As always: if epubveri and EPUBCheck disagree on a book, both tools' output as two text files is the most useful thing you can post.

Today, 04:14 PM	#146
Doitsu Grand Sorcerer Posts: 5,865 Karma: 24222221 Join Date: Dec 2010 Device: Kindle PW2	@Kayadelenium I noticed one more EPUB2/EPUB3 false positive: <link href="stylesheet.css" media="all" rel="stylesheet" type="text/css"/> epubveri:ERROR RSC-005: attribute "media" is not allowed here EPUBCheck: no error message