Fonts should have `VVAR`

[behdad]

Even if advance-height doesn't vary, font should have a (fixed-size empty) VVAR table to speed up advance-height calculation. Without it we have to process gvar to get to the varied advance-height.

[behdad]

Such VVAR just need to have all null "mappings", and a vstore with just the referenced (by gids) VarData, each of which having zero delta columns.

[behdad]

Looks like the OTF fonts have it, but not TTF?

[punchcutter]

OTF has it because it must. TTF doesn't because it doesn't need it. The spec says as such https://learn.microsoft.com/en-us/typography/opentype/spec/vvar
But of course it's possible to add it if that helps.

[behdad]

OTF has it because it must. TTF doesn't because it doesn't need it. The spec says as such https://learn.microsoft.com/en-us/typography/opentype/spec/vvar

The same paragraph says: "For this reason, the VVAR table is not required in variable fonts that have TrueType outlines. For text-layout operations that require glyph metrics but not actual glyph outlines, however, there can be significant performance benefits by being able to obtain adjusted glyph metrics for an instance without needing to interpolate glyph outlines. For this reason, it is recommended that a VVAR table be included in variable fonts that have TrueType outlines and that support vertical layout."

If we were to follow your argument, HVAR is not required either.

[punchcutter]

I'm just saying it was never an issue and one reason we didn't try to do it was because the spec didn't require it. Why is it suddenly a big deal?

[behdad]

I'm just saying it was never an issue and one reason we didn't try to do it was because the spec didn't require it. Why is it suddenly a big deal?

I've been optimizing vertical text layout shaping performance. It's, like, 50x slower than if VVAR was available. Sure, no one has complained, but that's because vertical layout in browsers is just not a thing really.

Of course feel free to ignore this. But since the table is already produced for OTF, I don't see why TTF should be denied of the optimization.

[behdad]

Some numbers here: harfbuzz/harfbuzz#5392 (comment)

[punchcutter]

Ok, good to know. Originally we didn't even make TTFs, but Windows had a major bug in CFF2 that crashed the whole text system so I added TTFs and now we can't just remove them, but can always update them.

[behdad]

Thanks. These fonts are great for stress-testing all systems, including my performance tunnings.

[davelab6]

@punchcutter whats the latest? :)

[behdad]

I did some measurements: Getting glyph v advance without caching, of NotoSansCJK-VF (first face):

• With VVAR (.otf file): 398us HarfBuzz, 1453us FreeType.
• Without VVAR (.ttf file): 6464us HarfBuzz, 98792us FreeType.