- From: 木田泰夫 <kida@mac.com>
- Date: Wed, 29 Apr 2020 11:56:55 +0900
- To: Kobayashi Toshi <binn@k.email.ne.jp>
- Cc: Koji Ishii <kojii@chromium.org>, public-i18n-japanese@w3.org
> 2020/04/29 10:15、Kobayashi Toshi <binn@k.email.ne.jp>のメール: > > みなさま > > 小林敏です > > まず，問題として，Segment Break Transformation Rulesは，ど > のような目的，あるいはどのような利用，必要性を考えているので > すか？ その使用例は多いのですか？ これは、文が文の区切りではない場所に改行を入れて区切って入力されている場合でも、ちゃんとウェブのデータにできるようにとの仕組みです。まさにこの敏先生のメールがそのようなテキストの例です。欧文でもテキストエディタで文を入力する場合に割と一般的かと思います。どのくらい多いのかの数字の想像はつきませんが。 > 次に，選択肢のあるアキに，書式（属性）で設定させるのか，それ > ともスペースを入れる方法をとるのが望ましいか，ということで > す． はい、まさに。 > 利用ケースが少ないのであれば，特別な処理なので，スペースを入 > れる処理でいいと思いますが，ある程度は一般的（一般的といえる > かどうか判断はむつかしいが）であれば，書式（属性）であるのが > 望ましいでしょう．データを作成する著者は，一般的な事項は，そ > の実現方法を理解していない場合も多いのでしょうし，書式（属 > 性）の設定の方が作業は楽ですし，誤りも少ないでしょう．もし， > そのアキに選択肢もあれば，変更も簡単です． 書式で設定することは、そこに空白文字データがあるかどうかとは理屈的には独立のことでしょうね。 > 特別なケースは，例えば，人名の姓と名の間を空ける例がありま > す．これはスペースを入れればよい問題です． > > アキを必要とする一般的な事項な例には，日本語組版では，次のよ > うな例があります．2）は，たしかJIS Z 8000-1（量及び単位−第 > １部：一般）に，その旨の規定があったと思います． > 1）和欧文のアキ > 2）数値（数値を示す欧字）と単位記号の間 > 3）見出しのラベル名と見出し文字列の間 > 4）？の後ろ > 5）注記の番号とテキストとの間 > 6）表や図版番号とテキストとの間 > > このうち，書式（属性）で設定できるのは1）だけです．2）は書式 > （属性）での設定方法は実現されていないかと思います．2）以降 > は，書式（属性）で設定できないから，スペースを挿入しているの > です． 例えば 2, 3, 4 などは全く同じことを欧文では空白文字を挿入して行なっています。5, 6 は web やワープロなどでは自動的に生成されたりしますが、手で入力するときには空白文字を入れるでしょう。 例えば、"5 kg" ということを表したいときに、これが欧文なら "5 kg” と空白文字を入れ、これが和文なら “5kg” と空白文字を入れずにデータを作るのは、国際化環境の中で互換性に乏しいやり方で、いろいろなところに齟齬が出てきます。 この齟齬を無くしたいというのが私の提案、モティベーションです。Segment Break Transformation Rules は単にその齟齬の現れの例であって、特に重要度が高いからというわけではないんですよ。 > また，書式（属性）での設定ができても，スペースを入れる方法は > とれるわけですから（例えば，私はWordでは書式の設定ができる > が，方法としてはスペースを入れる方法をとっている），スペース > を入れる方法が優先されるのであれば，書式（属性）での設定がで > きることは，問題にならないのですから，できるだけ一般的に使用 > 例があるものは，できるだけ書式（属性）での設定ができる方法が > ある方が望ましいように思います． > > そして，Segment Break Transformation Rulesの使用例が多いの > であれば，なんらかの方法を考えないといけないが，そうでないの > であれば，スペースを入れる，入れない，あるいか“スペースを入れ > たくない改行は，全角文字の間で行う”という方法をとればいいよう > に思います． > > ついでにいえば，私はよく知らないのですが，Webで使える固定幅 > のスペースには，どんなものがありますか？ 日本語組版では，全 > 角，二分，四分，それと，マイナス二分はほしい．（三分はなくて > もよい） 固定幅の空白「文字」は全角のみです。書式でならかなり自由だと思います。 木田 > > 以上です． > > Koji Ishii さん wrote > >> おっしゃっていることはわかります。ポリシーの問題だとも思うので、一貫性が取れればどちらでもいいのかもしれません。 >> >> 恐らく基本の部分で、エラー率に対する考えに差がある気がします。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 >>>> ————————————————————— >>>> >>>> > > > > ————————————————————— > 小林 敏（toshi） 2020年 4月29日 > e-mail: binn@k.email.ne.jp > ————————————————————— >
Received on Wednesday, 29 April 2020 02:57:13 UTC