Re: advanced font features in CSS

Some detailed comments below. Generally, this is exciting stuff!

On Mon, Jun 29, 2009 at 2:51 AM, John Daggett<> wrote:
> Below is a proposal for supporting in CSS advanced font features found
> in OpenType and AAT fonts.  Supporting features available in "smart
> font" formats like OpenType and AAT presents a quandary, there are lots
> and lots of features

Very true.

> and the list is constantly evolving.

Hardly at all. OpenType has about 100 features (counting things like
stylistic sets and character variants as one each, mind you) and
something like five of those were added in the last five years.

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

> OpenType also contains many language-specific features; some of these
> are best left to the control of the shaping engine using them.


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

In any case, they are both useful and relatively important, and at
least most should be included.

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

>   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).

> Note: no control over rlig, required ligatures, since this should be
> under the control of the shaping engine.  Should "common" ligatures be
> labeled another way?  "default"?

Probably, yes.

>   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)?

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

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



Received on Monday, 29 June 2009 08:29:29 UTC