明日のミーティング

JLReq TF の皆さま、

初夏の顔がチラチラと見え始める季節になりましたが、皆さまいかがお過ごしでしょうか。

明日 10:00 から JLReq TF 定例ミーティングです。今回のお題は：

「字間のための簡略化クラス」提案レビューの続き。特に、グリフベースで考えた場合にどんな問題・可能性があるか
万が一（にもないとは思うが）時間があまれば、JLReq 文字クラスの見直しの過程で見つけた九つの、Unicode に該当する文字がないかもしれない、と議論になった文字について検討したい。文字のリストは4/6 の私のメール「議論の必要な文字9つ」参照。

でした。他にあれば提案してください。


––––––
途中にフォント分科会もありましたので、ちょっと recap しましょう。前回 4/6 のミーティングでは私が 4/5 に出した「字間のため（だけ）のクラス、簡便化案」を検討していました。簡略化案はこんな感じ：

> 簡便化字間クラスの構成
> 簡便化の結果、七つにまとめることができました。それぞれ空き要求の性質でクラスを説明することができます。
> 
> A: 前に空間を必要とする約物：始め括弧類 cl-01
> B: 後ろに空間を必要とする約物：終わり括弧類と句読点 cl-02, 06, 07
> C: 両側に空間を必要とする約物：中点類 cl-05
> D: そのものが空間な約物：和字間隔 cl-14
> E: アルファベットとの間に空間を必要とする文字、漢字類：仮名と漢字 cl-9,10,11,15,16、および cl-19 の漢字
> F: 漢字類との間に空間を必要とする外国語文字：cl-27 のうち Letter であるもの
> G: どの文字ともベタ：その他全ての文字。cl-03, 04, 08, 17, 18, 26、cl-19 の非漢字、cl-27 の非ラテンアルファベット

A-D は JLReq のクラスを統合しただけですが、E, F, G は cl-19/27 の分割を含むので議論が必要です。また、この分割を除くと敏先生が簡便な行組版ルールで示された cl-i から xii のサブセットとなっています。

これに対するメールやミーティングでの主な議論のポイントを列挙するとこんな感じでした：
文字間の決定は文字ではなくグリフの問題と考えられる。同じコードポイントでもプロポーショナルなら F だが全角なら E となる（例、ギリシャ文字）。全角かどうかで判断が分かれるなら、文字間の決定は文字ではなくグリフの問題。だとしたら、どんな可能性と問題があるか
cl-19/27 から記号を分離して常にベタのクラス G を作るという点について、大きな変更だが、特に異論・問題点は出なかった
「行の調整処理で空ける処理が可能な箇所」は、簡便化字間クラスのサブセットで押さえられる
縦書きの英字の縦横の判断は自動化が難しい
どこまでプレーンテキストで達成したいか（e.g. Ellipses vs 三点リーダ？）、どこからマークアップを必要とする、と決めるか（この基準を考えるのは良いエクサザイズになりそう）
和文のクォーテーションマークは用法の整理が必要そう（e.g. 横書きは欧文幅+スペースにしてしまう？縦書きにしたらどうなる？）
記号の定義の不十分さは日本語だけの問題ではなさそう
グラフィック系、または和文書体が全角ではない場合など、全角前提でない組みについても考える必要があるかも（次期 JLReq の一部として？）
アプローチについて。日本語があってその中に外国の文字が取り込まれる場合を考える。また、まずシンプルな規則を作って、そこからシンプルな規則で捉えきれなかった問題を見つける方
Unicode への拡張：字間クラスを Unicode プロパティーで表そうとした場合、「字間要求のプロパティ」が必要。A/B/Cを他から分ける本質的な違いは字間要求だから
––––––

木田

> 2021/04/07 19:05、木田泰夫 <kida@mac.com>のメール:
> 
> JLreq TF 4/6 meeting notes draft 2
> （敏先生の発言を訂正・補足）
> 
> あっちこっち飛んだ、しかし根本に触れることのできた有意義な議論でした。重要なポイントを落とさずかつ流れがわかるよう、少し長いですが下のように整理してみました（これどうやって英語の meeting notes にしよう…結果だけ書けば良いのか）。流れに沿って発言を切り取っているので、訂正・補足箇所があったら教えてください。
> 
> 
> 「字間のための簡略化クラス」提案の説明（木田）
> 議論の一つのポイントは、何を英字類 F に含めるか。英字類とは、漢字との間にアキを要求する文字クラス。これをラテンアルファベットに限定するか、全ての全角でない Letter （言語の音声を表す文字）にするか。事前に田嶋さんから、ギリシャ文字が単独で現れる場合があって、その場合勝手にアキが入ると困るとのフィードバック（ギリシャ文字は日本語フォントにおいては全角）（木田）
> ヘブライ語のアレフなど（プロポーショナルの文字）も単独で使うことがある（小林）
> 敏先生がミーティング後のメールで、和文中の欧文文字について、縦、横、及び縦横両方に通用する書き方とアキについて解説してくださった（4/7の瓶先生の「和欧文のアキ問題」参照）。単独文字の場合に当てはめると、プロポーショナルの場合、縦書きの場合は正立させて縦中横処理つまり空きなし、横書きは両側に四分空き。全角の場合は縦書きは正立させ、縦書き横書きとも空きなし。
> これを単独ギリシャ文字の場合に当てはめると、縦書きの場合、UAX50で横倒しになるが、縦中横処理をして（故に自動的に）空きなし、でハッピー。しかし横書きの場合、もしグリフが全角だった場合に空きが入るのは期待に沿わない。今回の議論の最後の結論にみられるように、字間の設定は文字コードではなくてグリフの問題だということだろう（木田）
> （ところで、 この部分のタイトル、括弧 ”「” から始まると他の行から一段下がった項目のように見えますね。約物処理大事）
> 
> アプローチの話に移行：内か外か
> すべてを網羅し可能にする簡略化をやりたい。あまりにシンプルにしてしまうと数字とそれ以外の間を調整できないような話が出てきてしまう（Nat）
> 細かいことは例外処理として考えるべき（小林）
> 内と外を分けなければならない。外のもの、和文でない世界が内、和文の世界に入ってきた（Nat）
> 内と外がどんどん混じってきている。（木田）
> フラットな世界の中で組もうと思うと選択がなくなってくる、従来の中では外のものを取り込んで内側のルールを適用していた（Nat）
> 内と外はなくならないと思っている。arabicのrtlが混じってきたときとか、日本語の縦組みとか。何かを書くときに全体を支配する writing system が一つある。その中に別なものが入ってきたときにどうするか（小林）
> 仮想ボディのシステム vs アセントディセントのシステム。どちらの writing system を書いているか。内のための基準、外のための基準（Nat）
> 日本語の中にそれ以外（の文字や言語）を取り込むのをどうするのかというのと、日本語を他の言語にどう埋め込むかを分けて考えるといいのではないか（小林）
> ではまず日本語が主の場合を考えよう（木田）（つまり、特定の言語に関係ない環境に平等に多言語がある、というモデルではない）
> 英語以外の言語にとって、多言語をどう扱うかとても重要。タイ、活版印刷の時代がない。手書き→タイプライター。タイプライターの制限が writing system を制約している。ブラウザーの中で自分たちの持ってきた writing system をどう保存するか（がマイノリティー言語の課題）。日本語はマイノリティー言語のチャンピオン。（木田：これ重要なポイントね）
> 今の状況ではちゃんとした日本語ができない（Nat）。ちゃんとした日本語とは。時代によって人によって変わってくる（小林）。範囲がある。日本語は一つのルールはなくて範囲が広い。広告のタイトル、温泉の広告の広々とした組み、etc. （Nat）
> 正しいwriting systemはこういうものなのでコストをかけても実現すべきだというのはあり得ない、過去に正しかったというのがあっても今の状況ではどうか。その中で何を作らないといけないか（小林）
> 
> アプローチの方向性に合意が取れた
> まずシンプルな規則を作る。そうするとそこから、ここは格好悪い、などシンプルな規則で捉えきれなかった問題、何が必要なのかが見えてくるだろう。それを期待している。それゆえにまずシンプル化したい（木田）
> 賛成である（複数名）。ただし総論賛成各論反対がある（敏先生）。その各論が知りたい。具体例が欲しい。具体例があると議論ができる（木田）
> （＋日本語が主の場合をまず考える）
> 
> 話題を元に戻す & 行の調整処理の話が少し
> 今日の主題であるところの簡易化された約物のクラスの話に戻るが、何もないか、半角詰めるか、入れるかしかないことを思うともっと減らせるのではないか？ 振る舞いとして区別しないといけないものだけと考えてクラス分類とするのはどうか（小林）。その結果が今出ている表（敏先生）。始めに空きを要求する文字、後ろに空きを要求する文字、両側に要求する文字、そのものが空き、漢字仮名、アルファベット、全てべた、の７つに分類している。さらに簡略化できるならしたいが（木田）
> 空きそのものがどう伸縮するかのロジックがどこかにないといけない（Nat）。この表はデフォルトの字間の表で調整の表は別。調整の表は簡単で、E/Eが隣り合ったところを伸ばす（木田）。詰め処理は考えていない。それを入れ始めると優先順位がかなり問題になる。また空けるのは E-E だけ。4051でも A-E 間は優先順位が低いはず（敏先生）
> そうすると括弧類が喰いついたままになる？（Nat）括弧類の二分アキは変えたくない。字数が少ない行は辛くなるが、非常に調整量が多い時は既にみっともないので、あれこれ細かく言っても仕方ない（敏先生）。人生のアドバイス（Nat :）
> 
> 何を英字類 F に含めるか戻る → 実は対象はグリフではないか
> 依然として何を F （英字類）に入れるかというのは論点（木田）。すでに全角文字があるもの以外は全部外側と言ってしまう（小林）。一部を日本語文脈での文字とするのもあり得るかもしれないが複雑（敏先生）
> 文字間について現在は文字コードの文字クラスで抑えようとしている。実は相手にすべきなのはコードでなくグリフが全角かどうかではないだろうか。そう思えてきた。同じコードポイントでも全角なら E、プロポーショナルなら F。
> キャラクタでなく、グリフ問題であると捉えなおすと整理されてキレイになった（小林）
> 
> 和文で全角進行でない場合がある
> 文字組空き量ってそもそもベタの全角のため、プロポーショナルについては別途何か必要ではないのか（Nat）
> InDesignでMS P明朝を流すとどうなる？まあ MS P明朝を流すのは冗談だけれど、AXIS コンデンスなどの例がある（木田）設定が二つあって……（木田：掴み損ねました）（Nat）
> 全角ベースの書体でもグラフィック。ポスターなどは全く違う組み（どなたか）。プロポーショナル文字組み。イラストレーターの人たちは文字組みを off してから作るよ（Nat）
> 全角でない組みについても考える必要がある（どなたか）
> 
> 次回
> 次回は 4/27。「字間のための簡略化クラス」提案レビューの続き。特に、グリフベースで考えた場合にどんな問題・可能性があるか、についてオフラインで続けましょう
> 万が一（にもないとは思うが）時間があまれば、JLReq 文字クラスの見直しの過程で見つけた九つの、Unicode に該当する文字がない、かもしれない、と議論になった文字について検討したい。文字のリストは4/6 の私のメール「議論の必要な文字9つ」参照。
> //
>