Oddity in e²->e³ conversion

[DiapDealer]

Originally Posted by KevinH

Really not sure how the opf is read (ie by recreating it from parsed form; or by sneaking around the wrapper to directly access the opf file) but epubcheck and epubveri plugins could have made different choices here.

According to the plugin's thread, there have been some changes to epubveri in that regard. Looking at the code, I can see that epubveri doesn't have an option to validate an unzipped epub, so a temporary epub is created. In earlier versions, the copied opf was being overwritten using get_opf (which I believe is Sigil's parsed rebuild of the opf). That was changed to using readotherfile. This was in an attempt to verify unsaved edits. But it was resulting in line numbers that didn't match what the user was seeing in Sigil when reporting errors.

https://www.mobileread.com/forums/sh...7&postcount=20


I may be putting too much emphasis on the silent opf rebuild, since it's been that way for a long, long time. Any save is going to correct a missing closing tag in the opf afterall. It just seemed odd to me that a problematic epub could be opened, validated, and closed (with the pre-existing error still intact) with no warning messages whatsoever

[KevinH]

It should not happen as SaveAllToDisk is used in prep for any plugin and Save by Sigil. I can not see how using bk.readotherfile in a plugin gets something different. Even if it is just missing the xml header line if SaveAllToDisk actually is working properly. So I am with you on this. Something is strange. I will explore this with some debug output in ResourceObjects/TextResource.cpp to make sure its SaveToDisk routine is properly being hit (for the opf's bookpath). The OPFResource inherits from XMLResource which in turn inherits from TextResource, so that is the routine that should be triggered unless we override it in OPFResource itself.

[KevinH]

Actually, OPFResource overrides SaveToDisk so I will take a look at it.

[DiapDealer]

For what it's worth: The latest version of the epubveri is now returning the same two errors that epubcheck did in the original post. The missing closing spine tag is not being reported by epubcheck or epubveri. So that leads me to believe that plugins are getting the same opf (corrected to add the closing spine tag) that Sigil is seeing. The corrected closing tag has not been saved to the epub yet, but both validators are ignoring it. Which leads me to believe that the opf has indeed been saved to disk (to Sigil's scratch folder) before being handed off to the plugin.