Proposal for new Approach to Patch Categorization

The IFT spec currently classifies the different patch formats as either
dependent or independent. Where the application of a dependent patch
invalidates all other dependent patches referenced by the current font
subset. However, this definition is a little too strict and also doesn't
give a client any information on if independent patches can be applied
after the application of a dependent patch. We've previously discussed some
possible different approaches to classification of patches at previous
meetings, but never decided on a specific direction. I've spent some time
working out a new system that I'm proposing to replace the current
dependent/independent classification. This also addresses some open
questions about the handling of the IFT/IFTX table ID’s:


   1.

   When interpreting a mapping table each mapping entry will be assigned
   the ID that is set in the header of that mapping table. When applying
   patches the patch must have an ID that matches the ID assigned earlier.
   This changes the current spec text that allows the patch ID to match the ID
   of either mapping table.
   2.

   The mapping table will assign each patch entry one of three categories:
   1.

      Full invalidation: this patch is expected to change the ID of both
      IFT and IFTX tables. As a result all other patches are invalidated after
      the application of this patch.
      2.

      Partial invalidation: this patch is expected to change only the ID of
      the mapping table that contains it. As a result all patches in the same
      table are invalidated, but patches in the other table may still
be applied
      after the application of this patch.
      3.

      No invalidation: this patch does not change either ID, and will not
      affect the ability to apply any other patches.
      3.

   To encode the invalidation category of each patch, the patch format enum
   will be extended to include that info:

Encoding No.

Format

Invalidation

1

Brotli

Full

2

Brotli

Partial

3

Per Table

Full

4

Per Table

Partial

5

Glyph Keyed

None


Note: glyph keyed patches are always no invalidation since the patch format
has no mechanism to change the mapping table ID’s.


   4.

   Lastly, this will require some changes to the patch selection algorithm.
   It will become roughly:
   1.

      Collect all intersecting patch entries from the current font subset.
      2.

      Select and apply exactly one. Patches are put into groups by the
      invalidation categories and a single patch is selected from the highest
      priority group with at least one patch in it. Priority is Full, Partial,
      then lastly None.
      3.

      Go to a.


Note: under this setup the client is free to pre-fetch patches as they
wish. The invalidation categories make it explicit which patches can be
safely applied after the application of another. So the client can easily
determine which patches can be pre-fetched. For example in the case of
glyph keyed patches the client would know that applying a glyph keyed patch
won’t invalidate the other ones, so it can grab all intersecting ones in
parallel and then apply them one at a time as per usual.