<div dir="ltr"><div dir="ltr"></div>Hi Skef,<div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 7, 2024 at 9:02 AM Skef Iterum via mpeg-otspec <<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  

    
  
  <div>
    <p>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).</p>
    <p>The whole point of delta-set indices is:</p>
    <ul>
      <li>They are arrays, indexed by some external field (generally a
        GID)</li>
      <li>They allow the outer, inner pairs to be packed into 3, 2, or
        (I think) even 1 byte when that's possible.</li>
    </ul>
    <p>OK, but these values map into an Item Variation Store, and that
      section (7.2.3.2) says:</p>
    <blockquote>
      <p>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.</p>
    </blockquote>
    <p>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. </p>
    <p>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.</p>
    <p>Is that wrong, or did our ancestors not notice this interaction?
      (I'm hoping it's wrong.)</p></div></blockquote><div>The ancestor did know this indeed. Note that the 0xFFFF/0xFFFF convention was added around 2019; after the initial varfonts release in 2016.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p>Skef</p>
    <p>(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.)</p></div></blockquote><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>b</div><div><br></div><div> </div></div></div></div>