local variable 'x0' referenced before assignment

[dothinking]

I faced the following error when upgrade PyMuPDF to 1.18.15,

>>> import fitz
>>> fitz.version
('1.18.15', '1.18.0', '20210710000001')
>>> doc = fitz.open("demo.pdf")
>>> doc[0].get_drawings()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\89_Program_Files\Python368\lib\site-packages\fitz\fitz.py", line 6003, in get_drawings
    path["rect"] = Rect(x0, y0, x1, y1)
UnboundLocalError: local variable 'x0' referenced before assignment

According to the output and codes around fitz.py Line 6003, there is a chance leading to this issue when path['items'] is empty.

for i, item in enumerate(path["items"]):
    for j, p in enumerate(item[1:]):
        if i == 0 and j == 0:
            x0 = x1 = p.x
            y0 = y1 = p.y
        x0 = min(x0, p.x)
        x1 = max(x1, p.x)
        y0 = min(y0, p.y)
        y1 = max(y1, p.y)
path["rect"] = Rect(x0, y0, x1, y1)

Check page._getDrawings() of my pdf, unfortunately, the second item efill is the case, even though the output looks a bit abnormal.

>>> doc[0]._getDrawings()
[['fill', 'non-zero', ['matrix', (1.0, 0.0, 0.0, 1.0, 0.0, 0.0)], ('colorspace', 'DeviceRGB'), ['color', 0.0, 0.0, 0.0]], 
'efill',
['fill', 'non-zero', ['matrix', (1.0, 0.0, 0.0, 1.0, 0.0, 0.0)], ('colorspace', 'DeviceRGB'), ['color', 0.0, 0.0, 0.0]], 
'efill',
...
['fill', 'non-zero', ['matrix', (1.0, 0.0, 0.0, 1.0, 40.0, 111.988525390625)], ('colorspace', 'DeviceRGB'), ['color', 0.0, 0.0, 0.0]], 
['m', (0.0, 0.0)], 
['l', (550.0, 0.0)], 
'efill',
...]

[JorjMcKie]

Please let me have a reproducing file, thank you.

[dothinking]

Thanks for your quick reply. Sample file here

[JorjMcKie]

Found / resolved the issue (and it is a real issue actually):
The example contains several drawing start commands without subsequent draws. I therefore now check whether path["items"] is empty - in which case I don't generate a path at all.

[dothinking]

Yes, my local fix is to check if path["items"] is empty before running that clause.

Also, I think it's a "defect" of the example file, because this issue was gone after I did minor change (e.g. change any characters) and re-save the file. It seems the pdf editor fixed the file automatically during this process.

[JorjMcKie]

Also, I think it's a "defect" of the example file

I agree. But in any case, the method must be vaccinated against this type of sickness 😉. So thanks again for bringing this up.

[dothinking]

Make sense. It's my turn to thank you for this great library; and, take case.