Font Collection support

[litherum]

While some font collections exist merely for packaging convenience—a single font resource instead of several—some exist for a non-trivial size benefit, such as sharing a single 'glyf', 'CFF ', or 'CFF2' table with multiple fonts.

We should make sure that there are considerations for font collections with incremental transfer.

[garretrieger]

I think this is probably out of scope for incxfer given that @font-face doesn't support ttc's, but I suppose we way want to support it for non-browser based use cases.

For patch subset we could take two different approaches to support this use case:

1. Allow a single request to specify the have/needed state for each font in the collection. You get back a single patch.
2. Add a font index parameter to the request. Each patch request can generate a patch for a single font in the ttc at a time.

That said for patch subset, current subsetter implementations don't support subsetting entire ttc's at once. They can handle ttc's but only operate on and ouput a single font within the ttc. I also suspect that table sharing would become difficult and quite complicated once you have multiple different subsets cut on the individual fonts in the ttc.

So given the high complexity in supporting this case combined with the fact that the primary use case for incxfer does not support ttc's I lean towards not supporting it.

[jfkthame]

I think this is probably out of scope for incxfer given that @font-face doesn't support ttc's,

The CSS Fonts spec explicitly mentions a collection format keyword, and notes that a fragment identifier is used to select an individual face.

(I'm not sure if any browser currently implements this, but it's certainly included in the spec.)

[vlevantovsky]

We should make sure that there are considerations for font collections with incremental transfer.

We definitely need to make sure that the request format allows clients to identify any relevant info needed to support incremental transfer of font collection files. As far as server implementation is concerned though, I think the level of font collection support will depend entirely on a particular font subsetter capabilities - the process of patch creation won't be in any way dependent on whether subsetter can/cannot process font collection files.
Since a font subsetter is an external resource for the purposes of this IFT recommendation, I am not sure how much of control we have over it, but we can definitely say something.

[svgeesus]

(I'm not sure if any browser currently implements this, but it's certainly included in the spec.)

It is explicitly included in the spec in hope that near-term, browsers will implement it. I remember we made sure that WOFF2 could handle collections, for example, because not handling them would mean browsers would be blocked from supporting collections in the future.

[svgeesus]

Because browsers currently do not support TrueType Collections or OpenType Collections, in practice authoring tools avoid generating WOFF2 Collections. Font Squirrel rejects collection files; Everything Fonts accepts them, but generates a set of individual WOFF2 files (one for every font in the collection). In the future, as browsers implement collection support, authoring tools might change to generating WOFF2 Collections.
WOFF 2.0 Implementation Report
2017-Dec-11

[svgeesus]

Related, we should make sure the collections bug in the woff2 test suite doesn't also affect the IFT collection tests

[svgeesus]

The CSS Fonts spec explicitly mentions a collection format keyword, and notes that a fragment identifier is used to select an individual face.

Defined in https://datatracker.ietf.org/doc/html/rfc8081