W3C home > Mailing lists > Public > www-style@w3.org > October 2013

RE: CSS support for TrueType collection files

From: Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com>
Date: Fri, 25 Oct 2013 14:11:46 +0000
To: John Daggett <jdaggett@mozilla.com>
CC: "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>, "www-style@w3.org list" <www-style@w3.org>
Message-ID: <79E5B05BFEBAF5418BCB714B43F4419923F49BBB@wob-mail-01>
On Friday, October 25, 2013 5:17 AM John Daggett wrote:
> Vladimir Levantovsky wrote:
> >
> > But the majority of user agents use platform-supplied font rendering
> > solutions that do support TTC, so it is not the lack of rendering
> > support that is limiting but rather insufficient guidance from the
> > spec that makes it difficult to properly implement / handle TTC
> fonts,
> > IMO.
> What specifically is insufficient about the fragment identifier
> description? For a developer that reads the spec I see clear guidance
> for TTC or any other collection format that a user agent wants to
> support.  Jonathan suggests that an example would help and I think
> that's perfectly reasonable.  But claiming the current spec makes
> implementation "difficult" is puzzling to me.

In my opinion, fragment identifiers shift the burden of using TTC to web authors, as it's not trivial sometimes to associate a particular font as part of the collection with the fragment number. One can usually see font names that are included in the TTC but not the order they're encoded in the file. This, plus the inability to select a component font by name is what I think hampers the use of TTC.

> >> Here too, I think this is overstated.  For user agents that want to
> >> support TTC files, all that's needed is a format hint for TTC files.
> >> Then existing user agents would simply ignore the TTC references and
> >> load the single face.
> >
> > Sounds like a hack to me. Would you agree that it would be a benefit
> > if the proper behavior w.r.t. TTC is specified in details?
> Hack? This is precisely what format hints are defined for.  Same for
> WOFF2, format hints will allow older user agents to skip loading a
> format they don't support:

I was referring to the use of fragment identifiers, not format hints. Format hints are fine and self-explanatory, fragment identifiers are cumbersome for the reasons I mentioned earlier.

> I guess, in general, it would be more helpful if you could review the
> existing spec and suggest specific changes that you think are required.
> Both the fragment identifier syntax and the format hint mechanism are
> already defined.  It would be useful to understand what you think is
> required beyond that.

I'd suggest the following changes:
- editorial: create a subclause that is specifically dedicated to using font collections (so that it is visible in the Table of Content);
- editorial: add a format string for TTC; 
- editorial: like Jonathan suggested, explain the use of fragment identifiers in more details with some examples;
- substantive: allow individual font collection entries to be identified by name as part of the font-face-src definition, similar to how SVG fonts can be identified by id.

Thank you,

> Cheers,
> John Daggett

Received on Friday, 25 October 2013 14:12:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:16 UTC