[MPEG-OTSPEC] Interaction between delta-set indices and non-variable values

[Behdad Esfahbod]

Hi Skef,

On Sun, Apr 7, 2024 at 9:02 AM Skef Iterum via mpeg-otspec <
mpeg-otspec at lists.aau.at> wrote:

> I've been looking through the spec and want to ask a question about
> delta-set indices (7.2.3.1 in Vladimir's latest).
>
> The whole point of delta-set indices is:
>
>    - They are arrays, indexed by some external field (generally a GID)
>    - They allow the outer, inner pairs to be packed into 3, 2, or (I
>    think) even 1 byte when that's possible.
>
> OK, but these values map into an Item Variation Store, and that section
> (7.2.3.2) says:
>
> A complete delta-set index involves an outer-level index into the
> ItemVariationData subtable array, plus an inner-level index to a delta-set
> row within that subtable. A special meaning is assigned to a delta-set
> index 0xFFFF/0xFFFF (that is, outer-level and inner-level portions are both
> 0xFFFF): this is used to indicate that there is no variation data for a
> given item. Functionally, this would be equivalent to referencing delta-set
> data consisting of only deltas of 0 for all regions.
>
> So 0xFFFF,0xFFFF is used as the index pair for something that doesn't
> vary. And you'll often need these (or some substitute) in a delta-set index
> because all the elements (e.g. glyphs) are typically represented in a
> delta-set index.
>
> However, just on the face of it it seems like you'll need 16 bits of
> representation for the outer and 16 for the inner in the delta-set index
> just because those are both 0xFFFF.
>
> Is that wrong, or did our ancestors not notice this interaction? (I'm
> hoping it's wrong.)
>
The ancestor did know this indeed. Note that the 0xFFFF/0xFFFF convention
was added around 2019; after the initial varfonts release in 2016.


> Skef
>
> (One can add a zero-delta row to some subtable in the IVS and just use its
> inner and outer indices to work around this, but obviously that's not
> ideal.)
>
Indeed. That's the preferred solution when DeltaSetIndexMap is involved.
And exactly why the fonttools VarStore.optimize() takes a parameter for
whether to use 0xFFFF/0xFFFF or not.

If we were to design this from scratch, I would have suggested any "all
0xFF bytes" would mean no variation. But that's not backwards compatible.

You might ask where is 0xFFFF/0xFFFF used anyway. It was a rather
speculative addition. However, it's nice to be able to say "any indices
into DeltSetMapIndex beyond the number of items get the value of
0xFFFF/0xFFFF" instead of saying they don't vary... This arises in avar2
for example.

b
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240411/78e9e94b/attachment.htm>