Matthew Flaschen
2014-09-06 03:58:05 UTC
The font forge importation workflow was sticky enough (importing svgs
and mapping them, etc) that small visual tweaks (baseline offsets and
such) ended up being made in the font forge project itself as well,
thus diverging from the source svgs.
This is why automation and having a clear understanding of what theand mapping them, etc) that small visual tweaks (baseline offsets and
such) ended up being made in the font forge project itself as well,
thus diverging from the source svgs.
source code is are both so important.
I think this workflow stickiness was what led the designer to see the
font forge project as canonical.
Actually, it was somewhat ambiguous what the source code is. Readfont forge project as canonical.
https://gerrit.wikimedia.org/r/#/c/137888/ if you want to know what I mean.
One automates creating a font from a folder of svgs. Svgs are
canonical as they should be, but hey, you want a font? You got it.
Great. This will be useful for the app, and if we ever decide tocanonical as they should be, but hey, you want a font? You got it.
revisit the decision about icons on web (I completely agree SVG is
better as source code, but we could still use generated fonts on desktop
if we decided that approach was suitable).
Matt Flaschen