Re: advanced font features in CSS

>> For example, OpenType allows distinct sets of glyphs with
>> a common style to be specified independently but the 'styleset' value
>> defined here is associated with a single numeric value, so only one of
>> these stylesets could be applied at a time.
> 
> Why on earth would you do that?

Um, can you explain a little more?  Are stylesets commonly used as
distinct sets that can be mixed?  That seems to be the theory, I wasn't
sure whether fonts implemented this in practice.

>> Others, such as the CJK related glyphset and width properties listed
>> below seem like interesting candidates for inclusion but I'm still
>> unsure of the exact set of properties/values that are supported
>> currently.
> 
> What do you mean by "supported" in this context? By fonts, by the
> spec, by applications?
>
>> Other properties still under investigation
>>
>>   font-variant-east-asian: normal | [<char-variant-value> | <char-width-value>]+ ;
>>   <char-variant-value> :== hojo-kanji | jis04 | jis78 | jis83 | jis90 | nlckanji | simplified | traditional | traditional-names
>>   <char-width-value>   :== full-width | half-width | third-width | quarter-width | proportional
> 
> Under investigation by whom? What do you want to know?

I'm wondering about the support for these variations in fonts and to
what degree they are needed.  Are all these values still in common use
or have some been obsoleted by later additions?  I just want to confirm
that the answer is yes before adding them so that we don't end up with
variations that exist in theory but aren't in use.

I'm also concerned that there's some crossover with support for Unicode
variation sequences and in some ways that might be a better way to
support this (i.e. encourage the use of Unicode variation sequences,
look up to see if a font supports a given variant and fallback if it
doesn't).  "Under investigation" just means I'm still scratchin my
noggin' about it.  

>> Some feature selections only apply to a single font.  Swashes and
>> styleset values are defined differently across fonts,
> 
> Yes for stylistic sets, no for swashes.

Interesting, I've heard others say just the opposite, namely that
swashes are very contextual, one designs with a specific font in mind. 
When fallback occurs 'swash 5' will have a completely different meaning
to another font.

>>   normal: clears all features below, uses font defaults
>>   common-ligs: liga (OT), ligatures = common (AAT)
>>   additional-ligs: dlig (OT), AAT?
>>   historical-ligs: hlig (OT), ligatures = rare (AAT)
>>   no-xxx: disables features above
> 
> Here you do have a problem in that the mapping between OT and AAT is
> imperfect, and some bits of each do not clearly map to the other. In
> essence you need to either pick one and squish the other into that
> mold, or define unique properties where there isn't a clear mapping
> (in the latter case, you'd give a separate feature for AAT "rare"
> ligatures which would seem to be an amalgam of dlig and hlig).

I realize this, I think the best way is to target OpenType features and
try to do the best possible for AAT features.  Maybe both
additional-ligs and historical-ligs should enable AAT rare ligatures?

> >   normal: clears all features below, uses font defaults
> 
> Hmmm. According to the OpenType spec, and most OpenType supporting
> applications, certain features should be on by default. Can you explain
> why you don't want to do that? Or was this only in reference to the
> specific features listed in this section (which would be fine)?

Right, the latter. Similar to other CSS properties, 'normal' here
implies that any CSS enabling/disabling settings are cleared and returns
to the default behavior of the font.

>>   <caps-value> :== small-caps | petite-caps | titling-caps
>>
>> where these keywords imply the following underlying features
>>
>>   normal: clears all features below, uses font defaults
>>   small-caps: smcp (OT), letter case = small caps (AAT)
>>   petite-caps: pcap (OT), not in AAT
>>   titling-caps: titl (OT), style options = titling caps (AAT)
>>
>> All capitalization values are mutually exclusive.
> 
> So you don't want to provide access to the usual features to map from
> caps to small caps (and petite caps)? The above features for smcp and
> pcap only map from lowercase characters. Given the HTML/CSS desire for
> separation of form and content, and the desire to keep the original
> content intact, this seems like a mistake. Surely you don't want the
> underlying text to have to read "unesco" rather than "UNESCO" just
> because the designer wanted to format it in small caps?

Wasn't sure about this.  CSS already has text-transform: lowercase, it
seemed like you could define the combination of text-transform:
lowercase and font-variant: small-caps to imply enabling those features
if available, otherwise use character transform + small/petite caps. 
That way authors already doing this today would get the right thing.

Cheers,

John

Received on Monday, 29 June 2009 09:05:16 UTC