Possible replacement for EPUBCHECK - Page 4

DNSB · 07-10-2026, 07:35 PM

Quote:

Originally Posted by JSWolf

It's what most command line programs do that I've used that have this sort of option(s).

How often do you use a CLI program on a case sensitive OS?

JSWolf · 07-10-2026, 07:41 PM

Quote:

Originally Posted by DNSB

How often do you use a CLI program on a case sensitive OS?

Not often at present. But I have in the past.

In this case it would be best to be -v and --version or -V and --Version.

DNSB · 07-10-2026, 08:06 PM

I checked multiple apps I use. -V is used for version (--version for the long form) and -v is used for verbose mode (--verbose for the long form). This was on both Linux and Windows platforms.

Kayadelenium · 07-11-2026, 04:47 PM

epubveri 0.5.0 is out — thank you all

Hi everyone,

epubveri 0.5.0 just shipped, and a lot of it came straight from the feedback in this thread — so first, thank you. The reports here, and the GitHub issues several of you opened, shaped this release more than anything else.

Things that came directly from here:

- USAGE messages (@Doitsu's request): epubveri now reports epubcheck's full five severity levels — fatal, error, warning, info, and usage — instead of folding them together. usage findings appear in the JSON output and are colour-coded in the browser demo.
- -v (@JSWolf): an unknown flag now gives a proper error: unexpected option '-v' (see --help) instead of the confusing "cannot read -v". Per the CLI convention, -v is verbose and -V is version — the git/cargo style @DiapDealer and @PeterT pointed to.
- Earlier reports are in too: exact line:column on findings (@KevinH, for Sigil), the OPF-096 self-link rule, and the dc:date / CSS @media false positives (@DNSB / @JSWolf).

One breaking change to know before you test: the input is now passed with -i. So epubveri book.epub becomes epubveri -i book.epub. epubveri now follows a shared CLI convention across a small tool family, so the flags carry over between them. You can pass -i more than once to validate several books at once.

Also new in 0.5.0:

- --format json — machine-readable output: one JSON object per run, each finding with its code, severity, message and line:column. The CLI, a CI job, and the in-browser build all emit the exact same shape.
- The browser demo got a refresh — download the result as JSON, a dark mode, and still no install / no upload (your file never leaves the page): https://veripublica.github.io/epubveri/

Where to get it:

- Pre-built binaries (Linux, macOS, Windows — x86_64 and ARM): https://github.com/veripublica/epubv...ses/tag/v0.5.0
- crates.io: epubveri · npm: @veripublica/epubveri-wasm
- Source + issues: https://github.com/veripublica/epubveri

Full epubcheck parity is a long road, and there are still things on the list — e.g. @Doitsu's note about epub:type in EPUB 2 is noted but not done yet. If you test 0.5.0 and something misfires — a false positive, a missed error, a wrong severity — please open an issue with the book (or a snippet). Those reports are exactly what moved this forward. Thanks again.

rantanplan · 07-11-2026, 04:51 PM

Is it available via homebrew?

Kayadelenium · 07-11-2026, 04:58 PM

Quote:

Originally Posted by rantanplan

Is it available via homebrew?

Not yet — but I'd like to add a Homebrew tap down the line. Can't promise when, though. Thanks for asking.

PeterT · 07-11-2026, 08:14 PM

Which location do you prefer seeing bugreports? Here or via Github issues?

Kayadelenium · 07-11-2026, 08:23 PM

Quote:

Originally Posted by PeterT

Which location do you prefer seeing bugreports? Here or via Github issues?

Please use GitHub,

Doitsu · Yesterday, 01:12 AM

@Kayadelenium

Since I don't have a Github account, I hope you don't mind me posting problems here.

I noticed that epubveri doesn't report malformed html files. For example, it won't complain about missing tags:

Spoiler:

This file should have triggered:

Code:

RSC-016: Fatal Error while parsing file: The element type "p" must be terminated by the matching end-tag "</p>".

It also doesn't flag inline tags not enclosed by block level tags or text outside of tags.

For example.

Spoiler:

This file should have triggered:

Code:

RSC-005: Error while parsing file: text not allowed here; 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")
RSC-005: Error while parsing file: element "span" not allowed here; 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")

Since I don't know Rust, I asked Claude.ai for help. It said that the following section in opf.rs will suppress HTML errors:

Spoiler:

Kayadelenium · Yesterday, 05:35 AM

@Doitsu — thank you for these reports, they're exactly the kind of concrete test cases that help most. No problem at all posting them here.

1) Missing end-tags (your first example). Confirmed and fixed. A content document that wasn't well-formed XML was being silently skipped instead of reported — so an unclosed <p> slipped through. It now surfaces as a fatal RSC-016 at the exact line/column, the same way the package document already behaved. This will be in the next release.

2) Inline elements / loose text at block level (your second example). Before I match this one, a quick question: what EPUB version is the book? The elements listed in the epubcheck message you quoted (address, blockquote, div, h1–h6, ol, p, table, ul…) are the XHTML 1.1 block-level content model, which points to EPUB 2. In EPUB 3 (HTML5), a <span> or loose text directly inside <body> is actually valid flow content, so epubcheck wouldn't flag it there — which is why the correct behaviour depends on the version. If you can confirm 2 vs 3 (or share the OPF version), I'll make sure I target the right content model.

Thanks again — much appreciated.

Kayadelenium · Yesterday, 06:18 AM

Hello Again,

Version 0.5.2 is fresh out of the oven. The changes made are listed below. (I've taken them directly from the GitHub release notes.)

Fixed

Malformed content documents are no longer silently accepted. A content document that was not well-formed XML — for example an unclosed <p> — was skipped without a word, so the book validated clean (a false negative). It is now reported as a fatal RSC-016 at the exact line and column, the same way a malformed package document already was. Undeclared/malformed named-entity references (e.g.   with no declaration) keep their existing single RSC-016 and are not double-reported. (issue #12, reported by Doitsu on the MobileRead forum.)

Changed

A deprecated epub:type value is now reported as usage-level OPF-086b (previously info-level OPF-086), matching epubcheck — which distinguishes the usage-level OPF-086b for a deprecated semantic from the warning-level OPF-086 it uses for deprecated rendition/viewport properties. The set of deprecated values and the endnote-inside-endnotes exemption are unchanged.

Doitsu · Yesterday, 07:38 AM

Quote:

Originally Posted by Kayadelenium

2) Inline elements / loose text at block level (your second example). Before I match this one, a quick question: what EPUB version is the book? The elements listed in the epubcheck message you quoted (address, blockquote, div, h1–h6, ol, p, table, ul…) are the XHTML 1.1 block-level content model, which points to EPUB 2. In EPUB 3 (HTML5), a <span> or loose text directly inside <body> is actually valid flow content, so epubcheck wouldn't flag it there — which is why the correct behaviour depends on the version. If you can confirm 2 vs 3 (or share the OPF version), I'll make sure I target the right content model.

EPUBCheck displayed the error message for an epub2 book with xhtml fies. In epub3 books, the same HTML code won't trigger an error message.

KevinH · Yesterday, 08:55 AM

But bare text inside no tag except for the body is still an error in epubcheck under epub3, correct?

Doitsu · Yesterday, 09:14 AM

Quote:

Originally Posted by KevinH

But bare text inside no tag except for the body is still an error in epubcheck under epub3, correct?

EPUBCheck won't flag this in epub3 books.

epub3 sample:

Spoiler:

In epub2 books, it'll trigger the following message:

ERROR(RSC-005): Error while parsing file: text not allowed here; 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")

epub2 sample:

Spoiler:

@Kayadelenium

epubveri will complain about named entities in epub2 books with xhtml files.

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

Sample:

Spoiler:

JSWolf · Yesterday, 09:49 AM

While loose text (as shown above) may be valid in html5, it's not valid in epub3. It looks like a bug is found in epubcheck.

Yesterday, 09:49 AM	#60
JSWolf Resident Curmudgeon Posts: 84,119 Karma: 153695583 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	While loose text (as shown above) may be valid in html5, it's not valid in epub3. It looks like a bug is found in epubcheck. Last edited by JSWolf; Yesterday at 09:51 AM.

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

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

07-10-2026, 08:06 PM	#48
DNSB Bibliophagist Posts: 53,054 Karma: 181147351 Join Date: Jul 2010 Location: Vancouver Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos	I checked multiple apps I use. -V is used for version (--version for the long form) and -v is used for verbose mode (--verbose for the long form). This was on both Linux and Windows platforms.

07-11-2026, 04:47 PM	#49
Kayadelenium Member Posts: 11 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	epubveri 0.5.0 is out — thank you all Hi everyone, epubveri 0.5.0 just shipped, and a lot of it came straight from the feedback in this thread — so first, thank you. The reports here, and the GitHub issues several of you opened, shaped this release more than anything else. Things that came directly from here: - USAGE messages (@Doitsu's request): epubveri now reports epubcheck's full five severity levels — fatal, error, warning, info, and usage — instead of folding them together. usage findings appear in the JSON output and are colour-coded in the browser demo. - -v (@JSWolf): an unknown flag now gives a proper error: unexpected option '-v' (see --help) instead of the confusing "cannot read -v". Per the CLI convention, -v is verbose and -V is version — the git/cargo style @DiapDealer and @PeterT pointed to. - Earlier reports are in too: exact line:column on findings (@KevinH, for Sigil), the OPF-096 self-link rule, and the dc:date / CSS @media false positives (@DNSB / @JSWolf). One breaking change to know before you test: the input is now passed with -i. So epubveri book.epub becomes epubveri -i book.epub. epubveri now follows a shared CLI convention across a small tool family, so the flags carry over between them. You can pass -i more than once to validate several books at once. Also new in 0.5.0: - --format json — machine-readable output: one JSON object per run, each finding with its code, severity, message and line:column. The CLI, a CI job, and the in-browser build all emit the exact same shape. - The browser demo got a refresh — download the result as JSON, a dark mode, and still no install / no upload (your file never leaves the page): https://veripublica.github.io/epubveri/ Where to get it: - Pre-built binaries (Linux, macOS, Windows — x86_64 and ARM): https://github.com/veripublica/epubv...ses/tag/v0.5.0 - crates.io: epubveri · npm: @veripublica/epubveri-wasm - Source + issues: https://github.com/veripublica/epubveri Full epubcheck parity is a long road, and there are still things on the list — e.g. @Doitsu's note about epub:type in EPUB 2 is noted but not done yet. If you test 0.5.0 and something misfires — a false positive, a missed error, a wrong severity — please open an issue with the book (or a snippet). Those reports are exactly what moved this forward. Thanks again.

07-11-2026, 04:51 PM	#50
rantanplan Weirdo Posts: 1,148 Karma: 13000000 Join Date: Nov 2019 Location: Wuppertal, Germany Device: Kobo Sage, Kobo Libra 2, reMarkable PaperPro	Is it available via homebrew?

07-11-2026, 08:14 PM	#52
PeterT Grand Sorcerer Posts: 14,027 Karma: 83121446 Join Date: Nov 2007 Location: Toronto Device: Libra H2O, Libra Colour	Which location do you prefer seeing bugreports? Here or via Github issues?

Yesterday, 05:35 AM	#55
Kayadelenium Member Posts: 11 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	@Doitsu — thank you for these reports, they're exactly the kind of concrete test cases that help most. No problem at all posting them here. 1) Missing end-tags (your first example). Confirmed and fixed. A content document that wasn't well-formed XML was being silently skipped instead of reported — so an unclosed <p> slipped through. It now surfaces as a fatal RSC-016 at the exact line/column, the same way the package document already behaved. This will be in the next release. 2) Inline elements / loose text at block level (your second example). Before I match this one, a quick question: what EPUB version is the book? The elements listed in the epubcheck message you quoted (address, blockquote, div, h1–h6, ol, p, table, ul…) are the XHTML 1.1 block-level content model, which points to EPUB 2. In EPUB 3 (HTML5), a <span> or loose text directly inside <body> is actually valid flow content, so epubcheck wouldn't flag it there — which is why the correct behaviour depends on the version. If you can confirm 2 vs 3 (or share the OPF version), I'll make sure I target the right content model. Thanks again — much appreciated.

Yesterday, 06:18 AM	#56
Kayadelenium Member Posts: 11 Karma: 100000 Join Date: Jul 2026 Location: Planet Earth Device: Kobo Forma	Hello Again, Version 0.5.2 is fresh out of the oven. The changes made are listed below. (I've taken them directly from the GitHub release notes.) Fixed Malformed content documents are no longer silently accepted. A content document that was not well-formed XML — for example an unclosed <p> — was skipped without a word, so the book validated clean (a false negative). It is now reported as a fatal RSC-016 at the exact line and column, the same way a malformed package document already was. Undeclared/malformed named-entity references (e.g.   with no declaration) keep their existing single RSC-016 and are not double-reported. (issue #12, reported by Doitsu on the MobileRead forum.) Changed A deprecated epub:type value is now reported as usage-level OPF-086b (previously info-level OPF-086), matching epubcheck — which distinguishes the usage-level OPF-086b for a deprecated semantic from the warning-level OPF-086 it uses for deprecated rendition/viewport properties. The set of deprecated values and the endnote-inside-endnotes exemption are unchanged.

Yesterday, 08:55 AM	#58
KevinH Sigil Developer Posts: 9,788 Karma: 7500000 Join Date: Nov 2009 Device: many	But bare text inside no tag except for the body is still an error in epubcheck under epub3, correct?

Advert

Advert