Re: [css3-writing-modes] real vs. synthetic width glyphs

fantasai wrote:

>> I would propose that the process of laying out tatechuyoko runs be:
>>
>> 1. Convert full-width codepoints to their default equivalents (i.e.
>>     full-width digits would switch to their ASCII digit equivalents)
>> 2. Based on the length, apply the appropriate OpenType feature
>>     (i.e. half/third/quarter width)
>> 3. Scale the result to 1em if necessary
>> 4. Treat the resulting composition of glyphs as a single glyph that
>>     matches the metrics of typical ideographic glyphs for the font used
>>     (i.e. does *not* affect the size of the inline box).  The resulting
>>     composition of glyphs is defined to have no available substitions
>>     (i.e. none of the font-variant/font-feature-settings affect the
>>     rendering of the composition).
> 
> Alright, I've tried to add your proposed algorithm as resolved in
>    http://lists.w3.org/Archives/Public/www-style/2013Jul/0105.html

The wording in the spec doesn't accurately reflect step (1):

# In order to preserve typographic color when compressing the text to
# 1em, when the combined text consists of more than one character,
# then any full-width characters must first be converted to their
# proportional variants.

Step (1), which was resolved as required behavior last week, is to
convert the *codepoints* from full-width to their default equivalents.
This is a character level operation, not a glyph level operation which
the use of "variant" implies.  Example 20 also makes it appear that
this behavior is optional, which isn't what was resolved last week.

The reason it's important to do this at the codepoint level is for
older fonts like MS Mincho which don't support OpenType features. 
This avoids case (2) in the examples below independent of whether the
font supports width-specific variants or not:

http://lists.w3.org/Archives/Public/www-archive/2013Jul/0011.html

# Also, a ‘font-variant’ value of ‘full-width’ must be ignored in such
# cases: whether applied via ‘@font-face’ descriptor or property
# declaration, within the combined text this value does not not cause
# the UA to enable that font feature. [CSS3-FONTS]

I've said this before, both on the list and in person, this statement
is in conflict with the rendering order specified in the Fonts spec:

  http://dev.w3.org/csswg/css-fonts/#feature-precedence

Step (4) is where other CSS features influence feature state.  What
you've spec'ed is that it override (5) or maybe (6).  I think this is
a bad idea for a number of reasons.  It complicates the simple rule
that font variant features override other features only for the reason
of excluding one possible "bad scenario", namely the enabling of
full-width variants.  But an author could just as easily cause
problems by specifying other width variants, swashes or annotated
figures. I don't think it's worth muddying up the feature precedence
model simply to avoid one particular mistake authors may make.

I would propose that either font-variant/font-feature-settings has no
impact on tatechuyoko runs, since you're in fact synthesizing a single
"glyph" out of a set of characters or there's simply no auto-disabling
of features like this.

You can think of this as similar to an author writing this combination
of properties:

  .silly {
    text-transform: full-width;
    font-variant-east-asian: proportional-width;
  }

This is silly but possible.  Should user agents try to "prevent" it in
some way? I just don't think it makes sense to require complicated
logic for the sake of preventing authors from doing silly things. 
Keep the model simple and make it so authors understand the authoring
model well enough to be able to figure out what's going on when something
doesn't look right.

Regards,

John Daggett

Received on Wednesday, 10 July 2013 08:12:22 UTC