Re: [Justfont] CSS support for font collections

Ken Lunde <> Sat, 29 October 2016 04:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C783129522 for <>; Fri, 28 Oct 2016 21:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id niumJbj31C4n for <>; Fri, 28 Oct 2016 21:42:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C406D129460 for <>; Fri, 28 Oct 2016 21:42:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gv8FPBxorfzA5iU3uBApeCzzkIdZQbD2c7iCq3GEYe0=; b=hzWtfLcIA0vvba0qqM/86OhlyAah4AOmuT+TscQRtQLw7b/w6xTDvXLnuLqv/ZoD6rm+8Tkw9Vr9ZXFOIc3bM6oN24vgCwTMFSpbC0OrE8DzrA9q2XfgVDNgySZDnLSNBuR/qiCJciOxL87cononjTMsz8zAFN5QU06D73T8mJE=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Sat, 29 Oct 2016 04:42:15 +0000
Received: from ([]) by ([]) with mapi id 15.01.0679.018; Sat, 29 Oct 2016 04:42:15 +0000
From: Ken Lunde <>
To: "" <>
Thread-Topic: [Justfont] CSS support for font collections
Thread-Index: AQHR9y8fUA6RdjwZeE+9kAE1dktXTqC6DsyAgAVAeoA=
Date: Sat, 29 Oct 2016 04:42:15 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3251)
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2601:646:8400:da00:c9fe:2220:71d9:afc]
x-ms-office365-filtering-correlation-id: c28db54c-0eec-4860-fad0-08d3ffb5f4f6
x-microsoft-exchange-diagnostics: 1; CY1PR02MB1149; 7:5RwuO8Q6KoU0rnLrBGUryqjY50LaXbHYcVelDukuI6O0ay0gqXLew03N6fpu1gBZ40oDRg7b8S6Gsw06sRu05afp17IBfA1bL57SoOt8DtzJQr2MwlaJwm1B7E+MEGrpPIIP6Sky8+KSHyMJlYM4Rer9Ot6iLMRuU2tpP89swvR2FhxkGjLIsrIP8d7uJBNIMVBoFcoS6Sh0Cyf0SQuUkDKI6UreqxipTyPKcAviHQt7uNWqLD302CUsvnenF7oFUMIS8kSTgQ3O6L37pJhKD3xnJxRnyNevQrbBP3x5QhCgxDZQNr1JshaOCVRLr81J2JDxEgsyqHAVycN/T1/zeaq6T3nw4WS8m3qrwl7pjp4=; 20:L8uV8PyVhaLZMVP34L++Vny/ZhgEfHHA4mDEfTJxVUEikv/RnAUd64d5pbEBmKuDceGvC44gq2eBUmIaEQFsIFQ/KKE5zXV7d/etQt/lEsWPLzVyPePcg+4ngtXDsY7vOvo4jh6rf1/mtLuvKVbq8VdJNu8qFljeorjxdY6ciRI=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR02MB1149;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR02MB1149; BCL:0; PCL:0; RULEID:; SRVR:CY1PR02MB1149;
x-forefront-prvs: 01106E96F6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377424004)(24454002)(199003)(377454003)(189002)(5660300001)(77096005)(15975445007)(19580395003)(19580405001)(3280700002)(2900100001)(101416001)(36756003)(57306001)(3660700001)(92566002)(33656002)(99286002)(106116001)(105586002)(10400500002)(10090500001)(2501003)(11100500001)(5640700001)(102836003)(106356001)(6116002)(586003)(110136003)(189998001)(97736004)(6916009)(2950100002)(2351001)(1730700003)(8676002)(86362001)(8936002)(7736002)(82746002)(7846002)(2906002)(5002640100001)(68736007)(83716003)(81156014)(305945005)(87936001)(81166006)(4326007)(76176999)(50986999)(122556002)(50226002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR02MB1149;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2016 04:42:15.1480 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR02MB1149
Archived-At: <>
Cc: "" <>
Subject: Re: [Justfont] CSS support for font collections
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Font Top Level Media Type \(just font\) WG" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 Oct 2016 04:42:19 -0000


While my vote doesn't count, I am all for using the name.ID=6 string for this. Eric Muller once described a font collection in a way that may help. He said that it is simply a packaging detail, and that each font should be treated separately, but that their glyphs happen to come from a shared bucket (the 'glyf' of 'CFF' -- and now 'CFF2' -- table).


-- Ken

> On Oct 25, 2016, at 1:30 PM, Chris Lilley <>; wrote:
> 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
> @svgeesus
> Technical Director, W3C Interaction Domain