epubveri for calibre 0.1.0, and this is the "I will try to look at it tomorrow" from the Sigil thread.
https://github.com/veripublica/epubv...calibre-v0.1.0
Doitsu — written from calibre's plugin API, with none of your code in it, for the same licensing reason as the Sigil one. Yours is still the one with users, and on Windows and Linux it is the only one: mine has run on macOS and calibre 9.14 and nowhere else. Please leave yours up.
Every finding gets a row with its file, line and message, and activating a row opens the file and puts the cursor on the line. What calibre currently holds is what gets validated, unsaved edits included.
The settings —
Preferences / Plugins / epubveri / Customize, and the screenshot is what it looks like. Three switches,
all on by default, so out of the box the panel says exactly what the command line says.
- Keep epubveri up to date automatically. This one is about your connection rather than about versions. Left on, it reads 842 bytes of checksums at most once an hour and installs a newer epubveri if there is one, verifying it before it runs. Turn it off — a metered link, an air-gapped machine, or preference — and the plugin never touches the network again, and never mentions it. The one thing it still tells you is how old your copy is once a month has passed without a check, because that explains a finding that looks wrong.
- Show usage notes. Messages epubcheck also produces but hides unless you pass -u. They are observations, not defects, and they never move the verdict.
- Show advisory findings epubcheck does not make. epubveri's own ADV-* checks. Every one of them says so on its own line, and none of them can change VALID or NOT VALID: a book that passes epubcheck passes epubveri.
Two guarantees about those two display switches, because a settings screen is a good place to hide things by accident. Neither can hide an error, a fatal or a warning. And turning one off never makes the report quietly shorter: the summary then says how many findings are not listed and where the switch is.
Two things I could not have found by reading, in case they are worth checking in yours.
container.commit() edits the book. On an EPUB 3 it calls update_modified_timestamp(), so committing the container you are editing — even to a temporary path — rewrites dcterms:modified. Validating would modify the book. Cloning the container first keeps it out.
Cloning alone does not fix it. The timestamp update dirties the OPF, and a dirtied file is re-serialised on the way out rather than copied. calibre's serialiser is not byte-preserving: on my test book it split one line carrying dc:title and dc:language into two and wrote an empty dc:creator as a self-closing tag. The OPF gained a line and
every finding below it was reported one line off. Neutralising update_modified_timestamp on the throwaway clone leaves every file byte-identical, which is also what makes the line numbers trustworthy.
Six defects turned up in one day. Five appeared only by running it inside calibre, and the sixth by its own tests, on a fixture whose OPF is laid out the way a person writes one — two real books had missed it. That rate has not flattened, which is why this is 0.1.0 and not 1.0.0.
Bug reports on mine belong on GitHub rather than in your thread. A wrong finding — a wrong error on a good book — is the report I most want, and that one belongs with epubveri itself.