Re: [css3-fonts] font-feature-settings syntax

Although, I.d be concerned about typing it so tightly to opentype and
restricting it to ecactly four characters.

So far I have only heard on one browser experimenting with this feature and
that browser is supporting both opentype and graphite tables.

Or is it being proposed that these css properties are opentype only and we
need to proposed and defined a series of parrallel css properties for other
font technologies, ie AAT and graphite?

Esp since the only cross-platform way of implenting fonts for some unicode
blocks is via graphite in the absences of shapers for opentype based font
rendering systems.

Andrew

On Friday, 20 April 2012, Christopher Slye <cslye@adobe.com> wrote:
> The second sentence in your new (and old) wording seems redundant. I
would omit it, to say:
>
> The <string> is a case-sensitive OpenType feature tag. As specified in
the OpenType specification, feature tags contain four ASCII characters. Tag
strings longer or shorter than four characters, or containing characters
outside the U+20-7E codepoint range must be treated as invalid. User agents
must not use a feature tag created by truncating or padding the string to
four characters.
>
> -Christopher
>
>
> On Apr 19, 2012, at 12:33 AM, John Daggett wrote:
>
>> The font-feature-settings in CSS3 Fonts currently has a relatively
>> simple syntax, it takes a comma-delimited list of strings with an
>> optional value or on/off keyword [1].  The strings represent OpenType
>> tags which are defined to be 4-character ASCII strings.
>>
>> Example:
>>
>>  /* enable small caps and use second swash alternate */
>>  font-feature-settings: "smcp", "swsh" 2;
>>
>> The spec contains the following wording:
>>
>>  The <string> is a case-sensitive OpenType feature tag. For it to
>>  match an OpenType feature contained in a font, it must follow the
>>  syntax rules for tags. As specified in the OpenType specification,
>>  feature tags contain four characters. Tag strings longer than four
>>  characters must be ignored, user agents must not use a feature tag
>>  created by truncating the string to four characters.
>>
>> This doesn't define clearly the behavior for smaller strings and
>> strings containing non-ASCII codepoints.  I'd like to tighten this up
>> to make it so that only four-character ASCII strings are considered
>> valid, since shorter strings or strings with non-ASCII characters
>> won't ever match an OpenType font feature and are most likely a typo.
>>
>> I propose changing the wording above to:
>>
>>  The <string> is a case-sensitive OpenType feature tag. For it to
>>  match an OpenType feature contained in a font, it must follow the
>>  syntax rules for these tags. As specified in the OpenType
>>  specification, feature tags contain four ASCII characters. Tag
>>  strings longer or shorter than four characters, or containing
>>  characters outside the U+20-7E codepoint range must be treated as
>>  invalid.  User agents must not use a feature tag created by
>>  truncating or padding the string to four characters.
>>
>> The current editor's draft also lists an issue as to whether quotes
>> should be required.  I think it would be best to resolve this now and
>> simply require quotes. The Webkit-prefixed version of Chrome on
>> Windows doesn't require them but the IE10 Preview version does.  I
>> think there was enough opposition to unquoted strings during the
>> original discussion of this [2] that it would make sense to require
>> quotes and remove the issue from the spec.
>>
>> Regards,
>>
>> John Daggett
>>
>> [1] http://dev.w3.org/csswg/css3-fonts/#font-feature-settings-prop
>> [2] http://lists.w3.org/Archives/Public/www-style/2011Mar/0280.html
>>
>
>
>

-- 
Andrew Cunningham
Senior Project Manager, Research and Development
Vicnet
State Library of Victoria
Australia

andrewc@vicnet.net.au
lang.support@gmail.com