RE: CSS support for TrueType collection files

Hi John,

On Thursday, October 24, 2013 7:12 AM you wrote:
> 
> 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.
> 

I was the one making these statements based on what I remembered from prior discussions on the list. I believe (FWIW) is that lack of implementation support in current user agents is largely due to two reasons - limited use of TTC (like I mentioned, it's been seen as a niche solution) and lack of clear guidance from the CSS spec on how TTC fonts can be used via e.g. fragment identifiers.

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

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 CSS spec that makes it difficult to properly implement / handle TTC fonts, IMO.

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

I am not sure what you mean by savings, Adam was suggesting to consider color fonts where multiple color schemes are combined in a single collection that shares all glyph outlines / metrics / layout tables and only differs in color palette definitions. The results would be considerable size advantages, compared to using multiple individual font files for that purpose.

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

In fact, exactly the opposite is true - the support for TTC in WOFF 2.0 format will come naturally as a result of the design decisions we made (the most important one being that we don’t see a real need for replicating SFNT table header as part of the WOFF package), and single stream data compression offers significant advantages compared to 'per table' compression option.
 
> 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.
> 

We are not adding anything in particular to support TTC, we are simply removing the obstacles for using TTC as part of the WOFF 2.0 format. There may not be a strong need to support TTC today (I did agree it's a niche solution) but the technology in general offers some promises in the future and I personally wouldn’t want to see its use restricted on the web just because we made poor design decisions in the past.

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

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?

> In practice, it would be simpler to just use individual files. 

Agree - today this is the case, but the general statement you made would only be true if there is no tomorrow.

> It's only if there's a lot of table sharing that the
> use of TTC would be interesting.
> 

This exactly the use case that Adam discussed for color fonts on the OpenType list.

Thank you,
Vlad

> 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 14:55:27 UTC