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

> 2020/04/29 12:36、Koji Ishii <kojii@chromium.org>のメール:
> 
> Segment transformation rules の議論はいったん置いておいて、まず和欧間アキの在り方について議論したい、ということで理解していいでしょうか？　とりあえずその方向で。

和欧間アキを含め、敏先生が示してくださった下のようなケースで、空間をあける目的のために、字間を開けるという仕組みにするのか（現在の定義）、空白文字を入れるのか、どちらの手段をとるか、というのがまずしたい議論です。




>> アキを必要とする一般的な事項な例には，日本語組版では，次のよ
>> うな例があります．2）は，たしかJIS Z 8000-1（量及び単位－第
>> １部：一般）に，その旨の規定があったと思います．
>> 　1）和欧文のアキ
>> 　2）数値（数値を示す欧字）と単位記号の間
>> 　3）見出しのラベル名と見出し文字列の間
>> 　4）？の後ろ
>> 　5）注記の番号とテキストとの間
>> 　6）表や図版番号とテキストとの間



> ドキュメント中に空白文字がない前提で、アキを自動挿入する機能を考える
> ドキュメント中に空白文字がある前提で、その空白文字の幅を調整する機能を考える
> どちらもありだと思います。shimono さんがおっしゃるように多くの人が空白文字を入れたがりますし、X4051の両端揃えのためにツメるロジックでは
> 和欧間アキをゼロ（1/8emだったかな？）までツメる
> 欧文空白文字を1/3em (1/8emだったかな？...）までツメる
> があるため、どちらもほぼ同じ結果になることが多いように思います。

はい、どちらでも同じ結果を得られるなら、欧文組版や規格との互換性が良い、空白文字を入れる方法で日本語組版規則を記述するのが良いのではないか、というのが私の提起です。

木田

> 
> 2020年4月29日(水) 12:06 木田泰夫 <kida@mac.com <mailto:kida@mac.com>>:
> 
> 
> > 2020/04/29 11:27、Atsushi Shimono (W3C Team) <atsushi@w3.org <mailto:atsushi@w3.org>>のメール:
> > 
> >  shimonoです
> > 
> > # なんかわたしが勘違いしてる感も微妙にあるコメント＠このメールではあるのですが、、
> > 
> > On 2020/04/28 23:31, Koji Ishii wrote:
> >> おっしゃっていることはわかります。ポリシーの問題だとも思うので、一貫性が取れればどちらでもいいのかもしれません。
> >> 恐らく基本の部分で、エラー率に対する考えに差がある気がします。Shift-JIS の頃は割ときれいに作れたんですが、Unicode になって、例えば Å は unify されてしまったので、これの前後で改行されたら処理できません。また、以前に小林先生のメールにもありましたが、一定数のユーザーは和欧間アキはいらない、あるいは空白文字の方がよい、と考えています。このため
> >>    春はあけぼ
> >>    のが nice
> >>    ですって。
> >>       ↓ ↓ ↓
> >>    春はあけぼのが niceですって。
> > 
> >　 2000年代一桁のウェブ上の文章、特に技術ドキュメントサイトでは「半角空白」を和欧間空きとして入れる、
> > というのを規則にしていたところも多かったと思います。
> > # いま思い起こせば、確かMDN(の前身のMDCの前身のdevmo)の記述・編集規則を作ったときにそういう規則を明
> > 記したような覚えがあります。
> 
> 私もそのように入力することが多いです。が、それは JLReq の要求していることと違うでしょう？
> 
> >　 という中で、改行をするなら和欧間のところか、もしくは約物の後で入れるべし、というガイドラインを設
> > 定していたところは確かにありました。
> > 
> > 
> >> これはこれでそういうユーザーにとっては迷惑なわけです。なので、どうやってルールを作っても、エラー率は一定以下にはならない、という前提が私にはあります。
> >> で、
> >> 1. 親切度は低いが、エラー率がゼロあるいは低いシステム
> >> 2. 新設度は高いが、エラー率がそこそこあるシステム
> >> だと、エラーの記憶が強いネガティブイメージになりやすいため、１の方がよい、というのが私のロジックです。
> > 
> >　 +1
> > 
> >> 和欧間アキが昔ほど頻繁には使われない、という点も私と木田さんでは認識が違うんじゃないでしょうか。和欧間アキは、和文フォントの中の欧文の質があまりよくなく、欧文には欧文フォントを組み合わせる、という時代にはより頻繁に使われ、Word でもデフォルトオンにしましたが、和文フォントの中の欧文文字の品質がよくなるにつれ、必要となる頻度は減ってきていると認識しています。和欧間アキを使いたくない人が相応数存在する、という前提が、木田さんと私では違うのかな、と感じています。
> > 
> >　 というところで、宗派としては大きく分けて
> > ・和欧間空きを入れない宗派、改行がsegment break経由でU+0020に置換されるのも困っている (ideograph-*は設定しないが、white-spaceにも不満が残る)
> > ・和欧間空きを入れる宗派、あまりspacing量は気にしないのでU+0020でも大丈夫 (ここが意外と多そうではある？)
> > ・和欧間空きを入れる宗派、spacing量は気にしたいのでideograph-*を設定してsegment break経由のU+0020とかも置換してほしい宗派
> > になるのかな、という気がしています。
> > 
> > CSS-text-3 white space phases: https://drafts.csswg.org/css-text-3/#white-space-rules <https://drafts.csswg.org/css-text-3/#white-space-rules>
> > あんちょこ: https://himorin.github.io/w3c-memo/i18n/notes/white_space.html#%E7%A9%BA%E7%99%BD%E6%96%87%E5%AD%97%E5%87%A6%E7%90%86-section-41 <https://himorin.github.io/w3c-memo/i18n/notes/white_space.html#%E7%A9%BA%E7%99%BD%E6%96%87%E5%AD%97%E5%87%A6%E7%90%86-section-41>
> > 
> >  という中で、エラー率、という意味では
> > ・既存のドキュメントで改行から変換されたものを含むU+0020が和欧間・約物前後に入っているものは大量にある
> > ・幅が狭いZsの文字を入れまくる処理はめんどくさくてやりたくないが全部U+0020 (1/2em)より細いspacingにしたい宗派
> > の組み合わせが一番不満を抱くのかな、と思うのです。また、もちろん、空きを入れない宗派もある程度困ると
> > 表明するでしょうけれど。。というところで、追加としてもあまり複雑にならない程度で行くことを想定するな
> > らば、white-spaceにアグレッシブに空白除去するモードがあってもいいのかな、と思ったりするのです。
> >　 多分、前述の2つ目の宗派はいまのwhite space除去規則の中でのU+0020を除去する処理(約物かP*/S*、F/H/Wide
> > の2つが両側に連なるsegment breakは除去)でだいたい満足しているのかな、と思うところですので。。
> > # この両側の制限が本当にいいのかはもちとじっくり考えてみたいところですが、、。
> > 
> >　 いかがでしょうか、、
> 
> ということで（敏先生や石井さんへのメールを受けて）、この問題を Segment Break Transformation の問題に矮小化して考えたくないところ。まず足腰をちゃんとしたら、Segment Break Transformation Rules をどうすべきかの回答が出てくるでしょう。
> 
> 木田
> 
> > 
>