W3C home > Mailing lists > Public > www-international@w3.org > January to March 2007

Re: [CSS3 Text] punctuation-trim

From: MURAKAMI Shinyu <murakami@antenna.co.jp>
Date: Wed, 31 Jan 2007 07:36:05 +0900
To: www-style@w3.org
Cc: www-international@w3.org
Message-Id: <20070131030815.9CBF.MURAKAMI@antenna.co.jp>

On Mon, 29 Jan 2007 20:58:29 +1300
fantasai <fantasai.lists@inkedblade.net> wrote:

> MURAKAMI Shinyu wrote:
> > On Fri, 19 Jan 2007 00:36:07 +1300
> > fantasai <fantasai.lists@inkedblade.net> wrote:
> > 
> >> Just to clarify, the 'adjacent' value in 'punctuation-trim' is a
> >> replacement for the AXF / old CSS3 Text kerning-mode 'contextual'?
> > 
> > Yes. We implemented the kerning-mode 'contextual' based on the old CSS3
> > spec because at that time CSS3-Text was candidate recommendation and we
> > did not expect such changes. But I thought the term 'contextual kerning' 
> > was not intuitive for Japanese punctuation processing and
> > 'punctuation-trim' was better for it.
> 
> I completely agree.
> 
>  > [ http://lists.w3.org/Archives/Public/www-style/2006Oct/0155 ]
> 
> I have some questions on the definitions you gave.
> 
>   1) Should the 'start' and 'end' values apply to inlines or to blocks?
>        - if they apply only to blocks, the trimming behavior is set on
>          the block and cannot be changed within an inline element
>        - if they apply to inlines, then the behavior will inherit from
>          the block, but an inline element can turn off trimming at the
>          start and end of the lines.

It may not be necessary to specify on inlines, but I think they should
be able to apply to inlines for consistency because this functionality
is similar to text-autospace property and other text spacing properties
and they should have same scope.

> 
>   2) Was the omission of "fullwidth" before "opening punctuation" and
>      "closing punctuation" in the definition for 'adjacent' intentional?
>         | Fullwidth opening punctuation is trimmed if its previous adjacent
>         | character is an opening punctuation or a fullwidth middle dot
>         | punctuation.
>         | Fullwidth closing punctuation is trimmed if its next adjacent
>         | character is a closing punctuation or a fullwidth middle dot
>         | punctuation or a fullwidth opening punctuation

When I wrote it, it was intentional, I thought that "((あ))" (outer
parentheses are not fullwidth) should be rendered as "((あ))", but now I
have reconsidered since Japanese standard does not require it.

The following is a revised version of this rule, more close to Japanese
standard (JIS X 4051).

    Fullwidth opening punctuation is trimmed if its 
    previous adjacent character is a fullwidth opening punctuation 
    or a fullwidth closing punctuation 
    or a fullwidth middle dot punctuation 
    or a ideographic space (U+3000).
    Fullwidth closing punctuation is trimmed if its 
    next adjacent character is a fullwidth closing punctuation
    or a fullwidth middle dot punctuation
    or a ideographic space (U+3000).

BTW this wording is not same as in JIS X 4051, where the opening,
closing and middle dot punctuations in Japanese text are considered to
be halfwidth and spaces are added on condition of adjacent characters.
But actual Japanese fonts have fullwidth punctuations and trimming is
needed to treat them as halfwidth.

> 
>   3) In your proposal there are some language-based differences in whether
>      ・:;。.、, are considered middle dot punctuations, closing punctuations,
>      or neither. Is this a linguistic difference, or is it a reflection of
>      how the punctuation is typically drawn (centered vs. to one side)?
>      The reason I ask is because I have, for example, a simplified Chinese
>      textbook where the periods and commas are drawn centered -- in this
>      case, I'm guessing one wouldn't want them to be trimmed as closing
>      punctuation.

It is a reflection of how the punctuation is typically drawn (centered
vs. to one side), since I am not well versed in Chinese and Korean
punctuations. I did not know there was such case (simplified Chinese
with traditional Chinese punctuation?)

> 
>   4) The middle dot is classified only for Japanese. Is that because it is
>      typically only used for Japanese? Should it be classified as a middle
>      dot punctuation for other languages as well, if it happens to appear
>      in non-Japanese texts for some reason?

I omitted the middle dot in non-Japanese case because the 
"・" U+30FB KATAKANA MIDDLE DOT is only used for Japanese.
But now I have noticed that the "·" U+00B7 MIDDLE DOT is used in
simplified Chinese and the "‧" U+2027 HYPHENATION POINT is used in
traditional Chinese, both are fullwidth middle dot like Japanese
KATAKANA MIDDLE DOT.

The punctuation list in my proposal was not complete. The following is a
revised version. 

      (Japanese)
        Fullwidth opening punctuations:   「『(‘“〔[{〈《【〝〖〘〚⦅«
        Fullwidth closing punctuations:    」』)’”〕]}〉》】〟〗〙〛⦆»。.、,
        Fullwidth middle dot punctuations: ・:;
      (Korean)
        Fullwidth opening punctuations:    「『([{〈《【
        Fullwidth closing punctuations:    」』)]}〉》】.,
        Fullwidth middle dot punctuations:  :;
      (Simplified Chinese)
        Fullwidth opening punctuations:    「『(‘“〔[{〈《【〖
        Fullwidth closing punctuations:    」』)’”〕]}〉》】〗。.、,:;
        Fullwidth middle dot punctuations:  ·
      (Traditional Chinese)
        Fullwidth opening punctuations:    「『(‘“〔[{〈《【〝
        Fullwidth closing punctuations:    」』)’”〕]}〉》】〞
        Fullwidth middle dot punctuations:  ‧:;。.、,

The above Japanese list is based on JIS X 4051, and others are based on 
Word 2007's each primary editing language setting. (I want someone to
check this.)

When punctuations typically only used for one language appear in another
language text, punctuation trimming is not expected.

> 
>   5) Is there a need for specifying 'start' and 'end' separately, or would
>      they always be specified together?

They should be able to specify separately.

-- 
Shinyu Murakami
Antenna House XSL Formatter team
http://www.antennahouse.com
Received on Tuesday, 30 January 2007 22:36:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 19:17:09 GMT