W3C home > Mailing lists > Public > www-style@w3.org > May 2011

Re: [css3-fonts] multiple formats in src descriptor

From: John Daggett <jdaggett@mozilla.com>
Date: Thu, 26 May 2011 17:47:57 -0700 (PDT)
To: Vladimir Levantovsky <Vladimir.Levantovsky@MonotypeImaging.com>
Cc: www-style@w3.org, Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Message-ID: <758532553.56051.1306457277220.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
Vladimir Levantovsky wrote:

> Actually, format hints containing more than one format string may
> come handy with WOFF, where one string would identify WOFF as a
> container format, and another one (as in Daniel's example above)
> could be used to identify the format of a font encapsulated inside
> WOFF file. For this to be useful, the format hints should be well
> defined and specific  -e.g.:
> 
> src: url(foo) format("woff", "opentype-cff");
> 
> would allow UA to skip downloading a WOFF resource containing
> OpenType CFF font if it is known that the device cannot render CFF
> outlines.

I think you could just as easily create separate hints for fonts with
different glyph formats:

  "truetype-glyf"
  "opentype-cff"
  "woff-glyf"
  "woff-cff"

I'm not recommending this, I'm just saying multiple format hints
aren't required to attain the result you're looking for in your
example.

Multiple format hints might be handy in the way you suggest but you're
effectively making the format hint into a crude form of capability
mapping and that definitely adds complexity.  What's the rule for
matching multiple hints, all hints must be supported?  Fonts contain
all sorts of things that may not be fully supported by all clients,
AAT tables, OpenType layout tables, bitmaps, IVS cmaps, silly tables
for supporting colorful pile-of-poo emoji, etc.  I think capability
matching is possible but in practice it's hard to specify.

At least for this version of the spec, I would say it's better to
keep the structure of the format hint simple.

Cheers,

John Daggett
Received on Friday, 27 May 2011 00:48:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:40 GMT