Re: [css-writing-modes] Tate-chu-yoko sizing rules

fantasai wrote:

> Yesterday, Muarakami-san invited me to dinner with a group of 10
> Japanese typographers / type designers / DTP operators. Naturally,
> I put them to work on the question of the day, tate-chu-yoko.
> 
> We started out with two options, A) force to 1em and B) do nothing.
> The table was split about 4-2, but two others held out for an option
> C) "It depends". After much discussion in Japanese, the group at the
> table came to consensus on the following rules:
> 
>    1. If 1/N-width glyphs are available, use those. Otherwise
>       use regular glyphs.
>    2. If the resulting composition fits within the 'line-height',
>       don't scale.
>    3. If the resulting composition is wider than the 'line-height',
>       scale to fit within the 'line-height'.
> 
> I asked if they were ok with the implication that TCY might conflict
> with ruby if the line-height were too small, and they said it's
> acceptable, and assured me that these are the rules they want.
> 
> Here is the drawings we used for the discussion:
> 
>    http://lists.w3.org/Archives/Public/www-archive/2013Jun/att-0069/shinjuku-2013-06-11.png
> 
> I would like to edit CSS Writing Modes to reflect this consensus.
> Are there any objections to this?

While this sounds like an interesting discussion, I don't think it
converts well to what needs to be done in CSS.

Specifically, I don't think it's necessary to include auto-scaling at
this level of the spec. There's a big difference between using
half-width glyphs in tate-chu-yoko, the most common pattern, and using
1/3 or 1/4 width glyphs (much less frequent).  Some authors will only
want the half-width glyphs and won't ever want to use 1/3-width or
1/4-width glyphs.  And fonts typically only provide 1/3-width or
1/4-width glyphs for digits and a smattering of basic punctuation
characters.

To actually spec the behavior for this you'll need to spec a lot more
detail about the fallback behavior and I don't think it makes sense at
this point, when we're trying to move from spec to implementation.

I would strongly prefer to keep this feature as simple as possible at
this level and then add additional functionality later only if
necessary.

Regards,

John Daggett

Received on Wednesday, 12 June 2013 06:56:07 UTC