Descent of Noto Sans Symbols2 does not match that of Noto Sans

[kcohar]

Descent of Noto Sans Symbols 2 does not match that of Noto Sans

Font

NotoSansSymbols2-Regular.ttf

Where the font came from, and when

https://www.google.com/get/noto/ Also: standard versions of the Noto Sans fonts included in KDE neon and Arch Linux.

Font Version

git master

OS name and version

Arch Linux (latest), KDE neon (latest)

Application name and version

While using a QML TextField - the TextField gets taller to accommodate the disparity in font descent, see https://bugs.kde.org/show_bug.cgi?id=399155.

Issue

The descent of Noto Sans Symbols2 (7) doesn't seem to match that of Noto Sans (4). The disparity in descent (height) causes the TextField to artificially increase in height while entering a password because it switches from Noto Sans to Noto Sans Symbols2. A PlasmaComponents 3 TextField doesn't change its height, it just truncates the glyphs above and below, see https://phabricator.kde.org/file/data/x75du5yanhince3tbuy4/PHID-FILE-q7ao2tbeicsq6s3q62k7/image.png

1. Steps to Reproduce: Install kde neon and try entering your chosen password OR execute the following QML file in qmlscene (and KDE/Plasma)

import QtQuick 2.0 import QtQuick.Layouts 1.2 import org.kde.plasma.components 2.0 as PlasmaComponents

Rectangle { width: passwordBox.width + 4 height: passwordBox.height + 4 color: "gray"

PlasmaComponents.TextField {
    id: passwordBox
    revealPasswordButtonShown: true
    echoMode: TextInput.Password
    Layout.fillWidth: true
    font.family: "Noto Sans"
}

}

first with "Noto Sans" as the font.family and then with "Noto Sans Symbols2" as the family and observe the difference.

  2. Observed result: If "Noto Sans Symbols2" is used, the password field is taller than if "Noto Sans" is used. If it's a KDE neon setup, and Noto Sans is used, it switches to Noto Sans Symbols2 upon typing and the field becomes bigger all of a sudden.

  3. Expected result: The TextField height is constant. The height of the characters is always the same, regardless of whether Noto Sans or Noto Sans Symbols2 is used.

### Screenshot
https://phabricator.kde.org/file/data/pntw6ry5omyp6ec6omue/PHID-FILE-2aisfcd3rvjzkrikggbt/gets_taller.webm
also (in a PlasmaComponents 3 TextField)
![image](https://user-images.githubusercontent.com/47360019/53977395-3a4ac300-4109-11e9-8b43-e9cb404b1867.png)

[dougfelt]

At some level this is unavoidable. Noto covers all scripts in Unicode, and some of these (in particular, symbols) have different preferred metrics. So individual Noto fonts are allowed to have different height metrics. Code that assumes metrics for LGC will work for all of Noto are going to have this problem.

Probably the quickest fix is to use the bullet from the LGC font, U+2022.

[Pointedstick]

At some level this is unavoidable. Noto covers all scripts in Unicode, and some of these (in particular, symbols) have different preferred metrics. So individual Noto fonts are allowed to have different height metrics.

It may be allowed, but is there any particular reason for it? What problem does it solve? As we can see, it causes this problem when used as a fallback for another Noto font.

Probably the quickest fix is to use the bullet from the LGC font, U+2022.

That's definitely an alternative avenue we're investigating, yeah.

[dougfelt]

The problem it solves is the problem you are seeing. No one set of metrics is going to work for all the characters in Unicode. You're seeing a problem where the Latin metrics, which the code in the Konqi screenshot appears to be picking up and using to size this display, are too small for this font. There are glyphs in Symbols2 that do in fact use the full descent that this font provides, that's why it has the value it does. Those symbols would get clipped if we changed the metrics. The alternative is a 'shrink to fit' approach where we squeeze glyphs into metrics too small for them, basically as though they were in a smaller font. That's bad for those symbols, they are no longer sized correctly.

So we divide glyphs into groups, assign groups to fonts using a number of criteria, then pick metrics that generally work for each font given the sizes of the glyphs in that font. Code that sees these as separate fonts, and is prepared to deal with different ascent/descent metrics, handles this ok. Code that sees these as a single 'composite' font, and picks the metrics of one of these fonts to use for all of them regardless of what subfonts get used, doesn't do so well. Some do somewhat better than others. For example, in the QML example, it knows it needs to get larger to accommodate the font that actually gets used, but apparently doesn't let you presize the field based on the fonts needed by the text you expect to render, so did so incorrectly. It looks like it picked a default font for the empty string, most likely the Latin font, and used its metrics, which why the initial size was different from the size it determined once there was text there.

[marekjez86]

@dougfelt : thank you

[tuberry]

Can confirm this in Arch / Gnome Shell 3.38. It's 🏎 [U+1F3CE RACING CAR] from Noto Sans Symbols2 in the gif. I have to block it in fontconfig because of Arch's packaging granularity.

[SKing-2003]

Since it is acceptable for Noto fonts to have different metrics, there is no bug here.