New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Descent of Noto Sans Symbols2 does not match that of Noto Sans #18
Comments
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. |
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.
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 |
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
first with "Noto Sans" as the font.family and then with "Noto Sans Symbols2" as the family and observe the difference.
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.
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)
The text was updated successfully, but these errors were encountered: