Re: [css3-fonts] opentype font feature support

Christoph Päper wrote:

> 6.3.3 Ornaments
> 
> The OT feature ‘ornm’ has two modes. CSS must not use the one that
> replaces normal (ASCII) characters with ornaments, because that
> degrades badly. (Generated content /might/ be a different case.) CSS
> may support the other mode, i.e. alternates for the bullet U+2022.
> I’m not sure this feature is worth it, though.

I realize the point you're making here, I'm not sure whether an OT
engine can support one style and not the other. 

> 6.3.4 Annotation
> 
> I’m not really sure what ‘alt-annotation’ is supposed to do, but it
> got to lose the ‘alt’ prefix at least.

Point taken about the name.

This is the OT 'nalt' feature, it's often supported in CJK fonts that
provide glyphs for boxed numbers, circled numbers etc. but it's not a
CJK font feature per se.  The downside is that the OT spec doesn't
define a way to identify these consistently across fonts so it's hard
to specify "boxed" vs. "circled" in a font agnostic way.

> Otherwise ‘annotation’ might be similar to and could therefore be
> unified with ‘ruby’.

The 'ruby' feature picks glyphs specifically designed for use in ruby
but it does not affect layout in any way.  It is completely unrelated
to annotations.

> 6.6.1 Sinogram variants
> 
> If I read [OPENTYPE-FEATURES] correctly, ‘hojo’ are from 1990, and
> ‘nlck’ – there should be a hyphen in the CSS value, if it remains –
> are from 2000 and ‘jp04’ is a subset thereof. Although recent, these
> somewhat qualifiy as historic forms (6.3.5). ‘tnam’ is also specific
> to Japanese, but a ‘name’ <application> (6.3.5) does not have to be.

These are like historic forms with one very important distinction,
they indicate a defined form for a set of glyphs that will be
consistent across fonts, unlike historic forms.

> Simplified and traditional forms may be selected by language code
> (with area or time subcode), or by <complexity> (6.3.5).

That might be an interesting conceptual model for specifying
simplified vs. traditional forms but the feature here is based on the
concrete implementation available in OpenType, namely the 'trad' and
'smpl' features.  What you're proposing is more like custom features
in AAT where a font can define a custom variation axis such as
"complexity" and vary the glyph forms based on values along this axis.
Great functionality, not widely supported unfortunately.

> 6.6.2 Character width
> 
> There is no reason <char-width-value> couldn’t be applied to Western
> scripts, although we call “full” width “fixed” or “monospaced”.
> Actually “full” (‘fwid’) rather contrasts with “half” (‘hwid’,
> ‘halt’) or other fractions (“third” ‘twid’, “quarter” ‘qwid’).
> 
>   font-variant-width:       normal | proportional | fixed
>   font-variant-width-fixed: full | half | third | quarter

The features in the spec now are specific to Japanese, I don't think
it's easy or desirable to generalize them across languages.  Some of
the OT width features are confusing, they appear to be a continium
(full, half, third, quarter) but 'full' relates to kanji and kana,
'half' only to kana and punctuation while the other two are special
forms for numbers in vertical text.  

Here again, if there is functionality supported by fonts it makes
sense to consider supporting it in CSS but it doesn't make sense to
design something for functionality that doesn't exist.

> 6.9 font-lang-sys: normal | inherit | <string>
> 
> This property currently uses OT language tags which are not really
> well designed or know as far as I know. It would be better for authors
> to use [BCP47] and let UAs do the mapping. Why is this abbreviated as
> much as it is? ‘font-language-system’ would still be shorter than
> ‘font-variant-east-asian’.

In general I agree, it's better for authors to use the lang attribute
to specify the language of their markup.  But it's hard for authors to
always control the language tags supported by their fonts.  In some
cases using the typographic conventions of a language distinct from
the language of the text is necessary.  This property exists as an
override for those exceptional situations, not as the norm.

As for the property name, 'font-language-system' sounds better.

Received on Wednesday, 10 March 2010 12:46:21 UTC