Re: 和欧文間の空き or Segment Break Transformation Rules

石井さん:
> ちょっと違和感があって、何なのかな、と考えていたのですが、ゴールがそもそも違うのではないかと思い立ちました。

ゴールはそんなに違わないと思います。私の案の意図は、せっかくの仕様ができても欠点があって役に立たない残念な仕様とならないようにすることです。

従来のWebの改行→空白変換は、空白で分かち書きをする多くの言語のユーザーには役に立つものですが、そうではない日本語や中国語のユーザーには役に立たない残念なものでした。CSS Text 3の改行変換規則ができることで、それがやっと役に立つものになると期待できます。しかし、その規則が適切でなければ、結局は使えない残念な仕様になってしまいます。

木田さんが書いてくれている次のポイントは大事なことだと思います：

> 両側の文字で判定する方式の場合、句読点の後をどう書き始めるかを決めるまで、改行をして良いか判断ができません。かなり思考の邪魔じゃないでしょうか？ 前の文字だけで判定する方式なら、その時点で未来を知らなくても脊髄で改行を打てます。（余談ですが、私この、脊髄 or muscle memory で打てる、というの好きなんですよ。Mac の「かな」「英数」キーがそのポリシーです）。

また、テキストデータを作るときに１文ごとに改行を入れて書くようなユースケースも多いと思います。変更差分のチェックその他の文書処理の都合のためにそうすることもあるでしょう。欧文であれば、そのようにセンテンスごとに改行が入ったテキストデータをWebにもそのまま使うことができました。CSS Text 3の改行変換規則によって日本語でもそのようにできると期待したら、文の開始の文字種によって不自然に余計な空白が入ってしまうというのでは、とても期待外れになります。

> 一方、もっとスマートなルールの場合、例えば村上さんご提案の General Category=P* かつ EAW=F だったら、というルールがあったら、前の行や後ろの行を見て、さらにその文字がその条件に該当するかどうかを考えないといけません。句点読点くらいはすぐに覚えますが、三点リーダーは EAW=A だからだめ、全角の「！」はいいけど、「‼」はだめ（そもそも全角！の後は全角空白を入れたいのでだめですが）「⁉」は全角だっけ？ などと考えなければいけないことが増えます。

私の案 <https://lists.w3.org/Archives/Public/public-i18n-japanese/2020AprJun/0232.html>のルールは、「P* かつ EAW=F…」ではなくて、以下です：

 * If the character immediately before or immediately after the segment break <https://drafts.csswg.org/css-text-3/#segment-break> is the zero-width space character (U+200B), then the break is removed, leaving behind the zero-width space.（改行の直前または直後の文字がゼロ幅スペースU+200Bなら改行を除去してゼロ幅スペースを残す）
 * Otherwise, if both the characters before and after the segment break <https://drafts.csswg.org/css-text-3/#segment-break> belong to the space-discarding character set <https://drafts.csswg.org/css-text-3/#space-discarding-character-set>, then the segment break is removed.（改行の前と後ろの両方の文字ともスペース破棄文字セットに含まれる文字なら改行を削除）
 * Otherwise, if either the character before or after the segment break <https://drafts.csswg.org/css-text-3/#segment-break> belongs to the space-discarding character set <https://drafts.csswg.org/css-text-3/#space-discarding-character-set> and is a Unicode Punctuation (P*) or U+3000, then the segment break is removed.（それ以外の場合、改行の前または後の文字がスペース破棄文字セットに属し、Unicode句読点類(P*)または U+3000 である場合、改行を削除）
 * Otherwise, the segment break <https://drafts.csswg.org/css-text-3/#segment-break> is converted to a space (U+0020).（その他の改行はスペースU+0020に変換）

追加した3番目のルールでは、EAW属性ではなくて、2番目のルールで既に使っている space-discarding character set を使うことで、ルールの整合性を保つことと、いろいろな属性をチェックすることのオーバーヘッドを抑えることを意図しています。

どの文字が space-discarding character set に含まれるのか、多くの人にとっては分かりにくくチェックしづらいというのは同意ですが、それは私の案の3番目のルールを追加しなくても、2番目のルールにすでにある問題です。たしかに、波ダッシュ「〜」や全角の「！」と漢字との間での改行は空白にならないのに、三点リーダー「…」や1文字の「‼」と漢字との間での改行は空白になるということが分かりやすいという人は少数派でしょう。

しかし、人が書くHTMLの場合、長い文の途中で改行を入れるとき、自然な文の区切りである句読点（。、）などで改行を入れられるならば、それ以外のところでは余計な空白が入らないように改行を入れないようにするのはそれほど負担ではないはずです。ルールを学習して、改行を入れても空白にならない条件を知ればもっと自由に改行を入れて書けるけれども、まずは次のところで改行を入れられることを知ればあまり困らないでしょう：

 * 句読点（。、．，）のあと
 * 全角括弧類の前後
 * 漢字・仮名どうしの間

人が書くHTMLコードではなくて、プログラムにより生成されるHTML内のテキストを改行入りとする場合（HTMLコード整形プログラムの出力も）、これまでそのようなプログラムは、日本語のテキストを適切に処理することができませんでしたが、CSSの改行変換規則の標準ができれば、その規則で問題が起きない改行位置で日本語テキストに改行を入れるようにプログラムを作れるようになります。またその場合、文の区切りで優先的に改行を入れることで、人やほかのプログラムが利用しやすい形にすることもあるでしょう。しかし、もしも問題が起きない改行位置が「漢字・仮名どうしの間」だけだったら、それができなくなってしまいます。

> 著者が入れる改行位置は言語的に不自然でいいから、HTMLをより簡単に書ける、というのを尺度で測るのか、それともHTML/CSSを知らない人が言語的に自然な位置で改行して、余計な空白が少ないか、という尺度で測るのか、という話なのかな、と思いました。

私の案は、HTMLをより簡単に書けるようにするとともに、言語的に自然な位置で改行を入れられるようにするものです。どうしてその両者が対立すると考えるのでしょう？ HTMLは文書を論理的に構造化するためのものです。文書の構造の単位として段落があり、段落は、複数の文から構成されます。だから、HTMLソース上で段落のテキストを複数の行に分ける場合、文の区切りで行を区切ることが理にかなっています。文の区切りで行を区切ることができなくて、どうして「HTMLをより簡単に書ける」ということになるのでしょう？ 


もし私の案でのルールの追加で仕様が複雑になるのが問題というのであれば、前のメール <https://lists.w3.org/Archives/Public/public-i18n-japanese/2020AprJun/0242.html>に書いたように、TeXの日本語組版対応版（pTeX や LuaTeX-ja）で実績がある、行末だけで判定する方式を検討するべきではないでしょうか？
改行を入れられる箇所はやや不自由になる（英数字と全角括弧の間では改行を入れられないなど）けれども、木田さんが書いているように、「両側の文字で判定する方式」よりも「前の文字だけで判定する方式」のほうが、「その時点で未来を知らなくても脊髄で改行を打て」るという利点があります。

文の区切りで行を区切ることができなくて、漢字・仮名どうしの間で改行を入れなければならないのでは、書きにくいし、読みにくいし、それに論理的に構造化文書を作って、構造とレイアウトとを分けるというHTML+CSSの設計思想にも反していると思います。

私も今回、木田さんからコメントを求められて、それでよく考えてみるまで、CSS Text 3ドラフトに実はかなり前から書かれていた、この、改行の前後の両方とも和文文字等（その正確な定義はドラフトの版によって変わっている）なら無視してそれ以外は空白にするという方式で問題だと気づいていなくて、行末しかみていないTeX（日本語組版対応版）よりも良いような気がしていたのでした。それは考えが足りなかったと反省しています。


--
村上 真雄 (MURAKAMI Shinyu)
murakami@vivliostyle.org


On Wed, May 13, 2020, at 15:07, Koji Ishii wrote:
> ちょっと違和感があって、何なのかな、と考えていたのですが、ゴールがそもそも違うのではないかと思い立ちました。
> 
> 村上さんは、論理的区切りや人が自然と感じるところで改行を入れて、空白が挿入されないことをゴールにされていませんか？
> 
> 私のゴールはきっとかなり違うものになります。こういう出力を作りたい、というイメージを持っている時に、いかにスムーズに間違いの少ないファイルを作れるか、というのがゴールです。
> 
> 例えば人が書いたHTMLをレビューしていて、行頭、行末に英数字があったら空白が入る、という単純なルールの場合であれば、行頭、行末の英数字は簡単に見つかるので「そこに空白が入っていいか」という観点だけでレビューすることができます。
> 
> 一方、もっとスマートなルールの場合、例えば村上さんご提案の General Category=P* かつ EAW=F だったら、というルールがあったら、前の行や後ろの行を見て、さらにその文字がその条件に該当するかどうかを考えないといけません。句点読点くらいはすぐに覚えますが、三点リーダーは EAW=A だからだめ、全角の「！」はいいけど、「‼」はだめ（そもそも全角！の後は全角空白を入れたいのでだめですが）「⁉」は全角だっけ？ などと考えなければいけないことが増えます。私でもすべての文字にぱっと正解を出すことができません。ので、空白を入れたくない場合は結局英数字の前後で改行はしないと思いますし、入れたい場合は…ルールが単純で「必ず入る」なら改行できますが、条件が増えてくると、合っているかどうか怪しくなるので、やっぱり自動判定に頼るのはやめよう、となると思っています。
> 
> 著者が入れる改行位置は言語的に不自然でいいから、HTMLをより簡単に書ける、というのを尺度で測るのか、それともHTML/CSSを知らない人が言語的に自然な位置で改行して、余計な空白が少ないか、という尺度で測るのか、という話なのかな、と思いました。
> 
> 
> 2020年5月12日(火) 17:56 木田泰夫 <kida@mac.com>:
>> 村上さん、
>> 
>> 素晴らしい考察ありがとうございます。どちらが優れているかの議論や結論は分けて、情報としてこの日本語 Tex の仕様を CSS github に紹介するのはどうでしょう？ HTML/CSS の専門家でも日本語化 Tex の仕様については知らない人が多いでしょうし、議論の参考になると思います。
>> 
>> 確認ですが、この Tex の仕様は国際版というわけではなくて、日本語版独特の動作なのですかね？
>> 
>> 
>>> 句読点（。、）のあとで改行を入れることが多いです。
>> 確かに。
>> 
>> 
>> 村上さんの説明を読んでいて、いや、これは CSS でもありなのではという気もしてきました。人間に優しいのではと思います。例えば、こんな風に考えながら文を書くとします：「どうたらこうたらなのであるから＜句読点＞＜とりあえず適当な長さになったので改行＞（次をどう書くか考える）（その次を書き始める）」。考えながら書く場合に割と一般的かと思います。
>> 
>> 両側の文字で判定する方式の場合、句読点の後をどう書き始めるかを決めるまで、改行をして良いか判断ができません。かなり思考の邪魔じゃないでしょうか？ 前の文字だけで判定する方式なら、その時点で未来を知らなくても脊髄で改行を打てます。（余談ですが、私この、脊髄 or muscle memory で打てる、というの好きなんですよ。Mac の「かな」「英数」キーがそのポリシーです）。
>> 
>> それに比べたら、村上さんの説明してくださった下の例の頻度は比較的低い（日本語や中国語の中に和字以外の名詞などが入る頻度と、英語などの中に日本語や中国語の文字が入る頻度の単純な比較として）し、あっても上の例に比べて思考の邪魔にはなりにくい感じです。下のケースで空白を入れたい場合はどうするのよ、ですが、それこそ、そこで改行しない、です。
>>> もしも CSS で TeX 方式を採用すると、次のような例で問題になりそうです:
>>> 
>>>> This example tests
>>>> 日本語のテキスト
>>>> in English text.
>>>> ↓
>>>> This example tests 日本語のテキストin English text.
>>> 
>>> 欧文テキストの中で外国語の語句として日本語テキストを入れる場合、欧文の単語間のスペースが日本語の前後に入るべきでしょう。しかし改行の前の文字だけを見る方式だと片方（「tests 日本語」）は間にスペースが入るけどもう片方（「テキストin」）はくっついてしまうという結果になります。
>> 
>> 
>> 本当にそれで問題ないか、もうちっと検討しないとわかりませんが。
>> 
>> とりあえず、情報だけ css github に紹介していただくのはどうでしょう？
>> 
>> 木田
>> 
>>> 2020/05/12 12:31、Shinyu Murakami <murakami@vivliostyle.org>のメール:
>>> 
>>> 私のこの提案は、簡単に言うと、和文文字の約物と欧文文字との間での改行をスペースに変換しないで削除する規則を追加するというものです。
>>> 皆様の意見も聞いたうえで、CSS Text 3への提案としたいと思います。
>>> 
>>> この考えに至る前に前に検討したことは、TeX の日本語組版での改行の扱いでした。私は TeX ユーザーではないので、実際の TeX ユーザーにチェックしてほしいところですが、日本語組版対応がされた TeX（pTeX や LuaTeX-ja）での改行の扱いは、次のようになっています:
>>>  * 行末が和文文字の場合、改行は無視される
>>>  * 行末が欧文文字の場合、改行は空白になる
>>> 
>>>> 参照:
>>>> • 『LaTeX2ε美文書作成入門』の「3.10 改行の扱い」 <https://books.google.co.jp/books?id=sXcWAgAAQBAJ&lpg=PA44&ots=5HQ1ZxsDFy&dq=LaTeX2%CE%B5%E7%BE%8E%E6%96%87%E6%9B%B8%E4%BD%9C%E6%88%90%E5%85%A5%E9%96%80%20%22%E6%94%B9%E8%A1%8C%E3%81%AE%E6%89%B1%E3%81%84%22&hl=ja&pg=PA44#v=onepage&q=LaTeX2%CE%B5%E7%BE%8E%E6%96%87%E6%9B%B8%E4%BD%9C%E6%88%90%E5%85%A5%E9%96%80%20%22%E6%94%B9%E8%A1%8C%E3%81%AE%E6%89%B1%E3%81%84%22&f=false>
>>>> • LuaTeX-jaのドキュメント <http://git.sourceforge.jp/view?p=luatex-ja/luatexja.git;a=blob_plain;f=doc/luatexja-ja.pdf;hb=HEAD> の「13 和文文字直後の改行」
>>> 
>>> ここで「和文文字」というのは「ひらがな，カタカナ，漢字，和文用の約物といった日本語組版に使われる文字」、「欧文文字」というのは「ラテンアルファベットを始めとする，その他全ての文字」のことです（上記 LuaTeX-ja のドキュメントでは、それぞれ JAchar、ALchar となっていて含まれる文字種は変更可能とのこと）。
>>> 
>>> この「和文文字」が、CSS Text 3 のスペース破棄文字セット(space-discarding character set <https://drafts.csswg.org/css-text-3/#space-discard-set>)に相当するといえるでしょう。しかし、CSS の Segment Break Transformation Rules <https://drafts.csswg.org/css-text-3/#line-break-transform> との大きな違いは、行末（改行の直前）の文字種だけで改行を無視するか空白にするかが決まることです。
>>> 
>>> 改行の前と後ろの両方とも和文文字の場合に改行を無視して、それ以外（片方だけ和文文字でも）には空白にするという現状のCSSドラフト仕様と、行末だけを見るTeX 方式のどちらが優れているかをまず考えました。
>>> 
>>> 通常、自分で適当なところで改行を入れながら日本語テキストを書く場合、句読点（。、）のあとで改行を入れることが多いです。
>>> それ以外の任意の漢字や仮名文字が続いている途中で改行を入れると、日本語の語句の検索などが不便になるので入れたくありません。
>>> でも句読点以外のところに入れるとしたら、文節の区切りでとなるでしょう。
>>> 和文の中に英数字がある場合、英数字は文節のはじまりであることは多いですが文節の最後に来ることはありません。
>>> 「2020年」「CSSは」のように、英数字のあとに漢字や平仮名がついて、文節を構成するからです。
>>> だから、行末だけを見るTeX方式では句読点や文節区切りで改行を入れている入力テキストの場合、余計な空白が入ることはありません。
>>> それに対して、現状のCSSドラフト仕様の場合には、改行のあとの文字が英数字であれば余計な空白が入ってしまいます。
>>> したがって、TeX方式のほうが優れているので、CSSでもTeX方式に直せばよいのでないかと最初は考えました。
>>> 
>>> しかし、CSS 仕様を検討する場合、日本語テキストに英数字が含まれるというケースだけではなく、様々なケースの多言語の混在のテキストで問題が起きないことが大事です。また、TeX の日本語組版対応（80年代にアスキーが開発した pTeX など）では、はじめから和欧文間スペース機能があるので、入力テキストで和欧文間にスペースを入れる・入れないで問題になることがないという違いもあります。
>>> もしも CSS で TeX 方式を採用すると、次のような例で問題になりそうです:
>>> 
>>>> This example tests
>>>> 日本語のテキスト
>>>> in English text.
>>>> ↓
>>>> This example tests 日本語のテキストin English text.
>>> 
>>> 欧文テキストの中で外国語の語句として日本語テキストを入れる場合、欧文の単語間のスペースが日本語の前後に入るべきでしょう。しかし改行の前の文字だけを見る方式だと片方（「tests 日本語」）は間にスペースが入るけどもう片方（「テキストin」）はくっついてしまうという結果になります。
>>> 
>>> そう考えると現状の CSS 方式より TeX 方式が良いことがあるものの、それを採用というのも無理、ということで現状の CSS 方式を改良する提案を書いた次第です。
>>> 
>>> 
>>> --
>>> 村上 真雄 (MURAKAMI Shinyu)
>>> murakami@vivliostyle.org
>>> 
>>> 
>>>> On 2020/05/11, at 18:18, Shinyu Murakami <murakami@vivliostyle.org> wrote:
>>>> 
>>>> On 2020/05/11, at 14:56, Koji Ishii <kojii@chromium.org> wrote:
>>>>> 
>>>>> 他の方のご意見もいただきたのですが、とりあえず二点だけ情報共有。
>>>>> 
>>>>> 2020年5月9日(土) 21:02 木田泰夫 <kida@mac.com>:
>>>>>> そもそもそうやって入力されている html は日本語の場合どのくらいあるんでしょう？ 昔は問答無用で空白が入っていた時代があったので、あんまりない？
>>>>> 
>>>>> 少なくともWebにおいては、原則ないです。ほとんどの著者が、HTMLで改行すると空白が入ることを知っていて「日本語では改行しない」「 改行するならスペースを入れたい場所 」を実践しています。過去の記憶では電子書籍でも同様だと思いますが、最近の事情は他の方に。
>>>> 
>>>> 
>>>> 日本語でのHTML制作者たちの多くはそのような現状に特に困っていないのかもしれませんが、たまに
>>>> 不便に感じるケースもあるかと思います。例えば
>>>> 
>>>>  * gitなどソースコード管理ツールで変更箇所の差分をチェックするときなど1行がとても長いと不便
>>>>  * HTMLのソースを作成するときに、エディターやツールでの自動整形を使ったとき、英文は適切に改行されるが日本語はうまくいかない
>>>> 
>>>> ですので、Segment Break Transformation Rules が標準化されて使えるものになれば、いくらか便利になると期待します。
>>>> 
>>>> そのルールについて考えました。今のドラフト仕様では(https://drafts.csswg.org/css-text-3/#line-break-transform): 
>>>>  * If the character immediately before or immediately after the segment break <https://drafts.csswg.org/css-text-3/#segment-break> is the zero-width space character (U+200B), then the break is removed, leaving behind the zero-width space.（改行の直前または直後の文字がゼロ幅スペースU+200Bなら改行を除去してゼロ幅スペースを残す）
>>>>  * Otherwise, if both the characters before and after the segment break <https://drafts.csswg.org/css-text-3/#segment-break> belong to the space-discarding character set <https://drafts.csswg.org/css-text-3/#space-discarding-character-set> (see Appendix F. Space-Discarding Unicode Characters <https://drafts.csswg.org/css-text-3/#space-discard-set>), then the segment break is removed.（改行の前と後ろの両方の文字ともスペース破棄文字セットに含まれる文字なら改行を削除）
>>>>  * Otherwise, the segment break <https://drafts.csswg.org/css-text-3/#segment-break> is converted to a space (U+0020).（その他の改行はスペースU+0020に変換）
>>>> 
>>>> この2番目と3番目の規則の間に、もうひとつ規則を追加することにより、余計なスペースが入ってしまうことを防げればよいのでないかと思いました。
>>>> 余計なスペースが入ってしまうケースとして、まず次のような和文と欧文の間に改行があるケースが考えられます:
>>>> 
>>>>> 日本語のテキストに
>>>>> English text
>>>>> を埋め込む。
>>>>> ↓
>>>>> 日本語のテキストに English text を埋め込む。
>>>> 
>>>> しかし、和文と欧文の間にスペースを入れてテキストを書く流儀もあるので、必ずしもこれが「余計なスペースが入ってしまうこと」とはいえません。
>>>> 改行をスペースに変換すべきか除去すべきか、どちらがよいか曖昧な場合には、これまでのブラウザではスペースに変換していたのだから、スペースに変換するのが無難です。
>>>> 
>>>> 一方、次のケースでは:
>>>> 
>>>>> 日本語のテキストに、
>>>>> English textを埋め込む。
>>>>> ↓
>>>>> 日本語のテキストに、 English textを埋め込む。
>>>> 
>>>> これでは、読点(、)のあとに余計なスペースが入る結果になります。このスペースが入るのはどう考えても余計だと思います。組版結果では、句読点のあとに英単語があるときに、全角ドリの句読点のあと欧文スペースの分だけ余計にアキができることになります。
>>>> 
>>>> もうひとつ、余計なスペースが入ってしまうケース:
>>>> 
>>>>> 日本語のテキストにEnglish text
>>>>> （英語のテキスト）
>>>>> を埋め込む。
>>>>> ↓
>>>>> 日本語のテキストにEnglish text （英語のテキスト）を埋め込む。
>>>> 
>>>> 全角の開き括弧 “（” の前に余計なスペースが入る結果になります。このスペースもどう考えても余計です。句読点同様、全角の括弧類にはアキが含まれるので欧文スペースのアキを追加した組版結果は不自然にあきすぎになります。
>>>> 
>>>> 日本語のテキストで！や？のあとに次の文が続くときは全角スペース(U+3000)を入れる決まりがあります。そのU+3000の直後に改行がある場合、U+3000はスペース破棄文字セットに含まれるのでそのあとの文字が漢字や仮名ならば改行が除去されるだけで余計なスペースは入りません。しかし、次のように改行のあとが英単語の場合:
>>>> 
>>>>> 日本語のテキスト！ 
>>>>> English textを埋め込む。
>>>>> ↓
>>>>> 日本語のテキスト！ English textを埋め込む。
>>>> 
>>>> 全角スペースのあとに余計な欧文スペースが入る結果になります。
>>>> 
>>>> 
>>>> 以上のような余計なスペースが入ってしまわないようにするには、Segment Break Transformation Rules の2番目と3番目の規則の間に次の規則を追加するとよいのでないかと思います:
>>>> 
>>>>  * Otherwise, if either the character before or after the segment break belongs to the space-discarding character set and is a Unicode Punctuation (P*) or U+3000, then the segment break is removed.（それ以外の場合、改行の前または後の文字がスペース破棄文字セットに属し、Unicode句読点類(P*)または U+3000 である場合、改行を削除）
>>>> 
>>>> 
>>>> このように Segment Break Transformation Rules が修正されるならば使えるものになるのでないかと思います。
>>>> これでも、和文と欧文の間で改行を入れるとスペースが入るというところなど、ケースによっては不満足な結果になりますが、
>>>> 「スペースを入れるか入れないか、どちらがよいか曖昧な場合には、これまでのブラウザと同様にスペースを入れる」
>>>> という原則によって、がまんしてもらうべきでしょう。
>>>> この原則を保つべきだと思うので、EAW=Ambiguous である文字をスペース破棄文字セットに入れることにも反対です。
>>>> 
>>>> 以上、Segment Break Transformation Rules について考えたことでした。
>>>> 
>>>> 
>>>> ---
>>>> 村上 真雄 (MURAKAMI Shinyu)
>>>>