W3C home > Mailing lists > Public > www-style@w3.org > May 2013

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

From: 신정식 <jshin1987@gmail.com>
Date: Mon, 13 May 2013 15:14:59 -0700
Message-ID: <CAE1ONj9MNDkVfOctCJ59bS0qwDODVdrnNyD6J6LvPuDuWK2xiw@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: Glenn Adams <glenn@skynav.com>, Sangwhan Moon <sangwhan.moon@hanmail.net>, Koji Ishii <kojiishi@gluesoft.co.jp>, "www-style@w3.org" <www-style@w3.org>, "CJK discussion (public-i18n-cjk@w3.org)" <public-i18n-cjk@w3.org>, "HTML Korean Interest Group (public-html-ig-ko@w3.org)" <public-html-ig-ko@w3.org>, Richard Ishida <ishida@w3.org>
On Fri, May 10, 2013 at 8:56 PM, fantasai <fantasai.lists@inkedblade.net>wrote:

> Going back to Koji's original question...
>> The recommended code point list for the line-break property[1] has
>> additional
>> code points for Japanese and Chinese only, but it was pointed out by my
>> Korean friend that Korean should be treated more or less the same way as
>> Chinese and Japanese as far as line-breaking is concerned.
>> So I'd like to add Korean to the list of content language to enable
>> additional
>> set of line breaking rules.
>> Please let me/ML know if this doesn't sound like a good idea. Any other
>> opinions
>> and/or thoughts are also appreciated.
> While I think it's true that Korean should be treated more or less the same
> way as Chinese and Japanese wrt line-breaking *in general*, it seems to me
> from reading the KLREQ draft
>   http://www.w3.org/**International/docs/korean-**layout/#line-head-rest<http://www.w3.org/International/docs/korean-layout/#line-head-rest>
> that Korean should *not* be listed alongside Chinese and Japanese in these
> particular rules:
>   http://www.w3.org/TR/css3-**text/#line-break<http://www.w3.org/TR/css3-text/#line-break>

Sorry I'm slow here. It's not clear to me what made you reach that
conclusion from reading


which reads :

Lines cannot start with closing parenthesis (cl2), hyphen (cl5), dividing
punctuation marks (cl6), middle dots (cl7), periods and commas (cl8~9),
iteration marks (cl11), or prolonged sound marks (cl12).

Could you elaborate?

> So either CSS3 Text should not list Korean here, or the KLREQ document
> needs
> to be updated to describe the cases that would motivate its inclusion in
> the
> 'line-break' lists.
> ---
> Separately, there's an issue of handling such breaks in the case of
> 'word-break: keep-all', or what the KLREQ document calls "word basis"
> line breaking:
>   http://www.w3.org/**International/docs/korean-**layout/#line-break<http://www.w3.org/International/docs/korean-layout/#line-break>
> It's my impression that this is intended to enable Western-style
> line-breaking rules. In which case, none of the breaks described
> under the 'line-break' rules should be allowed.

I'm not sure why 'normal' or 'loose' cannot be used with what the KLREQ
document calls 'word basis' line breaking. I don't think they mean
'line-break: strict'.

One possible way to resolve this is to have 'auto' implicitly trigger
> 'strict' line-breaking whenever 'word-break: keep-all' is specified.
> Another is to always trigger 'strict' line-breaking whenever 'keep-all'
> is specified, regardless of 'line-break's specified value.

It would be helpful if the KLREQ community could step in here with
> some guidance.

I'm also curious to hear from the KLREQ about their intent.

BTW, that section needs some editing-love:

 - The right and left references in the caption for fig. 38 are reversed.
 - By 'words', they do not mean 'words' in the Korean grammar but segments
of text delimited by space (or other delimiters). That is, what they mean
is '어절' (Eo-jeol).
 - By 'characters', they mean Korean syllables (written either in Hangul or
 - By 'English', they mean Latin letters (and Greek/Cyrillic as well).
 - 'Hangul' should be 'Hangul or Hanja(CJK Ideographs)'.

Thank you,


> ~fantasai
Received on Monday, 13 May 2013 22:15:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:29 UTC