Possible replacement for EPUBCHECK - Page 6

Kayadelenium · 07-15-2026, 08:36 AM

epubveri v0.5.7 is out — two content-model reporting improvements, both straight from feedback in this thread:

- RSC-005 content-model errors now list every offending node, not just the first. So <ol>……</ol> reports each misplaced child with its own line/column, matching epubcheck's per-node output. (Thanks @Doitsu — this was your point about getting both locations.)
@JSWolf - Bare text directly in <body> is now flagged in EPUB 2 — XHTML 1.1's body is block-level only, so loose text there is a content-model error we were previously missing. (EPUB 3, where it's valid HTML5, is unchanged — that one's still waiting on epubcheck's #1671 (https://github.com/w3c/epubcheck/issues/1671).)

Binaries for all platforms: v0.5.7 release page (https://github.com/veripublica/epubv...ses/tag/v0.5.7). Keep the "epubcheck said X, epubveri said Y" reports coming — they're exactly what's driving these.

JSWolf · 07-15-2026, 08:44 AM

The thing is, don't go by the mistake/glitches that epubcheck has. Go with what's right.

If something in epubcheck doesn't flag an error and you don't want to flag it as an error until epubcheck does, flag it as a warning.

As for bare text, that should at least be a warning.

Doitsu · 07-15-2026, 09:06 AM

Quote:

Originally Posted by Kayadelenium

- RSC-005 content-model errors now list every offending node, not just the first. So <ol>……</ol> reports each misplaced child with its own line/column, matching epubcheck's per-node output.

I've just re-tested my test case with v0.5.7 and I'm still getting the generic error message for both epub2 and epub 3 books.

ERROR RSC-005: content document does not conform to the EPUB XHTML content-model schema
(The line and column numbers are correct.)

epubveri also still flags named entities such as   in epub2 books with XHTML content.

FATAL RSC-016: entity 'nbsp' was referenced, but not declared

For example:

Spoiler:

EPUBCheck does not report this error. Also the W3C validator says that the file is valid.

AFAIK, undeclared named entities are not allowed allowed in epub3 books with HTML5 content, but they're valid in epub2 books with XHTML content.

(  is often used in French ebooks.)

KevinH · 07-15-2026, 09:39 AM

Yes and those named entities are pulled in by the epub2 special doctype in its second line.

Numeric entities are always legal in epub2 and epub3.

JSWolf · 07-15-2026, 12:10 PM

I've seen books that use   for a line space.

Kayadelenium · 07-15-2026, 01:44 PM

Thanks all — a productive page. v0.5.8 is out and fixes both issues raised here.

1.   (and the other named entities) no longer throw a fatal in EPUB 2. Doitsu (#78) was right, and thanks to KevinH (#79) for pinning the mechanism: in EPUB 2 the named HTML entities are declared by the external XHTML 1.1 / OEB DTD the DOCTYPE pulls in, and my parser wasn't resolving that — so it flagged every  /é/… as an undeclared fatal RSC-016. It now accepts the full standard set when the document has a recognized EPUB 2 XHTML/OEB DOCTYPE (unknown entities still fail; EPUB 3 is unchanged). And to JSWolf's #80 —   was never affected; that's   inside a block, so it's fine either way.

2. RSC-005 now names what's wrong. Doitsu (#78), you were right that the message stayed generic. It now reads e.g. `element "p" is not allowed here [ch1.xhtml:6:1]` — one line per offending node, with line:column.

3. Bare text as a warning (JSWolf, #77): I agree, and I've been planning it as an opt-in advisory check — the default output stays faithful to epubcheck, and anyone who wants the stricter, accessibility-minded checks turns them on. Since this is really epubcheck's call (KevinH's w3c/epubcheck#1671), I've added a comment there to nudge a decision; if it lands as a warning, it becomes my default too.

Thanks again.

Doitsu · Yesterday, 12:54 AM

@Kayadelenium:

1. I've found one more epub2 discrepancy. epubveri will report:

Code:

ERROR RSC-005: the "content" attribute must have the value "text/html; charset=utf-8"

if the book contains the following metadata entry:

<meta content="application/xhtml+xml; charset=utf-8" http-equiv="Content-Type"/>

For example:

Spoiler:

See also this related EPUBCheck issue.

(EPUBCheck does not report this error.)

2. I've also found an epub3 issue where epubveri and EPUBcheck report different error messages, if the nav doc of an epub3 book is not in the spine.

epubveri will report:

ERROR RSC-011: 'OEBPS/Text/nav.xhtml' is hyperlinked but not listed in the spine [OEBPS/content.opf:2:1]

EPUBCheck will report:

ERROR(RSC-011): OEBPS/Text/nav.xhtml(20,40): Found a reference to a resource that is not a spine item

which is more helpful because it points to the following line in the nav doc.

Code:

        <a epub:type="toc" href="#toc">Table of Contents</a>

If you don't want to change the .opf file reference you should at least change line and column values so that they point to the starting <spine> tag instead of the <package> tag.

Kayadelenium · Yesterday, 04:39 AM

Thanks Doitsu — both are fixed in v0.5.9 (out now).

1. EPUB 2 content-type meta. You're right, that was a false positive. The rule
that the <meta http-equiv="Content-Type"> content must be exactly
"text/html; charset=utf-8" is an HTML5 (encoding-declaration) rule, so it only
belongs to EPUB 3. In EPUB 2 the document is XHTML 1.1 served as
application/xhtml+xml, where content="application/xhtml+xml; charset=utf-8" is
the correct form — and epubcheck doesn't flag it. It's now gated to EPUB 3 only.
(Chasing it down also turned up a duplicate copy of a related check, so that's
gone too.)

2. RSC-011 location. Also fixed — it now points at the source <a> in the nav
document (its file, line and column, and in the JSON output an element path),
instead of the OPF package tag. Matches where epubcheck points. Thanks for the
test file, that made it easy to reproduce.

Tracked as issues #21 and #22 if you want the details. Thanks again for the
careful reports.

Kayadelenium · Yesterday, 04:51 AM

Thanks for testing with the real file, Doitsu — good catch on the column.

The important part is fixed in v0.5.9: RSC-011 now points into nav.xhtml at the
link, not at the OPF package tag. On your file we report nav.xhtml:20:9 and
epubcheck reports (20,40) — same <a>, same line 20, same verdict.

The remaining column difference is just a parser convention. epubveri anchors at
the start of the element (the "<" of <a>, column 9); epubcheck anchors at the
position right after the start tag (column 40 is the "T" of "Table of
Contents" — the content, not the href). I'm keeping the element-start column,
since it's consistent with every other location epubveri reports, and any editor
jumping to line 20 lands on the link either way.

Both of your reports are tracked as #21 (the EPUB 2 content-type meta) and #22
(this one), now closed. Thanks again.

Doitsu · Yesterday, 04:55 PM

I attached a test case that illustrates several isuses that I found when checking older commercial epub3 books with epubveri. In most cases EPUBCheck produced more helpful messages.

epubveri reported:

Spoiler:

EPUBCheck reported:

Spoiler:

Code:

USAGE(OPF-086b): OEBPS/Text/Section0001.xhtml(13,26): epub:type value "sidebar" is deprecated. Consider using a bare "aside" element instead.
USAGE(OPF-086b): OEBPS/Text/Section0001.xhtml(15,23): epub:type value "note" is deprecated. Consider using a "footnote" or "endnote" property instead.
USAGE(OPF-086b): OEBPS/Text/Section0001.xhtml(17,26): epub:type value "warning" is deprecated. Consider using the "notice" property instead.
USAGE(CSS-028): OEBPS/Styles/font.css(2,3): Use of Font-face declaration.
USAGE(CSS-028): OEBPS/Styles/font.css(3,3): Use of Font-face declaration.
USAGE(CSS-028): OEBPS/Styles/font.css(4,3): Use of Font-face declaration.
INFO(CSS-007): OEBPS/Styles/font.css(5,3): Font-face reference OEBPS/Fonts/Charis-Bold.ttf" refers to non-standard font type "application/x-font-opentype".
USAGE(CSS-028): OEBPS/Styles/font.css(5,3): Use of Font-face declaration.
USAGE(CSS-028): OEBPS/Styles/font.css(9,3): Use of Font-face declaration.
USAGE(CSS-028): OEBPS/Styles/font.css(10,3): Use of Font-face declaration.
USAGE(CSS-028): OEBPS/Styles/font.css(11,3): Use of Font-face declaration.
INFO(CSS-007): OEBPS/Styles/font.css(12,3): Font-face reference OEBPS/Fonts/Charis-BoldItalic.ttf" refers to non-standard font type "application/x-font-opentype".
USAGE(CSS-028): OEBPS/Styles/font.css(12,3): Use of Font-face declaration.
USAGE(CSS-028): OEBPS/Styles/font.css(16,3): Use of Font-face declaration.
USAGE(CSS-028): OEBPS/Styles/font.css(17,3): Use of Font-face declaration.
USAGE(CSS-028): OEBPS/Styles/font.css(18,3): Use of Font-face declaration.
USAGE(CSS-028): OEBPS/Styles/font.css(19,3): Use of Font-face declaration.
USAGE(CSS-028): OEBPS/Styles/font.css(23,3): Use of Font-face declaration.
USAGE(CSS-028): OEBPS/Styles/font.css(24,3): Use of Font-face declaration.
USAGE(CSS-028): OEBPS/Styles/font.css(25,3): Use of Font-face declaration.
USAGE(CSS-028): OEBPS/Styles/font.css(26,3): Use of Font-face declaration.
USAGE(CSS-029): OEBPS/Styles/font.css(33,1): Found CSS class name "-epub-media-overlay-active" but no "media:active-class" property was declared in the package document.
USAGE(OPF-087): OEBPS/Text/nav.xhtml(14,26): epub:type value "list" is not allowed on documents of type "application/xhtml+xml".

Both epubveri and EPUbCheck didn't like the epub:type="list" attribute in the NAV TOC but gave different reasons. EPUBCheck offered alternatives for deprecated epub:type attributes.
Somehow fonts with a application/x-font-opentype MIME type triggered "font 'XXX' is a foreign resource, exempt from requiring a fallback" messages.

Kayadelenium · Yesterday, 06:32 PM

Doitsu — all six are fixed in 0.5.10. Thank you for fonts_nav_list.epub; a file built to show the difference is worth a great deal more than a description of it, and two of these turned out to be rules that were simply wrong rather than merely unhelpful.

OPF-088 + OPF-086b on the same value. You are right that these contradict each other: knowing a term is deprecated means knowing the term. The vocabulary list and the deprecated list lived in different modules and had drifted apart — 7 of the 13 deprecated terms were missing from the vocabulary. They live in one place now, and “is this a known term?” is derived from both lists rather than being a third list to keep in sync, so the contradiction can no longer be stated. sidebar and note now draw OPF-086b only.

OPF-087. This is the one worth explaining, because you caught a real bug and not a wording problem. The SSV gives list (and table, table-row, table-cell, list-item, figure, aside) an HTML usage context of “Not Allowed” — they identify escapable / skippable structure on a media overlay’s seq/par and mean nothing on an HTML element. I had read the rule as “the value restates the semantic of its host element” (ol + list, table + table, …). That agreed with EPUBCheck on every count of EPUBCheck’s own test fixture, because that fixture only ever pairs each term with its matching element — so both rules report its 7 and my corpus run scored it green. But it is not the rule: <div epub:type="list"> went entirely unreported. It is driven by the vocabulary now, whatever the host element. My message is my own wording, but it says the same thing yours does.

OPF-086b alternatives. Added. sidebar → a bare HTML aside element, note → the footnote semantic, warning → the notice semantic, plus help → tip and rearnotes → endnotes. I took them from the SSV’s appendix A, which names a replacement for 5 of its 13 deprecated terms; the other 8 say only that they are deprecated, rather than my inventing advice for them. One small difference from EPUBCheck: for note it suggests “footnote or endnote” while the spec names only footnote, and I followed the spec.

CSS-007. Your “somehow triggered” was the message failing at its only job. It said the font was “a foreign resource, exempt from requiring a fallback” — which describes the rule that does not fire (fonts never need a fallback) and buries the one that does, so it reads as a report of a non-problem. It now names what actually made it fire — the application/x-font-opentype media type, widespread and never registered — and points at the @font-face src, since a stylesheet can declare many fonts. I anchor at the url() token (font.css:5:8) rather than the src keyword (5:3); same line, slightly tighter.

CSS-029. Fixed, and it was worse than a missing line number: I was pointing at the content document, which is a file the class name does not appear in, and repeating myself once per document linking the stylesheet. It is now reported once per place the name is written, at that place — font.css:33:1, the same spot yours gives — and the message names the media:active-class property that would declare it.

CSS-028. Implemented, one usage note per @font-face.

Two more things your file led me to that you did not report:

figure drew a false OPF-088 too. Rather than fix the seven terms you happened to hit, I wrote a test asserting the “deprecated implies known” invariant across the whole table — and it immediately found an eighth case: figure was in neither list, so anyone writing <figure epub:type="figure"> got told it was not in the default vocabulary.
CSS findings inside an inline <style> reported the wrong line. Chasing the CSS-007 position turned this up: they reported the line within the extracted style text against the document’s path, so a direction property on line 7 of a content document came out as line 3, where you would find <head>. One root cause behind every CSS rule. A linked stylesheet like your font.css was never affected, which is why it did not show up in your output. Where the style text cannot be mapped back to the file exactly (a CDATA section, say) the finding now falls back to the <style> element’s own position rather than a confidently wrong line.

Worth being straight about the pattern in all of this, since it is the second time this week: my headline number — 600/607 exact-ID recall against EPUBCheck’s corpus — did not move for any of these six, and could not have. It checks that the expected message ID was reported, not that nothing extra was, so a spurious usage-level message is invisible to it; and its one OPF-087 fixture is precisely the case where the wrong rule and the right rule agree. A green corpus is not a correct rule, and real books keep finding what the corpus cannot. Which is to say your reports are landing exactly where my own testing does not reach — please keep them coming.

JSWolf · Yesterday, 08:38 PM

Speaking of fonts, could you have a message that says when a font file is not used? And the same thing with unused images.

PeterT · Yesterday, 09:39 PM

Surely it's important to consider the goals of epubverif..

Is it to find any and all errors in ePub files, or is it to be 1 for 1 replacement for EPUBCHECK?

Doitsu · Today, 02:40 AM

@Kayadelenium For completeness' sake I created an epub2 test case with an Adobe pagemap and several deprecated elements.

epubveri:

Spoiler:

EPUBCheck:

Spoiler:

Code:

WARNING(PKG-010): pagelist-deprecated_elements.epub(-1,-1): The file name "OEBPS/Images/book cover.png" contains spaces, which may create interoperability issues with older reading systems.
ERROR(RSC-005):OEBPS/content.opf(20,40): Error while parsing file: attribute "page-map" not allowed here; expected attribute "id"
USAGE(OPF-062):OEBPS/content.opf(20,40): Found Adobe page-map attribute on spine element in opf file.
ERROR(RSC-005):OEBPS/toc.ncx(29,42): Error while parsing file: element "pageList" missing required attribute "class"
ERROR(RSC-005):OEBPS/toc.ncx(16,45): Error while parsing file: identical playOrder values for navPoint/navTarget/pageTarget that do not refer to same target
ERROR(RSC-005):OEBPS/toc.ncx(22,45): Error while parsing file: identical playOrder values for navPoint/navTarget/pageTarget that do not refer to same target
ERROR(RSC-005):OEBPS/toc.ncx(33,66): Error while parsing file: identical playOrder values for navPoint/navTarget/pageTarget that do not refer to same target
ERROR(RSC-005):OEBPS/toc.ncx(39,66): Error while parsing file: identical playOrder values for navPoint/navTarget/pageTarget that do not refer to same target
ERROR(RSC-005):OEBPS/chapter1.xhtml(22,11): Error while parsing file: element "center" not allowed anywhere; expected the element end-tag or 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):OEBPS/chapter1.xhtml(22,62): Error while parsing file: element "font" not allowed anywhere; expected text or element "a", "abbr", "acronym", "applet", "b", "bdo", "big", "br", "cite", "code", "del", "dfn", "em", "i", "iframe", "img", "ins", "kbd", "map", "noscript", "ns:svg", "object", "q", "samp", "script", "small", "span", "strong", "sub", "sup", "tt" or "var" (with xmlns:ns="http://www.w3.org/2000/svg")
ERROR(RSC-005):OEBPS/chapter1.xhtml(22,111): Error while parsing file: element "s" not allowed anywhere; expected text or element "a", "abbr", "acronym", "applet", "b", "bdo", "big", "br", "cite", "code", "del", "dfn", "em", "i", "iframe", "img", "ins", "kbd", "map", "noscript", "ns:svg", "object", "q", "samp", "script", "small", "span", "strong", "sub", "sup", "tt" or "var" (with xmlns:ns="http://www.w3.org/2000/svg")
ERROR(RSC-005):OEBPS/chapter1.xhtml(22,142): Error while parsing file: element "strike" not allowed anywhere; expected text or element "a", "abbr", "acronym", "applet", "b", "bdo", "big", "br", "cite", "code", "del", "dfn", "em", "i", "iframe", "img", "ins", "kbd", "map", "noscript", "ns:svg", "object", "q", "samp", "script", "small", "span", "strong", "sub", "sup", "tt" or "var" (with xmlns:ns="http://www.w3.org/2000/svg")
ERROR(RSC-005):OEBPS/chapter1.xhtml(22,182): Error while parsing file: element "u" not allowed anywhere; expected text or element "a", "abbr", "acronym", "applet", "b", "bdo", "big", "br", "cite", "code", "del", "dfn", "em", "i", "iframe", "img", "ins", "kbd", "map", "noscript", "ns:svg", "object", "q", "samp", "script", "small", "span", "strong", "sub", "sup", "tt" or "var" (with xmlns:ns="http://www.w3.org/2000/svg")
ERROR(RSC-005):OEBPS/chapter1.xhtml(22,206): Error while parsing file: element "u" not allowed anywhere; expected text or element "a", "abbr", "acronym", "applet", "b", "bdo", "big", "br", "cite", "code", "del", "dfn", "em", "i", "iframe", "img", "ins", "kbd", "map", "noscript", "ns:svg", "object", "q", "samp", "script", "small", "span", "strong", "sub", "sup", "tt" or "var" (with xmlns:ns="http://www.w3.org/2000/svg")

IMHO, epubveri should not flag <big> in epub2 XHTML content, but it should flag other deprecated elements such as .

I'm not sure about this epubveri message:

ERROR OPF-096: non-linear content 'OEBPS/cover.xhtml' is not reachable from the reading order [OEBPS/content.opf:2:1]

It was triggered by an NCX TOC entry that referred to a document with a linear="no" spine attribute. IIRC, the epub 2.0.1 specs were less picky about non-linear elements.

epubveri missed identical playOrder values in the .ncx file. AFAIK, these attributes are optional, but if they're present, they must be unique.

BTW, I'm 99.99% sure that the following EPUBCheck message is a bug, because EPUBCheck never requested particular class attributes:
ERROR(RSC-005):OEBPS/toc.ncx(29,42): Error while parsing file: element "pageList" missing required attribute "class".

Kayadelenium · Today, 04:46 AM

v0.5.11 is out, with three of Doitsu’s four and JSWolf’s request.

Doitsu (#89) — OPF-096 on EPUB 2. You were right to be unsure; it was a bug. Reachability is an EPUB 3 requirement, EPUB 2.0.1 has no such rule. Three things agreed once I looked: every OPF-096 fixture in EPUBCheck’s corpus sits under epub3/, EPUBCheck says nothing about your book, and the note in my own source cited EPUBCheck’s EPUB 3 checker as where I’d read the rule off. Gated now. Same class as #21 and #9 — I clearly have a habit of applying EPUB 3 rules to everything, which is why this came with a test and not just a gate.

playOrder. Also right. All four elements now reported, at the lines EPUBCheck gives. One wrinkle worth spelling out, since it stops this being a plain duplicate scan: elements pointing at the same target may legitimately share a playOrder — one position, two routes. So it’s only a collision when they disagree about where they go, and then every one is named. Handing someone one line of a collision leaves them hunting for its partner.

Adobe page-map. OPF-062 added. The RSC-005 was already there, but the two say different things: one that the document is invalid, the other which non-standard extension is in use — the part that tells an author whether they meant it.

<big>, and /<s>/<strike>/ — not fixed, and I’d rather say why than quietly leave it. You’re right on both counts, but they’re one bug and it isn’t a list I can patch. I have no EPUB 2 content model at all: the schema check runs the EPUB 3 (XHTML5) grammar against every content document. That single fact produces your whole table — big is valid XHTML 1.1 but removed in HTML5, so I invent an error; s and u are invalid in XHTML 1.1 but valid in HTML5, so I stay quiet. center agreeing with you is luck: invalid in both.

I could special-case those five and your file would go green today. I won’t, and the reason is last week’s OPF-087: that rule was written to match a fixture rather than the rule, agreed with EPUBCheck on every count of that fixture, scored green on my corpus, and was still wrong. Doing it knowingly, in the same week, isn’t a trade worth making. Filed as #24 with the real scope — an XHTML 1.1

OPS 2.0.1 grammar. Your test file is in the issue as the case to beat, and EPUBCheck’s messages turned out to be a gift: the “expected element …” lists it prints are the content model, spelled out. Better oracle than me guessing from the spec.

The pageList class message. Agreed, looks like an EPUBCheck bug — the NCX DTD has no required class there, and I don’t report it. Worth filing upstream; you’d get a better hearing than me.

JSWolf (#87) — unused fonts and images. Done: OPF-097, usage level, so the book stays valid and you just get told which files nothing uses. Fonts, images, any manifest resource.

“Unused” is narrower than it sounds, deliberately: a hyperlink doesn’t count as using something — only loading it does, an image drawn, a stylesheet applied, a font loaded. Exempt is whatever the reading system itself consumes: spine documents, the nav, the NCX. One case to expect: a cover-image with no cover page gets reported, because the package document names it but nothing draws it. EPUBCheck does the same. The message says “no content document references it” rather than “unused” for that reason — it’s a fact, not advice; deleting anything is your call.

Not me being clever, incidentally — OPF-097 is EPUBCheck’s own message, it just wasn’t implemented here. Which is a good lead-in to PeterT.

PeterT (#88) — “any and all errors, or a 1 for 1 replacement for EPUBCHECK?”

Neither, in a specific way.

EPUBCheck is the authority. It decides what an EPUB error is. If I flag something it passes, I’m not being more thorough, I’m being wrong — and I’m the one explaining it to whoever’s book just got rejected. So on verdicts (valid or not, which ID, what severity) I aim to match it exactly, and every disagreement so far has been my bug, not theirs. Four in two weeks, all found by people in this thread.

Where I intend to be better is detail, because it costs nothing and takes nothing away: exact line and column where EPUBCheck gives a file, a machine-resolvable element path in the JSON, a message that names the offending element. Same verdict, more usable. Plus speed and no JVM, which is the actual reason this exists.

Beyond EPUBCheck’s verdict, it’ll be opt-in and never default. JSWolf’s “don’t go by EPUBCheck’s glitches, go with what’s right” is the real tension and I don’t think it fully resolves — but it points one way more than the other. Leading EPUBCheck by being more permissive is safe: nobody’s book breaks. Leading it by being more strict means inventing errors it hasn’t decided on, and looking wrong when it does. So: default tracks EPUBCheck, stricter-if-you-ask sits on top.

One illustration, since this release is a good one. My headline number is 98.8% exact-ID recall against EPUBCheck’s corpus, and nothing in this release moved it, or could have — two of these are usage-level, and that metric only checks the expected ID was reported, not that nothing extra was. OPF-097 doesn’t even have a scenario there. Fourth time in a week that real books found something the corpus structurally cannot see. So part of the answer to “what are the goals” is: not the number. It tracks parity on the cases someone already thought to write down. This thread has been finding the rest, and that’s been worth more.

Binaries: v0.5.11 release page. Keep them coming.

07-15-2026, 08:36 AM	#76
Kayadelenium Member Posts: 21 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	epubveri v0.5.7 is out — two content-model reporting improvements, both straight from feedback in this thread: - RSC-005 content-model errors now list every offending node, not just the first. So <ol><p>…</p><p>…</p></ol> reports each misplaced child with its own line/column, matching epubcheck's per-node output. (Thanks @Doitsu — this was your point about getting both <p> locations.) @JSWolf - Bare text directly in <body> is now flagged in EPUB 2 — XHTML 1.1's body is block-level only, so loose text there is a content-model error we were previously missing. (EPUB 3, where it's valid HTML5, is unchanged — that one's still waiting on epubcheck's #1671 (https://github.com/w3c/epubcheck/issues/1671).) Binaries for all platforms: v0.5.7 release page (https://github.com/veripublica/epubv...ses/tag/v0.5.7). Keep the "epubcheck said X, epubveri said Y" reports coming — they're exactly what's driving these.

07-15-2026, 01:44 PM	#81
Kayadelenium Member Posts: 21 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	Thanks all — a productive page. v0.5.8 is out and fixes both issues raised here. 1.   (and the other named entities) no longer throw a fatal in EPUB 2. Doitsu (#78) was right, and thanks to KevinH (#79) for pinning the mechanism: in EPUB 2 the named HTML entities are declared by the external XHTML 1.1 / OEB DTD the DOCTYPE pulls in, and my parser wasn't resolving that — so it flagged every  /é/… as an undeclared fatal RSC-016. It now accepts the full standard set when the document has a recognized EPUB 2 XHTML/OEB DOCTYPE (unknown entities still fail; EPUB 3 is unchanged). And to JSWolf's #80 — <p> </p> was never affected; that's   inside a block, so it's fine either way. 2. RSC-005 now names what's wrong. Doitsu (#78), you were right that the message stayed generic. It now reads e.g. `element "p" is not allowed here [ch1.xhtml:6:1]` — one line per offending node, with line:column. 3. Bare text as a warning (JSWolf, #77): I agree, and I've been planning it as an opt-in advisory check — the default output stays faithful to epubcheck, and anyone who wants the stricter, accessibility-minded checks turns them on. Since this is really epubcheck's call (KevinH's w3c/epubcheck#1671), I've added a comment there to nudge a decision; if it lands as a warning, it becomes my default too. Thanks again.

Today, 04:46 AM	#90
Kayadelenium Member Posts: 21 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	v0.5.11 is out, with three of Doitsu’s four and JSWolf’s request. Doitsu (#89) — OPF-096 on EPUB 2. You were right to be unsure; it was a bug. Reachability is an EPUB 3 requirement, EPUB 2.0.1 has no such rule. Three things agreed once I looked: every OPF-096 fixture in EPUBCheck’s corpus sits under epub3/, EPUBCheck says nothing about your book, and the note in my own source cited EPUBCheck’s EPUB 3 checker as where I’d read the rule off. Gated now. Same class as #21 and #9 — I clearly have a habit of applying EPUB 3 rules to everything, which is why this came with a test and not just a gate. playOrder. Also right. All four elements now reported, at the lines EPUBCheck gives. One wrinkle worth spelling out, since it stops this being a plain duplicate scan: elements pointing at the same target may legitimately share a playOrder — one position, two routes. So it’s only a collision when they disagree about where they go, and then every one is named. Handing someone one line of a collision leaves them hunting for its partner. Adobe page-map. OPF-062 added. The RSC-005 was already there, but the two say different things: one that the document is invalid, the other which non-standard extension is in use — the part that tells an author whether they meant it. <big>, and <font>/<s>/<strike>/<u> — not fixed, and I’d rather say why than quietly leave it. You’re right on both counts, but they’re one bug and it isn’t a list I can patch. I have no EPUB 2 content model at all: the schema check runs the EPUB 3 (XHTML5) grammar against every content document. That single fact produces your whole table — big is valid XHTML 1.1 but removed in HTML5, so I invent an error; s and u are invalid in XHTML 1.1 but valid in HTML5, so I stay quiet. center agreeing with you is luck: invalid in both. I could special-case those five and your file would go green today. I won’t, and the reason is last week’s OPF-087: that rule was written to match a fixture rather than the rule, agreed with EPUBCheck on every count of that fixture, scored green on my corpus, and was still wrong. Doing it knowingly, in the same week, isn’t a trade worth making. Filed as #24 with the real scope — an XHTML 1.1 OPS 2.0.1 grammar. Your test file is in the issue as the case to beat, and EPUBCheck’s messages turned out to be a gift: the “expected element …” lists it prints are the content model, spelled out. Better oracle than me guessing from the spec. The pageList class message. Agreed, looks like an EPUBCheck bug — the NCX DTD has no required class there, and I don’t report it. Worth filing upstream; you’d get a better hearing than me. JSWolf (#87) — unused fonts and images. Done: OPF-097, usage level, so the book stays valid and you just get told which files nothing uses. Fonts, images, any manifest resource. “Unused” is narrower than it sounds, deliberately: a hyperlink doesn’t count as using something — only loading it does, an image drawn, a stylesheet applied, a font loaded. Exempt is whatever the reading system itself consumes: spine documents, the nav, the NCX. One case to expect: a cover-image with no cover page gets reported, because the package document names it but nothing draws it. EPUBCheck does the same. The message says “no content document references it” rather than “unused” for that reason — it’s a fact, not advice; deleting anything is your call. Not me being clever, incidentally — OPF-097 is EPUBCheck’s own message, it just wasn’t implemented here. Which is a good lead-in to PeterT. PeterT (#88) — “any and all errors, or a 1 for 1 replacement for EPUBCHECK?” Neither, in a specific way. EPUBCheck is the authority. It decides what an EPUB error is. If I flag something it passes, I’m not being more thorough, I’m being wrong — and I’m the one explaining it to whoever’s book just got rejected. So on verdicts (valid or not, which ID, what severity) I aim to match it exactly, and every disagreement so far has been my bug, not theirs. Four in two weeks, all found by people in this thread. Where I intend to be better is detail, because it costs nothing and takes nothing away: exact line and column where EPUBCheck gives a file, a machine-resolvable element path in the JSON, a message that names the offending element. Same verdict, more usable. Plus speed and no JVM, which is the actual reason this exists. Beyond EPUBCheck’s verdict, it’ll be opt-in and never default. JSWolf’s “don’t go by EPUBCheck’s glitches, go with what’s right” is the real tension and I don’t think it fully resolves — but it points one way more than the other. Leading EPUBCheck by being more permissive is safe: nobody’s book breaks. Leading it by being more strict means inventing errors it hasn’t decided on, and looking wrong when it does. So: default tracks EPUBCheck, stricter-if-you-ask sits on top. One illustration, since this release is a good one. My headline number is 98.8% exact-ID recall against EPUBCheck’s corpus, and nothing in this release moved it, or could have — two of these are usage-level, and that metric only checks the expected ID was reported, not that nothing extra was. OPF-097 doesn’t even have a scenario there. Fourth time in a week that real books found something the corpus structurally cannot see. So part of the answer to “what are the goals” is: not the number. It tracks parity on the cases someone already thought to write down. This thread has been finding the rest, and that’s been worth more. Binaries: v0.5.11 release page. Keep them coming.

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-15-2026, 08:44 AM	#77
JSWolf Resident Curmudgeon Posts: 84,174 Karma: 153715495 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	The thing is, don't go by the mistake/glitches that epubcheck has. Go with what's right. If something in epubcheck doesn't flag an error and you don't want to flag it as an error until epubcheck does, flag it as a warning. As for bare text, that should at least be a warning.

07-15-2026, 09:39 AM	#79
KevinH Sigil Developer Posts: 9,795 Karma: 7500000 Join Date: Nov 2009 Device: many	Yes and those named entities are pulled in by the epub2 special doctype in its second line. Numeric entities are always legal in epub2 and epub3.

07-15-2026, 12:10 PM	#80
JSWolf Resident Curmudgeon Posts: 84,174 Karma: 153715495 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	I've seen books that use <p> </p> for a line space.

Yesterday, 04:39 AM	#83
Kayadelenium Member Posts: 21 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	Thanks Doitsu — both are fixed in v0.5.9 (out now). 1. EPUB 2 content-type meta. You're right, that was a false positive. The rule that the <meta http-equiv="Content-Type"> content must be exactly "text/html; charset=utf-8" is an HTML5 (encoding-declaration) rule, so it only belongs to EPUB 3. In EPUB 2 the document is XHTML 1.1 served as application/xhtml+xml, where content="application/xhtml+xml; charset=utf-8" is the correct form — and epubcheck doesn't flag it. It's now gated to EPUB 3 only. (Chasing it down also turned up a duplicate copy of a related check, so that's gone too.) 2. RSC-011 location. Also fixed — it now points at the source <a> in the nav document (its file, line and column, and in the JSON output an element path), instead of the OPF package tag. Matches where epubcheck points. Thanks for the test file, that made it easy to reproduce. Tracked as issues #21 and #22 if you want the details. Thanks again for the careful reports.

Yesterday, 04:51 AM	#84
Kayadelenium Member Posts: 21 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	Thanks for testing with the real file, Doitsu — good catch on the column. The important part is fixed in v0.5.9: RSC-011 now points into nav.xhtml at the link, not at the OPF package tag. On your file we report nav.xhtml:20:9 and epubcheck reports (20,40) — same <a>, same line 20, same verdict. The remaining column difference is just a parser convention. epubveri anchors at the start of the element (the "<" of <a>, column 9); epubcheck anchors at the position right after the start tag (column 40 is the "T" of "Table of Contents" — the content, not the href). I'm keeping the element-start column, since it's consistent with every other location epubveri reports, and any editor jumping to line 20 lands on the link either way. Both of your reports are tracked as #21 (the EPUB 2 content-type meta) and #22 (this one), now closed. Thanks again.

Yesterday, 06:32 PM	#86
Kayadelenium Member Posts: 21 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	Doitsu — all six are fixed in 0.5.10. Thank you for fonts_nav_list.epub; a file built to show the difference is worth a great deal more than a description of it, and two of these turned out to be rules that were simply wrong rather than merely unhelpful. OPF-088 + OPF-086b on the same value. You are right that these contradict each other: knowing a term is deprecated means knowing the term. The vocabulary list and the deprecated list lived in different modules and had drifted apart — 7 of the 13 deprecated terms were missing from the vocabulary. They live in one place now, and “is this a known term?” is derived from both lists rather than being a third list to keep in sync, so the contradiction can no longer be stated. sidebar and note now draw OPF-086b only. OPF-087. This is the one worth explaining, because you caught a real bug and not a wording problem. The SSV gives list (and table, table-row, table-cell, list-item, figure, aside) an HTML usage context of “Not Allowed” — they identify escapable / skippable structure on a media overlay’s seq/par and mean nothing on an HTML element. I had read the rule as “the value restates the semantic of its host element” (ol + list, table + table, …). That agreed with EPUBCheck on every count of EPUBCheck’s own test fixture, because that fixture only ever pairs each term with its matching element — so both rules report its 7 and my corpus run scored it green. But it is not the rule: <div epub:type="list"> went entirely unreported. It is driven by the vocabulary now, whatever the host element. My message is my own wording, but it says the same thing yours does. OPF-086b alternatives. Added. sidebar → a bare HTML aside element, note → the footnote semantic, warning → the notice semantic, plus help → tip and rearnotes → endnotes. I took them from the SSV’s appendix A, which names a replacement for 5 of its 13 deprecated terms; the other 8 say only that they are deprecated, rather than my inventing advice for them. One small difference from EPUBCheck: for note it suggests “footnote or endnote” while the spec names only footnote, and I followed the spec. CSS-007. Your “somehow triggered” was the message failing at its only job. It said the font was “a foreign resource, exempt from requiring a fallback” — which describes the rule that does not fire (fonts never need a fallback) and buries the one that does, so it reads as a report of a non-problem. It now names what actually made it fire — the application/x-font-opentype media type, widespread and never registered — and points at the @font-face src, since a stylesheet can declare many fonts. I anchor at the url() token (font.css:5:8) rather than the src keyword (5:3); same line, slightly tighter. CSS-029. Fixed, and it was worse than a missing line number: I was pointing at the content document, which is a file the class name does not appear in, and repeating myself once per document linking the stylesheet. It is now reported once per place the name is written, at that place — font.css:33:1, the same spot yours gives — and the message names the media:active-class property that would declare it. CSS-028. Implemented, one usage note per @font-face. Two more things your file led me to that you did not report: figure drew a false OPF-088 too. Rather than fix the seven terms you happened to hit, I wrote a test asserting the “deprecated implies known” invariant across the whole table — and it immediately found an eighth case: figure was in neither list, so anyone writing <figure epub:type="figure"> got told it was not in the default vocabulary. CSS findings inside an inline <style> reported the wrong line. Chasing the CSS-007 position turned this up: they reported the line within the extracted style text against the document’s path, so a direction property on line 7 of a content document came out as line 3, where you would find <head>. One root cause behind every CSS rule. A linked stylesheet like your font.css was never affected, which is why it did not show up in your output. Where the style text cannot be mapped back to the file exactly (a CDATA section, say) the finding now falls back to the <style> element’s own position rather than a confidently wrong line. Worth being straight about the pattern in all of this, since it is the second time this week: my headline number — 600/607 exact-ID recall against EPUBCheck’s corpus — did not move for any of these six, and could not have. It checks that the expected message ID was reported, not that nothing extra was, so a spurious usage-level message is invisible to it; and its one OPF-087 fixture is precisely the case where the wrong rule and the right rule agree. A green corpus is not a correct rule, and real books keep finding what the corpus cannot. Which is to say your reports are landing exactly where my own testing does not reach — please keep them coming.

Yesterday, 08:38 PM	#87
JSWolf Resident Curmudgeon Posts: 84,174 Karma: 153715495 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	Speaking of fonts, could you have a message that says when a font file is not used? And the same thing with unused images.

Yesterday, 09:39 PM	#88
PeterT Grand Sorcerer Posts: 14,035 Karma: 83121446 Join Date: Nov 2007 Location: Toronto Device: Libra H2O, Libra Colour	Surely it's important to consider the goals of epubverif.. Is it to find any and all errors in ePub files, or is it to be 1 for 1 replacement for EPUBCHECK?

Advert

Advert