[css3-writing-modes] text-combine and tatechuyoko

Some quick comments on the 'text-combine' property in the CSS3 Writing Modes spec:

http://dev.w3.org/csswg/css3-writing-modes/#text-combine

> Glyph Composition: the ‘text-combine’ property

The "glyph composition" heading is left over from an older definition of
this property that included a 'kumimoji' value for use in automatically
constructing four-character compound glyphs.  Since this property is
only for supporting tatechuyoko (literally "horizontal within
vertical"), I think the name of the property and the heading would be
more accurately described as:

Horizontal spans within vertical text: the 'text-inline-horizontal' property

Doesn't exactly roll off the tongue but it's a name that's closer to the
actual function than the rather generic 'text-combine'.

> In vertical writing mode, attempt to display the text contents of the
> element horizontally within the vertical line box, ideally within the
> space of one ideographic character (1em square).
> 
> The glyphs are stacked horizontally (similar to the contents of an
> inline-box with a horizontal writing mode and a line-height of 1em)
> and the baseline of the resulting composition chosen such that it is
> centered between the content edges of its parent inline box. 

This doesn't quite capture the essence of tatechuyoko.  This isn't a way
of specifying arbitrary horizontal inline text runs in vertical text,
the idea is to use the space of one em-box more efficiently for two or
three digit numbers and sometimes Latin letters. The JIS X4051 spec
includes an interesting example in section 4.8 where 5.8% is laid out in
vertical text with "5.8" appearing in the space of a single character
box:

  http://people.mozilla.org/~jdaggett/images/tatechuyoko-percent.png

This is an interesting example because it shows the relative power of
tatechuyoko to improve readability (compared with '5' '.' '8' '%' laid
out vertically in four separate character boxes).  But it shows that the
key is not the number of characters but the relative width of the
resulting composition.

So I think there are two key attributes of this property (1) it only
applies to text spans containing characters with intrinsic horizontal
orientation and (2) authors need a way to limit the use of specific
widths.  Newspapers love to use compactions like '1000' fit into a
single character box by using quarter-width glyphs but that's ugly as
sin.

So maybe a better way of formulating this is:

  text-inline-horizontal == none | half | third | quarter
  
If the value is anything other than 'none' is set, consecutive sequences
of intrinsically horizontal characters are rendered horizontally as long
as the width of that sequence fits within the line box. We could
restrict this to an em-box but common practice seems to be to let it
slip out of the box a bit.  Here 'half' means render as tatechuyoko but
don't use third or quarter width glyphs.  The existing wording leaves
the rendering behavior up to the user agent but that's a really bad
idea, you'll end up with bad interoperability that way.

For spans that don't fit into a single character box, they are treated as though
the value for this property was set to the initial value of 'none'.

There's also an interaction here with 'text-transform: full-width' and
the 'font-variant-east-asian: full-width' that needs to be explicitly
worked out.  If glyphs are placed inline horizontally, then both of
these values should be ignored I think (text-transform is nasty because
of the potential line-breaking impact).

There an example in the spec:

平成<span class="num">20</span>年
<span class="num">4</span>月
<span class="num">16</span>日に

Three spans?  Ick.  It would be nice if this could be formulated to 
avoid this sort of span pollution.

.date {
   text-inline-horizontal: half;
   font-variant-east-asian: full-width;
}

<span class="date">平成20年4月16日</span>に

<span class="date">2010年4月16日</span>に

The first date would appear as shown in the spec example.  The second example
would render '2010' as four consecutive vertically stacked glyphs.

Received on Wednesday, 1 June 2011 22:44:58 UTC