Kerning

[m4rc1e]

The original Open Sans has a kern table (not GPOS).

Should we use a kern table or use GPOS kerns?

I'm guessing old ms apps/browsers don't like gpos kerning?

Easiest approach is to just use the old kern table.

The family is loaded 30 billion times a week so it may be best to do this.

[laerm0]

[late reply]

We can use the old kern table but the issue is that we'll have to import it into the TTFs as it has too many pairs for Glyphs to export.

I vote we ship the standard version with the kern tables imported in to the TTFs and then do GPOS kerning on the variable font.

[m4rc1e]

@laerm0 interestingly on OS X, Safari will use the font's kern table

While Chrome doesn't.

[laerm0]

facepalm dot gif

Update while I am here: Kernschmelze is producing some good stuff for the new weights, so this is coming along well.

[davelab6]

I thought we had a fontbakery test for KERN tables; they should always be included in all GF fonts, because the API strips them out, but many desktop apps still rely on them - which is to say, GPOS-only fonts are rendered without kerning in a lot of places, still

[davelab6]

Should we use a kern table or use GPOS kerns?

Both.

Class kerning should be set up in Glyphs, and then both GPOS and KERN kerning exported.

[m4rc1e]

@davelab6 Glyphsapp removes the kern table but gens a gpos kern feat instead.

We have this check in FB https://github.com/googlefonts/fontbakery/blob/master/Lib/fontbakery/specifications/kern.py#L9-L45 which needs improving.

[davelab6]

Glyphsapp removes the kern table

Per https://github.com/googlefonts/fontbakery/issues/1949#issuecomment-403870671 this is configurable; since Open Sans is used so widely, it should not drop the KERN table and stop being kerned in the many places that rely on that table.

[davelab6]

@laerm0 please confirm the state of the kerning in the latest VF