Re: [css3-text] Korean should be added to enable additional line breaking rule sets

2012/9/16 Glenn Adams <glenn@skynav.com>

>
> -----Original Message-----
>> From: Sangwhan Moon [mailto:sangwhan.moon@hanmail.net]
>> Sent: Sunday, September 16, 2012 11:19 AM
>> To: Koji Ishii
>> Cc: www-style@w3.org; CJK discussion (public-i18n-cjk@w3.org); HTML
>> Korean Interest Group (public-html-ig-ko@w3.org); Florian Rivoal
>> Subject: Re: [css3-text] Korean should be added to enable additional line
>> breaking rule sets
>>
>> A quick review lead to the impression that the complexity needed to
>> implement this is overwhelming for
>> the benefits it provides - unless there is a absolute need for some of
>> the exceptions, I believe this should
>> be handled in a more pragmatic approach to reduce overall overhead needed
>> for rendering text.
>>
>
> I would not agree that this is too complex to implement, since I recently
> implemented it for Webkit without much difficulty. [1]
>

I wouldn't agree with Sangwhan  either and I'm fully with Glenn. Moreover,
the question asked by Koji is not about the feasibility/complexity of an
implementation  but about whether Korean should be treated the same way as
Chinese and Japanese are when it comes to CSS3 line breaking specification
[1]. Whether he likes it or not, Japanese certainly needs that and so does
Chinese and Korean (arguably to a lesser degree). Adding Korean to the mix
does not add complexity at all (implementations just have to check for one
more language).  How about 'Korean-only implementation'? There might be
some, but I'd strongly encourage those implementation to think twice before
claiming that they'll never support other languages.

Anyway, my answer to Koji's question is positive (as Glenn's webkit
implementation did) for the obvious reason (I suggested to him that Korean
should be added to the mix). :-)

FYI: the webkit bug in question is
https://bugs.webkit.org/show_bug.cgi?id=89235


>
>
>> so I believe this case should also be covered in the same (C)JK scope if
>> possible. (Note: Chinese probably doesn't apply, although I have seen
>> usages of ¥ instead of 元, only in ROC and only in a handwritten context.
>>
>
> I'm not sure if you are suggesting that CJK languages should all be
> treated the same here or not. I believe they should; that is, where the
> current CSS3 Text draft says "Chinese or Japanese", it should instead say
> "CJK languages" or "Chinese, Japanese, or Korean". This will improve
> interoperability and consistency of behavior.
>

Sangwhan was talking about the treatment of U+005C. Anyway, I don't think
it's relevant to the question at hand. Just because 0x5C in some legacy
encodings (e.g. Shift-JIS, EUC-KR/Windows-949) has been overloaded with
either 'back slash/reverse solidus' or the locale-dependent currency sign
cannot mean that U+005C should be treated the same way in CSS3 line
breaking specification.  U+005C IS 'reverse solidus/back slash' no matter
what.

Jungshik


[1] CSS3 now has the correct language about 'grapheme clusters' (instead of
a simple Unicode code point). Therefore, I don't have to add that Korean
line breaking has to be done in terms of Korean syllables (which can be
represented with a sequence of multiple Unicode characters).




> Regards,
> Glenn Adams
>
> [1] https://bugs.webkit.org/attachment.cgi?id=164255&action=prettypatch
> [2] https://trac.webkit.org/wiki/LineBreakingCSS3Mapping
> [3] https://bugs.webkit.org/attachment.cgi?id=163844
>