Possible replacement for EPUBCHECK - Page 12

Kayadelenium · 08-07-2026, 06:43 PM

epubveri 0.9.12

JSWolf — thank you for the two logs. The column number you mentioned was the smallest thing in them; the interesting part was the error count.

Your file: 21 fatals from both tools, then 96 errors from me against EPUBCheck's 127. That gap splits cleanly:

27 of them are inside the 21 documents that do not parse at all. EPUBCheck reads with a streaming parser, so it validates the <html> start tag on line 2 long before it reaches the unclosed <body> at the end of the file. I build a document tree, and a file that fails to parse gives me no tree to check. That is a real difference and not one I can close cheaply, so I am recording it rather than claiming otherwise.
4 were role on <img> — and that turned out to be five elements, not one. img, area, iframe, param and script were all quietly taking the EPUB 3 attribute set in an EPUB 2 book, so they escaped every EPUB 2 tightening of the last week. Rather than fix the one you found, I walked the grammar from the EPUB 2 root and listed everything that pulled in the wrong set; a test now asserts that nothing can, so the next one fails at build time instead of arriving as a forum post.

Chasing your report also made me sharpen the comparison I run against EPUBCheck over a shelf of real books: it compared which messages each tool reports, never how many. Your file is precisely the case that hides in — the message IDs agreed while the totals differed by 31.

With counting turned on, one book showed 7 errors from me against 79 from EPUBCheck. Two causes, both mine:

alt is required on <img> in XHTML 1.1 and optional in HTML5 — one of the few places EPUB 2 is the stricter version. I had it optional in both.
More seriously, a missing required attribute stopped me checking the rest of that file. One <img> without alt silenced everything after it. That book has 72 of them; EPUBCheck reports 73, I was reporting 2.

That book now matches EPUBCheck exactly, 82 to 82. Ten books on the shelf gained findings, all still at or below EPUBCheck's count, and six of them now match it exactly.

One thing I could use from you: lines 94 and 217 of that style.css, if you still have it. Two CSS differences are left and I cannot reproduce either from the log alone — one of them may well be EPUBCheck being stricter than the CSS specification rather than me being wrong, and I would rather know than guess.

Downloads (8 platforms): https://github.com/veripublica/epubveri/releases
Try it in the browser: https://veripublica.github.io/epubveri/

JSWolf · 08-08-2026, 09:53 AM

Quote:

Originally Posted by Kayadelenium

One thing I could use from you: lines 94 and 217 of that style.css, if you still have it. Two CSS differences are left and I cannot reproduce either from the log alone — one of them may well be EPUBCheck being stricter than the CSS specification rather than me being wrong, and I would rather know than guess.

Downloads (8 platforms): https://github.com/veripublica/epubveri/releases
Try it in the browser: https://veripublica.github.io/epubveri/

I don't have the ePub as it was when I ran the error checks. However, I do remember the errors in the CSS. One line had ; instead of : and the other ended in ;; instead of ;.

Doitsu · 08-08-2026, 10:40 AM

@Kayadelenium:

epubveri reports 3 errors for this very old IDPF epub3 sample book, however EPUBCheck reports only one USAGE message.

DNSB · 08-08-2026, 09:06 PM

If it's any help, here's the result of running epubcheck and epubveri on a scrambled copy of an ePub. ePubcheck came with 69 error lines while epubveri came up with 430. I also attached the scrambled ePub.

Basically, the ebook is a conversion from an azw3 file using calibre's conversion pipeline which produced an ePub2 file. Going by the contents of the ePub, the original that Amazon published from was an ePub3.

DNSB · 08-08-2026, 09:11 PM

Having nothing better to do while the hockey game I was watching was in an intermission, I directly edited the content.opf in the ePub to version ="3.0". I've attached the results of epubcheck and epubveri from running on that file.

Doitsu · 08-09-2026, 04:16 AM

Quote:

Originally Posted by DNSB

If it's any help, here's the result of running epubcheck and epubveri on a scrambled copy of an ePub. ePubcheck came with 69 error lines while epubveri came up with 430. I also attached the scrambled ePub.

This is actually a limit of the JSON mode of EPUBCheck. For some odd reason the EPUBCheck devs limited the number of identical messages per file to 25.

If you're curious is defined via MAX_LOCATIONS in: \src\main\java\com\adobe\epubcheck\reporting\Check Message.java

Somebody has already complained about it: output an all errors to XML document file #1489 but nothing has happend so far...

In text mode EPUBCheck reports 3433 errors.

Kayadelenium · 08-09-2026, 05:26 AM

epubveri 0.9.13

Doitsu — thank you, that is the answer and I would not have found it. I had just measured EPUBCheck 5.3.0 at 3432 errors on that file against DNSB's 69, and was about to ask which version produced the 69. Wrong question.

The fingerprint is worth knowing: DNSB's output was 25 section + 25 epub:type + 15 id + 2 + 1. Two counts landing on exactly 25 is MAX_LOCATIONS, and the lines that would print "there are N additional locations" are commented out, so nothing warns you. So there was never a 69-vs-430 gap — the real comparison is 3432 to 428, and I am the quiet one.

DNSB — your follow-up diagnosed your own file. Changing the version attribute to 3.0 collapses it: 429 errors to 6 for me, 3432 to 10 for EPUBCheck. The book is EPUB 3 wearing an EPUB 2 label, and those hundreds of findings are the accurate consequence of one wrong character.

I have a check that says exactly that in one line, and it stayed silent on your book: it only read the package document, and yours carries no EPUB 3 signal there at all — the give-away is 374 epub:type attributes in the content documents. It reads those now. The signal is an EPUB 3 construct being used, never merely declared: of 72 EPUB 2 books in my test shelf, 8 bind the namespace and only 2 ever use it, so keying on the declaration would cry wolf on six innocent books. It reports 3 of 125, and all three really are mislabelled. Behind --advisory.

Also fixed: Doitsu's image-based sample, where a nav linking straight at a JPEG is legal if the manifest declares an XHTML fallback — EPUBCheck's condition has three clauses and I had two.

And one I found by comparing error counts rather than types: a book where EPUBrs and I reported none. All were malformed selectors inside @media blocks —outside one I caught them, inside one I never re-read the contents as rules. Declaration errors in the same blocks were reported, which is why nothing looked broken; the count was just quietly too low.

Downloads (8 platforms): https://github.com/veripublica/epubveri/releases
Try it in the browser: https://veripublica.github.io/epubveri/

Kayadelenium · 08-10-2026, 03:51 AM

epubveri 0.9.15 is out.

0.9.15 fixes two false positives, both found by me rather than reported:

Custom elements (<epub-switch>, or any element name with a hyphen) were rejected — a book using one came out INVALID. epubcheck accepts them. This is the reason to upgrade.
In the EDUPUB profile, a role="heading" without aria-level wasn't counted as a heading.

So on those two, it now reports less. It reports more in one place: a <guide> reference's #fragment is now resolved, which epubcheck has always checked and I hadn't. Plus two profile checks (EDUPUB heading ranks, index documents).

0.9.14 was the EPUB 3.4 work: rendition:layout="roll" (the new webtoon layout) is accepted, and 3.4's new restrictions sit behind --advisory until epubcheck implements them — otherwise they'd be indistinguishable from false positives if you diff the two tools.

Downloads: https://github.com/veripublica/epubveri/releases
In your browser, no install: https://veripublica.github.io/epubveri/

As always: if you hit a disagreement with epubcheck, both tools' output as plain text is by far the most useful thing to post — that's how most of these get found.

JSWolf · 08-10-2026, 07:50 AM

I've found yet another error in epubveri. I've attached the output from epubveri and epubcheck as well as the scrambled eBook. The error is an <hr> instead of <hr/>. I think epubcheck overdoes it with the errors.

Kayadelenium · 08-10-2026, 05:07 PM

@JSWolf — thanks, and thanks for attaching both outputs as text; that made this a five-minute diagnosis.

Not a bug this time, and your instinct is right. The book has one unclosed <hr> in chapter32.html (line 81), which makes that file invalid XML. Of epubcheck's 75 findings, all 75 are in that one file and 74 are the same message: its validator is stream-based, so with <hr> left open it treats every following <p> as being inside it and says "not allowed here". One defect, reported 74 times. Our single fatal is the same defect, once.

Your report did turn up something real, though: both tools pointed at line 157, where parsing finally fails — not at line 81, the only line you can actually fix. Next release:

Code:

... expected 'hr' tag, not 'body' at 157:1 (<hr> at line 81 is never closed; XHTML requires <hr/>)

Keep them coming.

Kayadelenium · 08-10-2026, 05:52 PM

epubveri 0.9.16

Three things it was rejecting that epubcheck accepts:

<template> — it wasn't in the grammar at all, so it was an error everywhere: in <head>, inside a paragraph, anywhere.
<script> and <template> inside <ul>, <ol>, <dl>, <table>, <select> — HTML5 allows them there.
A role="heading" without aria-level, in the EDUPUB profile.

So it reports less in those. It reports more in two: <epub:switch> now needs a case and a default (we had both optional), and old OEBPS 1.2 packages are handled as OEBPS 1.2 instead of being judged by EPUB 2's rules — which had it inventing about six errors on such a file.

@JSWolf — your <hr> file is in this one. When a document fails to parse, the message now names the line the element was opened on, rather than the line where parsing finally gave up.

Downloads: https://github.com/veripublica/epubveri/releases
In your browser, no install: https://veripublica.github.io/epubveri/

Doitsu · Yesterday, 12:50 PM

@Kayadelenium:

I've found one more cosmetic issue:

Source:

Code:

<body>
  <p>Lorem ipsum<p>
</body>

epubveri:

FATAL RSC-016: content document is not well-formed XML: expected 'p' tag, not 'body' at 11:1 (<p> at line 10 is never closed)

EPUBCheck:

ERROR(RSC-005): Error while parsing file: element "p" not allowed here; expected the element end-tag, text, element "a", "abbr", "area", "audio", "b", "bdi", "bdo", "br", "button", "canvas", "cite", "code", "data", "datalist", "del", "dfn", "em", "embed", "epub:switch", "i", "iframe", "img", "input", "ins", "kbd", "label", "link", "map", "mark", "meta", "meter", "ns1:math", "ns2:svg", "object", "output", "picture", "progress", "q", "ruby", "s", "samp", "script", "select", "slot", "small", "span", "strong", "sub", "sup", "template", "textarea", "time", "u", "var", "video" or "wbr" (with xmlns:ns1="http://www.w3.org/1998/Math/MathML" xmlns:ns2="http://www.w3.org/2000/svg") or an element from another namespace
FATAL(RSC-016): Fatal Error while parsing file: The element type "p" must be terminated by the matching end-tag "</p>".

Kayadelenium · Today, 04:11 AM

@Doitsu — thanks, fixed in the next release.

The wording wasn't ours: expected 'p' tag, not 'body' is the XML parser's own text, and it calls neither of them an end tag — so it reads as if a <p> belonged where <body> is, which is backwards.

Code:

before: … expected 'p' tag, not 'body' at 12:1 (<p> at line 11 is never closed) after:  … unclosed <p> at line 11; expected </p> but found </body>

The defect leads now, both tags are named as end tags, and the position isn't printed twice. Same for the OPF, the NCX and container.xml — they all shared that wording.

The RSC-005 in your epubcheck output is a different thing, and not cosmetic: epubcheck validates as it streams, so it gets a schema error out before the parse dies. We build the tree first, so a document that doesn't parse gives the fatal and nothing else. Flagging it so you're not waiting on it.

Kayadelenium · Today, 04:44 AM

epubveri 0.9.17 is out — that's the fix from the post above, nothing else.

Wording only: no book changes verdict, and no id, severity, position or count moves on any input. It turned out the same parser wording was also reaching people from the OPF, the NCX, media overlays, container.xml, encryption.xml, signatures.xml and the rendition documents, so all eight now say it the same way.

Binaries: github.com/veripublica/epubveri/releases/tag/v0.9.17
Browser demo: veripublica.github.io/epubveri

As always — if our output disagrees with epubcheck's on one of your books, both logs as plain text is the most useful thing you can send.

08-07-2026, 06:43 PM	#166
Kayadelenium Connoisseur Posts: 61 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	epubveri 0.9.12 JSWolf — thank you for the two logs. The column number you mentioned was the smallest thing in them; the interesting part was the error count. Your file: 21 fatals from both tools, then 96 errors from me against EPUBCheck's 127. That gap splits cleanly: 27 of them are inside the 21 documents that do not parse at all. EPUBCheck reads with a streaming parser, so it validates the <html> start tag on line 2 long before it reaches the unclosed <body> at the end of the file. I build a document tree, and a file that fails to parse gives me no tree to check. That is a real difference and not one I can close cheaply, so I am recording it rather than claiming otherwise. 4 were role on <img> — and that turned out to be five elements, not one. img, area, iframe, param and script were all quietly taking the EPUB 3 attribute set in an EPUB 2 book, so they escaped every EPUB 2 tightening of the last week. Rather than fix the one you found, I walked the grammar from the EPUB 2 root and listed everything that pulled in the wrong set; a test now asserts that nothing can, so the next one fails at build time instead of arriving as a forum post. Chasing your report also made me sharpen the comparison I run against EPUBCheck over a shelf of real books: it compared which messages each tool reports, never how many. Your file is precisely the case that hides in — the message IDs agreed while the totals differed by 31. With counting turned on, one book showed 7 errors from me against 79 from EPUBCheck. Two causes, both mine: alt is required on <img> in XHTML 1.1 and optional in HTML5 — one of the few places EPUB 2 is the stricter version. I had it optional in both. More seriously, a missing required attribute stopped me checking the rest of that file. One <img> without alt silenced everything after it. That book has 72 of them; EPUBCheck reports 73, I was reporting 2. That book now matches EPUBCheck exactly, 82 to 82. Ten books on the shelf gained findings, all still at or below EPUBCheck's count, and six of them now match it exactly. One thing I could use from you: lines 94 and 217 of that style.css, if you still have it. Two CSS differences are left and I cannot reproduce either from the log alone — one of them may well be EPUBCheck being stricter than the CSS specification rather than me being wrong, and I would rather know than guess. Downloads (8 platforms): https://github.com/veripublica/epubveri/releases Try it in the browser: https://veripublica.github.io/epubveri/

08-10-2026, 03:51 AM	#173
Kayadelenium Connoisseur Posts: 61 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	epubveri 0.9.15 is out. 0.9.15 fixes two false positives, both found by me rather than reported: Custom elements (<epub-switch>, or any element name with a hyphen) were rejected — a book using one came out INVALID. epubcheck accepts them. This is the reason to upgrade. In the EDUPUB profile, a role="heading" without aria-level wasn't counted as a heading. So on those two, it now reports less. It reports more in one place: a <guide> reference's #fragment is now resolved, which epubcheck has always checked and I hadn't. Plus two profile checks (EDUPUB heading ranks, index documents). 0.9.14 was the EPUB 3.4 work: rendition:layout="roll" (the new webtoon layout) is accepted, and 3.4's new restrictions sit behind --advisory until epubcheck implements them — otherwise they'd be indistinguishable from false positives if you diff the two tools. Downloads: https://github.com/veripublica/epubveri/releases In your browser, no install: https://veripublica.github.io/epubveri/ As always: if you hit a disagreement with epubcheck, both tools' output as plain text is by far the most useful thing to post — that's how most of these get found.

08-10-2026, 05:07 PM	#175
Kayadelenium Connoisseur Posts: 61 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	@JSWolf — thanks, and thanks for attaching both outputs as text; that made this a five-minute diagnosis. Not a bug this time, and your instinct is right. The book has one unclosed <hr> in chapter32.html (line 81), which makes that file invalid XML. Of epubcheck's 75 findings, all 75 are in that one file and 74 are the same message: its validator is stream-based, so with <hr> left open it treats every following <p> as being inside it and says "not allowed here". One defect, reported 74 times. Our single fatal is the same defect, once. Your report did turn up something real, though: both tools pointed at line 157, where parsing finally fails — not at line 81, the only line you can actually fix. Next release: Code: ... expected 'hr' tag, not 'body' at 157:1 (<hr> at line 81 is never closed; XHTML requires <hr/>) Keep them coming.

08-10-2026, 05:52 PM	#176
Kayadelenium Connoisseur Posts: 61 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	epubveri 0.9.16 Three things it was rejecting that epubcheck accepts: <template> — it wasn't in the grammar at all, so it was an error everywhere: in <head>, inside a paragraph, anywhere. <script> and <template> inside <ul>, <ol>, <dl>, <table>, <select> — HTML5 allows them there. A role="heading" without aria-level, in the EDUPUB profile. So it reports less in those. It reports more in two: <epub:switch> now needs a case and a default (we had both optional), and old OEBPS 1.2 packages are handled as OEBPS 1.2 instead of being judged by EPUB 2's rules — which had it inventing about six errors on such a file. @JSWolf — your <hr> file is in this one. When a document fails to parse, the message now names the line the element was opened on, rather than the line where parsing finally gave up. Downloads: https://github.com/veripublica/epubveri/releases In your browser, no install: https://veripublica.github.io/epubveri/

Yesterday, 12:50 PM	#177
Doitsu Grand Sorcerer Posts: 5,875 Karma: 24222221 Join Date: Dec 2010 Device: Kindle PW2	@Kayadelenium: I've found one more cosmetic issue: Source: Code: <body> <p>Lorem ipsum<p> </body> epubveri: FATAL RSC-016: content document is not well-formed XML: expected 'p' tag, not 'body' at 11:1 (<p> at line 10 is never closed) EPUBCheck: ERROR(RSC-005): Error while parsing file: element "p" not allowed here; expected the element end-tag, text, element "a", "abbr", "area", "audio", "b", "bdi", "bdo", "br", "button", "canvas", "cite", "code", "data", "datalist", "del", "dfn", "em", "embed", "epub:switch", "i", "iframe", "img", "input", "ins", "kbd", "label", "link", "map", "mark", "meta", "meter", "ns1:math", "ns2:svg", "object", "output", "picture", "progress", "q", "ruby", "s", "samp", "script", "select", "slot", "small", "span", "strong", "sub", "sup", "template", "textarea", "time", "u", "var", "video" or "wbr" (with xmlns:ns1="http://www.w3.org/1998/Math/MathML" xmlns:ns2="http://www.w3.org/2000/svg") or an element from another namespace FATAL(RSC-016): Fatal Error while parsing file: The element type "p" must be terminated by the matching end-tag "</p>".

08-09-2026, 05:26 AM	#172
Kayadelenium Connoisseur Posts: 61 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	epubveri 0.9.13 Doitsu — thank you, that is the answer and I would not have found it. I had just measured EPUBCheck 5.3.0 at 3432 errors on that file against DNSB's 69, and was about to ask which version produced the 69. Wrong question. The fingerprint is worth knowing: DNSB's output was 25 section + 25 epub:type + 15 id + 2 + 1. Two counts landing on exactly 25 is MAX_LOCATIONS, and the lines that would print "there are N additional locations" are commented out, so nothing warns you. So there was never a 69-vs-430 gap — the real comparison is 3432 to 428, and I am the quiet one. DNSB — your follow-up diagnosed your own file. Changing the version attribute to 3.0 collapses it: 429 errors to 6 for me, 3432 to 10 for EPUBCheck. The book is EPUB 3 wearing an EPUB 2 label, and those hundreds of findings are the accurate consequence of one wrong character. I have a check that says exactly that in one line, and it stayed silent on your book: it only read the package document, and yours carries no EPUB 3 signal there at all — the give-away is 374 epub:type attributes in the content documents. It reads those now. The signal is an EPUB 3 construct being used, never merely declared: of 72 EPUB 2 books in my test shelf, 8 bind the namespace and only 2 ever use it, so keying on the declaration would cry wolf on six innocent books. It reports 3 of 125, and all three really are mislabelled. Behind --advisory. Also fixed: Doitsu's image-based sample, where a nav linking straight at a JPEG is legal if the manifest declares an XHTML fallback — EPUBCheck's condition has three clauses and I had two. And one I found by comparing error counts rather than types: a book where EPUBrs and I reported none. All were malformed selectors inside @media blocks —outside one I caught them, inside one I never re-read the contents as rules. Declaration errors in the same blocks were reported, which is why nothing looked broken; the count was just quietly too low. Downloads (8 platforms): https://github.com/veripublica/epubveri/releases Try it in the browser: https://veripublica.github.io/epubveri/

Today, 04:11 AM	#178
Kayadelenium Connoisseur Posts: 61 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	@Doitsu — thanks, fixed in the next release. The wording wasn't ours: expected 'p' tag, not 'body' is the XML parser's own text, and it calls neither of them an end tag — so it reads as if a <p> belonged where <body> is, which is backwards. Code: before: … expected 'p' tag, not 'body' at 12:1 (<p> at line 11 is never closed) after: … unclosed <p> at line 11; expected </p> but found </body> The defect leads now, both tags are named as end tags, and the position isn't printed twice. Same for the OPF, the NCX and container.xml — they all shared that wording. The RSC-005 in your epubcheck output is a different thing, and not cosmetic: epubcheck validates as it streams, so it gets a schema error out before the parse dies. We build the tree first, so a document that doesn't parse gives the fatal and nothing else. Flagging it so you're not waiting on it.

Today, 04:44 AM	#179
Kayadelenium Connoisseur Posts: 61 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	epubveri 0.9.17 is out — that's the fix from the post above, nothing else. Wording only: no book changes verdict, and no id, severity, position or count moves on any input. It turned out the same parser wording was also reaching people from the OPF, the NCX, media overlays, container.xml, encryption.xml, signatures.xml and the rendition documents, so all eight now say it the same way. Binaries: github.com/veripublica/epubveri/releases/tag/v0.9.17 Browser demo: veripublica.github.io/epubveri As always — if our output disagrees with epubcheck's on one of your books, both logs as plain text is the most useful thing you can send.

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