Jules

[julian-smith-artifex-com]

Install pymupdf command that runs fitz/__main__.py:main().

[JorjMcKie]

Script test_font.py is insufficient as it only confirms that the call to pdf_subset_fonts() does not crash.

Could we include additional tests:

• Fonts actually are being subset, e.g. by comparing file sizes before / after. So we do need examples with non-subset fonts.
• Text extraction is not being affected in any way by replacing fonts with their subsets, e.g. by comparing "dict" text extractions before / after.

As per Robin's statement, always all document pages should be used in the array - not a subset. One might argue, that in this case, we shouldn't ever need more than the PDF argument.

I have tried mupdf.pdf_subset_fonts2 and it did not work: no font subsets were created.

[julian-smith-artifex-com]

Script test_font.py is insufficient as it only confirms that the call to pdf_subset_fonts() does not crash.

It's only intended to check the python bindings are working. Additional checks can be added afterwards.

If you prefer, i could remove the test from this PR for now, until we have better tests written?

[...]

I have tried mupdf.pdf_subset_fonts2 and it did not work: no font subsets were created.

Unfortunately there's a mistake in the implementation in mupdf; i have a fix.

[JorjMcKie]

Ah, I understand.
We need to decide whether we want to safeguard against crashes in MuPDF's pdf_subset_fonts() at all.
If yes, we certainly should process more / many PDFs.
I vote for not doing this: I already confirmed that all our PDFs in the test/resources folder are processed without crash.

Otherwise, I have a test script that makes a fresh PDF with text using almost 10 different fonts and a consequential file size of 2 MB. Font types are OTF, TTF and CID.
After font subset, the file size is only 5% of the original.
If you want, you could include this one now instead ... or we postpone testing this completely.