Re: [css3-text][css3-fonts] text-transform: fullwidth

Koji Ishii:
> 
> The text-transform property is and has been a feature to transform characters, not glyphs as far as I know.

Until now it just transformed case pairs, without any external effect. ‘fullwidth’ would effectively transform a roman character into a sinogram (i.e. across scripts), although visually still resembling the former.

>> does this code point transformation do anything implicitly to default line-breaking, justification etc. that could not be specified explicitly with (…) CSS properties (…)?
> 
> No, not that I know of. 
> 
>> It would not be inadequate then to ask authors to use two properties instead of one,

I meant that if

  font-variant-east-asian: full-width;
  line-break: east-asian;
  text-justification: east-asian;
  /* or something like that, I didn’t look up
     the appropriate properties and values */

can replace

  text-transform: fullwidth;

then it should.

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

Why would they do that – because of (older) fonts not supporting the Open Type feature, but containing the compatibility characters?

> If you know authors who want to use OpenType 'fwid' feature, you can ask this ML to add it. 

The ED of CSS3 Fonts currently has a ‘full-width’ value for the ‘font-variant-east-asian’ property that basically maps to the pen Type ‘fwid’ feature. You should know that.

>> 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 shouldn’t say so, because that would mean that if I copy the styled text

  <foo style="text-transform: uppercase; color: green">bar</foo>

from a browser into a plain text editor where I expect

  bar

the transformations would stay intact

  BAR

whereas all other styles were lost. That is not a desirable behavior.

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

That’s awful.

> because Unicode does not define <wide> mapping for U+00E4.

It does for U+0061 ‘a’, why not require the UA to decompose U+00E4 ‘ä’ into U+0061+0308 and finally have U+FF41+0308 displayed?

> 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 know much about the technical internals, but the thing is you can reuse the metrics of the glyph(s) of U+0061 for those of U+00E4 and others.

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

I do.

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

The question is whether this is a stylistic change or if this server-side codepoint transformation is just an input manager like the “smart quotes” feature that transforms ‘"…"’ to ‘“…”’ (or language-dependent alternatives).

Has someone suggested “text-transform: curly” (or the like) for ‘'’ → ‘’’ etc.?

Received on Monday, 11 April 2011 08:15:39 UTC