Redundant feature reduction

[skef]

We might think about allowing and encouraging the client to specify what "level" of a feature it supports in cases where there may be redundant information in the font.

I'm thinking of COLR v1 vs v0 vs BW fallback as the central example. A font may have all of these and there probably won't be overlap between the BW fallbacks and the v0/v1 glyphs. There may or may not be overlap between the v0 and v1 glyphs. The server implementation could be intelligent with COLR subsetting if it knows what the client can and will use (in a way that a "conventional" subsetter can't be).

(When well used CFF subroutinization and glyf composites may make such optimizations not worth the effort, although you'd still get the benefit of reducing the COLR table size. If COLR fonts become widely used they're probably the second best case for augmentation after CJK, though, so I think it's worth doing a bit of research on this possibility.)

[garretrieger]

I think this would be better solved using the CSS @font-face tech() specifier (https://drafts.csswg.org/css-fonts-5/#font-face-src-parsing). Theoretically you should be able to mix this with the incremental transfer one as well. For example in the colr case there could be two urls listed in the CSS one with tech(incremental, color-COLRv1) and one with tech(incremental, color-COLRv0). The browser could then grab the COLRv1 url if it supports COLRv1.

So given that font feature detection already exists in CSS (and we're relying on it to trigger incxfer) I don't think we want to duplicate feature detection into the incxfer protocol as well.

[skef]

Interesting. I think I agree this makes sense. I suppose the option you lose as compared with a combined system is that you won't have the option of augmenting one "tech" into a subset that started out without it.

I can imagine cases where someone might want that. Maybe starting out with COLR backup glyphs and then loading the rest of the font as an augmentation in the background. But then again you could just load two separate fonts and swap them out at the cost of a bit more network traffic for the common bits.

I suppose that when there is subsetting technology on the server side it could be used without the incremental tech() specifier to build a reduced font file for a "normal" GET file request (as long as one can load an IFT subset as if it were a normal font, which I guess is TBD).

[garretrieger]

Using two separate font loads with a switch over sounds like a reasonable solution to me.

Yes, the IFT font loads should operate from the perspective of the client as a normal font load. ie. it should follow all the usual css selection/fallback logic and operate with the existing javascript font loading api.

[garretrieger]

Discussed in last meeting, decided to rely on existing feature detection mechanisms (ie. client hints or, tech()), but should add a note in the spec advising on the problem.