Noto Sans renders "not equal to" glyph (≠) incorrectly

[trbabb]

Summary

In all styles of Noto-Sans-*.ttf I've checked, the "not equal to" glyph (≠) is rendered incorrectly: It looks as though the glyph is composed of an "equals sign" glyph with a slash overlaid, but the slash is offset and misaligned. I first found this when using Harfbuzz to typeset, but it can be seen in Google's own "specimen" previewer:

This does not seem to be the rendering for other Noto fonts, like Noto Japanese:

Font

• NotoSans-Light.ttf

Where the font came from, and when

• Site: Google Fonts
• Date: 2023-10-14

Font Version

• 2.007

Application name and version

• Found in Harfbuzz results, but also viewable in the Google Fonts preview page. Haven't checked elsewhere.

Character data

• ≠

Harfbuzz hb-view and hb-shape

• hb-shape --font-file NotoSans-Light.ttf --text="≠"
• hb-view --font-file NotoSans-Light.ttf --text="≠"

[curya]

To add to this, I can't even type it in Photoshop/Illustrator. It literally switches fonts when I try to copy and paste.

[khaledhosny]

That is because the font does not have ≠ but has = and ̸, which are canonically equivalent, so Chrome uses them instead of falling back to ad different font. The font should either support ≠, or make = and ̸ render correctly.

[curya]

@khaledhosny Why does ≠ work perfectly fine in Noto Sans Mono?

This issue seems to have turned into a request. It seems to me that Noto Sans should support the ≠ glyph if Noto Sans Mono supports it...

[khaledhosny]

Noto Sans Mono has ≠, Noto Sans does not.

[curya]

@khaledhosny I think I worded my question a little awkwardly. I meant to say: Why does Noto Sans Mono have ≠ and Noto Sans does not?

But I guess the answer doesn't really matter. The main point I was making was that Noto Sans would benefit from having ≠.

[vk-github18]

Mathematical Symbols can be found in Noto Sans Math.

[simoncozens]

The problem is that the question of which glyphs "belong" in Noto Sans (and Noto Sans Mono) is not well defined. The purpose of Noto is to have a set of fallback fonts given which there will be No Tofu (i.e. all Unicode codepoints are covered). But that doesn't tell you much about what goes into each font, let alone where you have stylistic variants like Serif and Mono; the problem comes when people try to use these fonts as standalone fonts, rather than as part of a library. (Which of course we have rather encouraged by creating Serif and Mono variants.)

Clearly there's no obviously correct "end point" to Noto Sans Mono; ideally we'd like a monospaced version of all codepoints, but we're not going to get that, certainly not in one font. And so the question of which codepoints should be covered in Noto Sans Mono isn't an obvious one. Should it be "everything that's in Noto Sans LGC"? Probably. Should it be "everything that's in Noto Sans LGC + Noto Math + Noto Symbols"? Definitely not. So at some point you have to make a judgment call. "Why does Noto Sans Mono have ≠ and Noto Sans does not?" Basically, the answer is "Why not?"

[trbabb]

It isn't just Noto Sans Mono that has ≠, see e.g. the original example of Noto Sans Japanese, which was just one of the first ones I checked. This seems relevant because it leads me to believe this may simply be an oversight and not a deliberate decision to omit the glyph.

If the question is whether ≠ is 'notable' enough to include, you may find it relevant that the symbol can be typed without special codes on an ordinary mac computer / keyboard (opt + =).

If it's just an oversight, would it make sense to simply include it in the next revision?

[simoncozens]

Other way around. There's a good reason why ≠ is not in Noto Sans - we already have Unicode coverage for that in Noto Math, so there is no need to put it in Noto Sans LGC as well. (Noto Sans is intended to be used in the context of a fallback stack, not as an independent font.)

There's not really a good reason why we have ≠ in Noto Sans Mono, that's just a bonus...

[khaledhosny]

I think the practical argument here would be is that since ≠ decomposes to = and ̸ and both are in Noto Sans, it makes since to also include ≠, since the presence of the last two characters prevents Chrome (and potentially any other application that does shaping-driven font fallback) from falling back to a different font for ≠.

[prakashDiana]

That is because the font does not have ≠ but has = and ̸, which are canonically equivalent, so browsers like Chrome, Edge, etc. use them instead of falling back to ad different font, while Firefox doesn't use canonical decompositions. The font should either support ≠, or make = and ̸ render correctly.

[prakashDiana]

• notequal
• lessequal
• greaterequal
• lozenge
• fi
• fl