Re-support font name prefixes in span font names

[darraghmckay]

Is your feature request related to a problem? Please describe.

Before version 1.17.6 when you extracted the page text dict you would get font names like
MJGHPI+TimesNewRomanPSMT
and
YCCJKF+TimesNewRomanPSMT

Now those same text spans both return
TimesNewRomanPSMT

Note the lack of leading prefix

This is a breaking change for our current implementation and we can not upgrade beyond 1.17.5 until we can specify that full font-names should be used.

This is the line that was changed

https://github.com/pymupdf/PyMuPDF/compare/60e0c1fd5abadf61905253ea2fa19f62cb28e66e..10341cea796e8cbde86959a590d87b2596c27085#diff-04606915a2aa7f21b7798f15aba6f7b29a8900c7ac7403b13f2237f8214749ecR184

Describe the solution you'd like
It would nice to be be able to do one of the following:

1. Add a flag/option to get_text("dict") that specifies that font names should be returned as is
2. The font's xref is included in the final span so that it's xref could be found in the page's font list

Describe alternatives you've considered
I explored option 2 above but I don't currently think that's possible

Additional context
If you think this is something that is in-line with the project's vision I will happily implement it.

[JorjMcKie]

Ok, I understand.
Using the flags parameter for this won't work, because it is MuPDF's own bit switch field. Who knows what will happen to it in the future.
But I can offer to introduce a global parameter, that could be set like fitz.TOOLS.set_full_fontnames(True) or so - with False being the default.
This would be in effect for the rest of the current script, or until changed.

[darraghmckay]

That solution sounds great. Thanks for the suggestion

[JorjMcKie]

It is easy-peasy to do. At least for the dict / json / rawdict / rawjson outputs.
You may know, that XML, XHTML, HTML are original MuPDF code, so they will continue to behave as they currently do.
The other variants, text / words / blocks do not report the font name - so hopefully, that change will have no collateral impact ...
Please expect this to be included in the next version, 1.18.9.
If you want to test a pre-version, please let me know your environment, so I can point you to the right download location.

[darraghmckay]

Excellent, thanks so much, that looks perfect

[JorjMcKie]

You can find Linux and Mac OSX pre-version wheels in respective branches of this repo.
Drop me a note if you want to test Windows.

[darraghmckay]

Sorry for not getting back to you sooner. This worked exactly as expected thanks

[JorjMcKie]

I am planning to publish an official new version with a week from now.

[JorjMcKie]

Fixed in v1.18.9 currently being uploaded.

[darraghmckay]

Thanks again for this, it worked as expected.