Font issues from version 3.3.3 to 3.4

[NintendoPlayer]

Hi!

I've updated to the last version available right now, 3.4.6. Since then I have issues with PDF showing strange characters in determined lines. I did not have this issue before. So I downgraded to the last version that doesn't exhibit this behaviour. 3.3.3 is the last version showing the PDF's without issues, being 3.4 the first one.

This PDF's are created with a custom C# application we have inhouse. I'm not using strange fonts, the usual suspects. I can't share the PDF because it has sensitive info, but something changed from 3.3.3 to 3.4.

Maybe someone can help me. Thanks

[GitHubRulesOK]

Font support depends on underlying use of fontlibs primarily driven by MuPDF so constantly shifting, even day to day in Pre-release. I agree each version can differ drastically thus keep a copy of 3.1.2 for specific use cases where I consider it was at its best !.

IF the change can be identified as down to a MuPDF fail or regression then Bugzilla is the place to report such font handling bugs. Whatever the case only latest Pre-Release can be altered, so you need to check the current pre-release behaviour. (but last update has other known issues, a copy one step back is presently preferred see comment https://github.com/sumatrapdfreader/sumatrapdf/discussions/2797#discussioncomment-4690026)

[NintendoPlayer]

I've installed pre-release build version 15264, and the issue persist.

[GitHubRulesOK]

I suggest above (after you posted sorry) use 15263 as more stable but if issue is still present in 15264 then 15263 is irrelevant.

Can you please emulate a desensitised single page minimal example and post to this thread.

[NintendoPlayer]

Yes, here is a sample:

https://u.pcloud.link/publink/show?code=XZmSn9VZXOLTtgvhOpz40l6rTsdrmBSGscGk

Please, confirm you downloaded the PDF, so I stop sharing it, I prefer to do it that way.

Thanks for your help.

[GitHubRulesOK]

The developer @kjk will need to see a sample attached to this thread. So I have seen that it is a mess in places due to subset imbedding Arial bold True Type (CID) **not** embedded but many parts are embedded thus it seems the Character MAPping is poorly constructed when viewed by MuPDF 1.21.0 and thus SumatraPDF, possibly due to MuPDF not accepting/tolerating that mapping. Normally only see that in cut and paste of the underlying plain text, so was surprised it also affects visually it must be poor.

[GitHubRulesOK]

Since the visual distortion is clearly present in MuPDF only they can fix it, but I cannot say if they would declare the problem as bad file may not fix. If they remove that problem then SumatraPDF would inherit their fix. you would need to review known problems at https://bugs.ghostscript.com/describecomponents.cgi?product=MuPDF and raise a new one if not known to them.

so for a recent open bug that could be related I see https://bugs.ghostscript.com/show_bug.cgi?id=706060 however yours may not be related since that sample seems to exhibit other different problems.

[kjk]

It shows properly in chrome but as @GitHubRulesOK said, it's a mupdf issue.

[kjk]

This is a broken document in that it contains non-embedded fonts. mupdf says:

loading non-embedded font 'Century Gothic,Bold' from 'C:\WINDOWS\Fonts\GOTHICB.TTF'
loading non-embedded font 'Century Gothic' from 'C:\WINDOWS\Fonts\GOTHIC.TTF'
non-embedded font using identity encoding: Arial,Bold

On the other hand, FireFox/pdf.js renders it correctly.

Misrendered part:

[kjk]

The issue seems to be wrong encoding for Arial,Bold:

warning: non-embedded font using identity encoding: Arial
warning: non-embedded font using identity encoding: Arial,Bold

From: mutool trace .\bug3232-01_0000023031_v4.pdf

            <fill_text colorspace="DeviceRGB" color="0 0 0" ri="1" bp="1" op="0" opm="0" transform="1 0 0 -1 0 841.89">
                <span font="Arial,Bold" wmode="0" bidi="0" trm="8.999 0 0 8.999">
                    <g unicode="�" glyph="F" x="50.296" y="624.675" adv=".722"/>
                    <g unicode="�" glyph="g" x="56.79328" y="624.675" adv=".556"/>

pdf.js seems to have relevant work-around: https://github.com/mozilla/pdf.js/blob/master/src/core/evaluator.js#L4218

[kjk]

Reported to mupdf: https://bugs.ghostscript.com/show_bug.cgi?id=706394

[NintendoPlayer]

Hi @kjk! Thanks for your help. I forgot to mention that I opened a ticket on ghostcript, as suggested by @GitHubRulesOK. As your investigation is more specific I will link the new bug filed on the one that I opened.

Thank you for taking time on this issue.

[GitHubRulesOK]

for reference above report is at https://bugs.ghostscript.com/show_bug.cgi?id=706359