Extension algorithm language and pre-loading

[skef]

From the extension algorithm:

Remove any entries in entry list which have a patch URI which was loaded and applied previously during the execution of this algorithm.

What if some entries (e.g. of glyph-keyed patches) were preloaded in to the sources? It seems preferable to refer to the ongoing record of what patches are integrated rather than the algorithm. There might not be a clean way of doing that currently, but one could, e.g., add a definition to describe that record abstractly and then use it in the Font Patch Formats section.

[garretrieger]

So for some context that sentence was added specifically to prevent malformed fonts from entering into an infinite loop (ie. by having a patch which doesn't actually modify the font).

In well formed fonts the patch application process will remove any entries that reference a URI whose patch has been applied. For glyph keyed patches this is explicitly required in step 5 here. For table keyed patches this is an implied requirement since the patch application will modify the compatibility ID and thus the patch at that URL will no longer be valid and so a correctly encoded font wouldn't contain it post patch application.

For the preloading case both mapping table formats have a mechanism to mark via a single bit that and entry has already been applied. So the source font would just need to set those appropriately. More generally those bits will be used to track the current state of applications throughout the life time of the font.