Support for web fonts

[chrissimpkins]

Need to explore the fontTools library support.

Will need to take into account that line spacing may be handled differently in the browser setting, perhaps modify the approach with these file types. From Tim Brown in TypeKit blog comment:

Happy to share this info, although it’s not super interesting for most people. We’re constantly learning, but here’s what we know right now: Windows browsers use Win metrics, Mac browsers use hhea metrics, and Firefox on Linux uses Typo metrics unless the hhea values are greater. Win and hhea metrics must match, including an hhea linegap of zero. Typo linegap has to be zero too, or lines of text are spaced unpredictably across browsers.

The specific values to which metrics should be changed are unique to each font file. Our internal tools for foundry partners make recommendations based on the conditions I just mentioned, and also based on the maximum ascent/descent of glyphs in the font file.

Note TypoLineGap has to be zero comment.

[chrissimpkins]

@davelab6: Do any of your Python libraries permit direct modification of woff, woff2, and eot vertical metrics? It doesn't look like we will be able to support this with fontTools from what I can gather. It seems that support for svg has/is very actively fading and many people are dropping these so I didn't intend to support them.

[chrissimpkins]

From @davelab6 in #2 (comment):

no fonts distributed for download and desktop use by Google Fonts are different to those served to web browsers.

From @davelab6 in #2 (comment)

the conclusion is that each of the 3 sets of ascent/decent values should be the same, the ymax and ymin of the family, and both linegaps should be zero.

[chrissimpkins]

From @kenlunde in #2 (comment):

Someone else at Adobe can correct me if I am wrong, but we prefer to have uniform vertical metrics for web and desktop use.

[davelab6]

Do any of your Python libraries permit direct modification of woff, woff2, and eot vertical metrics?

I don't understand; these are just compression wrappers, like ZIP. There are, I think, pure python woff and woff2 libraries around, but perhaps not eot. But EOT is now pretty much not needed, along with SVG fonts.

[chrissimpkins]

@davelab6 Thanks Dave. That answers the question. I didn't know if anyone was working directly on these files. Based upon that comment, I gather that all work is done on the ttf or otf file prior to conversion. I am trying to decide how to handle web font metrics support here.

[davelab6]

I am trying to decide how to handle web font metrics support here

It seems clear from what Ken and I wrote that in 2016, web fonts metrics are used universally, ie for desktop fonts too.

[chrissimpkins]

@davelab6 agree. didn't mean how to handle them differently, meant whether to support direct modifications to Web font files in cases where a user wants to alter these values (including myself in our own releases). It sounds as though this is not necessary if all post build mods occur in the otf or ttf and then the compression methods are used to generate Web fonts. Didn't know if anyone had a library that automated decompression to a modifiable format then compression back to Web font formats.

[davelab6]

I believe fontTools can open woff2 files natively

[chrissimpkins]

I didn't realize that. Thank you!

[chrissimpkins]

Refactoring the percent command to support the approach @davelab6 recommended (TypoAsc/Desc|hheaAsc/Desc|winAsc/Desc equal) when designer used it. Also addresses #6.

[chrissimpkins]

v0.6.0 includes support for line spacing modifications across commonly used web font vertical metrics approaches. It does not currently support direct modification of metrics in eot, woff, or woff2 file types.