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

下農さん、石井さん、敏先生、Nat さん、それぞれに私の曖昧な問題提起の整理をしていただいてありがとうご合います。敏先生のドイツ語のようにギシッと詰まった文は読み応えがあります！　私の考えがもやもやしたままで、はっきりまとめていませんでしたが、みなさまのおかげで理解が深まりました。

主張は以下の2点かと思います。

A) 現状追認とその対処：和欧文間に空白文字が入れてある例が実際に多くある。これらは追認すべきではないか。そして、空白文字が入っている場合のあるべき空間の大きさを考えよう。同様な例を、敏先生が 4/29 のメールで挙げてくださいましたが、これらについても同様。
> 　1）和欧文のアキ
> 　2）数値（数値を示す欧字）と単位記号の間
> 　3）見出しのラベル名と見出し文字列の間
> 　4）？の後ろ
> 　5）注記の番号とテキストとの間
> 　6）表や図版番号とテキストとの間


B) 将来の JLReq に向けて：上記を踏まえて、将来の JLReq のあるべき記述を考える。特に和文独特ではないケース（上の 2 など）についてどう考えるか。どう文書データを作るべきかが影響されるので、そのガイドラインも必要だろう。


また、現状、敢えて空間がほしくないから空白文字を入れていないというケースもあります。それについて検討する必要もあるかと思います。空白文字を入れると空間が4分から3分となって、敏先生の考えられる理想的な空間の8分よりかなり大きくなります。もし空白文字を8分に制御できるなら、入れる派、入れない派の妥協点となる？　それとも、それでも入れたくない場所がある？　など。

木田

> 2020/05/02 0:17、Nat McCully <nmccully@adobe.com>のメール:
> 
> 木田さま、皆さま
>  
> 反対だ、と言っていましたが、もう少し説明をしようと思います。（皆さんのこのスレッドのやりとりが速いので追っかけないのですが）。
>  
> 私は文字組み空き量設定の優先度と範囲とがあることだと思っていて、追い込み処理などが必要な場合、あちらこちらに挿入されたU+0020よりは柔軟性があると思っています。欧文間隔の幅の調整のルールは和欧間隔の調整のルールと一緒ではない、ということであれば、全部同じコードポイントであれば属性を追加して区別をする必要になります。通常はそれらの間隔の幅のレンジは違うので、属性の追加は必要になると思います（和欧間隔は０〜４分、U+0020は８分〜４分、それぞれの優先度と拡大縮小タイミングは違うなど）。
> アーキテクチャーとして和欧間隔をU+0020を挿入して、その幅を特別に他のU+0020と違う扱いをしてもいいです。が、それはちょっとややこしいかなと思って反対だと言ってました。段頭空きもそうです。全角スペースを挿入する人はたくさんいますが、InDesignでは空き量設定を使用した方がベターです、インプリ上。
>  
> ナット
>  
> From: Kobayashi Toshi <binn@k.email.ne.jp>
> Date: Thursday, April 30, 2020 at 5:52 PM
> To: Koji Ishii <kojii@chromium.org>, Atsushi Shimono (W3C Team) <atsushi@w3.org>
> Cc: public-i18n-japanese@w3.org <public-i18n-japanese@w3.org>
> Subject: Re: 和欧文間の空き or Segment Break Transform ation Rules
> 
> Koji Ishii 様
> 木田 様
> みなさま
> 
> 　　　小林敏です
> 
> 木田さんの問題提起は，和欧文間のアキを書式（属性）として設定
> できるようにするか，しないか，ということだと理解しています．
> 
> 具体的には，和欧文間のアキを書式（属性）として設定できるよう
> になっているのは，各種の問題を考慮すると，よろしくない．そし
> て，和欧文間のアキは，欧文間隔を挿入すれば解決できるし，そう
> したデータもある．ですので和欧文間のアキの書式（属性）は，採
> 用しないこととし，必要があるものは欧文間隔を挿入すればよい，
> という提案だと理解しています．
> 
> この問題は，私は，以下のように考えています．
> 
> 前提：和欧文間のアキを書式（属性）として設定できる内容は，今
> は問題としない．行の調整処理で使用するか，しないか，また，ア
> キの値に複数を設定できるようにするかどうかは，後に検討する問
> 題とする．現時点では，書式（属性）として設定できるのは，四分
> アキの選択か，選択しないかが選べるだけとする．
> 
> 以下のような方式が考えられます．
> 
> A　和欧文間のアキを書式（属性）は採用しない。
> B　和欧文間のアキを書式（属性）は採用するが，デフォルト値と
> しては，“四分アキとしない”
> C　和欧文間のアキを書式（属性）は採用するが，デフォルト値と
> しては，“四分アキとする”
> 
> まず，議論すべきは第一は，和欧文間を空ける必要性です．
> 
> 少なくとも，和文間に挿入される欧文には，いろいろあるが，複数
> の単語（つまり単語間に欧文間隔を含む）場合は，複数の単語の前
> 後の和文との間はベタは望ましくないでしょう．ですから，その必
> 要がある，だと思います．
> 
> 次に，どう実現するか．
> 
> 四分アキにしたくない選択もできるのだし，簡単で，統一がとれる
> のは，書式（属性）で設定できることでしょう．いろんな文字種を
> 全て含めたものを対象にする際に問題がでる，と木田さんは指摘さ
> れていますが，少なくとも“欧文”というものの範囲，“和文”といわ
> れる範囲は特定できるので，“その他”をどうするかという問題は残
> るが，それは“和文”に含めると考えれば，とりあえず解決できま
> す．
> 
> 次に問題は，書式（属性）で設定できる方式の際に，和欧文間に欧
> 文間隔が挿入されている問題
> 
> これは，3つの解決方法が考えられます．
> 
> 1　何も考えない．
> 2　前準備で欧文間隔を削除，あるいは全部に挿入する．
> 3　欧文間隔がある場合の振る舞いを決める．
> 
> 実は，JLReqもJIS X 4051でも，欧文文字と欧文間隔は，文字クラ
> スを分けています．そして，欧文間隔と和文の間はベタ組です．で
> すから，それに従えば現状は3でもあるといえます．
> 
> ですので，和欧文間に欧文間隔が挿入されている場合は，それが優
> 先されるというか，和欧文間の四分アキは機能しません．ですの
> で，和欧文間に欧文間隔の挿入で処理したい場合は，和欧文間の四
> 分アキをONであろうとOFFであろうと，それが機能するので，和欧
> 文間の書式（属性）は関係なくなる．
> 
> 次に，和欧文間に欧文間隔の挿入に乱れがあった場合ですが，そこ
> まで面倒をみないといけないかどうかが，まず問題で，これは別に
> 考えることではないのかな．
> 
> また，実害という点からいうと，乱れがあった場合，和欧文間の四
> 分アキの場合は，片方が属性の四分アキ，片方が欧文間隔で，アキ
> に微妙に異なるが，たぶん，組版を見慣れた人でないと区別できな
> い事項ではないかな．逆に，属性のベタ組，または選定できなくて
> ベタ組の場合は，見分けがつく．（でも，ここまで面倒をみないと
> いけないのかな．）
> 
> こう考えれば，書式（属性）で設定できる場合のデフォルト値は，
> 四分アキとなるでしょう．
> 
> 最後にSegmentation Transformation Rulesですが，これは，私は
> なんともいえない．いえることは，このようなことを実現してほし
> い機会は，日本語組版では，多くないと思われるので，必要なら，
> なんらかの対策をとればよい．それを理由に，和欧文間に属性を削
> 除するというのは，いいすぎではないのかな，ということです．
> 
> 以上です．
> 
> Koji Ishii さん wrote
> 
> > 少し間をおいて考えていたのですが
> > 
> >    1. 和欧間アキを、空白文字が入っているとして説明するか、入っていないとして説明するか、という問題。これは、純粋に、仕様上の問題と思われる。これは、
> >    括弧類を半角として説明する方が都合がいいため、そういう実装がないのは承知でJLREQではそう仮定して定義する、のと同様ではないかと。
> >    2. 実装に対して「和字＋欧文空白＋欧字」などの組み合わせにおいて、和欧間アキのための組版規則を推奨するかどうか、という問題。
> >    3. Segmentation Transformation Rules に対する考え方の問題。
> > 
> > 木田さんが整理されたいのは、１ですか、２ですか？ ３は、２には影響を受けるかもしれませんが、１とは独立で議論できる問題ではないでしょうか？
> 
> ―――――――――――――――――――――
>  小林 敏（toshi）  2020年 5月 1日
>  e-mail: binn@k.email.ne.jp
> ―――――――――――――――――――――
>

Received on Saturday, 2 May 2020 01:03:49 UTC