[Plugin] epubveri - Simple epubveri wrapper

[DNSB]

I've tried it on Windows. It seems to run happily. One suggestion is to include the plugin.png and plugin.svg files in your .zip file. This gives an icon for the plugin.

For the most part, I am in the edit json for settings. It's very rare for me to change the plugin settings once I'm happy with them.

I should mention one issue. Everytime I run epubveri, I get an invalid book path provided on the line reporting the number of errors.

[PeterT]

installed on an Intel based chromebook running the AppImage build of Sigil.

No Issues

[Doitsu]

Originally Posted by DNSB

I should mention one issue. Everytime I run epubveri, I get an invalid book path provided on the line reporting the number of errors.

There's a typo in the code.

bk.add_result("info", "", -1, _xml_attr(summary))

should be:

bk.add_result("info", None, -1, _xml_attr(summary))

[DNSB]

Originally Posted by Doitsu

There's a typo in the code.

bk.add_result("info", "", -1, _xml_attr(summary))

should be:

bk.add_result("info", None, -1, _xml_attr(summary))

Replaced line 503 in plugin.py and looks good. None and no error.

[Kayadelenium]

epubveri for Sigil 0.1.1 is up, and it is the two you found plus one you did not.

https://github.com/veripublica/epubv...g/sigil-v0.1.1

DNSB, the summary line. A result about the book as a whole names no file, and I said so with an empty string. That is the one value Sigil's result table reads as a mistake rather than as an absence: it resolves the bookpath to a resource and, failing that, prints "Invalid Book Path Provided" for an empty one and the path itself for anything else. It now sends a single space, which is neither empty nor a path, so the File column comes out blank. Doitsu's None clears it too, and finding the line was his; I went with the space only because None reaches that column as the literal word. The same empty string was in seven other places, including every finding epubveri makes about the container rather than about a file, so this was waiting for a real book as well.

DNSB, the icon. Shipped, an svg with a png beside it, which is the order Sigil looks in. A filled tile rather than a line drawing, because Sigil has a dark theme and a single-colour outline vanishes into one of the two.

And the one nobody reported. Testing this build, content.opf said line 95 and the cursor landed on 96. The OPF only. I had been overwriting the copied OPF with get_opf, which is a rebuild from Sigil's model: it sorts the manifest by id and rewrites every entry. My line numbers were correct for that rebuild and for nothing else. On the book that caught it, the cover entry sits at line 91 in the file, 95 in the rebuild, and 96 in what Sigil was displaying. Three numbers for one line, and the two a user can see were not the one I sent. The substitution was there so unsaved manifest and spine edits would still be validated, and it was never needed: the OPF is not a manifest item, so readotherfile already hands back the live rebuild when there are unsaved OPF edits and the file from the ebook root otherwise. Removing it keeps both. One limit stays, and I would rather say it than have someone find it: with unsaved OPF edits, positions in the OPF refer to Sigil's rebuild rather than to the text on screen. I cannot see a way to ask a plugin what Code View is holding.

PeterT — thank you, that is the first Linux report. With DNSB on Windows, the line in 0.1.0's notes about nobody having run it outside macOS is now answered on all three.

[Doitsu]

I had a look at the latest version and noticed that there a no preference settings for disabling usage and advisory messages.
Since some users might not be interested in them, it'd great if you added preference settings for both. You can keep them enabled by default.
Also some users might not be interested in seeing the summary information.
Speaking of the summary information, you could also add the plugin version number for debugging purposes.

[DiapDealer]

Keep in mind that Sigil can have just about any theme colors imaginable on Linux. Simpler is best when including icons that may need to be visible in any theme from light to dark (and in between) on three platforms.

[DNSB]

In one of my automations, I found that replacing epubcheck with epubveri led to an error always being reported. Even if the line says no errors, that return appears to be an error to Sigil.

[DiapDealer]

Sigil will consider any final plugin return value other than zero an error.

[BeckyEbook]

Yes. A summary – while very useful – should be optional.

Temporary workaround – add a comment in this line:

bk.add_result("info", _NO_FILE, -1, _xml_attr(summary))

[DiapDealer]

Or at the very least, print the summary before returning control to Sigil.

[Kayadelenium]

DNSB — I cannot reproduce the automation, and I would rather ask than guess at it.

What I can tell you is that a validation which completes returns zero, whether the book is valid or not; there is a test on that now, against a clean book and a broken one. So on an ordinary run Sigil is not being told the plugin failed, and the mechanism DiapDealer describes is not the one you are hitting — which means I am missing something rather than that you are. Three questions, and any one of them may be enough:

Which automation is it, and does it also error on a book with nothing wrong with it? What appears in the plugin's output window when it happens? And does it stop if you comment out the summary line BeckyEbook pointed at?

Your report did turn up a real defect on the way, and a worse one than an exit code. PluginRunner::launch checks the return value before it copies the plugin's results into the wrapper XML. On anything non-zero it writes a failed result and returns early, so every add_result is discarded. Five paths in this plugin report a problem and then return non-zero — there is no binary, its checksum did not match, epubveri would not run, it could not read the book — and each one wrote its explanation into the results table and threw it away. You were told the plugin failed and nothing about why. Those five messages have never been read by anyone.

They are printed now, because standard output reaches the output window on both paths. DiapDealer — that is your #26 applied to a line you did not mean it for, and it was the right advice twice.

BeckyEbook, Doitsu — the summary is switchable in the next version, along with usage notes and advisory findings, all three defaulting to on so that nobody who ignores the settings sees any change. When the summary is off it is printed rather than dropped: the results table is empty, and you can still see that the plugin ran and what it decided. A category you switch off still says so in the summary with its count, because a panel with no usage notes should not read the same as a panel whose usage notes were filtered — and on Sigil that line is the only place the settings can be discovered at all.

Doitsu — the plugin's own version is in that line too now, beside epubveri's. Most of what has gone wrong here so far was the plugin rather than the validator, so it was the more useful of the two numbers to be missing.

DiapDealer — the icon is redrawn and the tile is gone. It is a filled document silhouette with the tick knocked out of it: it still carries its own contrast, so no theme shows through it, but the outline is the mark rather than a rectangle drawn around the mark, which is what lets it sit among glyphs that are strokes on nothing. The old one also put a page about seven pixels wide at 16 with the tick inside that, which is the half of "simpler is best" I had not seen until you said it.

[BeckyEbook]

Originally Posted by Kayadelenium

Which automation is it, and does it also error on a book with nothing wrong with it? What appears in the plugin's output window when it happens? And does it stop if you comment out the summary line BeckyEbook pointed at?

To enable automation in Sigil, go to: Preferences > Appearance > Main UI > Automation Menu (Advanced) > [X] Show Automation menu.

Next, define your Automation Lists:
Automation menu > Manage Automation Lists > New > New List > [NAME] > OK

Click on [NAME] > Edit > Add Plugin > epubveri

A "validation" plugin that finds no errors always returns the result shown in the image.
In that case, Automation "moves on" because it knows that the validation passed.

And yes, commenting out that line has exactly that effect.

[DNSB]

Sigil has the capability of running multiple tools/plugins from an automation list. This comes in very handy when you find yourself running multiple tools such as when checking an ePub file before saving it. Basically anything returned from the verification tools shows as an error including the summary. Since Sigil returns No Problem Found, the summary is not really needed since the errors are listed in the results box if any errors occur.

[Kayadelenium]

epubveri for Sigil 0.2.0 — everything in it came from this thread.

https://github.com/veripublica/epubv...g/sigil-v0.2.0

The archive is now epubveri_sigil_v0.2.0.zip — PeterT asked for a name that says which editor it is for, and both plugins were shipping the same one. Still do not rename it: Sigil takes the plugin folder name from the part before the first underscore, so epubveri has to stay there and only the rest was free.

DNSB, BeckyEbook — the automation. Fixed, and you two found it rather than I did. A validation result is not a neutral place to put a sentence: it is how Sigil is told the book has a problem. Automation has exactly three outcomes for a validation plugin and Sigil's own binary names them — Validation Tool Reported No Problems Found, Aborted due to Validation Errors, Ignored Validation Errors. Zero results is the first, and one result of any severity is the second, info included. So the summary line stopped every list this plugin was in, on every book, clean ones as well.

The summary is now a result only when there is another one. On a book with findings it is the last line, where you are already looking, and the list was going to stop on those findings anyway. On a clean book there is no line and Sigil says No Problems Found by itself. Built a list with BeckyEbook's steps and it moves on.

Doitsu — the settings. show_usage, show_advisory and show_summary in plugins_prefs/epubveri/epubveri.json, all defaulting to on and written into the file on the first run, so the file shows you which choices exist rather than making you know they do. A category you switch off still says so in the summary with its count: a panel with no usage notes should not read the same as a panel whose usage notes were filtered, and on Sigil that line is the only place these settings can be discovered at all. Anything not clearly a no is read as yes, which is deliberately the opposite of autoupdate — that one spends your connection, so a typo must not use it; these hide findings, so a typo must not hide them.

The plugin's own version is in that line too now, beside epubveri's.

DiapDealer — twice. The icon has lost its tile: it is a filled document silhouette with the tick knocked out, so it still carries its own contrast but the outline is the mark rather than a rectangle around the mark. The old one also put a page about seven pixels wide at 16 with the tick inside that, which is the half of "simpler is best" I had not seen. I only have macOS, so the Linux themes you were actually talking about are still untested.

And your #26 turned out to be right about a line you did not mean it for. Five paths report a problem and return non-zero, and PluginRunner::launch checks the return value before it copies results into the wrapper XML — so every one of those explanations was discarded and nobody had ever read them. They are printed now.

What is not verified. Everything above was run in Sigil on macOS, on real books and on a deliberately clean one. Nothing here has been on Windows or Linux. If you have five minutes and either of those, that is the gap.