[css-fonts] CSS support for TrueType collection files

[cross-posted to www-style and public-webfonts-wg]

In the notes below, TTC is a reference to the TrueType Collection
format, a packaging format used to wrap multiple font faces within a
single file.  One advantage of this format is that a single font table
can be shared across multiple faces.

>From the minutes of last night's Fonts WG telcon [1]:

> TTC issue has been discussed in detail in 2010 on wg reflector
> TTC can be used as webfonts, maybe some quirks need to be worked out
> at the moment, can only reference font #1 in the resource. Nothing
> in CSS that lets us reference other fonts
> This is the biggest issue that holds back usage of TTC

Not sure who was making these statements (raph?) but as I posted
yesterday [2], I think it's incorrect to say that the problem with TTC
support is a CSS problem.  It's simply a lack of implementation support
in current user agents.

We've discussed TTC support before on www-style and the CSS3 Fonts
spec describes the format of fragment identifiers used to reference
individual fonts within a collection format that doesn't support
explicit fragment identifiers (e.g. SVG fonts can be accessed via an
identifier, faces within TTC files typically cannot). I think that's
sufficient from a spec viewpoint.  Being able to only reference the
first font in a TTC package is an implementation detail, it is not a
CSS handling restriction.

Part of the problem may be that folks are imagining a single
@font-face rule supporting the loading of a *set* of faces:

  @font-face {
    font-family: My Big Fat Font Family;
    src: url(bigfamily.ttc);  /* contains multiple font faces */
  }

I don't think overloading a single @font-face rule to support the
loading of multiple faces makes sense.  It adds unnecessary complexity
to the authoring model.  It's much simpler to just use fragment 
identifiers to select individual faces, which doesn't break the
existing model of one face per @font-face rule:

  @font-face {
    font-family: My Big Fat Font Family;
    src: url(bigfamily.ttc#1);  /* first font == regular */
  }

  @font-face {
    font-family: My Big Fat Font Family;
    src: url(bigfamily.ttc#2);  /* second font == bold */
    font-weight: bold;
  }

> container format would need to support multiple font headers
> vlad: WOFF 1 attempts to replicate TTF header, this wouldn't be a problem with whole-stream compression
> raph: would affect TTC because of preprocessing step
> vlad: could Raph investigate how the preprocessing step would affect ttc files
> raph: yes
> adam twardoch suggested that ttc fonts may be useful to represent multiple color schemes for a color font
> fonts in the collection would share outlines but have different color palette tables

I think in practice the sharing of palette tables across fonts would
represent a very minimal savings. 

> ttc is currently niche in usage
> vlad: it is something we should support
> kuettel: are we talking about just making the font format support
>          ttc, or also pushing out changes all the way to the browser?
> vlad: we should make the wire format support it first, then consider other changes

This seems a little bit like feature creep for WOFF2.  I'm still not
seeing a strong need for TTC as a wire format, I think there really
needs to be a stronger justification for adding the additional
complexity.  Yes, sharing of tables is an advantage but is that really
something that would be useful in the context of *webfonts*? TTC
currently is used as a convenient packaging format for platform fonts.
I'm skeptical that it would be used enough on the web to justify
burdening all implementations with supporting it.

I think it's fine if individual user agents want to support TTC
loading but I think it's not terribly important to include support for
loading TTC fontsets withing WOFF2 containers.  Adding it to WOFF2
would require all user agents to support it.

> css is currently biggest obstacle

Nonsense, I think the "obstacle" here is that there isn't a strong use
case for TTC use on the web which is why all browser vendors have
ignored TTC support.

> raph: concern about backwards compatibility: css has no way to
>       conditionally use TTC if supported, fall back to separate TTF fonts
>       if not

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.  In practice, it would be simpler to just use
individual files.  It's only if there's a lot of table sharing that
the use of TTC would be interesting.

Regards,

John Daggett

[1] http://lists.w3.org/Archives/Public/public-webfonts-wg/2013Oct/0039.html
[2] http://lists.w3.org/Archives/Public/public-webfonts-wg/2013Oct/0030.html

Received on Thursday, 24 October 2013 11:12:05 UTC