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

Hi John,

On Thursday, May 26, 2011 8:48 PM John Daggett wrote:
> 
> 
> 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.
> 

My understanding is that multiple format hints are currently allowed, hence my previous comment re. their potential use.

I don't think we would ever need to try to address all possible flavors and variations - there are way too many features that can be combined together, and I agree that capability mapping would be hard to specify.

However, my take on all this is that outline formats are 'ground zero' functionality - if UA can render a particular outline format it will always be able to display _some_ text vs. none at all (if a particular outlines are not supported). The lack of support for any other feature would result in rendered text not always being true to author's typographic intent, but at least it will be visible and set in a font an author selected. So, IMO it does make sense to at least indicate the outline format so that UA can decide if it needs to download a font. I am open to whether it would better be done via an existing multiple format hint mechanism (if supported), or by defining a new set of format hints that combine needed info in a single hint (e.g. 'woff-ttf' or 'woff-cff') as you proposed.

Regards,
Vlad

> 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 Tuesday, 31 May 2011 14:56:20 UTC