Add check for MVAR table with correct values

[davelab6]

Observed behaviour

Per the spec, the MVAR tables contain variation data for metadata otherwise in like OS/2 and hhea; if not present, then the default values in those tables will apply to all instances, which can effect text layout.

Expected behaviour

We must check MVAR tables are present and correct, since text layout software depends on these values

Resources and exact process needed to replicate

https://docs.microsoft.com/en-us/typography/opentype/spec/mvar

[felipesanches]

Similar to #2119, I will call it com.google.fonts/check/varfont/has_MVAR and add it to the Google Fonts specification (a.k.a. "gfonts profile").

[felipesanches]

"Per the spec, the MVAR tables contain variation data for metadata otherwise in like OS/2 and hhea; if not present, then the default values in those tables will apply to all instances, which can effect text layout."

This description is not very clear to be used as a rationale for the check. Do you have a clearer way to express this idea? I will create the check using this text, but I would like to later further improve it.

[felipesanches]

@m4rc1e disagrees with this new check. He said at #2122 (comment):

I disagree with this check.

If we look at the attribs which will trigger MVAR table generation, if they differ, https://github.com/fonttools/fonttools/blob/master/Lib/fontTools/varLib/mvar.py, these should be consistent across a family (according to GF spec).

What do you think, @davelab6 ?

[felipesanches]

@m4rc1e, please see also this: #2123

[m4rc1e]

Thanks for this!

[felipesanches]

@nyshadhr9 said at #2122 (comment):

Interesting, I was unaware of this requirement. To confirm, the values listed in mvar.py should remain consistent across a family. If so, we should have a check for that if there isn't one already. Also, in that case do we require all current and future GF variables to NOT have an MVAR table? Is that a reasonable requirement?

[m4rc1e]

Closing since we don't want a MVAR table due to the DirectWrite issue.

We just use ttx to drop the table, https://github.com/googlefonts/OswaldFont/blob/master/sources/build.sh#L42-L47

[anthrotype]

@m4rc1e did you ever hear back from MS about this issue? Is there a link to the bug report available somewhere? Have you had the chance to see if the issue has been fixed in more recent versions of Windows?
It feels to me a bit too heavy handed to simply ban MVAR table from GF library because of a bug in Windows..

[m4rc1e]

I haven't heard back from them. I'll ping them now. You're also included in the mail. AFAIK there isn't a bugzilla like site for MS bugs.

It feels to me a bit too heavy handed to simply ban MVAR table from GF library because of a bug in Windows..

A few months ago, I accidentally pushed a VF with a MVAR, users complained, google/fonts#2085.

Once DW is fixed and we've waited a few months, we will/should restore this table.

Fyi, our vertical metrics and underline thickness vals remain consistent across a family.

[m4rc1e]

Will reopen since this check may be relevant one day. Thanks Cosimo.

[felipesanches]

I wish we could sumarize the status of this discussion in the rationale of an MVAR check. I think right now we only have MVAR being checked on the unexpected_tables one.

[chrissimpkins]

Perhaps downgrade to a warning and rephrase the recommendation to remove the MVAR table, at least in the universal profile?

[arrowtype]

Do we know whether the MVAR table is still causing this issue?

[tphinney]

I'm about to strip MVAR from a Google font-to-be (Science Gothic) in which the ascender height varies slightly between certain masters. To make the ascender metadata better in its incorrectness, I would go through and make all the lower-ascender masters “lie” about their ascender height—because it seems less problematic to overstate ascender height, than to understate it, and the default master has a lower value.

Is there any reason I should not do this?

[kosbarts]

Hi @m4rc1e . Do you know if the MVAR issue with DW is solved?

I am working on a static/vf font with optical sizes and I would ideally like the different subfamilies (text, display, etc) to have different vertical metrics values. If the vf can't handle this via MVAR then I would have to keep one set of values for the statics.

Thanks.