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

おっしゃっていることはわかります。ポリシーの問題だとも思うので、一貫性が取れればどちらでもいいのかもしれません。

恐らく基本の部分で、エラー率に対する考えに差がある気がします。Shift-JIS の頃は割ときれいに作れたんですが、Unicode になって、例えば
Å は unify
されてしまったので、これの前後で改行されたら処理できません。また、以前に小林先生のメールにもありましたが、一定数のユーザーは和欧間アキはいらない、あるいは空白文字の方がよい、と考えています。このため

春はあけぼ
のが nice
ですって。
  ↓ ↓ ↓

春はあけぼのが niceですって。

これはこれでそういうユーザーにとっては迷惑なわけです。なので、どうやってルールを作っても、エラー率は一定以下にはならない、という前提が私にはあります。

で、

   1. 親切度は低いが、エラー率がゼロあるいは低いシステム
   2. 新設度は高いが、エラー率がそこそこあるシステム

だと、エラーの記憶が強いネガティブイメージになりやすいため、１の方がよい、というのが私のロジックです。

和欧間アキが昔ほど頻繁には使われない、という点も私と木田さんでは認識が違うんじゃないでしょうか。和欧間アキは、和文フォントの中の欧文の質があまりよくなく、欧文には欧文フォントを組み合わせる、という時代にはより頻繁に使われ、Word
でもデフォルトオンにしましたが、和文フォントの中の欧文文字の品質がよくなるにつれ、必要となる頻度は減ってきていると認識しています。和欧間アキを使いたくない人が相応数存在する、という前提が、木田さんと私では違うのかな、と感じています。

2020年4月28日(火) 20:43 木田泰夫 <kida@mac.com>:

> 石井さんありがとうございます。
>
>
> 理解しますが、底辺にあるドロドロとした気持ち悪さが消えません。ユーザーがそんなチップスを知らなければならないというのはどこか何かが間違っている印です。もっと美しい解決方法がきっとあると信じたくなります。
>
> 一つ、この方向で考えたらひょっとしたら、という思いつきがあります。
>
> 英語組版には空白という文字があります。これは本来的に存在する「文字」ではありませんので、活字の誕生かもしくはタイプライターの誕生に伴って生まれたのでしょう。その歴史的な真偽はともかく、空白文字という概念の発明のおかげで、単語間の空きを「空白文字を入れる」と記述できるわけです。もしこの発明がなかったら、日本語の字間の調整のように、「1/3
> m アキ」と記述したでしょう。
>
> 何が言いたいかというと、
> 文字の列の間に適切に空間を配置する、その全く同じことを記述するために、英語組版では空白文字という道具を使い、日本語組版は使っていない。違いはそれだけじゃないか、ということです。だとして、日本語組版に積極的に空白文字という概念を導入してみたら？
>
> 日本語と英語と空間の用途が大きく異なるからそんな試みは無謀無益、かもしれません。が、何種類かとっかかりもあります。例えば役物の記述。二分開けたりする場所、あれは空白文字を使って記述できるかもしれません。実際、データを見ると、欧文役物に空白文字を組み合わせている例をよく見ます。また、組版規則には欧文では空白文字で達成している全く同じことを、空白文字なしで記述している例もあります。単位記号と数字の間。JLReq
> ではこれを空白文字ではなく、四分アキと表現します（3.1.10 f）。
>
>
> この辺り、見直して欧文組版、国際化ソフトウェアとの互換性を改善できるのではないかと思います。ただし、この記述方式の違いはデータの作り方に影響を与えていますので、そこをよく考える必要があります。
>
> で、和欧文間の空きにどう関わってくるかというと、ここの空間を空白文字を使って記述してもいいのではと。一般的な空白文字は、欧文書体を見ると、例えば
> Helvetica で同じサイズの和文全角と比べて三分くらい。広すぎるのですが、それこそ、空白の幅を CSS
> で調節すれば良いのですよ。空白文字がない場合の調節はすでに記述されていますよね。あってもなくても同じ結果。だって同じことを達成するのに違う言葉を使っているだけなんですから。
>
> 荒削りですが、こんな方向。どうでしょう？
>
> 木田
>
> 2020/04/28 14:13、Koji Ishii <kojii@chromium.org>のメール:
>
> 
> 個人的意見ですが、Segment transformation rule は「迷ったら
> conservative」であるべきと思っています。あいまいなケースを完全に排除することが困難であり、製作者が改行位置を選ぶことで挙動を選べること、確認が容易なこと（全ブラウザーに実装されれば）から、あいまいなケースは、「製作者があいまいな場所で改行しない」ことで回避すべきと思っています。
>
>
> 絶対的に正しい判定ができれば取ってもいいのですが、和欧間アキがどれくらい「絶対的」か、というと、私はそれほど強いルールだとは思っていません。Wordで和欧間アキを実装した時に、AutoFormat/AutoCorrectでスペースが入れられたら取っちゃえ、という案もあったのですが、スペースを好む人もいること、自動処理が製作者の意図を超えて行き過ぎた場合強い拒否反応が見られがちなこと、Wordのjustificationでは、spaceをcompressする機能があるためほとんど実質的な差が出ないことなどから、見送りました。
>
> また、Shift-JIS の時代と違って、ある文字が「和」か「欧」か、というのも Unicode
> では曖昧ですから、こだわる人にとってはいずれにしても細かい調整がいる機能だと思っていますので、ルールをシンプルにして、ベストプラクティスとして「スペースを入れたくない改行は、全角文字の間で行う」とする方が分かりやすいシステムなのではないかと思っています。
>
> 2020年4月28日(火) 10:53 木田泰夫 <kida@mac.com>:
>
>> 下に説明する議論、将来の JLreq にとても重要なポイントの一つだと思っています。
>>
>> この話が浮上してきた背景は、日本語や中国語に対して Segment Break Transformation Rules
>> の詳細を決める議論が現在行われていることです。私の気になるのは、このルールがJLreq のルールと異なる、整合しない点です。
>>
>> Segment Break Transformation Rules って何？ をちょっと説明すると、CSS
>> にはバラバラの行に分割して書かれたテキストを繋げ直して表示する機能があります。下のように改行をどんどん入れて書いても、ちゃんと一つながりの文にしてくれます。
>> –––––––
>>
>> Here is an English paragraph
>> that is broken into multiple lines
>> in the source code so that it can
>> more easily read in a text editor.
>>
>>    ↓ ↓ ↓
>>
>> Here is an English paragraph that is broken into multiple lines in the
>> source code so that it can be more easily read in a text editor.
>>
>> –––––––
>>
>> 改行を空白文字に置き換える動作は日本語や中国語では困ります。ので、簡単にいうと改行文字の「*両方*
>> 」が全角文字なら、空白を入れないことになっています。
>> –––––––
>>
>> 春はあけぼ
>> の。ようよ
>> う白くなり
>> ゆくやま
>> …
>>
>>    ↓ ↓ ↓
>>
>> 春はあけぼの。ようよう白くなりゆくやま…
>>
>> –––––––
>>
>> こんなことの詳細を決めているのが、Segment Break Transformation Rules です。正確なルールは CSS Text
>> Level 3、また、このルールを適用する文字のリスト（2番目のリンク）を参照してください。
>> https://www.w3.org/TR/css-text-3/#line-break-transform

>> https://drafts.csswg.org/css-text-3/#space-discard-set

>>
>> さて、議論が起きているのは、囲み数字などはどうするの？和文欧文両方で使う文字はどうする（EAW=Ambiguous）？ などの詳細です。
>> https://github.com/w3c/csswg-drafts/issues/4992

>> https://github.com/w3c/clreq/issues/293

>> https://github.com/w3c/csswg-drafts/issues/337

>>
>> それも重要なのですが、私が気になったのは、改行文字の「*両方*
>> 」が全角文字、という条件です。このルールで例えば和字の中に英字があった場合、和字と英字の間に空白（U+0020）が挿入されます。
>> –––––––
>>
>> 春はあけぼ
>> のがnice
>> ですって。
>>   ↓ ↓ ↓
>>
>> 春はあけぼのがnice ですって。
>>
>> –––––––
>>
>> これは JLreq のルールと異なります。JLreq
>> では和字と英字の間は空白文字を挿入するのではなく、字間を空ける処理を行います。一般には空白文字の幅と、字間を空ける処理の幅は異なりますので、上の処理によって前後に幅の異なる空間ができることになります。
>>
>> さて、世界に通用する JLreq にするために、我々は何を変え、何を提案すべきでしょう？
>>
>> 木田
>>
>> 2020/04/28 8:14、Kobayashi Toshi <binn@k.email.ne.jp>のメール:
>>
>> みなさま
>>
>> 小林敏です
>>
>> 以下の件に，少し補足しておきます．
>>
>> 1 JIS X 4051では，和欧文間の空きは四分アキが採用されていま
>> すが，このアキは行の調整処理に使用できる規定になっています．
>> 調整量の範囲は，広げる場合は二分まで，詰める場合は八分までで
>> す．
>>
>> 2 この規定に従い，JLReqでも，JIS X 4051の規定を解説してい
>> ます．しかし，伝統的な方法は，四分固定ですので，JLReqでは，
>> その方法も解説しています．
>>
>> 3 Wordでは，段落書式で“日本語と英字（数字）の間隔を自動調
>> 整する”を選ぶと，JIS X 4051の規定に従い、この四分アキが行の
>> 調整処理に使用されます．特にオプションで“文字間隔の調整”で“間
>> 隔を詰めない”を選ぶと，よく和欧文間が二分アキになります．です
>> ので，和欧文間の二分アキは，Wordを使用すると確認できます．
>> （私は，上記の設定をよく使用するのですが，和欧文間が二分アキ
>> を避けるために，すべての和欧文間には，四分スペースを挿入して
>> います．）
>>
>> 4 InDesignでは，各種の方法が設定でき，四分固定（別の値も選
>> 択できる）も，また，設定した範囲での行の調整処理にも使用でき
>> ます．たぶんInDesignの組版と思われる（紙の）書籍について，私
>> の読書範囲で見たものは，たまに調整に使用されている例も見掛け
>> ますが，多くは一定の値（四分アキが多いが，必ずしもそうでない
>> 例もある）で固定した処理をしたものが多いように感じています．
>>
>> 以上です．
>>
>> Atsushi Shimono (W3C Team) さん wrote
>>
>> みなさま
>>
>>
>> 完全に流れて行ってしまっていた間のこれではあるのですが、github issueでは
>>
>> https://github.com/w3c/jlreq/issues/163
>>
>> にあります。
>>
>> clreqでは
>>
>> up to a quarter of the width of a Han character
>>
>>
>> https://w3c.github.io/clreq/#handling_western_text_in_chinese_text_using_proportional_western_fonts

>>
>> という上限1/4emという扱いだそうです。
>>
>>
>>
>> ひとまずのポインタまで
>>
>>
>>
>> On 2020/02/07 19:16, Kobayashi Toshi wrote:
>>
>> みなさな
>>
>>
>> 小林敏です
>>
>>
>> 和欧文間の空きについて，問題をまとめてみました．
>>
>>
>> 1 和文文字とラテン文字は設計思想が異なり，文字面と文字の外
>>
>> 枠との間のアキの考え方が異なる．和文をベタ組した場合，ラテン
>>
>> 文字と和文間をベタ組にすると詰まった印象を与えるので，その間
>>
>> を少し開けたい．
>>
>>
>> 2 和文とラテン文字の組合せは，以下のようにいろいろある．こ
>>
>> れらのケースで，理想的な空き量は異なってくるが，それぞれの空
>>
>> き量を決めるのは大変なので，これまで，すべて同じ処理を行って
>>
>> きた．今後も同様でよい．
>>
>> 1）アラビア数字
>>
>> 2）ラテン文字1字 大文字の場合と小文字の場合
>>
>> 3）ラテン文字の複数文字 大文字の場合と小文字の場合
>>
>> 4）ラテン文字の単語 大文字の場合と小文字の場合
>>
>> 5）ラテン文字の複数単語 大文字の場合と小文字の場合
>>
>> 6）その他 “はJ. M. ケインズである“などといった例もある.
>>
>>
>> ＊ただし，見出し，あるいは書名など，個別に処理できるような場合は，特に書名などでは，字の並びに応じ，細かく調整していたので，個別の状況で変更したい場合は出てくるでしょう．しかし，自動処理を前提としてた本文組の場合は，一律の処理でよいでしょう．
>>
>>
>> 3 活字組版では，伝統的に四分であった．
>>
>> これは，活字組版の材料（スペース）が，小さいサイズでは，主
>>
>> に四分しかなかったためである．文字サイズによっては，八分，六
>>
>> 分，1ポイントなどもあったが，これらは薄く，扱いが面倒でもあ
>>
>> り，準備している印刷所は限られていた．
>>
>>
>> 4 活字組版で四分とする理由として，アラビア数字の問題があっ
>>
>> た．伝統的に活字組版で混植するアラビア数字の字幅は二分が原則
>>
>> であった．また，ラテン文字の小文字も二分の字幅のものが，それ
>>
>> なりにあった．
>>
>> 字幅が二分の場合，奇数文字数の場合，前後を四分空けると，全体
>>
>> で文字サイズの整数倍となり，行の調整処理の発生を，いくらか少
>>
>> なくすることができた．
>>
>>
>> 5 最近の組版では，和文中に使用するアラビア数字の字幅は二分
>>
>> でないものがけっこうある．
>>
>>
>> 6 DTPなどでは，和欧文間が指定でき，四分より狭いアキにして
>>
>> いる例がみられる．
>>
>>
>> 7 私が，だいぶ以前に比較的に組版を見る目を持っていた方に，
>>
>> コンピュータ組版で和欧文間の空きについて見本組を作成し（八分
>>
>> からニ分まで），アンケートをとったことがある．こまかい数値は
>>
>> 残っていないが，大方の意見として，六分又は五分がよいという意
>>
>> 見が多かったように記憶している．
>>
>>
>> 8 DTPが日本で使われ始めたとき，あるDTPソフトは，和欧文間
>>
>> の空き量として四分という指定が可能であった．しかし，この四分
>>
>> は全角の1/4ではなく，半角の1/4，つまり全角の1/8であった．
>>
>> このことはマニュアルを仔細に読まないと分からなかったので，1/4
>>
>> の指定をしたつもりが，実際は1/8のアキ量であった，ということ
>>
>> である．こうしたものでも，あまり問題とならずに流通していたこ
>>
>> とからも，和欧文間の空き量は四分より狭めてよいということを示
>>
>> している．
>>
>>
>> 以上のことから，和欧文間の空き量は四分より，いくらか狭めた選
>>
>> 択肢が可能になることが望ましいといえよう．
>>
>>
>> ―――――――――――――――――――――
>> 小林 敏（toshi） 2020年 4月28日
>> e-mail: binn@k.email.ne.jp
>> ―――――――――――――――――――――
>>
>>