Open m4rc1e opened 4 years ago
Some precomposed marks are also shifted
Glyph: Uhungarumlaut | solid: Variable font Light Master | outline: Google Fonts Open Sans Light
Maybe instead of letting interpolations be the intermediate weights, I should make a master for each to make sure the glyph metrics are the same.
Re: marks, don't trust the marks in the Romans that are there. They will be fixed.
The issues I've mentioned are in the masters. Converting every instance to a master won't solve this.
Re: marks, don't trust the marks in the Romans that are there. They will be fixed.
I'm not diffing your hinted sources. This misalignment is in the .glyphs source.
Just a quick thought.
What if the original family wasn't built using multiple masters or they were used then hand tweaked afterwards?
If it wasn't an MM family to begin with, we'll never get a perfect match, unless we make every static font a master. Unfortunately, this will drastically increase the file size.
If it wasn't an MM family to begin with, we'll never get a perfect match, unless we make every static font a master. Unfortunately, this will drastically increase the file size.
This is the least exciting news I have ever heard.
You don't have to make every static font into its own master to make the VF match them; you can have "sparse" masters (called "brace layers" in Glyphs.app), i.e. intermediate masters for specific glyphs only (as opposed to an entire master font containing all the glyphs). These allow you more local control without adding unnecessary masters for the rest of the glyphs that interpolate just fine.
GlyphsLib can convert brace layers to equivalent UFO sparse layers. In the designspace document, sparse layers are source elements that reference the same UFO as regular master fonts but get the glyphs data from a non-default layer (these special source elements have a layer
attribute with the name of the layer where the intermediate glyph masters are stored in each source UFO).
The rest of the build pipeline understands these and will compile sparse interpolatable master TTFs (only containing the glyphs in these sparse masters), and varLib will produce deltas accordingly.
Each glyph in gvar may contain different sets of deltas, depending on the number of masters used as input. That's the beauty of VF.
I've just taken another look at the design work and unfortunately it's way too messy for me to sign it off.
Most diacritics are shifted in the Italics.
MM compatibility errors are still occurring. My diff images in #9 showed some of these.
@davelab6 we should outsource this to TN or an individual who can do this type of work. I'll still finalise the build this week.
I've done these checks on @laerm0 's latest commit https://github.com/laerm0/opensans/commit/c72ab81b6430554bc9680ec13b70b2a365dcab1a. I also checked the commit before I started working on the project 087d229276ac19b643b7e795a0d0299bbe0f3eed, just to make sure I hadn't introduced these regressions. All these issues are present in this commit as well.
Ugh. Some of these errors have been here for months. I don't know how they got introduced or how I didn't notice them. Marc's right, they're not his fault, they're all on me.
I've been working on this project for so long, I don't know if I can see the trees for the forest anymroe. I don't trust my eyes looking at it so a brand new person would be greatly appreciated.
If I compare the masters in https://github.com/laerm0/opensans/blob/master/source/OpenSans-Roman.glyphs against the fonts we currently serve, we can see they're different.
Outline in Blue is from the Bold Variable font instance. Outline in grey is from the Bold we currently serve on Google Fonts. No kerning present in either fonts.
It isn't just the outlines, the glyph's horizontal metrics also differ.
Bold metric differences
Light metric differences
Since both the Light and Bold masters have metric issues, the Regular is getting distorted to an unacceptable level.
Open Sans VF regular instance vs Open Sans Regular on Google Fonts
For a font which is requested ~27 billion times a week and served on 25 million+ sites, there shouldn't be any document reflow.