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

Thank you for the feedback.

- The "(proportional-width)" removed.
- The term "OpenType implementation" changed.
- The "sophisticated" removed.

> I suggest that we simply omit this example.

I think we once resolved to add your algorithm as an example, so it's easier to edit than remove. Hope this edits resolve all your feedback.

/koji

-----Original Message-----
From: John Daggett [mailto:jdaggett@mozilla.com] 
Sent: Friday, September 20, 2013 10:45 AM
To: www-style@w3.org
Subject: 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 Monday, 23 September 2013 20:04:07 UTC