Scaling inconsistency between text and glyphs #1056
Comments
|
Sorry to hear that. Can see the differences...
|
|
Thanks for reporting. And thanks for a complete report with all the details I need to reproduce 👍 |
|
|
|
Oh man, do I hate the metrics inconsistencies 😒 And whats this |
|
On my machine with
When I can see it, it should be 'easy' to fix. |
|
I think I found the reason. Introduced a gap-redistribution with #943 Rewriting the gap stuff right now. Thanks again for reporting! Useful links
In |
|
Systematic examination of all source fonts regarding vertical metrics, one file of each font chosen at random.
Most crucial is that WIN does use the other gaps?! See https://learn.microsoft.com/en-us/typography/opentype/spec/recom#baseline-to-baseline-distances |
|
I will combine this with #1055 |
Finii
changed the title
[why] The initial font-patcher used the WIN font metrics to determine the cell height. What has been found was forced into HHEA metrics but without observing the USE_TYPO_METRICS flag. That has been changed to use the TYPO metric instead of the WIN metric when the font wants that. For that the gap value becomes important. This is the current code. It still has problems to detect the correct cell height. A more rigorous approach seem to be needed. [how] The baseline to baseline distance is what we need as 'cell height', to fill it completely with the powerline glyphs. This is a little bit complicated and not really specified, each font rendering application or engine can handle the font metrics differently. But there are some common approaches. So we try to come up with the correct and congruent height, comparing different metrics and issuing a warning on problematic fonts. Afterwards we make all metrics equal (even if they were not before), because our goal is clear now and we impose it onto all platforms. [note] Useful resources: * https://glyphsapp.com/learn/vertical-metrics * https://github.com/source-foundry/font-line Fixes: #1056 Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why] The initial font-patcher used the WIN font metrics to determine the cell height. What has been found was forced into HHEA metrics but without observing the USE_TYPO_METRICS flag. That has been changed to use the TYPO metric instead of the WIN metric when the font wants that. For that the gap value becomes important. This is the current code. It still has problems to detect the correct cell height. A more rigorous approach seem to be needed. [how] The baseline to baseline distance is what we need as 'cell height', to fill it completely with the powerline glyphs. This is a little bit complicated and not really specified, each font rendering application or engine can handle the font metrics differently. But there are some common approaches. So we try to come up with the correct and congruent height, comparing different metrics and issuing a warning on problematic fonts. Afterwards we make all metrics equal (even if they were not before), because our goal is clear now and we impose it onto all platforms. [note] Useful resources: * https://glyphsapp.com/learn/vertical-metrics * https://github.com/source-foundry/font-line Fixes: #1056 Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
|
Problematic cases:
[1] Mismatch detected, chooses TYPO All looks ok, except Lekton, the only font that selects TYPO. |
[why] When HHEA and (depending on USE-TYPO-METRIC) TYPO or WIN are not consistent it is unclear which metric we should trust. In #1056 the complete font bounding box (i.e. yMin and yMax) has been compared to the baseline to baseline distances, and in all these cases the WIN values seem to be best (preserve the glyph bounding box). font-line report fontname.ttf | grep metrics: ttfdump -t head fontname.ttf | grep "yM(in|ax)" [note] Roboto will still be clipped?! There seem to be ridiculously high glyphs in there. Did not check which. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why] When HHEA and (depending on USE-TYPO-METRIC) TYPO or WIN are not consistent it is unclear which metric we should trust. In #1056 the complete font bounding box (i.e. yMin and yMax) has been compared to the baseline to baseline distances, and in all these cases the WIN values seem to be best (preserve the glyph bounding box). font-line report fontname.ttf | grep metrics: ttfdump -t head fontname.ttf | grep "yM(in|ax)" [note] Roboto will still be clipped?! There seem to be ridiculously high glyphs in there. Did not check which. Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
|
Sorry, to ask this here but I cannot find what I want ... @dstoliker Where/What is these glyphs (the ones right in the line begining)?
|
|
This rounded line? At
|
|
While doing
Lets have a look at the table from above:
Lekton was the only font that selected TYPO but we forced it to WIN, because not all glyphs fit into the values from TYPO. |
This reverts commit 6210087, and adapts the code to more recent changes (logging, enums). [why] Lekton has a too wide line spacing. Lekton was the only font that selected TYPO but we forced it to WIN, because not all glyphs fit into the values from TYPO. But that seems to be wrong. Examining the glyphs that are really bigger than the TYPO line spaces, these are only graphical glyphs that shall span multiple lines. So I guess we should revert that change and render Lekton with the TYPO values. [note] #1056 (comment)
|
This issue has been automatically locked since there has not been any recent activity (i.e. last half year) after it was closed. It helps our maintainers focus on the active issues. If you have found a problem that seems similar, please open a new issue, complete the issue template with all the details necessary to reproduce, and mention this issue as reference. |
[why] The initial font-patcher used the WIN font metrics to determine the cell height. What has been found was forced into HHEA metrics but without observing the USE_TYPO_METRICS flag. That has been changed to use the TYPO metric instead of the WIN metric when the font wants that. For that the gap value becomes important. This is the current code. It still has problems to detect the correct cell height. A more rigorous approach seem to be needed. [how] The baseline to baseline distance is what we need as 'cell height', to fill it completely with the powerline glyphs. This is a little bit complicated and not really specified, each font rendering application or engine can handle the font metrics differently. But there are some common approaches. So we try to come up with the correct and congruent height, comparing different metrics and issuing a warning on problematic fonts. Afterwards we make all metrics equal (even if they were not before), because our goal is clear now and we impose it onto all platforms. [note] Useful resources: * https://glyphsapp.com/learn/vertical-metrics * https://github.com/source-foundry/font-line Fixes: ryanoasis#1056 Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
🗹 Requirements
🎯 Subject of the issue
Experienced behavior:
After upgrading to the latest version of the Hack nerd font via homebrew, there is an an apparent inconsistency between text and glyph scaling. I have a command line prompt configured with Oh My Posh with powerline symbols. After upgrading my font to the latest version, the glyphs no longer line up vertically. The glyphs are now taller. See screenshots below.
Expected behavior:
Text and glyphs should align as they did before the upgrade.
Example symbols:
\ue0b6
\ue0b4
🔧 Your Setup
Anonymice Powerline Nerd Font Complete.ttf)?iterm2,urxvt,gnome,konsole)?★ Screenshots (Optional)
Powerline bar as it appeared before font package upgrade:
After upgrade:
iTerm2 font settings:
The text was updated successfully, but these errors were encountered: