Closed monolied closed 1 year ago
Not a bug. Sigil is not a simple text editor. Sigil must keep the opf machine parseable at all times. That is how Sigil has worked from the very beginning. Sigil controls the opf which is how it can automate, link updates, renames, new resource additions, resource deletes, etc.
Directly editing the OPF and leaving it in a bad state even temporarily is a sure recipe for destruction and always has been. When you move focus outside of Sigil, Sigil will use lxml parser to make sure opf is in its standard format.
Just use Sigil's MetaData Editor to make your changes to multiple metadata at the same time much more safely. That is why it exists. The user should never need to directly edit the opf if they use the tools that Sigil provides.
Bug Description
I open content.opf. I want to edit a subject. So I copy the
<dc:title>
line, changetitle
tosubject
. I empty the content and tab to my web browser to copy a subject line. When I switch back to Sigil, the line, which looked like this:<dc:subject></dc:subject>
is "fixed" to be<dc:subject/>
This is annoying and destructive; and I didn't find any option to stop this behaviour. Even worse, once I had something like<dc:subject></dc:subject>
</dc:subject>
(invalid, of course, but I was in the process of editing and not asking for help) in the file for the time being, alt-tabbed away, came back and 85% of the content.opf was destroyed when I came back. This is reproducible. The only way I found to remedy that destruction was closing the file without saving and start the whole edit process anew. There is no undo available for the Sigil actions in the background. There also is no information about what has been done and why. Sigil should offer a way to prevent that behavior and/or have less destructive ways of handling malformed content.Platform (OS)
Windows (Default)
OS Version / Specifics
10 professional
What version of Sigil are you using?
2.0.1
Any backtraces or crash reports
No response