Re: [css3-text][css3-fonts] 'text-transform' for Accents

Koji Ishii:
> Christoph, thank you for the reply.
>> 
>> I just believe that the interdependence of 'font-variant' and 'text-transform' should be carefully designed, i.e. more with authors in mind, less font technology.
> 
> Fonts technology and code point transformation is two different animals.

Like apes and monkeys, many people don’t know the difference, neither do they care.

> You may be right that some may think the two has somewhat similar effects, but I don't think there's a good way to merge them.

There has to be. Stylesheets are not written by font designers who have to know the mechanics, but by site designers who care about the visual result only.

>>> What text-transform does is code point transformation and it doesn't deal with font properties. "fixed" and "proportional" are the font properties, so they should be done in CSS3 Fonts. "fullwidth" is Unicode code point transformation, so we have that here.
>> 
>> For an author it doesn't matter much whether different glyphs or different characters are
>> used to achieve the same desired visual result. Therefore those properties should be
>> unified or closely connected, with code point transformation being the fallback for
>> unavailable glyph switching.
> 
> The two result very different visuals. It sounds to me like the difference between Courier and Arial is similar to the difference between uppercase and lowercase. I think the two should be separated for authors.

As far as I understand it, neither ‘font-variant’ nor ‘text-transform’ should change the font-family of affected charcters. (That could be specified as a fallback, though.)

The ‘text-transform’ value does hardly more than transforming characters from U+00wx to the corresponding ones in U+FFyz. This block exists for compatibility with legacy encodings and only covers a very minor set of non-sinographs. The more modern font feature approach can, in theory, support two or more glyphs with different widths for any character, whether of East Asian, European or other origin.

The ‘font-variant’ value which maps to Open Type feature ‘fwid’ selects wider glyphs for all characters that don’t default to “full width”. The only difference, besides a larger set of affectable characters, is that the width does not have to be 1em, i.e. the width of sinograms, but nevertheless is fixed.

<http://www.microsoft.com/typography/otspec/features_fj.htm#fwid>
| Replaces glyphs set on other widths with glyphs set on full (usually
| em) widths. In a CJKV font, this may include “lower ASCII” Latin
| characters and various symbols. 
| In a European font, this feature replaces proportionally-spaced glyphs 
| with monospaced glyphs, which are generally set on widths of 0.6 em.
|
| The user may invoke this feature in a Japanese font to get full 
| monospaced Latin glyphs instead of the corresponding proportionally-
| spaced versions.
|
| The font may contain alternate glyphs designed to be set on full 
| widths (…), or it may specify alternate (…) metrics for the
| proportional glyphs (…).

The ‘font-variant’ value which maps to Open Type feature ‘pwid’

<http://www.microsoft.com/typography/otspec/features_pt.htm#pwid>
| Replaces glyphs set on uniform widths (typically full or half-em) with 
| proportionally spaced glyphs. The proportional variants are often used 
| for the Latin characters in CJKV fonts, but may also be used for Kana 
| in Japanese fonts.
|
| The user may invoke this feature in a Japanese font to get a 
| proportionally-spaced glyph instead of a corresponding half-width 
| Roman glyph or a full-width Kana glyph.
|
| The font contains alternate glyphs designed to be set on proportional
| widths (…).

By the way, the notes on “script/language sensitivity” for these two features

 ‘fwid’:
| Applies to any script which can use monospaced forms.
 ‘pwid:
| Although used mostly in CJKV fonts, this feature could be applied 
| in European scripts.

support my view that the property name ‘font-variant-east-asian’ is inapropriate, at least for “<east-asian-width-values>”.

>> In some orthographies diacritic marks are mandatory on lowercase letters, but (…) optional on uppercase letters. This […] has mostly technical reasons:
>> 1. (most) accents on lowercase letters, especially roman vowels, fit easily above the base glyph and below the capital height, […] and
>> 2. some typewriter and computer keyboard layouts […] only feature the lowercase accented letters and the uppercase only with dead keys or not at all.
>> Although no linguistic harm is done when accents remain on uppercasing, some people nowadays are accustomed to not seeing capitals with diacritics […] 
>> Unicode defines the case pair with accents of course.
>> 
>>> Also, as you can see in the current spec, text-transform relies on Unicode …
>> 
>> I haven't looked for it [in Unicode] yet, but I think it's basically NFD (…) with […] combining accents removed.
> 
> I'm not sure if I understand it correctly, but it sounds like it can be better implemented in fonts if it were to fit glyphs into the capital height.

That perhaps would be reasonable for the ‘inline’ (or ‘incorporated’) value I proposed, but not so much for the more important ‘accent-free-capitals’ (or ‘plain-caps’) value. I don’t know whether some font designers implement this and which Open Type feature they would (ab)use for doing it, opaque ‘salt’ or ‘ssXY’ probably and less likely ‘titl’.

> That way, you can keep the original code points without increasing the line height.

AAT has a font feature to “hide” *all* accents, not only those on capitals. <http://developer.apple.com/fonts/registry/#Type9>

Open Type, as far as I know, does not contain a registered feature ‘accent-free capitals’ or the like <http://www.microsoft.com/typography/otspec/featurelist.htm>. Therefore existing fonts wouldn’t support it and it really seems easier to implement on the character level across fonts, because the base characters (and therefore glyphs) would pretty much always be available if the accented ones are.

Received on Friday, 18 March 2011 12:33:00 UTC