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#mustLoadFontCollection

> >
> > 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/b47e71a16040ea7d4e837287b968dd80f61caa71

> >
> > Regards,
> > Khaled
> >
> >
> >
> 
>

Received on Thursday, 11 August 2016 04:00:07 UTC