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 · Yesterday, 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 · Yesterday, 10:40 AM

@Kayadelenium:

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

DNSB · Yesterday, 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 · Yesterday, 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 · Today, 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 · Today, 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/

08-07-2026, 06:43 PM	#166
Kayadelenium Connoisseur Posts: 52 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/

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

Today, 05:26 AM	#172
Kayadelenium Connoisseur Posts: 52 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/

Advert

Advert