Re: [css3-writing-modes] Examples of normal, unscaled glyphs work better than width-variant glyphs for text-combine-horizontal

fantasai wrote:

> I'm looking over Example 20, and I don't see how it's inconsistent
> with the prose quoted above.

Heh, that's because it's now Example 19... :P

> EXAMPLE 19
> 
> For example, a simple OpenType-based implementation might compress the
> text as follows:
> 
>   1. Enable 1/n-width glyphs for combined text of n characters. (I.e.
>      Use OpenType hwid for 2 characters, twid for 3 characters, etc.)
>      Note that the number of characters ≠ number of Unicode codepoints!
> 
>   2. Horizontally scale the result to 1em if it is not yet 1em or narrower. 
> 
> A more sophisticated OpenType implementation might compose the text
> first with normal (proportional-width) glyphs to see if that fits,
> then substitute in half-width or third-width forms as available and
> necessary, possibly adjusting its approach or combining it with
> scaling operations depending on the available glyph substitutions. 

This example is inconsistent with the requirement to use width
variants when they are available and it makes assumptions about fonts
that are incorrect.  The term "normal (proportional-width) glyphs" is
incorrect in the context of digits, modern Japanese fonts typically
use *fixed-width* glyphs for digits and proportional glyphs for Latin
alphabetic characters.  Not exclusively but that's the common pattern.
The term "OpenType implementation" doesn't make sense either because
it's referring to the implementation of a layout feature that
interacts with OpenType features, not something that exists as part of
the implementation of OpenType layout table handling.

The distinction between a "simple" and "sophisticated" implementations
is based on assumptions about what works that don't hold true in
practice. We've resolved to leave undefined the behavior for cases
where a font has width variants for some characters but not all.  For
other cases, the behavior is specified, there's no difference between
"simple" and "sophisticated" implementations.

I suggest that we simply omit this example.  It's incorrect,
misleading and I don't think it's really important since the case it
does cover is an edge case rather than normal usage.  We could fiddle
around with the text of this but to move to LC more quickly I would
suggest we just drop this example.

Cheers,

John Daggett

Received on Friday, 20 September 2013 01:45:35 UTC