Re: JLReq TF meeting notes 8/3

Nat さんありがとう。

その選択肢なら文句なく 1 ですよね。2 は解決になっていないし、3 はあまり現実的でないように思います。

halt の定義を変えるのはどのような手続きが必要なんですか？ Microsoft と Adobe の管理？

木田

> 2021/08/17 9:00、Nat McCully <nmccully@adobe.com>のメール:
> 
> そうですね。選択肢は次のように考えます。
>  
> １）                      haltをアキ量を抜く機能（つまりベタ組にする機能）として定義し、字形が600とかだったら400をとることにする。アキ量はその400の反対にして、エンジン側でとられたアキ量を計算しないといけない。
> ２）                      haltは行全体の幅をまるまる１emか２分アキ足りないか（いわゆる伝統的な組み方）を最優先して、字形の幅が500を超えても500をとることにする。食い込みが起こる。
> ３）                      字形が500よりも大きい場合はhaltを対象外にして、エンジン側では自動ツメ機能とアキ量挿入も合わせないといけない。
>  
> ナット
>  
> From: 木田泰夫 <kida@mac.com>
> Date: Monday, August 16, 2021 at 4:30 PM
> To: Nat McCully <nmccully@adobe.com>
> Cc: JLReq TF 日本語 <public-i18n-japanese@w3.org>
> Subject: Re: JLReq TF meeting notes 8/3
> 
> Nat さんありがとうございます。undefined なんですね。
>  
> 半角約物の幅が半角でない例は実際にありますよね。そのようなものに対応する必要があると思います。どうすれば良いと思われます？
>  
> 例えば、halt の記述をアップデートして、半角に収まらない場合でも使えるようにするとか、別のものを定義するとか。
>  
> 木田
> 
> 
> 2021/08/17 4:33、Nat McCully <nmccully@adobe.com>のメール:
>  
> I think the answer that behavior is currently undefined is correct. When a glyph like u+201c is made proportional and >500 units it is not in the ‘halt’ feature so nothing happens, although normally such characters are full width and should be auto tsume’d. 
>  
> —Nat
> From: 木田泰夫 <kida@mac.com>
> Sent: Friday, August 13, 2021 12:38:20 AM
> To: JLReq TF 日本語 <public-i18n-japanese@w3.org>
> Subject: Re: JLReq TF meeting notes 8/3 
>  
> ping!
> 
> 
> 2021/08/04 20:58、木田泰夫 <kida@mac.com>のメール:
>  
> Nat さんに質問です。
>  
> プロポーショナルな和文フォントも増えてきた。全体は全角でも例えば括弧が600/1000など、半角でないものもある（Nat）
>  
> 括弧の空白を除いた部分が 600/1000 の幅を持っていた場合、halt を適用するとどういう動作をするんですか？
>  
> 木田
> 
> 
> 2021/08/04 13:14、木田泰夫<kida@mac.com>のメール:
>  
> 間違い、抜け、補足、などあれば指摘してください。
>  
> ––––––––––––––––––––––––––––––––––––––––
> JLReq TF meeting notes 8/3
>  
> Unicode に拡張した字間プロパティのレビューを行った
>  
> 内容の変更を伴うコメント（反映済み）
> ·         J 漢字仮名、の拡張：全ての象形文字を入れる
> ·         それ以外では、数字の〇を入れる。漢数字と入れ替わるから
> ·         ゲタはどちらでもいい
> ·         その他はどうでしたっけ？
> ·         L ラテンアルファベット、の拡張：全てのプロポーショナルな Letter (GC=L*) を入れる
>  
> 派生したコメント
> ·         プロポーショナルベースの組版を考えるべき
> ·         プロポーショナルな和文フォントも増えてきた。全体は全角でも例えば括弧が600/1000など、半角でないものもある（Nat）
> ·         たくさんの欧文を入れたり仮名をプロポーショナルにすると、ルールが乱れる（Nat）
> ·         括弧類と句読点がプロポーショナルになったときのルールがない。何かの方針を言及しなければならないのではないか。他の文字はプロポーショナルになろうとベタで良い（敏先生）
> ·         必ずしも約物一つが全角でなければならないという縛りはもう必要ない。ただベタで組めるように中にアキを持つ。アキが二つ連続したものについては処理が必要（敏先生）。リガチャの利用？（木田）
> ·         モダンな組版でどこまで空き量設定を崩していくのか、何かの追加の説明を考えていきたい（Nat）
> ·         JLReq第３版ではプロポーショナルベースもカバーできるようにしよう（木田）
> ·         括弧類の二分空きは空きすぎという考えがある。二分空きは効率のため
> ·         円弧を浅くしたもの。欧文パーレンに近いもの
> ·         和欧文間に入れられたスペースの扱いは、欧文スペースそのままの幅で良いのではないか（敏先生）。それでは見かけが悪い（木田）
> ·         なぜ日本語組版がややこしいか、間にフォントやグリフが絡んでくるのでややこしいという話を、簡単な図で説明した方がいいかと思う（Nat）。GitHub #281 にコメント入れて
>  
> digital native / reflow version of JLReq (aka. ver 3)
> ·         第一版、第二版が印刷のための記述だったのに比べると、第三版はデジタルドキュメントなので、飛躍がある。また、今出されているコンテント案を見ると、レイアウトの範疇を超えているものもある。タイトルがそぐわなくなってくる。
> ·         可能なら同じタイトルでゆきたい。その方が人々にわかりやすい（木田）
>  
> Todo:
> ·         Nat: GitHub #281 に、デジタル向け JLReq に必要な内容をコメント
>  
> Next meeting will be on 8/24, to review JLReq ver 2 titles to see if they fit and how they fit in the ver 3.
> ––––––––––––––––––––––––––––––––––––––––

Received on Tuesday, 17 August 2021 00:04:08 UTC