Ho to handle fitz.open() error?

[gosforth]

Hi,

In my project not correct PDF file can happen - not valid file or simply empty file.
If I open it with:

doc = fitz.open(pdffile)

I get error:

mupdf: cannot recognize version marker
mupdf: cannot tell in file

How to handle this error? I tried:

try:
    b = open(pdffile, "rb").read()
    doc = fitz.open("pdf", b)
except:
    error = 1

Does not work. I get error as above.
I tried:

try: 
  with fitz.open(pdffile) as doc:
   print('ok')
except Exception: 
   print('oops')

Does not work.
Any suggestion?
Regards

[JorjMcKie]

MuPDF always does its best to repair a file. Therefore, things must really go very wrong to get an exception.
So mostly a doc is indeed created.
You now have a number of options to determine if you find this acceptable for going on:

• check doc.is_repaired which is true in those cases
• check the content of fitz.TOOLS.mupdf_warnings() which contains all errors and warning messages concatenated by "\n".
• check the number of pages doc.page_count if zero you know you have a severe problem
• and of course, if you opened from a bytes object, you can check its length yourself ...
• are you sure you are always actually dealing with a PDF? There is the separate filetype package, which reads / determines the MIME type ...

[gosforth]

Thanks a lot for supersonic answer!
I think doc.is_repaired, doc.page_count or other will change nothing since error occur during opening (before I can use mentioned functions). Or I do not know how to use them?

Checking file consistency and filetype before fitz could be a good idea. So I need to check at least two things:
File is not corupted
File is correct PD
I will try but if you have some advice, please let me know :-)

[gosforth]

After first test I see that this package is not able to deal with not correct files (at least empty ones).

[JorjMcKie]

After first test I see that this package is not able to deal with not correct files (at least empty ones).

An empty file or stream of length 0 leads to an exception. What more do you expect?

[JorjMcKie]

The sequence of logic is:

1. doc.fitz.open(something)
2. If no exception, then the document has been created and you can check doc.is_repaired
3. if last response ist False , check whether doc.page_count > 0
4. if all of the previous passes you are fine

[JorjMcKie]

If you want to be lazy, try this snippet:

try:
    fitz.TOOLS.mupdf_warnings()  # empty the problem message container
    doc = fitz.open(pdf_doc)
    warnings = fitz.TOOLS.mupdf_warnings()
    if warnings:
        print(warnings)
        raise RuntimeError()
expept:
    error = 1

[gosforth]

Hi,
thank you very much for your support. Above code still rises error (even if I disable print and raise)
But I manage this problem with filetype:

import filetype

type_detected = 0
kind = filetype.guess(pdffile)

if kind is None:
 type_detected = 0
else:
 type_detected = 1
 
if type_detected == 1 and kind.mime == 'application/pdf':
 #run the code

Thank you very much for your assistance - I appreciate!

[gosforth]

You can create such file in notepad. Just open file and save without any body (0 content). For some reason I get such files sent by users.

[JorjMcKie]

# empty file from memory
doc = fitz.open("pdf", b"")  # or b" "
# leads to an exception
# same is true for
doc = fitz.open("file.pdf")
# if the file is empty

So everything is as it should be in those cases: you get exceptions, and no fitz.Document is created.
What reason for complaint do you have here?

[gosforth]

:-)
block "try: except:" is not working with fitz.open casting error. Script blows up blocking program.
Anyway, I solved it as above.
Greetings

[JorjMcKie]

NuPDF's prominent goal is to make a PDF available if a minimum of content seems usable. You may be able to extract valuable stuff (like images or embedded files) from it - even if the page tree is corrupt or if there are severe other damages.
After all, look at what typical or frequent defects are: among those mostly are incomplete downloads - the %%EOF file marker and / or the trailer are missing. So a full file content scan is made in an effort to find the catalog, which should lead to the page tree and the EmbeddedFiles pointer aong other things.
Why on earth would you want to keep the application from exploiting these parts?

Also remember, that PDF is a text file structure potentially interspersed with binary data. There are no overall integrity indicators like hash codes or whatever. Not a strict integral coherent format like we have it with the ZIP format of XPS, FB2 and others.
So you always may find spots of partial damage, while the file in total is largely usable.