1794295 - Glitch in COLRv1 glyph rendering

Status: RESOLVED INVALID

(Core :: Graphics: Text, defect)

Description

[Khaled Hosny]

Attachment: Screenhost from Firefox 107

There is a glitch in rendering a glyph of a COLRv1 font, comopared to Google Chrome and FontGoggles.

Comment 1

[Khaled Hosny]

Attachment: Test file

Comment 2

[Khaled Hosny]

Attachment: Test font

Comment 3

[Khaled Hosny]

Attachment: Screenhost from Google Chrome

Comment 4

[Jonathan Kew [:jfkthame]]

This seems to be an issue with how Core Text handles the glyph outlines in the font -- maybe to do with Winding vs Even-Odd fill rules, or something like that. I modified the font to map character codes to the individual glyph elements, and notice that in both Safari and Firefox (which uses Core Text), the meem-ar.fina.0 and meem-ar.fina.1.1 glyphs render with the left-hand "tip" as a disjoint fragment, separated by a gap from the loop instead of joined by a continuous line. This is different from how Chrome (presumably using FreeType) renders it.

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: Safari (left) vs Chrome (right) rendering of the meem-ar.fina.0 glyph in isolation

Comment 6

[Jonathan Kew [:jfkthame]]

So Khaled, I'm guessing (without having analyzed the actual glyph paths properly) that you may need to do a "correct path directions" operation or something like that to ensure consistent rendering.

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: rendered with -webkit-text-stroke

Using -webkit-text-stroke, we can see that the glyph is composed of several subpaths, and apparently Core Text fails to render one of them when it fills the glyph. So that's the one to particularly check.

Comment 8

[Khaled Hosny]

Thanks Jonathan for the analysis, that was very helpful.

It wasn’t the path direction per se (or may be not only the path direction), but the fact that one of the subpaths was redundant as it was a subset of the other subpath is overlaid, so removing it fixed the rendering.

It is a CoreText not Firefox issue and there is an easy way to fix the font, so I think this issue should be closed.

Comment 9

[Jonathan Kew [:jfkthame]]

Ah, that explains it. Glad you were able to identify and fix the issue. Closing this as Invalid, as there's not a bug here for us to address in Firefox.

Incidentally, while I haven't confirmed what the OpenType/CFF spec has to say about this (I'm not sure if the Core Text rendering is a bug, or if the spec is unclear....?), I notice that the issue also appears even in Chrome Canary in the Print preview panel, and in saved PDF output. Maybe their print codepath also uses Core Text rendering rather than the bundled FreeType?

Comment 10

[Khaled Hosny]

It seems Chrome uses FreeType for COLRv1, and if I remove the color tables and try to show meem-ar.fina.0, I get the same issue as here.