testing file attached, please compare MuPDF display with Acrobat, then you can see Chinese texts displays are incorrect.
Created attachment 7281 [details]
testing file for reporting MuPDF bug
The infamous DynaLab fonts! I have added a fix using the freetype function to check for DynaLab fonts. This requires a relatively new version of freetype to work properly (2.4.3 or newer).
On further testing, the fix is not necessary on freetype >= 2.4.3 at all. Upgrade your system freetype (or compile with the freetype from mupdf-thirdparty.zip).
Even with Freetype 2.4.4, this document (mainly the title) misrenders in comparison to Adobe Reader.
The trickyness tests in freetype 2.4.4 are more extensive than in 2.4.3, and fail on the subset fonts in the file since the family_name isn't set. The only reason it "worked" in 2.4.3 was that the default if the family_name is null was to be tricky. The font DLCRoundBold isn't in freetype's list of known dynalab fonts.
I've reverted the patch so now mupdf will apply the hinting workaround for all truetype CJK fonts. It should not have any visual artefacts, since the hinting is run at a glyph size of 1000x1000 before the outline is scaled to the real size.
The new patch seems to be too broad. I've got documents containing e.g. a Type 2 Verdana subset with an Adobe-Identity CMap that's now got hinting enabled and no longer looks the same as in Adobe Reader.
Wouldn't an explicit fontname list the safer choice (similar to what FreeType does in tt_check_trickyness_family)?
I think I have a function to relatively safely identify DynaLab fonts by their name. The set of names from freetype plus checking for a "DF" or "DLC" prefix both with full and subset (ABCDEF+DF...) forms. Hopefully this won't catch too many false positives.
I also added a message with pdf_logfont when forced hinting is turned on (check by setting environment variable MULOG=f).