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

みなさま

　　　小林敏です

和欧文のアキがJIS X 4051で行の調整に使用されるのは，あそだけ
で書かれていることで，私の実感では，実際には，あまり採用され
ていないことではないかな．

次に感じていることは，実際に元のデータがこのように作られてい
るから，という議論は，どの程度尊重しないといけないのかな？という印象を持っています．

Segment transformation rulesも，私のメールがまさにそうだとい
うが，メールだから，そうしている面があって，メーラーで2行に
うまく折り返してくれる機能がかつてはなかったので，やむなくそ
うしていた（その習慣が残っている），また，きちんと組版するこ
とを考えていないテキストだという理由もあり，そうしている．
（組版するならテキストを添付する．）

和欧文間も，それを書式で設定する機能がなかったので，欧文スペ
ースを入れていたのではないかな，改行の全角下ガリも，書式で設
定できないから全角スペースを入れていたといったことなど，いろ
いろある．著者の書いた原稿を組版する場合でも，多くの問題があ
り，組版する際に整理した上で，組版していた．

こうした問題は，2段階で考えられないのかな．つまり，データを
整理するフィルターみたいなもので問題点を解決しておき，そのう
えで表示体裁を決める，ということはできないのかな？

Koji Ishii さん wrote

> Segment transformation rules
> の議論はいったん置いておいて、まず和欧間アキの在り方について議論したい、ということで理解していいでしょうか？ とりあえずその方向で。
> 
>    - ドキュメント中に空白文字がない前提で、アキを自動挿入する機能を考える
>    - ドキュメント中に空白文字がある前提で、その空白文字の幅を調整する機能を考える
> 
> どちらもありだと思います。shimono さんがおっしゃるように多くの人が空白文字を入れたがりますし、X4051の両端揃えのためにツメるロジックでは
> 
>    - 和欧間アキをゼロ（1/8emだったかな？）までツメる
>    - 欧文空白文字を1/3em (1/8emだったかな？...）までツメる
> 
> があるため、どちらもほぼ同じ結果になることが多いように思います。
> 
> 2020年4月29日(水) 12:06 木田泰夫 <kida@mac.com>:
> 
> >
> >
> > > 2020/04/29 11:27、Atsushi Shimono (W3C Team) <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://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
> > をどうすべきかの回答が出てくるでしょう。
> >
> > 木田

―――――――――――――――――――――
　小林　敏（toshi）　　2020年 4月29日
　e-mail: binn@k.email.ne.jp
―――――――――――――――――――――

Received on Wednesday, 29 April 2020 04:23:40 UTC