[Bug]: Incorrect rendering of some fonts at intersection of shapes

[MDLC01]

Attach (recommended) or Link to PDF file

Created with Typst using New Computer Modern Math Bold 8.0.1:

#set text(font: "New Computer Modern Math", weight: "bold")
#sym.eq.not

The OTF font file I used can be downloaded on CTAN.

font-rendering.pdf

Web browser and its version

Firefox 151.0.2 (64-bit)

Operating system and its version

Windows

PDF.js version

Don't know how to check the version that's embeded in Firefox

Is the bug present in the latest PDF.js version?

Yes

Is a browser extension

No

Steps to reproduce the problem

1. Open the PDF file I provided.
2. Have a zoom level up to 350 %.

What is the expected behavior?

The symbol should be displayed properly:

What went wrong?

The symbol is displayed improperly:

Link to a viewer

No response

Additional context

The issue can be reproduced with other symbols and other NewCM fonts.

[calixteman]

Interesting bug.
I can reproduce it on Windows but it depends on the zoom level.

[calixteman]

I think the bug is because of how DirectWrite handles self-intersecting glyphes in CFF fonts at some specific sizes.
So fixing this issue is possible in checking if each glyph is self-intersecting or not and in such a case we could fallback on our font renderer, but it means we'll have the check that for whatever CFF font so it'll induce some overhead for something which is likely a corner case.
FYI, I can reproduce with Acrobat too.
Ideally this is something which should be fixed in the font itself: it exists some tool like https://fonttools.readthedocs.io/en/latest/ttLib/removeOverlaps.html for doing that.

[MDLC01]

I have already reported this issue to the font maintainer, and he told me it should be solved, but evidently it is not fully solved. If the font files are conformant to the OpenType specification, I feel like ideally the renderer would display it properly instead of every font author having to remove overlaps. Of course, I understand that this is easier said than done.

[calixteman]

A pdf viewer/renderer isn't supposed to be a font rasterizer. Honestly the bug isn't on the pdf.js or Acrobat or Chrome or Firefox side but it's an issue in DirectWrite. So if you've some super powers for convincing MS people to fix it, let's use them, else the easiest thing is to ask to the font dev. And last but not least, the cheapest fix is to fix the font !!

[MDLC01]

I'm sorry if my message came across as a bit agressive. I also did not know what DirectWrite was, so I did not realize that this was essentially an upstream issue.

I'll let you decide whether the issue should bee kept open anyway, but I understand that this can be considered out of scope for PDF.js.

[calixteman]

@MDLC01, I filed a bug in Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=2043684

[LaurenzV]

FWIW, Adobe Acrobat (on MacOS) also has this artifact at certain zoom levels. However, I believe this is strictly speaking not a bug. I think what's going on here is that those renderers, for some reason, they use the even-odd winding rule instead of non-zero for filling the glyphs in some situations. I saw this mentioned in a Github comment, but I can't find it anymore unfortunately. CFF fonts don't support overlaps (in which case EO vs. NZ doesn't matter), so I think this really just is a font bug.

[calixteman]

I think what's going on here is that those renderers, for some reason, they use the even-odd winding rule instead of non-zero for filling the glyphs in some situations

Yep, I think it's the right explanation.
As far as I know, it isn't really a bug since it isn't really specified. But having a different winding rule depending on the font size is a bit weird, and this discrepancy is probably a bug.
Again, I'm not super excited by the idea of checking all the glyphs in CFF fonts for whatever pdf because it'll add a perf penalty for everybody.
For me, the only acceptable thing we could do is to use our font renderer for a specific list of fonts, I'm not crazy about that but we already have some hard-coded font stuff for guessing a "good" font substitution when the font isn't embedded in the pdf.

I saw this mentioned in a Github comment, but I can't find it anymore unfortunately.

Maybe in: google/fonts#7594

[LaurenzV]

Nope, found it, it was harfbuzz/harfbuzz#4014 (comment)!