Re: [css3 fonts] font-specific features

John Daggett wrote:

>> Fallback to the first variant -- as happens for e.g. the <salt>
>> feature in current applications that do not provide access to
>> enumerated variants -- is not acceptable in such a situation, since
>> it would result in an inaccurate transcription of the object being
>> catalogued.

> So you're saying setting salt = NNN implies salt = 1 when no lookup exists
> for NNN? 

That's not what I was saying, but is a separate issue as discussed 
below. What I was referring to is the situation in which a font does 
contain a type 3 (one-to-one-of-many) lookup associated with the <salt> 
feature, but the application, e.g. Adobe InDesign, does not provide any 
mechanism to access the 'many'. What applications have tended to do, as 
a fallback, is to treat that type 3 lookup as if it were a type 1 lookup 
(single substitution), and apply the first enumerated variant. I was 
saying that this is not an acceptable fallback mechanism in a situation 
in which the particular form of the glyph is meaningful to the user, as 
is more likely to be the case with Character Variant features.

>  In other words, the two style rules below would be the same, assuming
> no font supports a lookup value of NNN:
> 
>   @font-feature-settings MyFont {
>     stylistic: wacky 666;
>   }
> 
>   p { font-family: MyFont; }
>   p#test1 { font-variant: stylistic(wacky); }
>   p#test2 { font-feature-settings: salt(1); }

I'm not sure I understand the example, but I think you are asking about 
fallback behaviour when a font does not support the enumerated variant 
specified in the CSS, i.e. where the browser does support access to such 
an enumerated variant but the font doesn't contain a corresponding 
lookup (unlike my example above, where it is the application rather than 
the font that lacks support).

> Things like this need to be captured somewhere in a spec.  If OpenType
> doesn't define default behavior explicitly in these cases, it needs to
> be defined explicitly somewhere.  I think in general the rule should
> be that if a given feature is specified and a given font doesn't
> support it, the glyph used should be the same one used if the feature
> was not specified explicitly (i.e. whatever the OpenType engine
> defaults would be).  Having undefined per-feature defaults defined at
> an engine level is a recipe for incompatibility across user agents.

I agree. If a feature is not supported in the way that the author has 
specified in the CSS, then the feature should be ignored and not applied 
to the glyph string. So the displayed glyph will be either the default, 
cmap-encoded glyph or whichever glyph has been arrived at already 
through language shaping or other, supported features.

JH

Received on Tuesday, 28 September 2010 18:50:11 UTC