- From: Koji Ishii <kojii@chromium.org>
- Date: Wed, 13 May 2020 15:07:59 +0900
- To: 木田泰夫 <kida@mac.com>
- Cc: Shinyu Murakami <murakami@vivliostyle.org>, Koji Ishii <kojii@chromium.org>, public-i18n-japanese@w3.org
- Message-ID: <CACQRE+SGNH-ir64BH+qCVGamwniv35Fp+gvVqGj4ihGjMGODbg@mail.gmail.com>
ちょっと違和感があって、何なのかな、と考えていたのですが、ゴールがそもそも違うのではないかと思い立ちました。 村上さんは、論理的区切りや人が自然と感じるところで改行を入れて、空白が挿入されないことをゴールにされていませんか? 私のゴールはきっとかなり違うものになります。こういう出力を作りたい、というイメージを持っている時に、いかにスムーズに間違いの少ないファイルを作れるか、というのがゴールです。 例えば人が書いた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) > > > >
Received on Wednesday, 13 May 2020 06:08:33 UTC