search

notofonts / latin-greek-cyrillic

Noto Latin, Greek, Cyrillic
SIL Open Font License 1.1
39 stars 8 forks source link

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

Closed trbabb closed 1 week ago

trbabb commented 11 months ago

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:

image

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

image

Font

Where the font came from, and when

Font Version

Application name and version

Character data

Harfbuzz hb-view and hb-shape

curya commented 11 months ago

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 commented 11 months ago

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 commented 10 months ago

@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 commented 10 months ago

Noto Sans Mono has ≠, Noto Sans does not.

curya commented 10 months ago

@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 commented 10 months ago

Mathematical Symbols can be found in Noto Sans Math.

simoncozens commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 6 months ago

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 commented 6 months ago