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