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

>
>
> そして、話の大本となる仕様の意図ですが、このメールスレッドから私と村上さんは同じように読めましたが、村田さんは違うように読んだそうですので、いったん現状認識を「不明」に改めるべきかと思います。太郎さんが返信くださいましたが、私には解読できませんでした。村田さん、この太郎さんの返信で理解は、揃ったのでしょうか？
>

Natの回答を山本さんは要請していると理解しています。

しかし、山本さんはこう書いています。

 I personally think that Western (Latin) fonts and true-proportional
> Japanese fonts don't need the 'palt' feature at all. Therefore, even if the
> ‘palt’ is activated on the application software by the user, it is ignored.
> Right?


これからすると、If 'kern' is activated, 'palt' must also be activated if it
exists.が恐らく
指しているでろう内容は訂正の必要がないのだろうと思います。つまり、CJK全角文字
という条件は要りません。

生粋の規格屋の私ならこう書きます。これが私のS2.bです。

Suppose that a font specifies the 'kern' feature
and the 'palt' feature for a given glyph.
If the abstract font engine uses the 'kern'
feature for rendering this glyph, it shall also use
the 'palt' feature.

山本さんの書いている以下の文章は、私も扱いに困ります。

以前の、メールで、'palt'がなくて'kern'だけがある日本語フォントを作って、それが使えるなら、そうすれば良いだけではないか、
> というようなことを書いたかもしれません。その意図は、「間違っている」フォントがありえて、しかも現実にあるのであれば、
> それを切り捨てないアプリケーションの実装があったとしても、それもまた現実として許容できるという意味で書きました。ただ、
> その時も、それだけでなく、同じことを達成する方法として、字幅やサイドベアリングを一切書き換えないダミー的な'palt'
> と実際に必要なカーニングの情報を入れた'kern'をもつフォントを作ることは可能ではないかとも書きました。（
> この方法が実際に現実のアプリケーションの実装上で期待通りに動くかどうかはわかりませんが、理屈の上では可能なので述べた次第です。）この方法が使えれば、
> 無意味な'palt'を付け足すだけで「間違っている」フォントが「間違っていない」フォントに変わります。


しかし、規格屋である私の割り切りは、 'palt'がなくて'kern'だけがある
日本語フォント（プロポーショナルでないもの）を作っても問題なく、
abstract font engineは'kern'だけ利用しても構わないという
ものです。

村田 真



> あと、太郎さんの「間違っている」というお話ですが、私の理解では、村上さんの「間違っている」はフォントの設計思想のお話で、太郎さんのお話は仕様から逸脱している、というお話ですが、合っていますか？
> 私は、実装は、仕様に基づくもので、仕様の裏にある設計思想を矯正するものではないと思っているので、私の村上さんへの返信はここから来ていますが、太郎さんの「間違っている」の場合には、仕様の記述が充分でないため、仕様から逸脱しているとは言い切れず、その裏にある設計思想から逸脱していても「間違っている」とはいえないと思っています。
>
> また、太郎さん、村上さんから、既存フォントの数についてご意見が出されていますが、私は逆の想像をしているので、綿心もデータは持っていませんが、数の押し出しは、データが揃うまでやめませんか？
> 現状認識F4に追加しました。
>
> 現状認識改め（番号の付け方を変えました）：
> OpenType/OFF仕様について：
>
> S1. "If 'kern' is activated, 'palt' must also be activated if it exists."
> と記述されている。この記述は、複数の解釈が可能で、改善が望まれる。
> S2. 上記S1の提案者の意図は現状不明確。本スレッドでの釈明を受けて、二通りの解釈が存在している。
>
> S2.a. CJK全角文字に対しては、`palt` が指定されない限り、`kern` をかけない、という暗黙の前提が入っている。
>
> S2.b （村田さん解釈。違う、とおっしゃられましたが、村田さんの解釈がわかっていません）
>
> S3. 改善の方向性として、２つの意見がある
>
> S3.a 既存フォント、ソフトの実装を追認し、互換性に配慮した仕様に更新する
> S3.b.既存フォント、ソフトの実装は無視して、上記S2で明確にされた意図を仕様化する
> S3.c. 合意がないため、何もしない
> S3.d. 合意がないため、複数の解釈が可能な部分を削除する
>
> S4. "CJK文字" という用語は、OpenType/OFF仕様において定義されていない。
> S5. "全角文字" という用語は、OpenType/OFF仕様において定義されていない。
> S6. Unicode Scriptで文字列を分割する方法は、標準化されておらず、実装によって異なる。
> S7.
> アプリケーションレベルの実装においては、多くの場合、幅によって適用する機能を変更することは困難である。A2がA1と少し違うのは、S5とS7から来る妥協であると推測される。この制限は、シェイプエンジン内部に実装することによって緩和できることがある。OpenType
> spec <https://learn.microsoft.com/en-us/typography/opentype/spec/>の左側ナビゲーションバーにある「Script
> development
> specs」では、前後の文字列やグリフの情報によって適用する機能を変更しているので、幅によって機能を変える場合には、この仕様への変更が望ましい。
>
> 現在のフォント実装について：
>
> F1. 全角文字に対しての `kern` が、`palt` をかけた後にかける前提で設計されている日本語フォントがある。
> F2. 全角・非全角ともに、`kern` が、`palt` をかけない時にかける前提で設計されている日本語フォントがある。
> F3. CとKについては、事実確認が十分にできていない。
>
> F4. 既存フォントで、F1とF2のいずれが多いかについては意見が割れており、データがない。
>
> 現在のアプリ・OSの実装について：
>
> A1. CJK全角文字に対しては、`palt` がオフの場合には、`kern` もオフにする実装がある。これは上記2に従っている。
> A2. Unicode Scriptで文字列を分割し、分割した部分のscriptがCJKの場合に、全角・非全角にかかわらず、`palt`
> がオフの場合には、`kern` もオフにする実装がある。
> A3. `palt` がオンだと、`kern` をオフにする実装がある。意図した挙動ではないかもしれないので、確認する。
> A4. `palt` と `kern` は独立していて、ユーザーの指定の通りに制御する実装がある。
>
>
>
> 私の意見になりますが、S3については、Chromeとしては、互換性を無視することはありえないと思っていますし、マイクロソフト、アップルに持っていっても同様の反応ではないかと想定しています。このため、私の立場は、S3.a、S3.c、S3.dのいずれかになります。
>
> 村田さん、とりあえず期限が迫っているのであれば、複数解釈が可能で、期限には間に合わないが、元の意図の解釈を現在議論中、と一報入れておくのはいかがでしょう？
> 次のレビューのタイミングで大きな変更を入れるにしても、事前に一報入っていたほうがスムーズな気がします。
>
>
> On Fri, Apr 14, 2023 at 11:23 AM Taro Yamamoto <tyamamot@adobe.com> wrote:
>
>> 各位、
>>
>> いくつかコメントします。（複数のコメントがあったので、書くのに時間がかかってしまいました）。
>>
>>
>>
>> 村田さんwrote:
>>
>> > 欧文フォントやプロポーショナル日本語フォントにpaltを指定する人はいないから、そういうフォントにpaltを指定した
>>
>> ときの動作は気にするはないという割り切りはありですか？
>>
>> > つまり、全角日本語文字という判定に苦労する条件は入れなくていいのでは？
>>
>>
>> ナットの方がアプリケーションソフトの動作には詳しいと思います。
>>
>> I believe Nat knows better about the behavior of apps.
>>
>>
>>
>> Nat,
>>
>>     I personally think that Western (Latin) fonts and true-proportional
>> Japanese fonts don't need the 'palt' feature at all. Therefore, even if the
>> ‘palt’ is activated on the application software by the user, it is ignored.
>> Right?
>>
>> But it seems to me that the question has two underlying layers: 1) with
>> what information apps. distinguish Western (Latin) fonts, EM-based standard
>> Japanese fonts, and true-proportional Japanese fonts, and 2) with what
>> information apps. distinguish Japanese characters that should be regarded
>> as "Japanese EM-body-based" characters (which do not always need to have
>> em-square bodies actually, as there can be condensed fonts. In the sense,
>> the "Japanese EM-body-based" characters, in this context, are only
>> nominally "EM-based" for the purpose of determining whether the 'kern'
>> feature can be applied to the characters without the 'palt' activated.
>>
>> I guess some code ranges such as that which is defined in the UAX #11 are
>> used, to determine 2) above. But is this correct?
>>
>> Also, what do you think about the question 1) above?
>>
>> If you could make any comments here to answer Mr. Murata's questions, I
>> should be most appreciative.
>>
>>
>>
>> 石井さんwrote:
>>
>> >
>> 木田さんは「追認」と書かれましたので、二種類の異なる解釈をしたフォントと、三種類の異なる解釈をしたソフトの合計五者が、それぞれ過去互換性を大きく損なうことはなく、フォント実装者の意図を正しく反映した表示ができる未来を作りたい、ということだと私は理解しています。そのために、共存するための技術と、それを仕様に反映する必要がありますね、というのが私のまとめの意図です。
>>
>>
>>
>> 了解しました。その点は、村上さんがコメントされている内容と関係するように思います。
>>
>>
>>
>> Nat wrote:
>>
>> > To transform a monospaced font into a proportional font to ready it for
>> creation of kern pairs, you use the palt feature.
>>
>>
>>
>> I completely agree, as far as the abovementioned questions 1) and 2) are
>> answered clearly.
>>
>>
>>
>> 村上さんwrote:
>>
>> 7のような日本語フォントは実際にあるのでしょうか？ `palt`
>> が存在しないデフォルトでプロポーショナルなフォントであれば、それがありえると思いますが、`palt` が存在するのに `palt`
>> をかけないときに `kern` をCJK
>> 全角文字にかける前提で設計されている日本語フォントというのはありえない（あったとしたら、フォントの設計が間違っている）と思います。ですので、「二種類の異なる解釈をしたフォント」ではなくて、単に
>> `palt` が存在するかしないかの二種類のフォントがあることを考慮するとよいでしょう。私の
>> https://github.com/w3c/csswg-drafts/issues/6723#issuecomment-1454783131

>> での `font-kerning: normal` についての提案（フォントに `palt` が存在する場合は非CJK
>> 文字のみをカーニングし、フォントに `palt` が存在しない場合は全てカーニングする）は、それを考慮したものです。
>>
>>
>>
>> 私も同じように考えます。
>>
>>
>>
>> 石井さんwrote:
>>
>> 「設計が間違っているフォントは互換性を取らなくて良い」という理論で存在するフォントを切り捨てることは難しいかと思います。
>>
>>
>>
>>
>> アプリケーションの実装が、仕様から逸脱した「間違っている」フォントを切り捨てることが難しい場合があることは理解します。しかし、だからといって、そのような実装間の互換性のために、「間違っている」内容を元の仕様に反映させて、「間違って」いないないようにさせる、というのは本末転倒ではないでしょうか。「間違っている」フォントの存在を現実として許容する必要があるのであれば、そのような「間違っている」フォントを許容するアプリケーションの実装もまた、現実として許容すればよいだけです。しかし、その運用上の現実的対応が必要だったとして、「間違っている」内容を仕様に反映させなければならない理由にはならないと思います。その理屈でいくと、どんな仕様や規格が作られても、それから逸脱した実装を誰かが作りさえすれば、それを仕様に反映させなければいけなくなります。また、実際に「間違っている」フォントが存在したとして、その数は相対的に極めて少ないことを考慮する必要があります。さらに、仕様を改善するのであればそれらの、ごく少数の「間違っている」フォントの数を、将来的には低減させて最終的にはゼロにするための改善でなければならないと考えます。
>>
>>
>>
>> 村田さんwrote:
>>
>> > paltがなければkernも適用しないという規則がCJK全角文字のときには
>>
>> > 存在すると主張しているわけですね。私が山本さんのメールから
>>
>> > 読み取った内容とは違うので、山本さんに確認をお願いします。
>>
>>
>>
>> 以前の、メールで、'palt'がなくて'kern'
>> だけがある日本語フォントを作って、それが使えるなら、そうすれば良いだけではないか、というようなことを書いたかもしれません。その意図は、「間違っている」フォントがありえて、しかも現実にあるのであれば、それを切り捨てないアプリケーションの実装があったとしても、それもまた現実として許容できるという意味で書きました。ただ、その時も、それだけでなく、同じことを達成する方法として、字幅やサイドベアリングを一切書き換えないダミー的な
>> 'palt'と実際に必要なカーニングの情報を入れた'kern'
>> をもつフォントを作ることは可能ではないかとも書きました。（この方法が実際に現実のアプリケーションの実装上で期待通りに動くかどうかはわかりませんが、理屈の上では可能なので述べた次第です。）この方法が使えれば、無意味な
>> 'palt'を付け足すだけで「間違っている」フォントが「間違っていない」フォントに変わります。
>>
>>
>> Nat, please add your comments and correct any points in my comments, as
>> necessary. Thanks.
>>
>> 山本
>>
>> アドビ
>>
>>
>>
>> *From:* MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
>> *Sent:* Friday, April 14, 2023 5:35 AM
>> *To:* Koji Ishii <kojii@chromium.org>
>> *Cc:* Taro Yamamoto <tyamamot@adobe.com>; 木田泰夫 <kida@mac.com>; Nat
>> McCully <nmccully@adobe.com>; Shinyu MURAKAMI <murakami@vivliostyle.org>;
>> 敏 小林 <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を持つCJKフォントで、太郎さんの意図に沿ったフォントにおいては、kern
>> の解釈を以下のようにする必要があります（私が誤解していなければ、ですが。）
>>
>>    - 適用対象がCJK全角文字である場合には、paltも指定されていれば適用するが、そうでない場合には適用しない
>>    - 適用対象がそれ以外の場合には、常に適用する
>>
>> このルールを仕様化するために、「CJK全角文字である」という定義が必要になる、というのが私の理解です。
>>
>>
>>
>> paltがなければkernも適用しないという規則がCJK全角文字のときには
>>
>> 存在すると主張しているわけですね。私が山本さんのメールから
>>
>> 読み取った内容とは違うので、山本さんに確認をお願いします。
>>
>>
>>
>> 村田 真
>>
>>
>>
>

-- 
Regards,
Makoto