Closed kcohar closed 2 years ago
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.
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.
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.
@dougfelt : thank you
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.
Since it is acceptable for Noto fonts to have different metrics, there is no bug here.
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
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"
}