Table Key Patch Preloading Proposal

During todays meeting I presented a small proposal for a small extension to
the spec that allows the encoding to specify table keyed patches to be
preloaded. Here's a copy of the proposal:Problem

   -

   We have an IFT font that is split into a number of segments where each
   is delivered via a table keyed patch.
   -

   Since table keyed patches are invalidating at most one patch can be
   fetched and applied at the same time.
   -

   If  an encoder wants to make it possible to add more than one segment
   simultaneously it can currently include combination patches at each state.
   For example for segments a, b, and c:
   (i to i+a), (i to i+b), (i to i+c), (i to i+a+b), (i to i+a+c), …
   -

   For larger segment counts this generates a significant amount of extra
   patches, and table keyed encodings are already fighting to limit the patch
   count in the simple case.
   -

   Skef suggested a solution to this problem: allow multiple table keyed
   patches to be listed per entry.

Goal

   -

   If instead the client can be informed about what follow up patches are
   needed for the second segment then it could just preload the follow up
   patch at the same time.
   -

   In the example above you would have the following.

   (i to i+a), (i to i+b), (i to i+c), {(i to i+a), (i+a to i+a+b)}, …

   Where the bold part is a patch mapping that lists multiple table keyed
   patches.
   -

   Ultimately we want to make it easy for an encoding to support one round
   trip encodings that support loading multiple segments.

Approach to Spec Changes

   -

   In format 2 allow entries to list multiple entry IDs.
   -

      Extend the ID delta field to each value to signal that an additional
      delta follows.
      -

      These then are expanded to URIs per normal.
      -

   In the extension algorithm when multiple URIs are attached to an entry:
   -

      The first listed URI is the primary patch which is handled per the
      existing procedures (including prefetching rules, etc.)
      -

      Any additional URIs are treated as preloads, the client is instructed
      to load them alongside the first URI and make them available for future
      iterations of the extension algorithm.
      -

      Then on the second iteration the follow up patches will have already
      been loaded.

Concrete Spec Changes Needed

   -

   Patch Map Entry definition:
   -

      Update “Value” to include a list of URIs
      -

   Format 2:
   -

      entryIdDelta
      <https://w3c.github.io/IFT/Overview.html#mapping-entry-entryiddelta>:
      reserve a bit here that indicates an additional delta follows.
      -

         Make this into a variable length array field.
         -

         Delta value = floor(entryIdDelta[i] / 2)
         -

         Value follows = entryIdDelta[i] & 0b1
         -

      Format 2 interpretation: update to reflect entryIdDelta changes
      -

   Format 1:
   -

      Update to reflect changes to patch map entry, will output entries
      with only one URI.
      -

   Extension Algorithm:
   -

      In top level intro section mention that preloading might happen
      beyond the one selected patch.
      -

      Step 9: start loads for all listed URIs, but first one is the named
      variable “patch file”. Mention the other are preloads.