[css-fonts-5] Details of format() and technology() values

[jfkthame]

[Originally referred to css-fonts-5, edited to refer to css-fonts-4 as technology() is there...]

Before the technology() extension to the @font-face rule's src descriptor ships, I think we need to bikeshed its potential values a bit further.

Currently, https://drafts.csswg.org/css-fonts-4/#font-face-src-parsing has

< font-technology > = [< font-feature-technology > | < color-font-technology > | variations | palettes | incremental ]
< font-feature-technology > = [feature-opentype | feature-aat | feature-graphite]
< color-font-technology > = [color-COLRv0 | color-COLRv1 | color-SVG | color-sbix | color-CBDT ]

I see a couple of issues/questions regarding this collection of values:

• variations should perhaps be split into variations-truetype (or variations-gvar, similar to how specific table tags are used to identify the color technologies?) and variations-cff2, as these are two quite distinct technologies (even though by design they behave similarly on the surface) and font rendering systems exist that support one but not the other. Distinguishing these is equivalent to distinguishing among color technologies, where rendering systems may support only a subset of the possible types.
• incremental seems to me to be out of place here. It's about how the font data is packaged and delivered, not about the rendering technologies that are supported. Should it be a new value of format() rather than technology()? (And should it be specific about the raw format, so format(incremental-opentype)? I don't think the proposal is designed to support incremental transfer for "packaged" font resources such as WOFF or collection, AFAICT.)

[jfkthame]

@drott @litherum I'd be interested to know any opinions you have here... thanks.

[svgeesus]

For variations, I agree, variations-cff2 should clearly be separate. Multiple tables affect variations though. Not sure on a good name for the truetype-glyphs variations.

For incremental I am unsure, particularly since there are two methods for incremental (range request, and patch-subset) and it is envisaged that some implementations might only support range request..

It isn't exactly a format (it applies to any sfnt font format) but yeah it isn't exactly a rendering technology either. Indeed incremental is forbidden from affecting rendering:

When a subsetted font is used to render text using any combination of the subset codepoints it must render identically to the original font. This includes any optional features that a renderer may choose to use from the original font such as hinting instructions, positioning rules, and/or glyph substitutions.
https://w3c.github.io/IFT/Overview.html#font-subset

[drott]

Quick thoughts: As soon as we got CFF2 support via FreeType code in Blink, we also got CFF2 variations with it for free. So I am curious if there is practically a situation where you'd have an engine's stack support CFF2, but not support CFF2 variations?
In principle, no objections in principle on splitting variations into those two, but perhaps it'd be sufficient to have cff2 as a technology, and variations as one and then combine them?

[litherum]

IIRC there are old versions of WebKit on macOS that support "variations-truetype" but not "variations-cff2." However, those old versions wouldn't be getting updates any more - so nothing we resolve on here will affect them. In the interest of steering people toward the right answer (aka the "pit of success" idea), I'm sympathetic to @drott's idea about avoiding combinations which don't actually exist in the wild.

incremental [is] about how the font data is packaged and delivered, not about the rendering technologies that are supported. Should it be a new value of format() rather than technology()?

I don't know if putting it in technology() is the right solution, but putting it in format() is probably the wrong solution. It isn't a format, and all the incremental delivery technologies can work with all formats.

[jfkthame]

IIRC there are old versions of WebKit on macOS that support "variations-truetype" but not "variations-cff2." However, those old versions wouldn't be getting updates any more - so nothing we resolve on here will affect them.

While that may make this somewhat irrelevant for what Apple ships in Safari (and equivalently for Edge on Windows), I'm not sure it holds more generally. Gecko relies on the host OS font system -- Core Text on macOS, DirectWrite on Windows -- and therefore the capabilities that are supported depend not only on the version of Gecko (which may be updated, e.g. to recognize the tech(...) function) but also what OS version it is running on (which may be older, and lack support e.g. for CFF2 variations).

My understanding is that both macOS and Windows shipped support for TrueType variations in earlier releases than CFF2; indeed, I notice that https://github.com/adobe-fonts/source-han-serif/releases/tag/2.000R, for example, warns users that

Currently Windows 10 and Windows 11 do not support CFF2 variable fonts. Please use the TTF variable instead.

(My own experience suggests that there is some CFF2 support in Windows, but that it is somewhat unreliable, so that a browser running on Win10 and using DirectWrite to render -- as Firefox does -- might want to treat variations-cff2 as unsupported in order to fall back to a variations-truetype resource. I'm not sure offhand which macOS version first included Core Text support for CFF2 variations?)

all the incremental delivery technologies can work with all formats.

Is that really the case? https://w3c.github.io/IFT/Overview.html#declaring-fonts says that "An incrementally transferred font must be in a raw format such as truetype or opentype", which I understood to exclude compressed packages like WOFF/WOFF2. I find it difficult to imagine how either range-request or binary patching could usefully work with a compressed packaging like WOFF2.

[svgeesus]

Can we get this resolved (at least, the CFF2 variations part of the question) before we resolve to republish (one hopes) on the next CSSWG call? Or do we need more discussion.

[drott]

No objections to splitting it into variations-truetype and variations-cff2 given that I understand from @jfkthame's explanations that there is a significant population of FF installations where the system rasteriser can handle the former but not the latter.

Also ok with, but not necessarily needed: in addition, keep un-postixed variations to mean requiring both of those, whichever applies to the font, i.e. needs variable support in CFF2 and glyf/TrueType contours.

[jfkthame]

Offhand, I'd be inclined not to keep the bare variations, just like we don't have a simple color keyword here; the technology that the resource depends on should be named specifically. I think that will give us a clearer path forward if some entirely new technology (e.g. a new format for glyph descriptions, with its own distinct technology to handle variations) is added in the future.

[Lorp]

I wonder if variations-gvar would be better than variations-truetype. This way, both variations-gvar and variations-cff2 identify the SFNT table within an OpenType font that handles glyph variations. Note that, for authors unsure what kind of variable font they have, opening the file with a hex editor and inspecting the first ~200 bytes with a hex editor will show either a CFF2 or a glyf entry.

[litherum]

Reading the conversation here, I'm pretty worried about over complicating this. Most CSS authors don't look inside their fonts. We should make sure that these CSS facilities are usable even if you don't understand what specific tables do inside the font files.

[Lorp]

Good point. I don’t like the idea of authors looking inside their font files at all. Assuming they’re working with WOFF2 files they’d have to decompress before inspection too.

[svgeesus]

We should make sure that these CSS facilities are usable even if you don't understand what specific tables do inside the font files.

Fair point, but we already require them to tell sbix, CBDT, SVG , COLR and COLR apart.

[Lorp]

Perhaps the W3C should host a web app, where fonts can be dropped and their capabilities displayed in terms of font-technology, with a link to Can I Use to see what can be used where.

[svgeesus]

That already exists @RoelN

[svgeesus]

Revisiting this old issue, what we have now in the spec seems to be well tested and interoperable

so I don't think we should change it at this point.