Behdad Esfahbod
Behdad Esfahbod
> > While this might architecturally look cleaner, I don't think in reality it is. I tried implementing this yesterday and found it extremely hard to decouple this table from...
@nedley @PeterCon Your input is appreciated.
Let's work on a concrete table proposal. I'm willing to implement this and try.
Let's design this. ``` struct VARC { uint16_t majorVersion; // == 1 uint16_t minorVersion; // == 0 Offset32To componentsListOffset; Offset32To gvarOffset; // may be Null }; struct ComponenstList { uint16_t...
I think the overhead of this approach, compared to the current proposal, is roughly 6 bytes per glyph. In the CJK font with 45,000 Kanji that I built, that translates...
We can slightly optimize the variation storage by using a cvar-style, instead of gvar-style, TupleVariationStore. That is, store scalars instead of x,y variation values. I'm leaning towards keeping it simple...
I really dislike all the duplication here though, of loca/gvar basically. A middle approach would be to use the `VARC` table only for `CFF2`, the way that `VORG` is CFF-only.
I'm leaning towards reusing gvar unmodified, and leave optimizations to a newly designed version of gvar. The gvar with only scalars instead of x,y has some precedent in the cvar...
> Does no `numberOfContours` save another two bytes? True. So the damage is 2 bytes only. That's nice.
> That was just a sketch, of course. There are probably better mappings and may be better overall mapping strategies. What we did in the COLRv1 is to store one...