Potential special handling of "alt" features

[skef]

There are a few registered feature tags that share most or all of these attributes:

• They at least sometimes use alternate substitutions
• They are only rarely used in typical "web" situations
• They are sources of dependency overlap
• They have "alt" in the tag name

The most important of these is "aalt" but there is also "nalt" and "salt". "aalt" poses the biggest problem because it's often quite large, as its role is (more or less) to collect together substitutions from other tags into one place.

It would be counter-productive to optimize for these features given how rarely they will be used. In practice some of them can be addressed while addressing the related features. (If there is a feature-specific or glyph-combination-specific patch entry for the "original" substitution then the aalt case can be added to it.) But that won't cover all cases.

If you're not trying to optimize the segmentation of glyph-keyed patches to handle these features you may need to add a bunch of extra entries in the glyph-keyed patch map to do so. But ideally you wouldn't pay the price for those extra entries unless you needed to.

So there's a question: is it worth being able to add entries to the glyph-keyed map for low-use features so that they don't need to be present in the common case? And would the current mechanisms let you get away with that with an invalidating table-keyed patch similar to how changing the glyph-keyed designspace would work? (For this purpose an extra round-trip or two isn't a big deal.) And could such a mechanism be used to lower the glyph-keyed patch map cost for other little-used features?

[garretrieger]

Related #106 some of the alt features appear in the default feature list of the IFT spec. The spec does not obligate us to follow this list (just strongly recommends), so we can choose to special case handling of alt features on that list if we ultimately decide that makes sense.

[garretrieger]

So there's a question: is it worth being able to add entries to the glyph-keyed map for low-use features so that they don't need to be present in the common case? And would the current mechanisms let you get away with that with an invalidating table-keyed patch similar to how changing the glyph-keyed designspace would work? (For this purpose an extra round-trip or two isn't a big deal.) And could such a mechanism be used to lower the glyph-keyed patch map cost for other little-used features?

This is a potentially bit tricky from a technical perspective. While its definitely possible for a table keyed patch to modify the glyph keyed mapping (for example we do this for design space extensions), we currently restrict (in the encoder impl) that to cases where we completely rewrite/replace the existing glyph keyed mapping. If we're instead doing a diff based patch this has to be done with care since the glyph keyed patch mapping table gets modified by glyph keyed patch application. So the table keyed patch will have to be careful not to clobber any such changes.

At first glance I think it should be possible to construct a table keyed patch of this style, but we would definitely need to spend some time investigating whether its actually possible in practice.

[garretrieger]

The custom brotli stream builder (https://github.com/w3c/ift-encoder/blob/main/brotli/brotli_stream.h) would likely be useful in constructing a table keyed patch in this style.

[skef]

some of the alt features appear in the default feature list of the IFT spec.

I looked through the list of every registered OpenType feature with "alt" in it and I currently believe the ones on by default aren't relevant to this: none of those are described as using alternate substitution and more generally don't fall under what I'm getting at with this issue. It may be just the three I listed, with aalt being the main problem. So I think we're OK on this front.