Sigil crashes on error in metadata, content.opf

[st_albert]

Hello all,

I'm using Sigil ver 0.9.8, Qt ver 5.6.1 on kubuntu 16.04.2 LTS (Xenial Xerus).

I was creating an epub and editing the content.opf, which included adding additional metadata copied from an external file. After adding the metadata, on saving, sigil crashed and the error message popup was blank (sigil having locked up before printing the actual error message).

I repeated my steps, with the same result. On one occasion, the error message was printed, and it said something like "internal Python error" but of course the details button was inactive.

After starting again and adding the metadata one line at a time, I identified the following line as the culprit: (the names have been changed to protect the innocent.)

<dc:contributor opf:role="art" opf:file-as="Rockwell, Norman>Norman Rockwell</dc:contributor>

Note the missing quote between Norman and >.

When changed to :

<dc:contributor opf:role="art" opf:file-as="Rockwell, Norman">Norman Rockwell</dc:contributor>

it saved without error.

Given that I'm no stranger to missing quote marks, hopefully something can be done to provide a more gentle response to this error.

ETA: Of course I haven't tested this on other platforms, but if it really is an "internal python error" it seems likely that the error will extend across platforms.

All the best,
Albert

[KevinH]

The python lxml library is used to parse the opf file in places and that python interpreter is directly linked into sigil and for some reason the missing attribute ending quote is really confusing the parse code. I will look into making it more robust to that particular error. The regular gumbo xhtml parser is much more forgiving than the lxml xml parser, and the other python parser code.

Thank you for your bug report.

[KevinH]

Okay I can recreate this on my Mac but I can see and report the details in the "Embedded Python Error"

Traceback (most recent call last):

  File "/Volumes/SSD-Drive/repo/build2/bin/Sigil.app/Contents/python3lib/xmlprocessor.py", line 192, in repairXML
    newdata = Opf_Parser(newdata).rebuild_opfxml()

  File "/Volumes/SSD-Drive/repo/build2/bin/Sigil.app/Contents/python3lib/opf_newparser.py", line 422, in rebuild_opfxml
    xmlres.append(self.convert_spine_attr_to_xml())

  File "/Volumes/SSD-Drive/repo/build2/bin/Sigil.app/Contents/python3lib/opf_newparser.py", line 381, in convert_spine_attr_to_xml
    for key in attr:

TypeError: 'NoneType' object is not iterable

The code that fails is trying to repair your opf as it is not well formed (every attribute in xml must be quoted) but gets confused trying to repair it causing the error.

Since Sigil requires a fully well-formed opf to function, even temporarily leaving the opf is a broken state is a serious issue for Sigil. Unfortunately, making a "robust" pure xml parser is hard without access to the exact schema used for that xml document. In the future I recommend using the MetaData Editor to make metadata changes as they will always be properly quoted preventing this error.

[KevinH]

Okay, I just committed a "fix" that will make the opf parser more robust to missing end quotes on attribute values. The repair is not perfect but loses no text.

The non-well formed line:

<dc:contributor opf:role="art" opf:file-as="Rockwell, Norman>Norman Rockwell</dc:contributor>

will get repaired to the following which should be easy to manually fix without information loss:

<dc:contributor opf:role="art" opf:file-as="Rockwell, Norman&amp;gt;Norman Rockwell></dc:contributor>

And Sigil will continue to function properly with no Embedded Python Error.

Thank you for your bug report and for your sample code to test things with.

[st_albert]

Hey, thanks for your quick response and fix.
I can fully understand how the parser gets confused. When I was a young pup learning Algol on a Burroughs B5500, we used to have a game: How many compiler errors could you generate with a single typo in the source code? Hint: leaving off a semicolon at the end of a statement was a good move.
Seems like the same kind of problem is at work here. Without the closing quote, how does the parser know when the end of the quoted text actually occurs? So, even if the solution isn't precisely correct, it at least calls attention to the error and allows one to actually fix the problem.

(For me, using the metadata editor is not nearly as good a solution, since I'm dealing with inserting at least a dozen or more entries, which are *usually* provided, well formed, in a text file that only needs to be copied into content.opf. I've done this close to a hundred times, and this is the first time I've run into this error. So next time, I'll know what to look for.)

Kudos!

Albert