Quote:
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.
Quote:
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.
Quote:
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).