RE: CSS support for font collections

Hi Ken, Behdad, all,

The issue with 'name' table here is due to the way how CSS font definitions work - the association between the name given to a font resource and the resource locator is established at the CSS font declaration level. A web developer can literally put a name to a face without ever looking at the 'name' table - if one is specifying the explicit resource location, a name is simply assigned to it (and doesn’t have to even resemble the actual typeface name).

I am inclined to use the font fragment identifier approach in CTS, as already defined in CSS. Yes, I realize it's not currently implemented by any browser but if it's been kicked around long enough and there seem to be an agreement in CSS WG to use numerical fragment identifiers for font collections. I feel like an attempt to redefine it may result in many more years of delayed implementation support, where supporting fragment identifiers by number may be just around the corner.

Thanks,
Vlad


-----Original Message-----
From: Ken Lunde [mailto:lunde@adobe.com] 
Sent: Thursday, August 11, 2016 12:00 AM
To: Behdad Esfahbod
Cc: WebFonts WG
Subject: Re: CSS support for font collections

Behdad,

Without a 'name' table, dealing with fonts collections feels a bit like rolling dice...

-- Ken

> On Aug 10, 2016, at 5:19 PM, Behdad Esfahbod <behdad@google.com> wrote:
> 
> Hi Ken,
> 
> That's interesting; but then the client needs to inspect the name table of all faces before resolving the request.  Also, currently name table is unused in webfonts.
> 
> 
> On Wed, Aug 10, 2016 at 4:57 PM, Ken Lunde <lunde@adobe.com> wrote:
> Behdad and others,
> 
> I can think of two ways to index into a font collection. One is by number, as you suggested. Another is by the name.ID=6 string of the desired font in the collection. Perhaps the same syntax could be used:
> 
>   font-collection#font-name
> 
> Example from Noto Sans CJK's Super OTC:
> 
>   NotoSansCJK.ttc#NotoSansCJKsc-Medium
> 
> 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.
> 
> Best...
> 
> -- Ken
> 
> > On Aug 10, 2016, at 4:45 PM, Behdad Esfahbod <behdad@google.com> wrote:
> >
> > We talked about this with John Daggett and Jonathan Kew before.  From CSS's point of view this is unambiguously specified [0]:
> >
> > Fragment identifiers are used to indicate which font to load. If a container format lacks a defined fragment identifier scheme, implementations should use a simple 1-based indexing scheme (e.g. "font-collection#1" for the first font, "font-collection#2" for the second font).
> > src: url(fonts/simple.woff);   /* load simple.woff relative to stylesheet location */
> > src: url(/fonts/simple.woff);  /* load simple.woff from absolute location */
> > src: url(fonts.svg#simple);    /* load SVG font with id 'simple' */
> >
> >
> >
> >
> > [0] https://www.w3.org/TR/css-fonts-3/

> >
> >
> > On Wed, Aug 10, 2016 at 3:21 PM, Roderick Sheeter <rsheeter@google.com> wrote:
> > Unfortunately I don't believe the syntax has been formally agreed on and no browser I'm aware of supports it. I think the best we can do is implement a test based on the explicit assumption (perhaps we should note in test plan?) that the #N syntax will work.
> >
> > Or drop the test. WG ... thoughts?
> >
> > On Wed, Aug 10, 2016 at 3:14 PM, Khaled Hosny <khaledhosny@eglug.org> wrote:
> > I’m trying to implement:
> > https://www.w3.org/Fonts/WG/wiki/TestPlan20-UserAgent#mustLoadFontCo

> > llection
> >
> > But no UA supports font collections, which has been discussed 
> > several times before but I’m not sure what the conclusion is. 
> > Particularly, how should individual fonts inside the collections be 
> > referred to? Fragment identifiers are suggested here, but I’m not 
> > sure how widely agreed upon is it:
> > https://github.com/svgeesus/ietf-justfont/commit/b47e71a16040ea7d4e8

> > 37287b968dd80f61caa71
> >
> > Regards,
> > Khaled
> >
> >
> >
> 
>

Received on Thursday, 11 August 2016 13:47:12 UTC