[Plugin] epubveri - Simple epubveri wrapper

[PeterT]

Installed and working on intel chromebook; sigil installed via appimage

[DiapDealer]

Originally Posted by Kayadelenium

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.

I'm a little confused by what you're doing here. Any unsaved changes in the epub (including the opf file) are supposed to be flushed to disk (to Sigil's temp scratch area) before any plugin runs. So the copy of the files that Sigil gives each plugin should already contain any and all changes that the user sees in Sigil (even if the epub has not been saved yet). So I don't quite understand why you'd be overwriting that opf with anything when you build the epub that epubveri needs to validate. The plugin framework has already given you (or should have anyway) the very latest staged edits. If it hasn't, then we have a problem somewhere in Sigil.

[Kayadelenium]

DiapDealer — short answer: the plugin does not overwrite the OPF. It did in the first release; the post you quoted was announcing that it stopped.

What it does today, all of it: it calls copy_book_contents_to into a temporary folder of its own, zips that folder into an .epub, runs epubveri on the zip, and deletes the whole thing when the run ends. The zip step is there because epubveri validates a packaged file rather than a folder. Nothing is written into Sigil's scratch area, and nothing is written back into the book — the plugin reads and reports.

One thing is left over, and it may well be intended. For an OPF the user has edited in the session, readotherfile does not return the file: it returns build_opf(). So the plugin is handed a rebuild, and any line number it reports for that file is a line in the rebuild rather than in what Code View is showing. On the book where I ran into it, one manifest entry was at line 91 in the file, 95 in the rebuild and 96 in Code View.

Everything else lines up: every other file in the book matches exactly, and so does an OPF nobody has edited in the session.

So this is not a request, just a question with a short answer either way: is the rebuild what a plugin is meant to get there? If it is, I will note it in the plugin's documentation and leave it alone.

[DiapDealer]

Originally Posted by Kayadelenium

DiapDealer — short answer: the plugin does not overwrite the OPF. It did in the first release; the post you quoted was announcing that it stopped.

Understood. Thanks for clarifying.

Originally Posted by Kayadelenium

What it does today, all of it: it calls copy_book_contents_to into a temporary folder of its own, zips that folder into an .epub, runs epubveri on the zip, and deletes the whole thing when the run ends. The zip step is there because epubveri validates a packaged file rather than a folder. Nothing is written into Sigil's scratch area, and nothing is written back into the book — the plugin reads and reports.

Seems to be a bit overkill--albeit harmless. Every plugin is already handed a temporary folder (which is a copy of Sigil's scratch area for that epub). Only the epub you create for epubveri to use would need to be created in its own temporary folder.
Strike that. A plugin IS given a copy of the contents of the epub, but for the purposes of building a temporary copy of the epub, copy_book_contents_to is probably the much simpler route.

Originally Posted by Kayadelenium

One thing is left over, and it may well be intended. For an OPF the user has edited in the session, readotherfile does not return the file: it returns build_opf(). So the plugin is handed a rebuild, and any line number it reports for that file is a line in the rebuild rather than in what Code View is showing. On the book where I ran into it, one manifest entry was at line 91 in the file, 95 in the rebuild and 96 in Code View.

Everything else lines up: every other file in the book matches exactly, and so does an OPF nobody has edited in the session.

So this is not a request, just a question with a short answer either way: is the rebuild what a plugin is meant to get there? If it is, I will note it in the plugin's documentation and leave it alone.

Let me do some checking, but yes... the rebuild is what a plugin is meant to get there. But I was under the impression that the flush-to-disk before a plugin run would mean that what Sigil shows and what a plugin gets should be identical. That was the intention anyway. We'll have to do some investigating to make sure that is the case (or why it's not).

[Kayadelenium]

On the extra copy being overkill: you are right that it is one copy more than necessary, and the reason is only that ebook_root is reachable through the wrapper's private attributes while copy_book_contents_to is the documented way to get the book's files somewhere I can zip them — if reading the folder Sigil already hands us is fair game for a plugin, I will drop the copy.

[Kayadelenium]

epubveri for Sigil 0.3.0 — one setting, and one thing written down.

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

The order of the findings is a setting now, in the same JSON file as the display switches: "sort", one of severity (the default), severity-low, or document. It is written into the file on the first run, like the others, so the file shows that the choice exists.

Severest first was already what this plugin did. What changed is that you can ask for something else, and that each severity group now keeps the book's order instead of being re-sorted by file name. Advisory findings sort last, since they never move the verdict. The words are epubveri's own — the command line takes --sort severity and --sort document — and the calibre plugin's setting uses the same three, so the two never need different vocabulary.

A setting rather than clickable columns because Sigil draws the results table: its columns are File, Line, Offset and Message, and clicking Message sorts the severities alphabetically, which puts ERROR above FATAL. What the plugin hands over is the only correct severity order available here. Ran all three orders through Sigil's own launcher before releasing.

And one limit is now in the README rather than only in this thread: if you have edited the OPF in the session and not saved, a position in that file can be a line or two away from what Code View shows, because a plugin is handed a rebuild of a modified OPF rather than the text on screen. Everything else in the book, and an OPF you have not edited, matches exactly. DiapDealer is looking at whether the two ought to line up; if they come to, the note goes away.

Thanks again to PeterT for the Linux run and to DNSB for Windows on the last one.