W3C home > Mailing lists > Public > www-style@w3.org > July 2014

Re: [css-text] Universal Compromise Default Justification

From: Asmus Freytag <asmusf@ix.netcom.com>
Date: Sun, 27 Jul 2014 09:48:32 -0700
Message-ID: <53D52D60.7090500@ix.netcom.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, Koji Ishii <kojiishi@gluesoft.co.jp>
CC: fantasai <fantasai.lists@inkedblade.net>, www-style@w3.org, CJK discussion <public-i18n-cjk@w3.org>, WWW International <www-international@w3.org>
On 7/26/2014 11:26 PM, Tab Atkins Jr. wrote:
> On Sat, Jul 26, 2014 at 12:46 PM, Koji Ishii <kojiishi@gluesoft.co.jp> wrote:
>> As you already said by yourself, a good value for the AmountX is hard—or, I actually think it’s not possible.
>>
>> I’m not very familiar with cluster scripts, but even within block scripts, max(0.5em, character’s own advance width) is good for Chinese/Japanese but is too small for Korean. If we make it larger, it’ll be good for Korean, but bad for Chinese and Japanese.
>>
>> I know you do not like the idea to handle Hangul and ideographic differently, but given there are no browsers today that expands between Hangul (except when inter-ideograph is applied to IE,) I don’t think we should change this behavior.
> They're different scripts; why wouldn't it be okay to treat them differently?

If Han Ideographs in Korean are treated consistently (and consistently 
different from Hangul) there's in principle no reason to not have 
differences in behavior for different script runs. Justification treats 
different classes of characters differently already (space vs letter vs 
punctuation) so I must say I am also puzzled why a classification by 
script isn't valid input into any justification algorithm.

However, if the way ideographs are treated varies across Korean 
documents, and in ways that are not simply based on interaction between 
adjacent runs, then simply "treating ideographs differently" wouldn't 
work. You'd still have to have a way of specifying what that behavior 
would be.

A./
Received on Sunday, 27 July 2014 16:49:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC