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

On 07/10/2013 01:11 AM, John Daggett wrote:
>
> fantasai wrote:
>> jdaggett 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)
>>
>> 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.

Sorry, "variant" is also used in describing Unicode character variants,
so the text is per resolution. However, I accept the terminology is
ambiguous because "variant" is also used to describe font glyph variants,
so I've changed it.

> Example 20 also makes it appear that this behavior is optional,
> which isn't what was resolved last week.

I've removed Step 1. Let me know if that's sufficient or you want
something else.

> The reason it's important to do this at the codepoint level is for

Yeah, I know. I'm not disagreeing here.

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

We're already breaking "the model" by doing codepoint transformations
for a property other than text-transform. I don't have a problem with
this, because as you've argued, it makes sense, gives better results,
and satisfies use cases, whereas not doing it gives bad results and
doesn't satisfy any real use case.

I don't see why breaking "the model" by tweaking the font feature
stack in a well-defined way is so much more special that the same
arguments you gave for the codepoint transformation do not apply.

~fantasai

Received on Wednesday, 10 July 2013 15:50:40 UTC