Re: JLReq TF meeting notes 8/3

石井さん、ありがとうございます。

> 「半角にfitするように」とは書いてありますが、fitしないグリフをどうするかは未定義のようです。

halt の値が半角から外れる例はあるんでしょうか。かづらぎとか？ > Nat / Taro-san ?

グリフ幅が全角の半分でない場合にどうするかを明確にする必要がありますね。halt のスペックにグリフ幅が全角の半分でなかったらどうするか、を書き加えるのが良いのかな？　それともなんらかの理由でそれはできなくて、別個のテーブルを提案する必要があるんでしょうか。

木田

> 2021/08/15 4:48、Koji Ishii <kojii@chromium.org>のメール:
> 
> OpenTypeの仕様面からお答えすると、GPOSというのは、グリフの場所や大きさを本来の場所から変更するための指示になります。なので、例えば、units_per_em=1000で作っているフォントで、右半分をカットするのであれば
>   xAdvance = -500
> 左半分をカットするのであれば
>   xPlacement = 500
>   xAdvance = -500
> のようなデータを作り、該当するグリフに割り当てます。指示の詳細はこちら <https://docs.microsoft.com/en-us/typography/opentype/spec/gpos#value-record>。
> 
> GPOS自身は様々な目的に使用されるので汎用的に作ってありますが、haltはどう定義しているか <https://docs.microsoft.com/en-us/typography/opentype/spec/features_fj#tag-halt>を見ると
> 
> Function: Re-spaces glyphs designed to be set on full-em widths, fitting them onto half-em widths, to approximate more sophisticated text layout, such as what is described in Requirements for Japanese Text Layout (JLREQ) or similar CJKV text-layout specifications that expect half-width forms of characters whose default glyphs are full-width.
> 
> 「半角にfitするように」とは書いてありますが、fitしないグリフをどうするかは未定義のようです。
> 
> 論理的には
> a. そのグリフには割り当てない
> b. 600になるようにカットする
> c. 半角でカットして、隣のグリフと被る
> のいずれかで、cはあまりないかとは思うのですが、現実としてはcが多いように思われます。
> 
> この仕様だけで、アプリもテストツールもない状態では致し方ないかとも思います。もう少し分かりやすいサポートをしてあげたいところです。
> 
> On Fri, Aug 13, 2021 at 4:38 PM 木田泰夫 <kida@mac.com <mailto:kida@mac.com>> wrote:
> ping!
> 
>> 2021/08/04 20:58、木田泰夫 <kida@mac.com <mailto:kida@mac.com>>のメール:
>> 
>> Nat さんに質問です。
>> 
>>> プロポーショナルな和文フォントも増えてきた。全体は全角でも例えば括弧が600/1000など、半角でないものもある（Nat）
>> 
>> 括弧の空白を除いた部分が 600/1000 の幅を持っていた場合、halt を適用するとどういう動作をするんですか？
>> 
>> 木田
>> 
>>> 2021/08/04 13:14、木田泰夫 <kida@mac.com <mailto: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.
>>> ––––––––––––––––––––––––––––––––––––––––
>>> 
>> 
>