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

石井さん、

コメントいただきありがとうございます。



> 既存フォント、ソフトの互換性を考慮し、追認する方法を探す議論かと思っていましたが、まずそこが違いますね？　太郎さんは、ご自身のご意図に沿わないフォントやソフトの互換性を考慮しないことを推奨されているんですね？



「意図に沿わない」フォントとの互換性を実装が考慮すること自体に絶対反対というわけではありません。



ただし、その「意図」は規格としては不完全であるかもしれないOpenTypeの仕様の背後にある考え方であるため、その「意図」と仕様の意味すべき内容とを切り離すことはできず、規格の改善とは、その仕様の「意図」が規格の内容として反映されるように改訂すること、あるいは暗黙の前提条件がある場合には、それを規格の上で明示すること、であると考えます。



> あと、太郎さんの「間違っている」というお話ですが、私の理解では、村上さんの「間違っている」はフォントの設計思想のお話で、太郎さんのお話は仕様から逸脱している、というお話ですが、合っていますか？ 私は、実装は、仕様に基づくもので、仕様の裏にある設計思想を矯正するものではないと思っているので、私の村上さんへの返信はここから来ていますが、太郎さんの「間違っている」の場合には、仕様の記述が充分でないため、仕様から逸脱しているとは言い切れず、その裏にある設計思想から逸脱していても「間違っている」とはいえないと思っています。



現在議論されている、‘palt’の仕様は、規格が存在する以前から存在していました。その設計思想はさらにそれ以前から存在していたはずです。規格上は必ずしも「間違っている」わけではない実装であっても、それが、元々の仕様とその設計思想の意味する内容から逸脱している場合には、それは設計思想の上では「間違っている」とみなすことができます。その点では、私の考えは村上さんの考え方に近いものと考えます。



そして、規格が存在する以前には、そもそも規格の観点から「間違っている」実装も「間違っていない」実装もありえません。しかし、規格になる以前の仕様に、“If ‘kern’ is activated, ‘palt’ must also be activated if it exists.”と書いてあった場合に、‘palt’があっても‘palt’をアクティベートせずに‘kern’を日本語の全角文字にかけても良いという解釈の妥当性を、規格上の用字用語の規則の観点から、「間違ってはいない」と判断することもできなかったわけです。むしろ、たとえ解釈に幅があったとしても、“If ‘kern’ is activated, ‘palt’ must also be activated if it exists.”という文を、“If ‘kern’ is activated, ‘palt’ does not need to be activated even if it exists.”と理解するような解釈は、規格以前の仕様の段階では、「間違っている」と見なされていたとしても不思議ではありません。書いてある事と正反対の意味に解釈しているのですから。



設計思想と一致する実装を可能にする規格にすることが、規格の改善の目的であって、設計思想から規格が乖離していくことを助長することが改善とはいえないのではないでしょうか。したがって、理想的には、設計思想をより正確かつ明示的に規格に反映させるべきでしょう。



> S2.a. CJK全角文字に対しては、`palt` が指定されない限り、`kern` をかけない、という暗黙の前提が入っている。



繰り返しますが、なぜ、S1.に書いてあることと同じことが、暗黙の前提なのか、が理解できません。規格として不適切・不完全かつ改訂を要する記述であって、それによって設計思想上は「間違っている」実装もまた「間違っていない」と見なされることがあるとしても、そこに書いてあることは暗黙の前提ではなく、明記された意図であるはずです。でなければ、書く必要はなかったのです。



> S1. “If ‘kern’ is activated, ‘palt’ must also be activated if it exists.” と記述されている。この記述は、複数の解釈が可能で、改善が望まれる。



どのような解釈の幅があるのかは私には理解できませんが、上と同様、規格の上で、その記述の不完全さのために、設計思想上は「間違っている」実装もまた「間違っていない」と見なされることがあったとしても、そのことによって、‘palt’があっても‘palt’をアクティベートせずに‘kern’を日本語の全角文字にかけても良いという解釈を可能にしているなら、その記述を改め、そのような解釈の可能性を封じる必要があると考えます。（しかし、そのこととは独立に、‘must’の意味を‘does not need to’という意味で解釈できるほどに、実装者の解釈の幅が広くなりうるということを理解するのは、かなり難しく感じます）。



> S3.b.既存フォント、ソフトの実装は無視して、上記S2で明確にされた意図を仕様化する



設計思想上の意図を正確に明示した上で、それに加えてこれまでの規格の上では「間違っていない」けれども、設計思想上は「間違っている」実装を必ずしも無視しない、方法はありえないのでしょうか。



つまり、設計思想上の意図を正確に規格の文言に反映させる改訂を行うと同時に、それを正としつつも、歴史的経緯として存在しうる（あるいは存在する）規格上は「間違っていない」けれども設計思想上は「間違っている」実装を、非推奨の実装ではあるが、歴史的経緯の上から、（時限的にでも）許容されうる、副次的な実装として例示し、ただし、未来においてははそのような実装を許容しない、等の、方法はないのでしょうか。（もちろん、その種のフォントの実装の数が相対的に少ない場合には、このような救済策は必要ないと考えますが）。



以上、毎回長くなり申し訳ありませんが、追加のコメントをしました。



山本

アドビ