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

I changed subject to reflect what we're discussing.

> I don't think CSS should transform characters,
> just glyphs and only in a way that does not affect
> other properties.

Why not? The text-transform property is and has been a feature to transform characters, not glyphs as far as I know. As you said, if the use case was about glyph transform, it should be in CSS Fonts. The fullwidth feature is driven by actual users' requests, and there is a use case. The use case requests to transform characters, and therefore we're proposing to add a new value to text-transform.

You can request to add such feature if you have use cases, it will then be CSS Fonts feature rather than text-transform.

> However, does this code point transformation do
> anything implicitly to default line-breaking, justification
> etc. that could not be specified explicitly with (future)
> CSS properties (in contrast to just Open Type)?

No, not that I know of. 

> It would not be inadequate then to ask authors to use
> two properties instead of one, if this makes the overall
> model cleaner.

Authors I have been talking to will use text-transform:fullwidth rather than 'fwid' OpenType feature even if it was added to CSS Fonts, so I'm not asking authors to use two features.

If you know authors who want to use OpenType 'fwid' feature, you can ask this ML to add it. But their use cases would be different from the one I know, and therefore authors would not overlap. As I said, feature doesn't overlap either. The only common is glyph ID in OpenType fonts. Other aspects are different; other aspects include line-breaking etc. and also workable with non-OpenType fonts.

> The existing transformations for bicameral scripts
> don't affect anything but looks (glyphs) and metrics.

The spec clearly says it should transform code points using Unicode case mapping. It usually doesn't affect line breaking because original code point and transformed code point share the same property values used in CSS line break. But it's a result, not a definition. If Unicode mapping includes changes in property values used in CSS, it should be affected. I'm not sure if it's happens today, or just a possibility in future though. Unicode case mapping is complex enough for me to know everything.

> Maybe not, but they probably can be done using a combination of CSS features.

Not that I know of. I guess other CSSWG members don't know either as this feature has been reviewed more than a few times. If you know, I'd be happy to know.

> Maybe it would be if it were the only option. What
> would happen with my family name, for instance, if
> a UA tried "text-transform: fullwidth" on it, since there
> is no monospaced (precomposed) 'ä' in the compatibility
> block?

It will not be transformed, because Unicode does not define <wide> mapping for U+00E4. It's just like PERIOD is not transformed by text-transform:uppercase.

I'm not sure if recent OpenType fonts includes 'fwid' feature for U+00E4, but as long as user's font doesn't have 'fwid' defined for U+00E4, CSS Fonts can't do anything either.

I don't think the fact that it can't transform U+00E4 would reduce the value of the feature at all.

>> A lot of real web pages in East Asia use it today,
>
> You mean they use the compatibility wide roman
> characters verbatim? That's another story and does
> not prove a usecase for text transformation yet.

Since CSS doesn't support the feature, users today do this by server-side script, XSLT, or javascript. I understand it is our goal to make stylistic changes in CSS without relying on such technologies. If we eliminates all features that can be done by such technologies, we'll lose a lot of features from CSS.

For server-side scripts, you can look at features provided by ICU[1] or Strings.StrConv function in .NET[2].

>> ['fwid' is] more modern and could provide more glyphs. I completely agree with you on that.
>
> So let's use that, in form of a CSS property of course
> - hopefully better named than "font-variant-east-asian:
> full-width", though.

Again, I don't have any use cases for the feature for 'fwid'. That's why I'm not requesting, but I don't stop you or anyone from requesting such feature. Rather, I'm asking you to do so if you have use cases. I agree that it's a nice feature, but I can't request because I don't have use cases.

Actually, CSS3 Fonts has low-level font feature settings control: the 'font-feature-settings' property[3]. I suppose you can use this feature to access 'fwid' feature in OpenType, if it solves your problem. It doesn't solve my problem though.


Regards,
Koji

[1] http://site.icu-project.org/
[2] http://msdn.microsoft.com/en-us/library/microsoft.visualbasic.strings.strconv.aspx
[3] http://dev.w3.org/csswg/css3-fonts/#font-feature-settings-prop

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Christoph Paper
Sent: Friday, April 08, 2011 9:44 PM
To: www-style@w3.org list
Subject: Re: [css3-text][css3-fonts] 'text-transform' for Accents

Koji Ishii (2011-03-22):

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

A "sinogram" - "sinograph" is used almost synonymously - is basically what Unicode calls an "ideograph". <http://unicode.org/faq/han_cjk.html#17>

> The 'text-transform' does code point transformation and therefore it affects line break, justification, etc., while OpenType 'fwid' does not.

I don't think CSS should transform characters, just glyphs and only in a way that des not affect other properties. However, does this code point transformation do anything implicitly to default line-breaking, justification etc. that could not be specified explicitly with (future) CSS properties (in contrast to just Open Type)?

It would not be inadequate then to ask authors to use two properties instead of one, if this makes the overall model cleaner.

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

The existing transformations for bicameral scripts don't affect anything but looks (glyphs) and metrics.

> I wrote several use cases of fullwidth a week ago[http://lists.w3.org/Archives/Public/www-style/2011Mar/0320.html], and these cannot be done by OpenType features.

Maybe not, but they probably can be done using a combination of CSS 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.

Maybe it would be if it were the only option. What would happen with my family name, for instance, if a UA tried "text-transform: fullwidth" on it, since there is no monospaced (precomposed) 'ä' in the compatibility block?

> A lot of real web pages in East Asia use it today,

You mean they use the compatibility wide roman characters verbatim? That's another story and does not prove a usecase for text transformation yet.

> ['fwid' is] more modern and could provide more glyphs. I completely agree with you on that.

So let's use that, in form of a CSS property of course - hopefully better named than "font-variant-east-asian: full-width", though.

Received on Friday, 8 April 2011 16:15:36 UTC