Re: CJKフォントのpalt（詰め組）とkernの関係

>
>
> 村田さん、互換性の問題がある場所は、paltを持つCJKフォントで、太郎さんの意図に沿ったフォントにおいては、kernの解釈を以下のようにする必要があります（私が誤解していなければ、ですが。）
>
>    - 適用対象がCJK全角文字である場合には、paltも指定されていれば適用するが、そうでない場合には適用しない
>    - 適用対象がそれ以外の場合には、常に適用する
>
> このルールを仕様化するために、「CJK全角文字である」という定義が必要になる、というのが私の理解です。
>

paltがなければkernも適用しないという規則がCJK全角文字のときには
存在すると主張しているわけですね。私が山本さんのメールから
読み取った内容とは違うので、山本さんに確認をお願いします。

村田 真


>
> On Thu, Apr 13, 2023 at 5:23 PM MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
> wrote:
>
>> 皆さん、
>>
>> 今までのメールを時間を掛けて読み返しました。
>>
>> 山本さんとNatに一つ質問があります。
>>
>> 欧文フォントやプロポーショナル日本語フォントにpaltを
>> 指定する人はいないから、そういうフォントにpaltを指定した
>> ときの動作は気にするはないという割り切りはありですか？
>> つまり、全角日本語文字という判定に苦労する条件は入れ
>> なくていいのでは？
>>
>> 村田 真
>>
>> 2023年4月13日(木) 16:44 Taro Yamamoto <tyamamot@adobe.com>:
>>
>>> 誤記があったので、加筆修正して再送します。
>>>
>>> 木田さん、
>>>
>>> もう1点追加すると、CJKV
>>> 全角文字以外の文字に対応するグリフ、主に欧文の文字に対応するグリフは（全角のものを除けば）すべて、はじめからプロポーショナルでなので、
>>> ’kern’をデフォルトでかけることで、それらの視覚的なスペーシングは改善されるので、’kern’
>>> をかけない理由が特にありません（かけたくない場合だけOFFにすればよい）。それに対して、CJKV
>>> 全角文字の場合は、最初から個々のグリフが独自の字幅をもつプロポーショナルCJKV
>>> フォントの場合（これは極めて稀）以外では、普通は、全角でベタで組めなくないと困るわけです。’kern’
>>> がかかる状態をデフォルトにすることは不可能なのです。
>>>
>>> なので、’palt’と’kern’のfeature interaction
>>> のもう一つの背景として、プロポーショナルが普通の状態である欧文のタイポグラフィと、全角ベタ組が普通の状態である和文のタイポグラフィの違いがある、といえると思います。
>>>
>>> このことから、’palt’を明示的に利用者が指定しないと、CJKV全角文字はプロポーショナルにすることができない。’palt’
>>> を明示的に指定してはじめて、’kern’を使った字間のスペーシングも許容されることになります。
>>>
>>> 山本
>>>
>>> アドビ
>>>
>>>
>>>
>>>
>>>
>>> *From:* Taro Yamamoto <tyamamot@adobe.com>
>>> *Sent:* Thursday, April 13, 2023 4:16 PM
>>> *To:* 木田泰夫 <kida@mac.com>
>>> *Cc:* Koji Ishii <kojii@chromium.org>; Nat McCully <nmccully@adobe.com>;
>>> Shinyu MURAKAMI <murakami@vivliostyle.org>; Makoto MURATA <
>>> eb2m-mrt@asahi-net.or.jp>; 敏 小林 <binn@k.email.ne.jp>; JLReq TF 日本語 <
>>> public-i18n-japanese@w3.org>
>>> *Subject:* RE: CJKフォントのpalt（詰め組）とkernの関係
>>>
>>>
>>>
>>> 木田さん、
>>>
>>>
>>>
>>> なぜ、
>>> （1） "If 'kern' is activated, 'palt' must also be activated if it
>>> exists."と明示的に書かれているのに、（2)CJK全角文字に対しては、`palt` が指定されない限り、`kern`
>>> をかけない」ことが「暗黙」に前提されていると、考えられるのですか？
>>> この2つは同じことを意味していませんか？
>>>
>>> 書かれていないことがあるとすれば、それは、’palt’が存在しなければ、’kern’をアクティベートする場合でも、’palt’
>>> をアクティベートする必要はない、ということですが、これは、（1
>>> ）から論理的に自明ですし、存在しなければアクティベートすることは不可能という意味でも正しいわけです。そして、このことは、「’palt’
>>> はほとんどの場合にCJKVフォントの全角文字のために用いられる」と明示的に書かれていることに対応しています。
>>>
>>> >
>>> 現実的に考えて、この定義に沿ってテキストシステムが動いた場合、仕様を異なる解釈で読んで作られたフォントにはどのくらい深刻な影響があるでしょう？
>>>
>>>
>>> これは、アプリがどう動くかということなのでNatの方が詳しいのでは？ Nat, please say something here.
>>> 私の考えは次のとおりです。
>>>
>>> ‘palt’が無くて‘kern’だけがあるフォントをのCJKV全角文字について、’palt’が無いという理由でアプリが’kern’
>>> をかけない場合には、フォントを作った人が期待する結果は得られなくなるでしょう。アプリは’palt’が無いのだから、’kern’
>>> をかけても良いはずだ、だから、その動作は間違いだ、と言えるのは、CJKVの全角文字以外に対して、’kern’
>>> をかけろと指示しても、かけてくれない場合だけで、CJKVの全角文字については、’palt’が無ければ’kern’
>>> をかけないというのは、正しい動作でしょう。
>>>
>>> なぜ、こうなっているかというと、それは、日本語で’palt’
>>> をかける場合というのは、日本語フォントの多くでは、主に仮名文字（一部の漢字や記号類が含まれる場合もありますが）が本来手書きの場合にはかなり自由な形状をもっていたものを全角等幅のボディに収容しているために、特に見出しなどの大きな文字サイズ（あるいは、商業印刷物や広告のように、タイトな組み上がりの効果が期待される用途では）、字間の視覚的なスペースがバラついて見えてしまうのを、個別のグリフごとの字幅とサイドベアリングを、欧文と同様に与えて（つまりプロポーショナルとして扱う）ことで、視覚的な見えを改善したい場合なのです。いわゆる写植のツメ組、そして後期の手動写植機が実装していた仮名ツメ文字盤と同じことを行うのが目的です。しかし、全角ベタで組めなくなったら困るので、
>>> ’palt’は、alternate widths
>>> として、あくまでオプショナルな字幅情報だとしているのです。これによって、デフォルトでは全角ベタで組めるようになっています。
>>>
>>> つまり、CJKV全角文字に対して’palt’が行っていることと、’kern’が連続する2
>>> グリフ間のスペースを詰める（または空ける）こととは、目的も機能も異なっています。異なっているなら、なぜ’palt’がなければ’kern’をしてはいけないのか？
>>> その理由は、’kern’だけを用いて、CJKV
>>> 全角文字のグリフ間のスペースが視覚的に均等に見えるように「詰める（または空ける）」ためには、途方もない数のペアを設定しなければならなくなり、非現実的である。なぜなら、本来
>>> ’palt’によって行うべき、個別グリフの字幅の調整までも、2
>>> 文字間のグリフのスペースの調整によって行わなければならなくなり、それは調整して作成する必要のある’kern’
>>> のペアの数が膨大になってしまうからで、だから、’palt’を使って、CJKV
>>> 全角文字に対応する個々のグリフが個々の字幅とサイドベアリングをもつプロポーショナルなグリフに変換した上で、さらに個別2
>>> グリフ間のスペーシングが必要となる場合に限定して、’kern’を適用することで、はじめて’kern’
>>> の目的である視覚的なグリフ間のスペーシング調整がCJKV
>>> 全角文字について現実的に達成可能になる。という日本語の全角の活字書体に固有の特性の理解に基づいているわけです。したがって、この’palt’と
>>> ’kern’のfeatire interactionには十分理由があるのです。
>>>
>>>
>>>
>>> また長くなったので、この辺で失礼します。
>>>
>>>
>>>
>>> 山本
>>>
>>> アドビ
>>>
>>> *From:* 木田泰夫 <kida@mac.com>
>>> *Sent:* Thursday, April 13, 2023 3:16 PM
>>> *To:* Taro Yamamoto <tyamamot@adobe.com>
>>> *Cc:* Koji Ishii <kojii@chromium.org>; Nat McCully <nmccully@adobe.com>;
>>> Shinyu MURAKAMI <murakami@vivliostyle.org>; Makoto MURATA <
>>> eb2m-mrt@asahi-net.or.jp>; 敏 小林 <binn@k.email.ne.jp>; JLReq TF 日本語 <
>>> public-i18n-japanese@w3.org>
>>> *Subject:* Re: CJKフォントのpalt（詰め組）とkernの関係
>>>
>>>
>>>
>>> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>>>
>>>
>>>
>>> 山本さん、
>>>
>>>
>>>
>>> ありがとうございます。
>>>
>>>
>>>
>>> ‘palt’ の定義に、"Re-spaces glyphs designed to be set on full-em widths,
>>> fitting them onto individual (more or less proportional) horizontal widths.”
>>> とありますから、確かに 2 の前提があるという解釈は合理的であるように感じます。それが明示的でなかったことで混乱が生じていると言えますかね？
>>>
>>>
>>>
>>> 現実的に考えて、この定義に沿ってテキストシステムが動いた場合、仕様を異なる解釈で読んで作られたフォントにはどのくらい深刻な影響があるでしょう？
>>>
>>>
>>>
>>> 木田
>>>
>>>
>>>
>>> 2023/04/13 14:35、Taro Yamamoto <tyamamot@adobe.com>のメール:
>>>
>>>
>>>
>>> 各位、
>>>
>>> 2、3の点について、コメントします。
>>>
>>>
>>>
>>> 1. "If 'kern' is activated, 'palt' must also be activated if it exists."
>>>  と記述されている。この記述は、改善が望まれる。
>>>
>>> 2. 提案者によると、上記1は、CJK全角文字に対しては、`palt` が指定されない限り、`kern`
>>> をかけない、という暗黙の前提が入っている。
>>>
>>>
>>>
>>> たしかに、ここでいう「全角文字」が、具体的に文字サイズと同じ字幅を持つグリフに対応する文字を意味しているのではなく、慣習的に従来大多数の日本語フォントにおいて全角の字幅を持つグリフとして実装されてきた文字、を意味していることは、暗黙の前提といえると思います。（そのことを明示化することは改善といえるかもしれません）。
>>>
>>> しかし、‘palt’は、その全角文字のためのフィーチャーなのですから、1.の"If 'kern' is activated, 'palt'
>>> must also be activated if it exists."
>>> ことには、十分合理性があります（その理由は既に何度も説明したので繰り返しませんが）。そして、上に述べた暗黙の前提があるとはいえ、1.
>>> が言っていること自体は、暗黙の前提ではなく、スペックに書いてあるので、明示された仕様です。
>>>
>>> 規格としての形式あるいは表現形式上の不具合、項目間の意味上の矛盾や不整合、はあるかもしれませんが、上記の1.が意味していること、あるいは、なぜ
>>> 1.
>>> の文言が書かれたか、ということには合理性があり、それを「改善」することができたとしても、その「改善」が現在意味している内容自体を変える必要があるとは考えません。
>>>
>>>
>>>
>>> 他方で、1.
>>> が意味するところの内容、それに基づいて実装されたフォントの利便性、そのように実装することから得られる便益が、十分に尊重される範囲において、それ以外の実装の可能性を議論し、必要であれば提案することには反対はしません。
>>>
>>>
>>>
>>> ただ、一つ疑問なのは、1.
>>> のように明示されていることに従っていない実装というのは、それなりの個別の意図や目的があるか、あるいは単に書いてあることを読んでなかったというだけなのかもしれませんが（特に前者の場合には、その目的の上では正しいわけですが）、例外的な実装には違いありません。なぜ例外的な実装を許容することが初めから議論の「暗黙の前提」になっていて、そのことが「改善」と考えられているのかが、私には、いまだにはっきりとは分からないのです。
>>>
>>>
>>>
>>> 以上、私の考えを述べました。
>>> (Nat, if anything that I wrote in each paragraph of the abovementioned
>>> is incorrect or nonsense, please correct me. Thanks.)
>>>
>>> 山本
>>>
>>> アドビ
>>>
>>>
>>>
>>> *From:* 木田泰夫 <kida@mac.com>
>>> *Sent:* Thursday, April 13, 2023 11:53 AM
>>> *To:* Koji Ishii <kojii@chromium.org>; Nat McCully <nmccully@adobe.com>;
>>> Shinyu MURAKAMI <murakami@vivliostyle.org>; Taro Yamamoto <
>>> tyamamot@adobe.com>
>>> *Cc:* Makoto MURATA <eb2m-mrt@asahi-net.or.jp>; 敏 小林 <binn@k.email.ne.jp>;
>>> JLReq TF 日本語 <public-i18n-japanese@w3.org>
>>> *Subject:* Re: CJKフォントのpalt（詰め組）とkernの関係
>>>
>>>
>>>
>>> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>>>
>>>
>>>
>>> 村上さん、Nat さん、山本さん、コメントいただけますか？
>>>
>>>
>>>
>>> 合意の見通しを ISO Open Font Format 5th edition Working Draft へのコメント締め切り 17
>>> 日に間に合わせるのは結構チャレンジですね。
>>>
>>>
>>>
>>> 木田
>>>
>>>
>>>
>>> 2023/04/12 20:19、Koji Ishii <kojii@chromium.org>のメール:
>>>
>>>
>>>
>>> 村田さんがおっしゃられるように現在の記述から意図を読み取ることは難しいと思いますので、改善が必要ですが、 これは結構深いと思います。
>>>
>>>
>>>
>>> まずCKの状況がわかっていません。8について事実確認して、C/Kが6なのか、7なのか、6/7混在なのかを調査する、という手順が必要になりますね。
>>>
>>>
>>>
>>> その上で、6と7
>>> の両方の既存フォントを生かすとなると、仕様として共存できないので、そこを解決しないといけません。新規フォントに関してはいずれかにするか、選べるスイッチを追加するとして、既存フォントに対しては、ヒューリスティックを導入することになるんだと想像しています。いずれにせよ、新規フォントを区別するためのスイッチは必要だと思われますが、これはその方法の議論次第ですね。
>>>
>>>
>>>
>>> 両方を生かす道が見つかったとして。次に、6と7とそのスイッチを仕様化する必要がありますよね。7は、1を削除すれば仕様化できるので簡単ですが、6
>>> は、3/4/5を解決しないと仕様化は難しいかと思います。太郎さんとNatさんのお話だと「全角のみ」というお話なので、3/4/5
>>> を解決したとしても、13よりCSSでは仕様化できません。13に書いた「OpenType Script development specs」に
>>> Japanese（あるいは8の結果ではCJK）セクションを作って、そこに書き起こすのがもっとも筋がよいと思われます。
>>>
>>>
>>>
>>> OpenType/OFFでスイッチの仕様が決まったら、そのスイッチをCSSに入れる、という手順が良いのではないでしょうか。
>>>
>>>
>>>
>>> On Wed, Apr 12, 2023 at 5:53 PM 木田泰夫 <kida@mac.com> wrote:
>>>
>>> 石井さん、
>>>
>>>
>>>
>>> 事実確認ありがとうございます。他の方、コメントがあればお願いします。
>>>
>>>
>>>
>>> この前提で、OpenType の記述を改善するとしたら、6を追認、7を追認、の二つのオプションがある、ということになりますか？
>>>
>>>
>>>
>>> 木田
>>>
>>>
>>>
>>> 2023/04/12 16:16、Koji Ishii <kojii@chromium.org>のメール:
>>>
>>>
>>>
>>>
>>> 返信がすごく遅くなってしまって申し訳ありません。スレッドが予想を超えて多岐にわたり、長くなってきたので、この後の議論を進めるため、一度ここまでの事実関係をまとめたいと思います。私の認識に間違いがありましたら、ご指摘いただけると幸いです。
>>>
>>>
>>>
>>> OpenType/OFF仕様について：
>>>
>>> 1. "If 'kern' is activated, 'palt' must also be activated if it exists."
>>>  と記述されている。この記述は、改善が望まれる。
>>>
>>> 2. 提案者によると、上記1は、CJK全角文字に対しては、`palt` が指定されない限り、`kern`
>>> をかけない、という暗黙の前提が入っている。
>>>
>>> 3. "CJK文字" という用語は、OpenType/OFF仕様において定義されていない。
>>>
>>> 4. "全角文字" という用語は、OpenType/OFF仕様において定義されていない。
>>>
>>> 5. Unicode Scriptで文字列を分割する方法は、標準化されておらず、実装によって異なる。
>>>
>>> 現在のフォント実装について：
>>>
>>> 6. 全角文字に対しての `kern` が、`palt` をかけた後にかける前提で設計されている日本語フォントがある。
>>>
>>> 7. 全角・非全角ともに、`kern` が、`palt` をかけない時にかける前提で設計されている日本語フォントがある。
>>>
>>> 8. CとKについては、事実確認が十分にできていない。
>>>
>>> 現在のアプリ・OSの実装について：
>>>
>>> 9. CJK全角文字に対しては、`palt` がオフの場合には、`kern` もオフにする実装がある。これは上記2に従っている。
>>>
>>> 10. Unicode Scriptで文字列を分割し、分割した部分のscriptがCJKの場合に、全角・非全角にかかわらず、`palt`
>>> がオフの場合には、`kern` もオフにする実装がある。
>>> 11. `palt` がオンだと、`kern` をオフにする実装がある。
>>>
>>> 12. `palt` と `kern` は独立していて、ユーザーの指定の通りに制御する実装がある。
>>>
>>> 13. アプリケーションレベルの実装においては、多くの場合、幅によって適用する機能を変更することは困難である。10が9と少し違うのは、上記4
>>> とこの理由から来る妥協であると推測される。この制限は、シェイプエンジン内部に実装することによって緩和できることがある。OpenType spec
>>> <https://learn.microsoft.com/en-us/typography/opentype/spec/>
>>> の左側ナビゲーションバーにある「Script development specs
>>> 」では、前後の文字列やグリフの情報によって適用する機能を変更している。
>>>
>>>
>>>
>>> 村上さんの調査によると、9がAdobe製品、10がFirefox、11がSafari、12がChromeで合っていますでしょうか？ OSでは、
>>> SafariがCore Textを使っているので、iOS/macOSは11かもしれませんね。Windows/Android/Linuxは12
>>> だと思われます。
>>>
>>>
>>>
>>> 村上さんの csswg#6723 <https://github.com/w3c/csswg-drafts/issues/6723>
>>> の最初のご質問に対しては、13が答えになっているでしょうか？ また、二番目のご質問に対しては、3/4/5/7/8が課題になるかと思います。
>>>
>>>
>>>
>>> 誤認、追加、修正、削除などありましたら、ご指摘いただけると幸いです。
>>>
>>>
>>>
>>> On Wed, Jan 18, 2023 at 6:02 AM Nat McCully <nmccully@adobe.com> wrote:
>>>
>>> 村上さま、皆さま
>>>
>>>
>>>
>>> ナットです。
>>>
>>>
>>>
>>> 村上さん、本当にありがとうございました。このような詳細リサーチは貴重なのです。
>>>
>>>
>>>
>>> Adobe製品では、次の設定がります：
>>>
>>>
>>>
>>> kerning 機能
>>>
>>> CJK全角文字
>>>
>>> 非全角文字
>>>
>>>  Auto （メトリックス）
>>>
>>> kern on, palt on
>>>
>>> kern on (palt no op)
>>>
>>> 和文等幅 (default)
>>>
>>> kern off, palt off
>>>
>>> kern on (palt no op)
>>>
>>> kerning off
>>>
>>> kern off, palt off
>>>
>>> palt off, kern off
>>>
>>>
>>> つまり、和文のデフォルト（ベタ組）と、欧文の望ましいデフォルト（kerning on
>>> ）を同時にサポートするには、「和文等幅」というハイブリッドを追加しなければなりません。CSSのOTFダイレクト設定機能とは違う話なので、kern,
>>> paltをそれぞれ別途で設定できることは許します。ただし、村上さんが見つけた不具合（デフォルトがおかしいとか、和文フォントでpaltなしで
>>> kernがつけられていること）は直して欲しいです。
>>>
>>>
>>>
>>> ナット
>>>
>>>
>>> ------------------------------
>>>
>>> *From:* Shinyu MURAKAMI <murakami@vivliostyle.org>
>>> *Sent:* Monday, January 16, 2023 23:57
>>> *To:* Makoto Murata <eb2m-mrt@asahi-net.or.jp>
>>> *Cc:* Nat McCully <nmccully@adobe.com>; Taro Yamamoto <
>>> tyamamot@adobe.com>; 敏 小林<binn@k.email.ne.jp>; Koji Ishii <
>>> kojii@chromium.org>;泰夫 木田 <kida@mac.com>; public-i18n-japanese <
>>> public-i18n-japanese@w3.org>
>>> *Subject:* Re: CJKフォントのpalt（詰め組）とkernの関係
>>>
>>>
>>>
>>> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>>>
>>>
>>>
>>> 村上です。
>>>
>>>
>>>
>>> CSS仕様とブラウザの実装での palt（詰め組）と kern（あるいは CSS font-kerning
>>> プロパティ）の望ましい関係について、考え直しています。
>>>
>>> 私は前のメール
>>> <https://lists.w3.org/Archives/Public/public-i18n-japanese/2022OctDec/0103.html>
>>>  で次のように書きました:
>>>
>>>
>>>
>>> > font-kerningプロパティでカーニングを有効にしたとき（font-kerning: normal を指定）、OpenTypeの
>>> 'kern' だけではなく 'palt' も on になるとよいです（縦書きでは 'vkrn' と 'vpal'）。最新のFirefox
>>> （開発版）を試したところ、そのようになってました。すべてのブラウザでこの仕様に統一してほしいです。
>>>
>>>
>>>
>>> しかしそのあと、この仕様になるのが本当によいのかどうか迷っています。またFirefox
>>> ばかりがこの動作仕様になって、ほかのブラウザと挙動が一致しない状態が続くということも問題だと感じてます。
>>>
>>>
>>>
>>> 村田さん:
>>>
>>> engineの挙動としては、"you must turn palt on or you turn kern on"の
>>>
>>> 意味が分かりません。paltを適用するか、kernを適用しなければ
>>>
>>> ならない？
>>>
>>>
>>>
>>> Natさんはそのあとのメール
>>> <https://lists.w3.org/Archives/Public/public-i18n-japanese/2022OctDec/0132.html>
>>> で "Typo below.." として"you must turn palt on if you turn kern on"
>>> と訂正されてます。
>>>
>>>
>>>
>>> 'kern' on にするのであれば、必ず 'palt' on にするべきということですね。
>>>
>>> Firefoxではそれが実装されました。
>>>
>>> Mozilla Bugzilla: Kerning is applied to the CJK with "font-kerning:
>>> auto". <https://bugzilla.mozilla.org/show_bug.cgi?id=1797431>
>>>
>>> 関連CSS issue: [css-fonts] Improve implementation guidance for
>>> font-kerning <https://github.com/w3c/csswg-drafts/issues/7958>
>>>
>>>
>>>
>>> Firefoxの現在のバージョン108でこの実装が確認できます。
>>>
>>>
>>>
>>> これをテストするためのHTMLファイルを作りました。
>>>
>>>
>>>
>>> test-font-kerning-palt-ja.html
>>> <https://gistcdn.githack.com/MurakamiShinyu/816d50f2e16bb25a4e13d8b3bd6201fa/raw/test-font-kerning-palt-ja.html>
>>>
>>>
>>>
>>> (on GitHub Gist:
>>> https://gist.github.com/MurakamiShinyu/816d50f2e16bb25a4e13d8b3bd6201fa

>>>  )
>>>
>>>
>>>
>>> このHTMLファイルは、CSSのfont-kerningプロパティとfont-feature-settingsの 'kern' と 'palt'
>>>  の組み合わせについて、カーニングや詰め組の効果がどうなるかをテストするものです。フォントはGoogle FontsでNoto Sans JP
>>> を使ってます。
>>>
>>>
>>>
>>> これで3つのブラウザ（Safari 16.2、Chrome 109、Firefox 108、いずれもmacOS
>>> 版）をテストしたスクリーンショット画像を添付します（上からSafari、Chrome、Firefox）。
>>>
>>>
>>>
>>>
>>>
>>> <kern-palt-safari-chrome-firefox.png>
>>>
>>>
>>>
>>> この結果を見ると、3つのブラウザとも違ってます。1〜10のテスト項目のうち、Safari、Chrome、Firefox
>>> のすべてで一致するのは、次の3項目だけです:
>>>
>>>
>>>
>>>    - 2. font-kerning: none; （カーニングなしの指定の結果、カナ文字や和文約物は全角幅になってる）
>>>    - 5. font-kerning: normal; 'palt' off; （カーニングありと 'palt' off
>>>    の指定の結果、カナ文字や和文約物はほぼ全角幅だがカナ文字のペアカーニングの効果で少し文字間が詰められている）
>>>    - 6. font-kerning: none; 'palt' on; （カーニングなしと 'palt' on
>>>    の指定の結果、カナ文字や和文約物はプロポーショナル幅になっている。カナ文字のペアカーニングがオフなので、ゆるい詰め組となっている）
>>>
>>>
>>>
>>> Safari以外（ChromeとFirefox）が一致するのは次の2項目:
>>>
>>>
>>>
>>>    - 3. 'kern' off; （Safari以外では 2.の font-kerning: none; と同じだが、Safariでは
>>>    font-feature-settings での 'kern' の on/off は無視されるよう）
>>>    - 10. font-kerning: normal; 'palt' on; （'palt' on
>>>    の指定の結果、カナ文字や和文約物がプロポーショナル幅になっているのは一緒だが、Safari
>>>    だけはカナ文字のペアカーニングの効果が見られない。'palt' off のときに kern が効くのに 'palt' on
>>>    のときに効かないというのは、逆であるべきではないか）
>>>
>>>
>>>
>>> Chrome以外（SafariとFirefox）が一致するのは次の1項目:
>>>
>>>
>>>
>>>    - 7. 'palt' on; （'palt' on の指定の結果、カナ文字や和文約物がプロポーショナル幅になっているのは一緒だが、
>>>    Chromeだけはそれに加えてカナ文字のペアカーニングが効いている）
>>>
>>>
>>>
>>> Firefox以外（SafariとChrome）が一致するのは次の4項目:
>>>
>>>
>>>
>>>    - 1. default （font-kerningもfont-feature-settingsも指定しないデフォルトの挙動は、
>>>    Firefoxではカーニングなしの全角幅のカナ文字や和文約物になっているが、SafariとChromeでは5.の font-kerning:
>>>    normal; 'palt' off; と同じく、カナ文字のペアカーニングの効果で少し文字間が詰められている）
>>>    - 4. font-kerning: auto; （font-kerning: auto; はデフォルトなので当然1.と同じ結果）
>>>    - 8. 'kern' on; （Firefoxだけはカーニングありの指定だけで 'palt' on
>>>    の効果もあり、カナ文字や和文約物がプロポーショナル幅でペアカーニングが効いたものになる。しかし、和文約物が欧文文字と隣接するところだけプロポーショナルでなく全角幅になっていることがあり、'palt'
>>>    onを明示的に指定した10.とは結果が少し違っている。この挙動が理解できない）
>>>    - 9. font-kerning: normal; （8.と同様）
>>>
>>>
>>>
>>>
>>>
>>> これらブラウザによる挙動の不一致のうち、望ましい仕様を決めるのに論点になるのは次の2点でしょう:
>>>
>>>
>>>
>>>    - デフォルト（＝font-kerning: auto）の挙動
>>>    - font-kerning: normal （あるいは font-feature-settings: 'kern' on）の挙動
>>>
>>>
>>>
>>> デフォルトの挙動については、Firefoxが適切だと思います。詰め組（'palt' on）ではない和文文字に対してデフォルトで 'kern'
>>> on が適用される現在のSafariとChromeの挙動はOpenType仕様の 'kern'
>>> <https://learn.microsoft.com/en-us/typography/opentype/spec/features_ko#tag-kern>
>>>  の Feature interaction として書かれている "If 'kern' is activated, 'palt' must
>>> also be activated if it exists." と合っていません。
>>>
>>>
>>>
>>> font-kerning: normal （あるいは font-feature-settings: 'kern' on）のFirefox
>>> の挙動は、"If 'kern' is activated, 'palt' must also be activated if it
>>> exists." という要求を忠実に実装しようとしたもののようですが、本当にこの挙動が適切なのかどうか再検討する必要があると思います。
>>>
>>>
>>>
>>> paltとkernの組み合わせで可能なカナ文字など和文文字の詰め方は次の4通りがあります。
>>>
>>>
>>>
>>>    - 'palt' off, 'kern' off ベタ組み （テスト項目2の結果）
>>>    - 'palt' off, 'kern' on ほぼベタ組み （テスト項目5の結果）
>>>    - 'palt' on, 'kern' off ゆるめの詰め組 （テスト項目6の結果）
>>>    - 'palt' on, 'kern' on きつめの詰め組 （テスト項目10の結果。ただしSafari以外）
>>>
>>>
>>>
>>>
>>> ここで「ベタ組み」と書いたのは、カナ文字と和文約物が全角幅の固定ピッチになっているということです。「ほぼベタ組み」は、見た目はほとんど「ベタ組み」だけど、和文ペアカーニングが有効になっているためにカナ文字などが少しだけ詰まっているものです。'palt'
>>> off, 'kern' on という組み合わせを使うのはOpenType仕様の記述に合っていないとしても、現状のブラウザ（Safariと
>>> Chrome
>>> ）のデフォルトではこれになるので、無視することはできません。また、これがデフォルトの挙動であることに、これまでほとんどクレームがなかった、あるいは誰も気にしていなかったように、
>>> Web上の和文のテキストレイアウトとして不自然には見えません。
>>>
>>>
>>>
>>> 「詰め組」（'palt' on）を 'kern' の off と on で「ゆるめの詰め組」と「きつめの詰め組」に分けました。'palt' の
>>> off と on の大きな違い（全角幅だった句読点や括弧類が半角幅になり、カナ文字は全体的に詰められる）に対して、'kern' の off と
>>> on との違いはそれほどは目立たないものです。
>>>
>>>
>>>
>>> CSSでカーニングありを指定した場合の挙動が、SafariとChromeでは「ほぼベタ組み」なのに、Firefox
>>> だけは「きつめの詰め組」になるので、かなり変わります。このFirefoxの今の挙動が適切で、ほかのブラウザも追随するべきなのでしょうか？
>>> 次のようなところ疑問に感じてます。
>>>
>>>
>>>
>>>    - CSSでカーニングありが指定されている意図は、和文の詰め組のためではなく、欧文のためであることがほとんどでしょう。そのようなWeb
>>>    サイトで日本語のテキストが詰め組になってしまうことで、文字間が詰まって読みにくくなるケースが出てきます。カーニングありを指定すると必ず
>>>    'palt' が有効になる（和文が詰め組になる）という挙動は、多くのWeb
>>>    制作者やユーザーが期待するものとは違っているのではないかと思います。
>>>
>>>
>>>
>>>    - カーニングありを指定するCSSのfont-kerningプロパティの値 normal で和文が詰め組になるというのは、まったく「
>>>    normal」という感じがせず、違和感があります。普通に読みやすい結果になるというのが「normal」であるべきでしょう。
>>>
>>>
>>>
>>> 現在の日本語のWebでは、詰め組にするのに font-feature-settings: 'palt' を使うことが広まっています。'palt'
>>> on によって詰め組になった和文テキストに対して、さらに和文ペアカーニングによる詰めを適用するかどうかをfont-kerning
>>> プロパティで指定できるというのが、期待されるものなのでないかと思います。それが可能である現在のChromeの実装の方がよいのでないでしょうか。
>>>
>>>
>>>
>>> 現在CSSで詰め組の指定のために使われている font-feature-settings プロパティ
>>> <https://developer.mozilla.org/ja/docs/Web/CSS/font-feature-settings>は、「
>>> OpenType
>>> フォント特性を有効またはアクセスするための他の方法が存在しない特殊なケースを処理するように設計された低レベルの機能」を指定するためのものです。日本語の詰め組はよく使われるものであり、「特殊なケース」とはいえません。また、
>>> font-feature-settings でこの機能を指定する場合、横組では 'palt'、縦組では'vpal'
>>> と使い分ける必要があります（縦組用と横組用とが間違って使われるとレイアウト不具合が起きます）。CSSプロパティで詰め組（横組では 'palt'
>>> 、縦組では 'vpal'）を指定するためfont-feature-settings以外のものがあるとよいと思います。
>>>
>>>
>>>
>>> すでにCSSの font-variant-east-asian プロパティ
>>> <https://developer.mozilla.org/ja/docs/Web/CSS/font-variant-east-asian>
>>> には'proportional-width' という値が定義されています。ただし、これはOpenTypeの 'palt'/'vpal' ではなく
>>>  'pwid' を指定するものです。和文を詰め組にするのに 'pwid'よりも 'palt' を使いたいことのほうが多いでしょう。すでにある
>>> 'proportional-width' という値の定義は変えられないでしょうから、横組では 'palt'、縦組では'vpal'
>>> を指定するための値として *'proportional-spacing'* を追加するのがよいのでないかと考えてます。
>>> font-variant-east-asian プロパティはショートハンドプロパティの font-variant
>>> プロパティで指定することもできるので、 *'font-variant: proportional-spacing'*
>>> で詰め組を指定することができるようになります。
>>>
>>> （csswg-drafts/issues <https://github.com/w3c/csswg-drafts/issues>
>>> に提案を書こうと思います）
>>>
>>>
>>>
>>> 'proportional-spacing' （＝ 'palt’/'vpal'）が指定されている和文テキストに対して、font-kerning:
>>> normal で和文ペアカーニングが有効になり、それが指定されていない和文テキストに対しては font-kerning: normal
>>> で和文ペアカーニングが有効にはならない、という挙動であれば、OpenType仕様の "If 'kern' is activated,
>>> 'palt' must also be activated if it exists." という要件とも合っていると思います。
>>>
>>>
>>>
>>> font-kerning: normal がこの挙動であれば、デフォルトの font-kerning: auto
>>> （カーニングを使用するかをブラウザーに任せる）も同じで問題ないでしょう。
>>>
>>>
>>>
>>> 以上、CSS仕様とブラウザの実装での palt（詰め組）と kern（あるいは CSS font-kerning
>>> プロパティ）の望ましい関係について、考え直したことを書きました。
>>>
>>>
>>>
>>>
>>>
>>> ----
>>>
>>> 村上 真雄 (MURAKAMI Shinyu)
>>>
>>> Vivliostyle Foundation
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Dec 19, 2022, at 13:46, MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
>>> wrote:
>>>
>>>
>>>
>>> Nat,
>>>
>>>
>>>
>>> 2022年12月19日(月) 0:50 Nat McCully <nmccully@adobe.com>:
>>>
>>> It occurs to me we are also taking about two things. I am taking about
>>> requirements for apps to support the fonts correctly.
>>>
>>>
>>>
>>> 確かに、フォントの適合性要件と、engineの適合性要件
>>>
>>> はまったく別ですね（engineという言葉を私は適当に
>>>
>>> 使います、組版プログラムと、フォントを扱うエンジン
>>>
>>> を分ける必要があるのかどうかも私には分かって
>>>
>>> いません）。
>>>
>>>
>>>
>>> The spec is about the fonts only,
>>>
>>>
>>>
>>> engineの適合性要件は定めていないし、それでいいという主張ですね。
>>>
>>> 普通、規格では、データの意味をきちんと規定するためには、
>>>
>>> 何らかのプログラムの動作を（少なくともreference modelとして）
>>>
>>> 記述します。engineについての記述を完全に避けるわけには
>>>
>>> 行かないと思います。
>>>
>>>
>>>
>>> and for a font it is perfectly fine not to include palt if they do not
>>> want to. But if you are an app you must turn palt on or you turn kern on.
>>>
>>>
>>>
>>> あるフォントのあるグリフに対してpaltがなくてもいい。たとえ日本語全角
>>>
>>> 文字についてもそうなのでしょう。ここは理解しました。
>>>
>>>
>>>
>>> engineの挙動としては、"you must turn palt on or you turn kern on"の
>>>
>>> 意味が分かりません。paltを適用するか、kernを適用しなければ
>>>
>>> ならない？
>>>
>>>
>>>
>>> 村田 真
>>>
>>>
>>>
>>> The font spec isn’t going to tell you that necessarily, since it is
>>> taking about correct font implementation and the limitations of the format
>>> force any Japanese font that kerns Japanese characters to use palt plus
>>> kern to do it. The problem is apps are not aware of this and read the font
>>> spec expecting app implementation advice and apparently it isn’t clear.
>>> Apps must turn palt on together with kern. If the font lacks palt it’s
>>> a no-op.
>>>
>>>
>>>
>>> —Nat
>>> ------------------------------
>>>
>>> *From:* MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
>>> *Sent:* Sunday, December 18, 2022 7:34:15 AM
>>> *To:* Nat McCully <nmccully@adobe.com>
>>> *Cc:* Taro Yamamoto <tyamamot@adobe.com>; 敏 小林<binn@k.email.ne.jp>;
>>> Koji Ishii <kojii@chromium.org>; 泰夫 木田<kida@mac.com>;
>>> public-i18n-japanese <public-i18n-japanese@w3.org>
>>> *Subject:* Re: CJKフォントのpalt（詰め組）とkernの関係
>>>
>>>
>>>
>>> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>>>
>>>
>>>
>>> Nat,
>>>
>>>
>>>
>>> I am saying that OFF fails to clearly state
>>>
>>> conformance requirements.  Meanwhile, you
>>>
>>> are talking about the background or rationales
>>>
>>> behind conformance requirements.
>>>
>>>
>>>
>>> Our concerns are orthogonal, as I see it.
>>>
>>> I personally do not care about the rationales
>>>
>>> behind conformance requirements.
>>>
>>> Your remarks are certainly useful and should
>>>
>>> probably be added as a note in OFF.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Makoto
>>>
>>>
>>>
>>>
>>>
>>> 2022年12月18日(日) 23:55 Nat McCully <nmccully@adobe.com>:
>>>
>>> Actually, the problem is that the spec and the kern featur originally
>>> only considered Latin proportional typography. When Japanese fonts
>>> introduced a design that was monospaced for part of its repertoire and
>>> proportional for the other, there exists a conundrum. How to make kerning
>>> optional for only part of the font and normal for the other part? That was
>>> how palt was introduced and that is why it can be confusing until you think
>>> through the technical limitations of the font format such as glyph number
>>> limitations and kerning table limitations etc.
>>>
>>> If the font is monospaced and you want to optionally kern it with a kern
>>> feature, you need kerning pairs for all combinations of glyphs. No one does
>>> this, so everyone thinks the kern feature if it exists is required. This is
>>> true for Latin but not for Japanese fonts. Japanese fonts usually are
>>> monospaced for the Japanese glyphs and proportional for the Latin, so the
>>> kern feature is usually turned on only for the proportional glyphs and
>>> requires the monospaced glyphs to be made proportional by palt before you
>>> can apply kern to them. Most people do not understand this technical
>>> detail.
>>>
>>>
>>>
>>> —Nat
>>>
>>>
>>>
>>> —Nat
>>> ------------------------------
>>>
>>> *From:* MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
>>> *Sent:* Sunday, December 18, 2022 5:17:43 AM
>>> *To:* Taro Yamamoto <tyamamot@adobe.com>
>>> *Cc:* 敏 小林 <binn@k.email.ne.jp>; Koji Ishii <kojii@chromium.org>; 泰夫 木田<
>>> kida@mac.com>; public-i18n-japanese <public-i18n-japanese@w3.org>
>>> *Subject:* Re: CJKフォントのpalt（詰め組）とkernの関係
>>>
>>>
>>>
>>> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>>>
>>>
>>>
>>> 山本さん、
>>>
>>> 有難うございます。
>>>
>>> 文面を読んでみて、山本さんの主張している内容は、こ
>>> の規格には適合性要件として記述されていないと判断し
>>> ます。以下、その理由を詳しく説明します。
>>>
>>> まず、OFFは何を規定しているか？スコープを読むと、二
>>> つのことを規定しているようです。一つは、フォントを
>>> 表すデータ形式です。もう一つは、font rendering and
>>> text layout/shaping enginesの挙動です。
>>>
>>> しかし、font rendering and text layout/shaping
>>> enginesとは何かの定義はOFF規格書のどこにもありませ
>>> ん。そして、enginesを主語としてshall, are required
>>> to, shouldで始まる文も一つもありません。つまり、
>>> font rendering and text layout/shaping enginesの適
>>> 合性要件はOFFには規定されていないと私は判断します。
>>>
>>> 次に以下の二つの文について論じます。
>>>
>>> >If 'kern' is activated, 'palt' must also be
>>> > activated if it exists.
>>>
>>>
>>> うるさいことを言うと、ISO/IECでは適合性要件を書くた
>>> めにmustは決して使ってはいけません（mustを使うと、
>>> 法律など規格でないものが定めた要件になります）。大
>>> 目に見ることにして、mustはshallのタイポだと思うこと
>>> にします。
>>>
>>> さてこの二つの文はフォントというデータの適合性要件
>>> を書いているのでしょうか？それとも、font rendering
>>> and text layout/shaping enginesの適合性要件を書いて
>>> いるのでしょうか？私にはどちらなのかよく分かりませ
>>> ん。
>>>
>>> kernをもつフォントは、paltが必須なのでしょうか？if
>>> it existsという条件があるところを見ると、どうやらそ
>>> うではなさそうです。kernを持つがpaltを持たないフォ
>>> ントは許されているような気がします。
>>>
>>> activateという語は、rendering and text
>>> layout/shaping enginesの挙動を意味するので
>>>
>>> しょうか？だとすると、これらの文はフォントの
>>>
>>> 適合性要件をまったく規定していないことになります。
>>>
>>> 以下の四つの文のどれが山本さんの意図と合っていますか？
>>>
>>> 1) kernを持つフォントは、paltは持たなければならない
>>>
>>> 2) kernを持つフォントは、paltを持ってもよいが、持た
>>>    なくてもよい。
>>>
>>> 3) フォントのkernを考慮してglyphの位置決めを行う
>>>     engineは、paltも考慮しなければならない。
>>>
>>> 4) フォントのkernを考慮してglyphの位置決めを行う
>>>    engineは、paltを考慮してもよいが、しなくてもよい。
>>>
>>> 村田 真
>>>
>>>
>>>
>>> 2022年12月18日(日) 7:03 Taro Yamamoto <tyamamot@adobe.com>:
>>>
>>>
>>>
>>>    - 書かれているか具体的に教えていただけますか？
>>>
>>>
>>>
>>> p. 585 (‘kern’), p. 596 (‘vpal’), p. 624 (‘vkrn’, ‘vpal’)のFeature
>>> interactionの項目に、’kern’と’palt’, ‘vkrn’と’vpal’との関係が書かれています。
>>>
>>>
>>>
>>> 山本
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Regards,
>>>
>>> Makoto
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Regards,
>>>
>>> Makoto
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Regards,
>>>
>>> Makoto
>>>
>>>
>>>
>>
>>
>> --
>> Regards,
>> Makoto
>>
>

-- 
Regards,
Makoto