search

googlefonts / science-gothic

Science Gothic, a libre variable font
Other
143 stars 4 forks source link

Slanted glyph horizontal offset problems #211

Closed tphinney closed 4 years ago

tphinney commented 4 years ago

Glyphs which have a Glyph Construction Syntax vertical offset are fine in the upright. But in the oblique (slant) masters, when they get shifted vertically, they do not also get slid along at a 10° angle from vertical, it is a pure vertical shift. So they go out of position horizontally, relative to their slant angle. If the vertical shift is small, the position problem is quite small. But for some cases, it is substantial.

The amount of shift needed is a trigonometric function: shift = V x (tan 10°) where V = the vertical shift. And of course 10° because that is our slant angle.

Severe problems: /exclamdown /questiondown /questiondown.case many .smcp punctuation alts, and especially all .numr .sinf and .sups glyphs (.dnom are fine, they were the base glyphs before vertical movement to create the others)

Check for slight problems?: /parenleft.case /parenright.case /bracketleft.case /bracketright.case /braceleft.case /braceright.case /slash.case /backslash.case

tphinney commented 4 years ago

This might be a FontLab bug in their Glyph Construction Syntax (GCS) implementation. When should it apply the inherited metrics? Obviously, it is doing so BEFORE the vertical shift. The vertical shift, which is part of the recipe. But arguably it should be doing so AFTER.

At least, if FL did it after, it would solve our problem. And I do not immediately see any advantage to applying the horizontal metrics before the vertical shift.

BUT, that also relies on slanted sidebearings being in play. And GCS was developed for environments that do not have slanted sidebearings, so FL cannot make their GCS implementation slanted-sidebearings aware, without breaking compatibility with other GCS implementations. :(

tphinney commented 4 years ago

We could just add an offset of (tan 10°) × yshift. Since yshift is constant for each set of glyphs, across all the masters, that is just three constants, one for each:

numr: 614 ... 108 sinf: -300 ... -53 sups (and hardcoded superiors): 950 ... 168

tphinney commented 4 years ago

What is odd is, why do some glyphs, in some-but-not-all transforms, get the correct sidebearings, already? /zero.numr /one.numr /zero.sups — but not /zero.sinf /one.sups /one.sinf

kateliev commented 4 years ago

@tphinney i examined the problem. No rocket-science needed - manually linking the metrics to parents does the job! It seems that auto-layers inherit their metrics from their parents, but do not accomodate for slanted metrics. For them to work one must bind/link them (=). Who knows it might be FL bug. Nevertheless the solution works like charm...