Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Rewrite font height calculation #1060

Merged
merged 4 commits into from
Jan 22, 2023
Merged

Rewrite font height calculation #1060

merged 4 commits into from
Jan 22, 2023

Commits on Jan 22, 2023

  1. font-patcher: Use format for output 

    Signed-off-by: Fini Jastrow <[email protected]>
    @Finii
    Finii committed Jan 22, 2023
    Configuration menu
    Copy the full SHA
    5cc911e View commit details
    Browse the repository at this point in the history

  2. font-patcher: Handle -l option in all metrics 

    [why]
The -l option tries to improve (especially) the powerline glyphs by
making the baseline to baseline height (cell height) an even number.
But it does so only for 2 of the three possible metrics.

[how]
Assuming the hight is identical for all metrics we just need to add '1'
to all ascender values.

[note]
I'm not sure this does anything. After rounding an odd height might
create a 'sharper' triangle tip, not an even height?
Do not understand the real reason for the -l option.

Signed-off-by: Fini Jastrow <[email protected]>
    @Finii
    Finii committed Jan 22, 2023
    Configuration menu
    Copy the full SHA
    ce6c161 View commit details
    Browse the repository at this point in the history

  3. font-patcher: Rewrite font height calculation 

    [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 <[email protected]>
    @Finii
    Finii committed Jan 22, 2023
    Configuration menu
    Copy the full SHA
    04c682f View commit details
    Browse the repository at this point in the history

  4. font-patcher: Use WIN metrics in all conflicting cases 

    [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 <[email protected]>
    @Finii
    Finii committed Jan 22, 2023
    Configuration menu
    Copy the full SHA
    6210087 View commit details
    Browse the repository at this point in the history