Re: Proposal for new Approach to Patch Categorization

I put together a PR that contains the set of changes to the spec for this
proposal: https://github.com/w3c/IFT/pull/166

On Thu, Apr 11, 2024 at 3:07 PM Garret Rieger <grieger@google.com> wrote:

> 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.
>
>
>
>
>
>