[`VARC`] Final touches

[behdad]

The https://github.com/harfbuzz/boring-expansion-spec/blob/main/VARC.md spec has been fairly stable. I have three things that I like to consider and welcome external feedback:

• Define a int32var that is a signed counterpart to uint32var; then instead of FWORD, F4DOT12, and F6DOT10, simply use int32var. In my testing, this slightly shrinks slightly.

• For each of the reserved bits in flags, require that the client read and discard a uint32var if the bit is set. This is for future-proofing the format.

• Finally, the main outstanding issue is the "conditional components" discussed in https://github.com/harfbuzz/boring-expansion-spec/issues/104; it's trivial to implement: 1 flag, and a top-level array of offsets to ConditionSet tables as already defined in the spec.

[behdad]

@nedley @PeterCon @skef

[skef]

I had a mild (barely expressed) preference for just using F2DOT14 types with constant multipliers rather than defining new types, and substituting those with an int32var would be consistent with that.

Might a Fixed32Var make more sense, though? Seems like the optimal compression for fixed-point values would be different than for integers. (Maybe the FWORDs could be left as they are?) Maybe start out with F4d3 + the extra bit and go from there? (Note that this thought is very speculative ...)

For the flags, is there a strong reason to do that for more than one flag value?

Unsurprisingly, I favor the addition of conditional components. I think the best non-speculative evidence of the value of this (not to dismiss the speculative reasons) is the proliferation of design tricks along the lines of https://github.com/notofonts/noto-cjk-varco/issues/14#issuecomment-1921010429 . I think it will often be easier and less error-prone (including when it comes to rendering) to make and switch between separate components than to play these kinds of tricks. And I suspect the use of these tricks mostly reflects the fact that it's currently easier to add extra source instances to the design space than to switch, because of tool and format support. Conditional components address that gap.

[behdad]

Also: Remove USE_MY_METRICS. It doesn't make sense outside of glyf table.

[behdad]

I had a mild (barely expressed) preference for just using F2DOT14 types with constant multipliers rather than defining new types, and substituting those with an int32var would be consistent with that.

Might a Fixed32Var make more sense, though? Seems like the optimal compression for fixed-point values would be different than for integers. (Maybe the FWORDs could be left as they are?) Maybe start out with F4d3 + the extra bit and go from there? (Note that this thought is very speculative ...)

I'm leaning towards leaving them as is.

For the flags, is there a strong reason to do that for more than one flag value?

I think Ned mentioned doing it for all flags, and I think that would be more future-proof, if we keep adding new features.

The alternative is to say if any of the reserved flags is set, processing should stop right there.

Unsurprisingly, I favor the addition of conditional components. I think the best non-speculative evidence of the value of this (not to dismiss the speculative reasons) is the proliferation of design tricks along the lines of notofonts/noto-cjk-varco#14 (comment) . I think it will often be easier and less error-prone (including when it comes to rendering) to make and switch between separate components than to play these kinds of tricks. And I suspect the use of these tricks mostly reflects the fact that it's currently easier to add extra source instances to the design space than to switch, because of tool and format support. Conditional components address that gap.

I'm for conditionals. Let me see if I can implement them. But I wouldn't have the bandwidth to produce test fonts for them.

Remove USE_MY_METRICS. It doesn't make sense outside of glyf table.

It really doesn't belong. Now the question is do we renumber the flags after removal? I suppose we can.

[behdad]

Anyone else want to chime in here? I'll try to write these down tomorrow and submit to Vlad.

[nedley]

For the flags, is there a strong reason to do that for more than one flag value?

I think Ned mentioned doing it for all flags, and I think that would be more future-proof, if we keep adding new features.

The alternative is to say if any of the reserved flags is set, processing should stop right there.

I did mention that we need to consider this, yes. Saying that each flag bit increases the size of the record by a fixed amount seems fairly straightforward (an analogy would be the size of a GPOS ValueRecord being given by the valueFormat bits).

[behdad]

I added one uint32var per reserved flag bit; removed USE_MY_METRICS, and added ConditionSets.

[Lorp]

I assume you mean "I added one uint32var per reserved flag bit"

[behdad]

I assume you mean "I added one uint32var per reserved flag bit"

Fixed. Thanks.