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

Hmm...I guess I'm a bit lost about what we're discussing.

If I understand correctly, you proposed that you may have better solution to the requirement I'm trying to solve by text-transform: fullwidth. I was very happy to hear such proposals, but unfortunately, it turned out that it didn't meet the requirement.

OpenType feature is nice. It looks like you're a big fan of that, and I'm glad to hear that as I like that too. But what authors need here is a feature that works against any fonts, including TrueType, WOFF, SVG fonts, etc. Even some OpenType fonts may not have 'fwid' feature since it is an optional feature that font designers can opt in.

So, I can't even compare which of the two, OpenType feature or code point transformation, is better in general. They are two different tools each of which has its own strengths and weaknesses.

It looks to me that I'm talking about which one can meet the authors' requirements, while you're talking OpenType feature strengths and Unicode <wide> mapping weakness. To me, whether an option can meet the requirements or not is more important. If an option doesn't meet the requirement, it's no longer an option, no matter what the strengths it has.

I understand Unicode <wide> mapping is not perfect and has some weaknesses, just like ones you pointed out. But as long as it is the only option that meets the authors' requirements, and authors agreed that the weaknesses are reasonably acceptable, I can't find any problems to design a CSS feature based on Unicode mapping.

If you still think I'm trying to take a wrong way, or have better proposal that meets the requirements, I'd be more than happy to hear that.


Regards,
Koji

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Christoph Paper
Sent: Monday, April 11, 2011 5:15 PM
To: www-style@w3.org list
Subject: 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 14:46:18 UTC