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

I'd like to keep the current behavior as written in the spec.

I understand there're needs for several variations, but for this level, I'd like us to pick one behavior that is common, the most reasonable, the least problematic, and the most wide range of people accepts, even though it may not necessarily be the best for a segment of people.  We've been discussing to find such one for years by talking to several parties, and the current behavior is the one all agreed most reasonable.

There may be more findings than we had before, I'm a bit curious on that point, but what I found before was that, in general, uses/authors/publishers segments generally want to avoid conflicts. Printing and typographer segments don't care much of conflicts. Rather, they prefer conflicts than unexpected automatic behavior, but it is merely to find and fix errors easily. Either way, conflicts must be resolved before readers see the documents.

Given that, if we'd pick one default for this level, I think we should avoid conflicts. It may make some of professionals's tasks harder, but still doable, and it is acceptable for much wider stakeholders.

In terms of picking up 1/N glyphs, again, I'd like to keep the current definition--which is, undefined. We had this discussion before if I remember correctly, we actually had some words to specify the behavior in the spec, but removed them since there were some opinions including ones from implementers preferring it be left undefined. It allows implementations to use smarter technologies such as multiple master or iType. We may find even better logic after implementations. I can't find good reasons to revert the consensus at this point.

/koji

2013/06/12 15:56、"John Daggett" <jdaggett@mozilla.com> のメッセージ:

> 
> 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 Thursday, 13 June 2013 00:35:00 UTC