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

私のこの提案は、簡単に言うと、和文文字の約物と欧文文字との間での改行をスペースに変換しないで削除する規則を追加するというものです。
皆様の意見も聞いたうえで、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 <mailto:kojii@chromium.org>> wrote:
>> 
>> 他の方のご意見もいただきたのですが、とりあえず二点だけ情報共有。
>> 
>> 2020年5月9日(土) 21:02 木田泰夫 <kida@mac.com <mailto:kida@mac.com>>:
>> そもそもそうやって入力されている html は日本語の場合どのくらいあるんでしょう? 昔は問答無用で空白が入っていた時代があったので、あんまりない?
>> 
>> 少なくともWebにおいては、原則ないです。ほとんどの著者が、HTMLで改行すると空白が入ることを知っていて「日本語では改行しない」「 改行するならスペースを入れたい場所 」を実践しています。過去の記憶では電子書籍でも同様だと思いますが、最近の事情は他の方に。
> 
> 
> 日本語でのHTML制作者たちの多くはそのような現状に特に困っていないのかもしれませんが、たまに不便に感じるケースもあるかと思います。例えば
> 
> gitなどソースコード管理ツールで変更箇所の差分をチェックするときなど1行がとても長いと不便
> HTMLのソースを作成するときに、エディターやツールでの自動整形を使ったとき、英文は適切に改行されるが日本語はうまくいかない
> 
> ですので、Segment Break Transformation Rules が標準化されて使えるものになれば、いくらか便利になると期待します。
> 
> そのルールについて考えました。今のドラフト仕様では(https://drafts.csswg.org/css-text-3/#line-break-transform <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)
> 

Received on Tuesday, 12 May 2020 03:31:51 UTC