Font errors during document processing

[djoltes]

I'm working on a solution that involves PDFs from multiple sources, and recently ran across a file that apparently uses Calibri as its primary font. This is resulting in errors I've seen rarely in past cases, but this file produces a huge string of them. Examples below.

mupdf: FT_Get_Advance(OOFOFP+Calibri,20037): invalid glyph index
mupdf: FT_Get_Advance(OOFOFP+Calibri,21589): invalid glyph index
mupdf: FT_Get_Advance(OOFOFP+Calibri,21058): invalid glyph index
mupdf: FT_Get_Advance(OOFOFP+Calibri,22345): invalid glyph index
mupdf: FT_Get_Advance(OOFOFP+Calibri,21576): invalid glyph index
mupdf: FT_Get_Advance(OOFOFP+Calibri,21840): invalid glyph index
mupdf: FT_Get_Advance(OOFOFP+Calibri,17473): invalid glyph index

The end result is that many areas of the document don't get redacted, apparently due to an inability to process the font. I've been poking at the doc, but can't find a solution (do I need to add a font package so mupdf?). This is on Windows 2019, and I do see that Calibri is installed via the OS. Ideas appreciated.

[JorjMcKie]

There seems to be an error in the PDF's fontfile, which is a subset of the full Calibri font. The message reports a freetype error.
freetype is one of several thirdparty libraries used by MuPDF. All this happens outside PyMuPDF.
MuPDF does not access the system fonts of the OS.

To isolate the problem from any special processing in your app, you may want to try and convert it to another PDF using mutool draw -o test.pdf input.pdf or, equivalently doc.convert_to_pdf().
I would bet you'll see similar messages ...

I am boing to notify some of the MuPDF experts, too.

[djoltes]

Thanks Jorj. We get PDFs from a huge variety of sources, and it's not surprising that some will be broken in some way. If it turns out there's some way to rewrite and correct this, I can add it to the code but I may just need to report this kind of error and abort processing. The use case is automated redaction, and if we can't perform that task on a given file it'll need to be passed to human intervention.

[djoltes]

Did you ever get a reply from them? I was just running some additional files through today and got different errors (different file as well).

mupdf: cannot load object (4926 0 R) into cache
mupdf: cannot load object (4926 0 R) into cache
mupdf: cannot load object (4860 0 R) into cache
mupdf: 'F11' is no font dict (4860 0 R)
mupdf: cannot load object (4926 0 R) into cache
mupdf: 'Helv' is no font dict (4926 0 R)
mupdf: cannot load object (4926 0 R) into cache
mupdf: cannot load object (4926 0 R) into cache
mupdf: cannot load object (4860 0 R) into cache
mupdf: 'F11' is no font dict (4860 0 R)

[JorjMcKie]

My assumptiona have been confirmed by the MuPDF colleagues.
These errors and the set of others you are reporting, are badly formed / damaged PDFs.
Hard to say from my level of detail what the best approach is to handle these undoubtedly severe situations.

Messages like "'F11' is no font dict (4860 0 R)" or "cannot load object" of course indicate that the PDF contains severe damages.
Probably valid to pass such a file to human processing. It may be too risky to try programmatic repair.

[djoltes]

I'd not be surprised; we get files from a large number of corporations and other entities, and who knows how they're all being generated.