Re: Preparing for CSS Writing Modes LCWD

<resend to www-style>
I have some comments:

> 9. Glyph Composition: the ‘text-combine-horizontal’ property
> 
> Name:	text-combine-horizontal
> Value:	none | all <integer>? | [ [digits <integer>? || ascii-digits <integer>? ] || [ alpha <integer>? | latin <integer>? ] || alphanumeric <integer>? ] && [ scale | no-scale || use-glyphs ]?
> Initial:	none
> Applies to:	non-replaced inline elements
> Inherited:	yes
> Percentages:	N/A
> Media:	visual
> Computed value:	specified value
> This property allows the combination of multiple characters into the space of a single character. This property only has an effect in vertical writing modes. Values have the following meanings:
> 
> none
> No special processing.
> all
> 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. (See below.) The resulting composition is treated as a single glyph for the purposes of layout and decoration. If the content contains any element boundaries, or if it contains more characters than the integer given (if any), this is treated as ‘text-combine-horizontal: none’.

This last part looks like auto-TCY (a paragraph attribute in InDesign). Is that the intended use? That you set text-combine-horizontal on all the text and specify 2 digits, etc., and the UA then makes TCY runs out of the contiguous runs of digits?

I find this kind of confusing since auto-TCY and TCY runs are a separate thing, yet here you allow for both (I guess, since <span> is your unit and it can be a paragraph, or a long run, or just the TCY run?).

I would have made auto-TCY its own attribute just to make the syntax simpler. I would allow manual TCY to just put whatever is in the span in a single TCY. No digits or character types needed.

> digits
> Within the element, each sequence of consecutive horizontal digits that has as many or fewer characters than the integer given (or 2, if no integer is given) is treated as if it were in an anonymous inline box with ‘text-combine-horizontal: all’. For this property, a digit is any character belonging to a Number category (N*) that does not belong to a vertical script.
> ascii-digits
> Within the element, each sequence of consecutive ASCII digits (U+0030–U+0039) that has as many or fewer characters than the integer given (or 2, if no integer is given) is treated as if it were in an anonymous inline box with ‘text-combine-horizontal: all’.
> This definition is would replace ‘digits’ as a simplification.
> 
> alpha
> Within the element, each sequence of consecutive horizontal letters that has as many or fewer characters than the integer given (or 2, if no integer is given) is treated as if it were in an anonymous inline box with ‘text-combine-horizontal: all’. For this property, a horizonal letter is any character belonging to a Letter category (L*) that does not belong to a vertical script.
> latin
> Within the element, each sequence of Latin letters that has as many or fewer characters than the integer given (or 2, if no integer is given) is treated as if it were in an anonymous inline box with ‘text-combine-horizontal: all’. For this property, a Latin letter is any character belonging to a Letter category (L*) that also belongs to the Latin script.
> This definition is would replace ‘alpha’ as a simplification.
> 
> alphanumeric
> Within the element, each sequence of consecutive horizontal digits and/or letters that has as many or fewer characters than the integer given (or 2, if none is given) is treated as if it were in an anonymous inline box with ‘text-combine-horizontal: all’.
> use-glyphs
> If the UA has alternate-width glyphs available for the contents of the element, then it must use those glyphs to attempt sizing the contents to 1em square. For example, a one-digit number would use a fullwidth glyph, a two digit number would use halfwidth or proportional glyphs, a three-digit number would use 1/3-em glyphs (if available, else halfwidth or proportional glyphs), etc. If such glyphs are not available (and ‘no-scale’ is not specified), the UA must compress the composition horizontally until it fits within the width tolerance of 1.1em.

Why 1.1 em? Seems arbitrary and not technically correct, and the user would want to set that threshold themselves if they care.

Substituting full-width for a single digit is unexpected. In my mind a full-width digit is not TCY, and if the user set TCY on a run, they would use the character they want, not want it to be automatic. However, they do want glyphs that are 1/2 or 1/3 or 1/4 em.

There is a need for automatic setting of glyphs to a given width, including full-width for single digits, etc. This feature is used in lists, and should be its own property, not combined into TCY.

> scale
> Compress the composition horizontally until it fits within the width tolerance (1.1em). Do not substitute alternate-width glyphs.

You would only want to scale down in this case, not up. And why 1.1 em?

> no-scale
> Do not compress the composition or perform any glyph substitution in order to make the composition fit within the tolerance. This may cause the glyphs to overflow the line significantly.


--Nat

On 2011/07/22, at 18:52, fantasai wrote:

> On 06/27/2011 10:57 PM, Nat McCully wrote:
>> On 2011/06/28, at 6:43, fantasai wrote:
>>> On 06/26/2011 07:47 PM, Nat McCully wrote:
>>>> Normally the em body escapement is scaled 80% or so for newspaper fonts, so the TCY
>>>> height automatically is scaled 80% as well. The line "height" is 100%, so the TCY
>>>> widths are unscaled.
>>>> 
>>>> For layout engines that are less savvy, the user must manually scale the TCY to
>>>> match the body escapement.
>>> 
>>> Does the scaling scale the limits, or does it also scale the glyphs?
>> 
>> For TCY the glyphs themselves are scaled to match the rest of the text.
> 
> Ok, here's what I've got:
> 
> http://dev.w3.org/csswg/css3-writing-modes/#text-combine
> 
> Let me know if that's sane, or I should fix anything. :)
> 
> ~fantasai

Received on Sunday, 24 July 2011 17:15:44 UTC