Re: [Justfont] CSS support for font collections

[Chris Lilley <[e-mail]>]

On 2016-08-15 15:56, Ken Lunde wrote:
> All,
>
> Chris Lilley asked me to forward to this mailing list a point I made on the [e-mail] mailing list about indexing fonts in a font collection in the context of CSS.
>
> below is the specific two-paragraph excerpt:
>
>> The latter method will be more reliable, because it doesn't depend on the order of the fonts within the collection, which have the potential to change over time, especially if additional fonts are added. A good real-world example of this is the forthcoming HK (Hong Kong) support for Source Han Sans (Adobe) and Noto Sans CJK (Google) that will add HK versions of the fonts to the collection, both weight-specific and the Super OTCs. These additional fonts will not be appended, but rather inserted, at least for the Super OTCs.
>>
>> Come to think of it, this actually happened to the SuperOTCs in Version 1.002 when HW (half-width) fonts were added for Regular and Bold. They were inserted, not appended.
> In other words, font collections have the potential to change the relative ordering of the fonts, which would usually happen when fonts are added. This is in terms of their index values, and this has actually happened in at least one broadly-distributed collection, and there are plans in place for having this happen again.
This seems sufficient motivation to try and make the fragments more robust.

> I was told that the 'name' table plays little or no part in terms of how CSS deals with a font collection, which is unfortunate because that is the table which provides the most reliable (unique) name of a font, such as the name.ID=6 string.

The name.ID=6 string (Postscript name) is already used in CSS 3 Fonts, 
in the local() part of the src descriptor
https://drafts.csswg.org/css-fonts/Fonts.html#src-desc
although that discussion does not mention font collections.

However, if the locally installed version for the bold face of Foo can 
already be referenced in CSS 3 Fonts using
|src: local(Foo-Bold)|
then it hardly seems a stretch to extend that to point to the bold face 
of Foo which happens to be in a collection
|src: local(Foo-Bold)|
and also to point to a non-installed webfont which is a collection, like
|src: url(https://example.org/Bar.woff2#Foo-Bold)|

It is an open question whether the fragment syntax should allow 
Postscript names *as well* as number, or *instead of* number.

I think it is okay to allow both, as long as the name is searched for 
first. So if someone happens to have a font family called "7", with a 
single weight, the ambiguity of #7 is resolved by first searching for a 
name, then if that fails searching for a number.

On the other hand, just using the Postscript name is clearer and more 
self-documenting, maybe we don't need the numeric fragments at all?


-- 
Chris Lilley
@svgeesus
Technical Director, W3C Interaction Domain