|
A note on what happens on my side, in case it is useful context rather than anything needing action.
My Sigil plugin builds what it validates from bk.copy_book_contents_to(workdir) and zips that, mimetype first and stored. It substitutes nothing afterwards. That last part was a change in 0.1.1 on 3 September, after a book where the OPF gave me one line number and the cursor landed on another.
What that leaves me depending on is one thing. Each finding's line and column is turned into an absolute character offset so the cursor can be placed on it, and that is only right when the copy I was handed matches what Code View is showing.
So the part I would like to understand, whenever it suits you:
1. With the change you have in mind, would a repaired-on-load OPF reach a plugin as the repaired text — that is, is the flag set before the flush that runs ahead of a plugin?
2. And would the same hold for XHTML mended on open? I have not measured this and am not suggesting anything is wrong. It is the same question one file type over, and my XHTML findings carry offsets computed the same way.
Thank you for the LoadWarning idea in particular. In #22 I asked whether a plugin could tell that Sigil had repaired something during load, and could not answer it myself — that answers it.
If testing would save you any time, I can drive launcher.py headless, so running a build against the shapes in this thread and reporting what a plugin receives is cheap here. Happy to do that, or to make a minimal book for anything you want isolated — and equally happy to leave you to it.
|