Unicode character U+2262 ("not identical to") is not drawn correctly

[jubajube]

I've chased this bug upstream 3 "upstream hops" now and hoping you guys can help me get to the root of it. I first noticed the problem in VSCode and Discord, and reported it there:

VSCode: microsoft/vscode#53816

Both VSCode and Discord said it was an Electron issue, so I opened one there:

Electron: electron/electron#13582

Electron folks said it was a Chromium issue, now 2 years old:

Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=645723&q=U%2B2262&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

If I understand the comments in the Chromium issue correctly, they're pointing the finger at HarfBuzz and/or specific font(s). I'm not exactly sure though. I know nothing about HarfBuzz and fonts. However, you guys do, so maybe you'd be interested in seeing/fixing this bug?

Expected Behavior
This Unicode code point "Not Identical To", or U+2262 (≢) should appear as a triple horizontal bar with a slash through the middle.

Actual behavior
On both VSCode 1.25.0 and Discord "Release Channel: stable, Build Number: 18280, Version Hash: 9fed7c903d2a5cd3fba8e16b269ed4b1f48c159f", the slash is drawn off the right-hand side of the triple-bar instead.

VSCode:

Discord:

To Reproduce
Copy single code point U+2262 (≢) and paste into any open editor window in VS Code, or chat in Discord.

[davidcarlisle]

It seems that U+2262 is being (always) rendered as the decomposed U+2261 U+0338 then whether that works or not is font-specific (presumably? depending on the implementation of the combining slash). With xetex I get \documentclass{article} \usepackage{fontspec} %\setmainfont{Arial}% bad \setmainfont{Consolas}% bad %\setmainfont{STIX Two Math}% good %\setmainfont{Latin Modern Math}% good %\setmainfont{TeX Gyre Termes Math}% good \begin{document} [≢] U+2262 [≢] U+2261 U+0338 \end{document} so most math fonts U+2262 and the combining version with U+0338 works, but I couldn't find any text font I had to hand where this rendered correctly.

[jfkthame]

As far as I can see, neither Arial nor Consolas (at least the versions I happen to have on hand) supports U+2262; that's why harfbuzz decomposes the character, and the result is then dependent on the font's support (or lack of it) for properly positioning the combining slash.

I don't think there's a harfbuzz bug here, just lack of font support. The solution is to use a better font.

[khaledhosny]

Maybe we should skip decompositions involving U+0338 since it will almost always be poorly supported in fonts? But it is still a font bug, since U+2262 and U+2261 U+0338 are canonically equivalent and should render the same.

[jfkthame]

We only decompose if the original character isn't found, right? In which case skipping the decomposition would just result in tofu (.notdef), which isn't much of an improvement. At least with the decomposition, the user can probably tell what was intended, even if it's ugly.

[khaledhosny]

Yes, we will output tofu, but then applications like Chrome will catch this and use a fallback font, which I believe is similar to what happens in Firefox already as it will check the font’s cmap table for U+0338 and use a fallback font since it is missing from the font.

[khaledhosny]

I forgot about XeTeX, it does not do font fallback and well be left worse off indeed.

[behdad]

Leaning on closing. We cannot put hacks for every character that is not properly supported in common fonts.

[davidcarlisle]

No objection to closing from me. Sorry I should have noticed that the decomposition was just if U+2262 wasn't in the font.

[davidcarlisle]

@jubajube to sum up, it is essentially a font issue, not an issue with the applications you cited or with harfbuzz. Basically you need, for the code editor, a monospace font that has a U+2262 glyph. These are not that easy to find but DejaVu Sans Mono is free and seems to work fine, here is an image of visual studio code editor:

(note I'm just passing by, not connected with harfbuzz development in any way :)

[jubajube]

@davidcarlisle Thanks, I will try that out! I really appreciate the recommendation of a better font.

I get the gist of the root cause now. I still don't think it's right to draw the glyph if the font doesn't support it. I think it would be better to draw a replacement glyph instead (such as what a UTF-8 decoder would do in the event of a coding error: show as replacement character U+FFFD, '�').

@khaledhosny you say it's a font bug. Is there a way to report the bug to the maintainer of the font? Come to think of it, is there a maintainer of the font in the first place? Just curious if you know if there might be a way to let the developer(s) (or is artist(s)?) of the font know about the issue.

I'm willing to accept it if a majority of people consider this a relatively unimportant or pedantic issue. I guess I just thought it would be an easy fix (like fix some typo in a font metric somewhere) and got a bit frustrated when my bug reports were being dismissed seemingly out of hand.

[khaledhosny]

You probably need to contact Microsoft somehow for these font bugs.

[abrudz]

I have understood that both Blink and Gecko use HarfBuzz, so how comes Chrome ends up with a composition that fails while Firefox ends up falling back to a different font?

[khaledhosny]

Chrome shapes with HarfBuzz first, and if the output includes unsupported glyphs it tries fallback fonts. While Firefox checks the fonts first before shaping and uses fallback font from the start.

Both approaches has its pros and cons, but IMO Chrome approach tends to give better results in general.