Re: CSS support for TrueType collection files

Vladimir Levantovsky wrote:

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

No, it's simply a lack of user agents wanting to implement this
feature. I'm sure many of those same API's could load Type1 fonts but
I don't think anyone is clamoring for Type1 webfont support.

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.

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

Ok, fair enough.  After talking to Jonathan Kew about the latest WOFF2
proposal, fairly simple TTC support will fall out of that structure.

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

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:

  @font-face {
    font-family: emojis rule;
    src: url("emoji.woff2") format("woff2"),
         url("emoji.woff") format("woff");
  }

Sure, it would be better if there's a spec that lists format tags
for all supported formats when they come into use but that's easily
rectified.  It's not some huge structural problem.

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

Here again, I don't think "poor design decisions" are blocking
implementation at all.

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.

Cheers,

John Daggett

Received on Friday, 25 October 2013 09:17:38 UTC