W3C home > Mailing lists > Public > www-style@w3.org > September 2013

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

From: John Daggett <jdaggett@mozilla.com>
Date: Mon, 23 Sep 2013 19:47:45 -0700 (PDT)
To: Koji Ishii <kojiishi@gluesoft.co.jp>
Cc: www-style@w3.org
Message-ID: <1485586421.208448.1379990865493.JavaMail.zimbra@mozilla.com>

Koji Ishii wrote:

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

It was added as an example before we resolved to require the use of
width variants. That's the problem with the example now,
it muddles the distinction between normative and optional behavior:

http://dev.w3.org/csswg/css-writing-modes/#text-combine-compression

Current wording of example in section 9.1.3 (including changes that
don't appear yet due to null-file checkin snafu):

# 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 different implementation that utilizes OpenType layout features
# might compose the text first with normal 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. 

I think this whole example is problematic.  The use of "simple" is
problematic, as is the use of "might".  It also implies there will be
variations in behavior across implementations when, in the vast
majority of cases, combinations of digit glyphs won't fit within 1em
so the use of width variants is *required* behavior and there should
be no difference between "simple" and "non-simple" implementations.

This example really only applies to special cases when 'all' is used
with specific content (e.g. 'iii').  Once you've detailed the actual
conditions under which variations might occur, I think the utility of
this example is fairly low.

In the interests of moving the spec to LC quickly, I would suggest
that we simply omit it.

Regards,

John Daggett
Received on Tuesday, 24 September 2013 02:48:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:34 UTC