Mixing patch types and GID "management"

[skef]

At earlier points of the discussion of the new system we discussed the various issues relating to the multiple patch types and GIDs. One of these has to do with how codepoints are mapped -- whether the mapping goes through the GID or directly from codepoint to a bin or "segment". (I believe this was addressed by providing both options.)

The other issue is how GIDs are managed outside of the mapping. There are three ways of dealing with this, broadly speaking, but one probably doesn't make sense. The first is to have the dependent patches preserve GIDs. That will probably have a minimal impact on the compressed size of transmitted fonts, but will increase the uncompressed size. The second is to add a "remapping" table indicating the independent-patch-GID for the current dependent patch state. This can be as simple as an array of GIDs where the index is the dependent patch GID and the content is the independent patch GID.

Note that the second solution requires a bit more infrastructure, because not only do you need to do some client-side management when a new patch changes the mapping (to get everything in the right place), you also need to either keep the chunks around, or to stash the content of GIDs you're not using yet, so that if a new patch adds a glyph in an already downloaded independent patch you can insert it without re-downloading.

(The third option is to have different independent chunk sets for different patch levels, but that's unattractive for a variety of reasons.)

I'm not sure what decisions we came to about this stuff, maybe it was just to require that when the patch types are mixed one must preserve GIDs in the dependent patches. But either way, after a quick scan through the document (and having read the relevant sections more completely in recent weeks) I don't think we're addressing this yet.

[garretrieger]

At earlier points of the discussion of the new system we discussed the various issues relating to the multiple patch types and GIDs. One of these has to do with how codepoints are mapped -- whether the mapping goes through the GID or directly from codepoint to a bin or "segment". (I believe this was addressed by providing both options.)

That's right, format 1 uses gids in the entry key (with the expectation that cmap is used to translate codepoints from the subset definition to gids) and format 2 is codepoint based.

The other issue is how GIDs are managed outside of the mapping. There are three ways of dealing with this, broadly speaking, but one probably doesn't make sense. The first is to have the dependent patches preserve GIDs. That will probably have a minimal impact on the compressed size of transmitted fonts, but will increase the uncompressed size. The second is to add a "remapping" table indicating the independent-patch-GID for the current dependent patch state. This can be as simple as an array of GIDs where the index is the dependent patch GID and the content is the independent patch GID. Note that the second solution requires a bit more infrastructure, because not only do you need to do some client-side management when a new patch changes the mapping (to get everything in the right place), you also need to either keep the chunks around, or to stash the content of GIDs you're not using yet, so that if a new patch adds a glyph in an already downloaded independent patch you can insert it without re-downloading. (The third option is to have different independent chunk sets for different patch levels, but that's unattractive for a variety of reasons.) I'm not sure what decisions we came to about this stuff, maybe it was just to require that when the patch types are mixed one must preserve GIDs in the dependent patches. But either way, after a quick scan through the document (and having read the relevant sections more completely in recent weeks) I don't think we're addressing this yet.

Earlier during prototype development I implemented and experimented with having a old to new glyph mapping (the second option here) and found that it was overly complicated and didn't yield any improvements over the simpler method of retaining gids (here's the previous post <https://lists.w3.org/Archives/Public/public-webfonts-wg/2023Dec/0004.html> to the wg mailing list with more details). My conclusion was to use option one, retain gids when mixing dependent and independent patches, which is what the current prototype is doing. The current draft of the spec doesn't have any requirements about this, but we should definitely add a sub section to encoder guidance that discusses this problem and says to retain glyphs when mixing glyph keyed with other patch types. I'll make some changes and send a PR.

[garretrieger]

Looks like we currently don't say anything really about how to mix patch types in the considerations section. So I'll add a new sub section for that and discuss this issue and the other considerations for constructing an IFT font with mixed patch types.