- From: John Daggett <jdaggett@mozilla.com>
- Date: Wed, 10 Mar 2010 04:45:47 -0800 (PST)
- To: Christoph Päper <christoph.paeper@crissov.de>
- Cc: www-style list <www-style@w3.org>
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