Re: CSS support for font collections

On Wed, Aug 10, 2016 at 8:59 PM, Ken Lunde <lunde@adobe.com> wrote:

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


The CSS is typically autogenerated; the generator can look-up the names and
do the correct mapping.

Anyway, it's not worth than hardcoding "ss08" in your CSS anyway...  I
suggested feature names be used for those but daggett didn't like that for
some reason I didn't understand.  I still think that should be done.


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