Re: [Justfont] CSS support for font collections

Chris Lilley <> Tue, 25 October 2016 20:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C416129556 for <>; Tue, 25 Oct 2016 13:30:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FaPlDz-vMc9y for <>; Tue, 25 Oct 2016 13:30:15 -0700 (PDT)
Received: from ( [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 24F241298B1 for <>; Tue, 25 Oct 2016 13:30:14 -0700 (PDT)
Received: from ([]) by with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bz8MQ-000ATs-1A; Tue, 25 Oct 2016 20:30:14 +0000
To: Ken Lunde <>, "" <>
References: <>
From: Chris Lilley <>
Organization: W3C
Message-ID: <>
Date: Tue, 25 Oct 2016 16:30:11 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------FD6631C3A0DD2826A6DF1FB6"
Archived-At: <>
Subject: Re: [Justfont] CSS support for font collections
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "" <>
List-Id: "Font Top Level Media Type \(just font\) WG" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Oct 2016 20:30:19 -0000

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 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
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(|

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
Technical Director, W3C Interaction Domain