Add VVAR for variable fonts that support vertical

[rsheeter]

@cmyr pointed out we have a bunch of VVAR fontmake only diffs in crater, first swing at adding it.

Makes at least the following identical:

• python3 resources/scripts/ttx_diff.py 'https://github.com/notofonts/ethiopic?1cc6933c58#sources/NotoSerifEthiopic.glyphs'
• python3 resources/scripts/ttx_diff.py 'https://github.com/notofonts/tamil?626575fa0c#sources/NotoSerifTamil.glyphs'

Hopefully helps with others whose diff is (VVAR) as well.

Mostly just boilerplate and shuffling things to not be HVAR-only. Note that resources/testdata/HVVAR/SingleModel_Direct/SingleModelDirect-Regular.ufo/fontinfo.plist now specifies the magic keys to trigger build vertical.

[anthrotype]

@rsheeter did you see this #1489 ?

[anthrotype]

one thing #1489 has which this is missing is gvar vertical phantom points. We can add those as follow up

[anthrotype]

btw, both NotoSerifEthiopic.glyphs and NotoSerifTamil.glyphs may now be identical in both fontc and fontmake, but they actually produce a no-op VVAR with empty VarData items, so they may not actually be the best candidates for testing:

  <VVAR>
   <Version value="0x00010000"/>
    <VarStore Format="1">
      <Format value="1"/>
      <VarRegionList>
        <!-- RegionAxisCount=2 -->
        <!-- RegionCount=0 -->
      </VarRegionList>
      <!-- VarDataCount=1 -->
      <VarData index="0">
        <!-- ItemCount=222 -->
        <NumShorts value="0"/>
        <!-- VarRegionCount=0 -->
        <Item index="0" value="[]"/>
        <Item index="1" value="[]"/>
        <Item index="2" value="[]"/>
        <Item index="3" value="[]"/>
        <!-- empty [] all the way down to the end -->

I wonder why do we even bother compiling such a VVAR...

[anthrotype]

oh right, so in Glyphs.app if any glyph has vertWidth or vertOrigin set, it's deemed "vertical". Those sources I mentioned above are probably like that and get VVAR because some glyphs by accident has one of those:

https://github.com/googlefonts/glyphsLib/blob/c4db6b981d577f456d64ebe9993818770e170454/Lib/glyphsLib/builder/builders.py#L197-L198

[anthrotype]

actually, the correct thing to do is not to error when we don't have a GlobalMetricsInstance at the same location as a given glyph instance, but we should interpolate one! #1518 was added by @Hoolean exactly for this purpose.

[rsheeter]

Should that just be how accessing metrics works? Is there a case where we don't want that?

[anthrotype]

you'll actually never hit this NoGlobalMetricsInstance error because when you call GlobalMetrics::at below inside AdvanceDeltas::new, new GlobalMetricsInstances will be interpolated automatically if missing:

        let metrics = glyph_locations
            .into_iter()
            .map(|loc| {
                let loc = loc.subset_axes(&axes);
                let metrics = global_metrics.at(&loc);
                (loc, metrics)
            })
            .collect();

we can probably get rid of it altogether and simply assert/unwrap

[anthrotype]

Is there a case where we don't want that?

no, we do want to interpolate all the time

[rsheeter]

@rsheeter did you see this #1489 ?

Nope, just noticed in conversation with Colin and filled in some of the blanks! If that is better happy to land that and close this.

[anthrotype]

If that is better happy to land that and close this.

I prefer this one because it extracts the common code in a shared metric_variations.rs and has tests. But we can incorporate the missing bits from that one here. I'm already working on that actually

[anthrotype]

i think we can land this first, and then follow up with the gvar vertical phantom points in a subsequent PR