googlefonts / opensans

Open Sans font
Other
212 stars 31 forks source link

Masters are not accurate enough #15

Open m4rc1e opened 4 years ago

m4rc1e commented 4 years ago

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.

Screenshot 2019-07-30 at 11 41 10

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

Upsilontonos 1278.0 1565.0
uni1F4D 1630.0 1712.0
threequarters 1822.0 1804.0
uni0485 0.0 1182.0
Iotatonos 678.0 1049.0
uni0486 0.0 1182.0
uni0512 1526.0 1675.0
Omicrontonos 1630.0 1712.0
uni0513 1321.0 1483.0
IJ 1356.0 1475.0
onehalf 1822.0 1804.0
seveneighths 1822.0 1804.0
circumflex 869.0 1243.0
napostrophe 1606.0 1595.0
uni0483 0.0 1141.0
uni0484 0.0 1182.0
oneeighth 1822.0 1804.0
macron 600.0 1243.0
onequarter 1822.0 1804.0
threeeighths 1822.0 1804.0
equal 1162.0 1169.0
uni0478 2743.0 2701.0
uni0479 2433.0 2345.0
Etatonos 1567.0 1710.0
CR 532.0 1044.0
ij 1250.0 1210.0
fiveeighths 1822.0 1804.0
Epsilontonos 1147.0 1290.0
uni0511 1137.0 1139.0
uni04FC 1366.0 1499.0
uni04FD 1184.0 1321.0
uni04F9 1882.0 1741.0

Light metric differences

uni03D2 1104.0 1081.0
uni03D1 1208.0 1238.0
Upsilontonos 1321.0 1081.0
uni03D6 1587.0 1594.0
uni1F4D 1632.0 1565.0
dotaccent 483.0 389.0
threequarters 1516.0 1592.0
uni0485 1182.0 0.0
Iotatonos 602.0 516.0
uni0486 1182.0 0.0
uni0462 1378.0 1345.0
Omicrontonos 1577.0 1565.0
cedilla 420.0 445.0
hungarumlaut 1182.0 1162.0
uni0463 1241.0 1195.0
ring 1182.0 4.0
tonos 1182.0 1123.0
onehalf 1516.0 1592.0
grave 1182.0 9.0
seveneighths 1516.0 1592.0
circumflex 1182.0 582.0
uni0483 1141.0 0.0
uni0484 1182.0 0.0
oneeighth 1516.0 1592.0
uni0489 1958.0 1989.0
uni0488 2025.0 2024.0
macron 1141.0 52.0
onequarter 1516.0 1592.0
threeeighths 1516.0 1592.0
uni02BC 297.0 310.0
uni0472 1565.0 1551.0
uni0473 1200.0 1166.0
uni0474 1210.0 1267.0
uni0475 973.0 1000.0
uni0476 1210.0 1267.0
uni0477 973.0 1000.0
uni0478 2335.0 2337.0
uni0479 2093.0 2140.0
Etatonos 1563.0 1473.0
breve 1182.0 56.0
CR 1044.0 532.0
ij 926.0 889.0
fiveeighths 1516.0 1592.0
Epsilontonos 1221.0 1130.0
uni04E8 1565.0 1551.0
uni04E9 1200.0 1166.0
tilde 1182.0 93.0
uni04BB 1167.0 1208.0
acute 1182.0 9.0
uni01F0 463.0 426.0
uni04EB 1200.0 1166.0
uni04EA 1565.0 1551.0
jcircumflex 463.0 426.0
caron 1182.0 582.0
Omegatonos 1608.0 1587.0
dieresistonos 1182.0 1133.0
uni04FC 1192.0 1102.0
uni04FD 1036.0 1020.0
fraction 246.0 216.0
dieresis 1182.0 1266.0
uni04F9 1481.0 1628.0
j 463.0 426.0
ogonek 356.0 8.0
cyrillichookleft 418.0 348.0

Since both the Light and Bold masters have metric issues, the Regular is getting distorted to an unacceptable level.

opensans-overflow

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.

m4rc1e commented 4 years ago

Some precomposed marks are also shifted

Screenshot 2019-07-30 at 12 32 12

Glyph: Uhungarumlaut | solid: Variable font Light Master | outline: Google Fonts Open Sans Light

laerm0 commented 4 years ago

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.

m4rc1e commented 4 years ago

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.

m4rc1e commented 4 years ago

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.

laerm0 commented 4 years ago

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.

anthrotype commented 4 years ago

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.

m4rc1e commented 4 years ago

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.

italic_shift1

Screenshot 2019-10-02 at 10 35 30

MM compatibility errors are still occurring. My diff images in #9 showed some of these.

Screenshot 2019-10-02 at 10 27 06 Screenshot 2019-10-02 at 10 29 28

@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.

laerm0 commented 4 years ago

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.

laerm0 commented 4 years ago

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.