W3C home > Mailing lists > Public > www-style@w3.org > January 2011

Re: [css3-writing-modes] auto text-combine requirements

From: John Daggett <jdaggett@mozilla.com>
Date: Mon, 17 Jan 2011 21:03:58 -0800 (PST)
To: Koji Ishii <kojiishi@gluesoft.co.jp>
Cc: www-style@w3.org
Message-ID: <1924022066.12435.1295327038495.JavaMail.root@cm-mail03.mozilla.org>
Koji Ishii wrote:

> We had some discussions in Japanese ML about the requirements
> for auto text-combine mentioned in the current writing modes
> spec[1].

Could you include a link to these discussions, if they are public?

> Whether it's required in Writing Modes Level 3 or not (could be
> considered in future levels) still splits. A few argued it
> should be, while most think it can be in future levels. But to
> make sure we are talking about the same thing, we had some
> discussions about its requirements. So, please consider this
> mail to help us understand the requirements better, not to push
> the feature into the current spec.
> 
> The feature should have two options:
> 1. The maximum number of characters to apply text-combine automatically
> 2. The class of characters to apply
> 
> For the class of characters, it's a choice between the two options:
> 2.1. Digits only
> 2.2. All narrow letters and punctuation
> 
> The definition of 2.2. should be defined in more details as we
> go further, but for now I think all narrow as defined in
> UAX#11[2], and all L*/P* categories would suffice.
> 
> The definition above matches to what Adobe In Design has today.
> 
> There's another opinion that should also be supported, which is
> about how to or whether to fit within almost 1em box.
> 3.1. Don't do anything
> 3.2. Allow use of half/third/fourth glyphs if available in the font
> 3.3. Scale to 1em box if the width exceeds some specified limits
> This isn't a feature In Design doesn't support today in its
> auto text-combine feature today (supports 3.1. only), but we
> might want to, because In Design is a software for authors and
> authors can do anything after applying the feature, while in
> CSS the feature can be the one user can apply. This part I
> believe is still unbaked well enough and we need more
> discussions.
> 
> It might sound like it's still rough idea, but I hope this
> helps us to think about the feature.

I understand your analysis but I'm not at all clear on the
specific proposals you're listing here, especially with regards
to the discussion of "auto" between you and Murata-san.  Could
you give a concrete example and then list the different ways in
which behavior would differ?

The one general comment I would have is that the rendering
behavior must be consistent across user agents, allowing user
agents to pick and choose which behavior to implement is a recipe
for inconsistency and a huge headache for authors.

For example, if text-combine is applied to a three character span
containing "123" then there should be a way of assuring that
third-width glyphs are *always* used if an a font containing
third-width glyphs is provided.  This should work across
implementations, it should *not* be up to the implementation to
decide to wing it and render using shrunken glyphs from MS PGothic
(double ick!).

Cheers,

John Daggett
Received on Tuesday, 18 January 2011 05:05:02 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:36 GMT