W3C home > Mailing lists > Public > www-style@w3.org > March 2011

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

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Tue, 22 Mar 2011 09:51:31 -0400
To: Christoph Päper <christoph.paeper@crissov.de>, "www-style@w3.org list" <www-style@w3.org>
Message-ID: <A592E245B36A8949BDB0A302B375FB4E0AB3D54EE9@MAILR001.mail.lan>
I'm focusing on the width here as that's my expertise and I hope others help accents.

I don't know what "synograph" is, nor my dictionary does either, so I'm not sure if I understand what you wrote correctly. But if I do, aren't we saying the same thing?

The 'text-transform' does code point transformation and therefore it affects line break, justification, etc., while OpenType 'fwid' does not. The two may produce the same visuals if font designer wanted to do so, but the core value of the 'text-transform' is that it does code point transformation. I wrote several use cases of fullwidth a week ago[1], and these cannot be done by OpenType features.

You're right that it uses compatibility area and the area is not comprehensive, but is still good enough for a lot of use cases in East Asia. A lot of real web pages in East Asia use it today, and the feature is for such authors. If you need more characters with modern fonts, and you don't need to change line break, justification, etc., you're right that 'fwid' is the feature to use. It's more modern and could provide more glyphs. I completely agree with you on that.

We could add a note saying something like "text-transform: fullwidth is a feature designed for a specific needs for East Asian scripts. Authors who wants more generic feature can use 'fwid' OpenType feature instead," if this helps you feel better.

[1] http://lists.w3.org/Archives/Public/www-style/2011Mar/0320.html


Regards,
Koji

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Christoph Paper
Sent: Friday, March 18, 2011 9:32 PM
To: www-style@w3.org list
Subject: 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 Tuesday, 22 March 2011 13:52:49 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:38 GMT