font-patcher: Use correct source font metrics #593
Conversation
[why] With a source font where Win Ascent/Descent differs from Typo Ascend/Descent newly added symbols that are intended to be centered _within the visual space_ can end up too far up or down. The happens for example when patching CascadiaCode. Added glyphs like the Ubuntu logo (unicode 0xF31B) is not centered between the square brackets or on a line with the less then and other centered glyphs. [how] The calculation takes the Win Ascent/Descent to calculate the visual hight. That information is a mix of hight and line spacing and can be misleading. Therefore, if use_typo_metrics is set in a font, we obey that flag and use the typo metrics values instead. [note] Some websites with further information follow. https://github.com/googlefonts/gf-docs/tree/main/VerticalMetrics > Hhea metrics are used in Mac OS X, whilst Microsoft uses > Typo when Use_Typo_Metrics is enabled https://docs.microsoft.com/en-us/typography/opentype/otspec160/os2#fsselection https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6hhea.html Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
|
Because this PR can potentially break all patched fonts, we want to know which fonts are really patched differently. Here follows a complete list of all fonts where the PR changes the behavior, all other will run the same as before. (Positiv is after PR the midline is shifted up.)
#!/usr/bin/env python
# find . -name '*tf' -exec fontforge -quiet -script get_size {} \; 2>/dev/null
import sys
import fontforge
sourceFont = fontforge.open(sys.argv[1])
if sourceFont.os2_use_typo_metrics:
tya = sourceFont.os2_typoascent
tyd = sourceFont.os2_typodescent
osa = sourceFont.os2_winascent
osd = -sourceFont.os2_windescent
tysize = tya - tyd
ossize = osa - osd
tymiddle = tya - tysize / 2
osmiddle = osa - ossize / 2
if sourceFont.os2_use_typo_metrics and tymiddle != osmiddle:
sys.stdout.write("{:4.0f} -> {:4.0f} ({:4.0f}: {:3.0f}%) ".format(
osmiddle, tymiddle, tymiddle - osmiddle, (tymiddle - osmiddle) * 100 / osa))
sys.stdout.write(" on {}: {}\n".format(sys.argv[1], sourceFont.fullname))This limits the number of font faces to check from 700+ to 50. |
|
Next will come before/after images, which I will limit to
|
|
Here for all fonts one face shown. First 'original' directly from the All fonts shown with size 40 pt. Agave
Cascadia Code
Hermit
Inconsolata
Monofur
Overpass
|
|
Even more notable than having the round symbols etc really centered is the now-correct (i.e. working) Powerline Triangular Stuff. It was not apparent at Delugia, because there we base on |
|
Really thank you for this. I need a bit to unpack and understand to be honest 😆 ... though it looks like generally a great improvement with some thorough explanation and screenshots which i appreciate. Tempted to merge this in soon, will try to look in a day or 2 🤞🏻 |
|
Sorry that I've been unavailable. If anyone else can test this out that'd be great. Going to be digging into PRs again. |
|
I'm back merging again, I need to take some more time with this PR though 😄 |
|
I did some checking locally, most of these do end up looking better, e.g.:
I think Overpass (at least for my setup) looks better as the separators are no longer bleeding over but not quite vertically centered as they were for you: before
after
I also checked out Anyway I think this is an improvement for sure and also based on the info you provided these are the right metrics to use in these cases anyways. |
|
I guess all the fonts that leak out originally already, (where the two-dots of Overpass looks really bad in your screenshots (
|
|
Ah, here the test it all script, after patching with Why is the spiky branch thing ( Ah it's not in the {'Enabled': self.args.powerline,
'Name': "Powerline Symbols",
'Filename': "powerline-symbols/PowerlineSymbols.otf",
'Exact': True,
'SymStart': 0xE0A0, 'SymEnd': 0xE0A2, 'SrcStart': None, 'SrcEnd': None,
'ScaleGlyph': None,
'Attributes': SYM_ATTR_POWERLINE},
{'Enabled': self.args.powerline,
'Name': "Powerline Symbols",
'Filename': "powerline-symbols/PowerlineSymbols.otf",
'Exact': True,
'SymStart': 0xE0B0, 'SymEnd': 0xE0B3, 'SrcStart': None, 'SrcEnd': None,
'ScaleGlyph': None,
'Attributes': SYM_ATTR_POWERLINE},
def setup_patch_set(self):
""" Creates list of dicts to with instructions on copying glyphs from each symbol font into self.sourceFont """
# Supported params: overlap | careful
# Powerline dividers
SYM_ATTR_POWERLINE = {
'default': {'align': 'c', 'valign': 'c', 'stretch': 'pa', 'params': ''},
# Arrow tips
0xe0b0: {'align': 'l', 'valign': 'c', 'stretch': 'xy', 'params': {'overlap': 0.02}},
0xe0b1: {'align': 'l', 'valign': 'c', 'stretch': 'xy', 'params': {'overlap': 0.02}},
0xe0b2: {'align': 'r', 'valign': 'c', 'stretch': 'xy', 'params': {'overlap': 0.02}},
0xe0b3: {'align': 'r', 'valign': 'c', 'stretch': 'xy', 'params': {'overlap': 0.02}},
# ... and more entries with higer codepoints ... Maybe it should have a |
…-font-metrics font-patcher: Use correct source font metrics
Description
[why]
With a source font where Win Ascent/Descent differs from Typo
Ascend/Descent newly added symbols that are intended to be centered
within the visual space can end up too far up or down.
The happens for example when patching CascadiaCode. Added glyphs like
the Ubuntu logo (unicode 0xF31B) is not centered between the square
brackets or on a line with the less then and other centered glyphs.
[how]
The calculation takes the Win Ascent/Descent to calculate the visual
hight. That information is a mix of hight and line spacing and can be
misleading.
Therefore, if use_typo_metrics is set in a font, we obey that flag
and use the typo metrics values instead.
[note]
Some websites with further information follow.
https://github.com/googlefonts/gf-docs/tree/main/VerticalMetrics
https://docs.microsoft.com/en-us/typography/opentype/otspec160/os2#fsselection
https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6hhea.html
Requirements / Checklist
./font-patcher Inconsolata.otf --fontawesome --octicons --pomicons./gotta-patch-em-all-font-patcher\!.sh HermitHow should this be manually tested?
This need visual inspection of the generated fonts. Only some fonts are affected, I will give a list of these in a comment below (with a script that creates that list).
Any background context you can provide?
This came up as Issue adam7/delugia-code#53 at
Delugia Code, where we usefont-patcheralso to patchCascadia Code, but with some (few) specialties. That repo stems from the time whenCascadia Codewas not part ofNerd Fontsand is (almost) obsolete now (except for the added specialties).What are the relevant tickets (if any)?
#592
Screenshots (if appropriate or helpful)
Screenshots will follow as comments after the 'affected fonts' list.