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

On 07/01/2013 01:07 AM, John Daggett wrote:
>
> I think if the spec is going to require "compression" of a tatechuyoko
> run to fit the run into 1em, then it should be defined clearly and not
> left undefined.  Specifically, I don't think synthesizing tatechuyoko
> from full-width glyphs should be allowed.  Allowing naive user agents
> to render this way will force authors to target the "least common
> denominator" rendering by avoiding full-width digits and I don't think
> that's a great idea.
>
> 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).
>
> Elika proposed something similar [1] but and Koji's response was "nah,
> undefined is better" [2].  However, I think if scaling to 1em is a
> requirement then how that occurs must to be defined explicitly.
> Leaving it undefined would force authors to work around naive
> implementations that simply scale whatever the content is, even if
> full-width codepoints are used.  I think the examples above make it
> plain that's not a good idea.

I think it would be *great* to put your algorithm here as an example
of good practice, and to point out the dangers of not converting
full-width codepoints to half-width variants.

However, I think I'm convinced by Koji and others that the spec's
normative requirements should leave the exact implementation of this
open, in case UAs are able to improve on it.

So I would like to include your algorithm in the spec as an example
of a good one, but not require it. Is that acceptable?

--

Wrt font-variant ... I don't think tate-chu-yoko should disable the
use of 'font-variant' except maybe to ignore full-width/proportional-width
(well, basically any width settings, which the UA should be messing with
on its own). If someone wants to use small-caps,or slashed-zero, or some
particular character-variant in their tate-chu-yoko, I don't see a problem
with that.

Or am I misunderstanding what you meant by the second sentence in #4?

> One additional note, I think the possible set of values for use with
> 'digits' should be limited to 2, 3, 4.  Anything else is nonsensical,
> theoretically possible but illegible in practice.

I'm also good with this change.

~fantasai

Received on Wednesday, 3 July 2013 01:02:06 UTC