- From: Koji Ishii <kojii@chromium.org>
- Date: Mon, 5 Dec 2022 13:32:58 +0900
- To: atsuda@fontworks.co.jp
- Cc: tyamamot@adobe.com, kida@mac.com, public-i18n-japanese@w3.org
- Message-ID: <CAHe_1dKe+c4_Kg306q4GE6730s_nUVtRAdjywWxOD2nmsMynwg@mail.gmail.com>
津田さん、情報ありがとうございます。実装方法がどうなるかまだよく見えていませんが、実装の話になれば、既存フォントとの互換性を考えることになると思います。その時に、どれほどの既存フォントがあるのか、というのは大変参考になるかと思いますので、情報、大変ありがたいです。 On Tue, Nov 29, 2022 at 4:27 PM <atsuda@fontworks.co.jp> wrote: > 横から失礼いたします。 > > フォントワークスの津田です。 > > > > 弊社では、kernを設定する際には、palt、BASEを適用した上で行っております。 > > それは、この一連のメールの最初の方で上がった仕様があるからです。 > > もし、それが無ければ、二つの状況(palt有無)で、kernを設定する必要が出てきます。 > > > > > > *差出人**: *Koji Ishii <kojii@chromium.org> > *日付**: *火曜日, 2022年11月29日 14:22 > *宛先**: *Taro Yamamoto <tyamamot@adobe.com> > *CC: *木田泰夫 <kida@mac.com>, W3C JLReq TF <public-i18n-japanese@w3.org> > *件名**: *Re: CJKフォントのpalt(詰め組)とkernの関係 > > 太郎さん、お返事ありがとうございます。こちらの返事が遅くなりましてすみません。 > > > > 大変丁寧に説明していただき、お考え、よく理解できたと思います。重ねてありがとうございます。 > > > > > 私は実装者であり、フォントデザイナーではないので、どちらの意見にも加担するわけではないのですが、少なくとも「す。」や他のいくつかの全角ペアにカーニングを設定したフォントを作った方々がいらっしゃる、ということは、太郎さんのおっしゃる > > > 「詰めた方が視覚的に好ましい」と感じることを理由にしてカーニングを有効にするのであれば、当然、特に他の仮名文字間の視覚的なスペーシングの不均等もまた、「詰めた方が視覚的に好ましい」と感じるはずです(そう感じない人がゼロではないかもしれませんが、感じてもおかしくないと考えるのが自然でしょう)。 > > の部分を「仮名文字間は全角送りで、特定の文字間を詰めるのは自然」と考える方が一定数いらっしゃる、ということを示唆しているように思われます。 > > > > > 私は、異なる考え方は複数あってもよい、ある方が自然、と思っていますので、いずれを否定するわけでも肯定するわけでもありませんが、全角グリフにカーニングを禁止、となると、それらの方々の考え方を否定することになってしまうかと思います。 > > > > 具体的な細かい実装方法の話を少し離れて、目指す場所を考えた時に、 > > 「全角送りの場合、すべての文字が全角送りになり、カーニングはするべきではない」 > > 「全角送りの場合でも、特定の文字間は詰めたい」 > > の両方の考え方が存在するのであれば、両方の考え方を許容できる方が、いずれかの考え方を否定・却下するよりも好ましいと感じていますが、いかがでしょうか? > > > > On Mon, Nov 21, 2022 at 8:31 PM Taro Yamamoto <tyamamot@adobe.com> wrote: > > 石井さん、 > > > > コメントありがとうございます。 > > > > その次に続く「つまり、’kern’を、プロポーショナルな字幅を持たず、まだスペーシングの最適化が何らなされていない2 > つのグリフに対して適用することは、無意味」の文が、私の頭の中でつなぐことができませんでした。 > > *プロポーショナルなグリフに対してカーニングを設定したい > > ということと > > *全角幅のグリフに対してカーニングを設定したい > > > は私にとっては独立事象に思えました。原稿用紙レイアウトならいざしらず、現代的な全角幅のレイアウトにおいて、「す。」にカーニングを設定したいとフォントデザイナーさんがおっしゃられているのは、妥当に思えますが、「つまり」とおっしゃっているので、太郎さんの中では何かこのメールでは語られていない関連がこの > 2つの中にあると思うのですが、そこをご教示いただけますか? > > > > まず、通常の全角正方形の等幅のボディの中で漢字や仮名などのグリフが設計されているフォントでは、約物や欧文を除く漢字や仮名のグリフは、全角正方形の中でデザインされている状態が、基本の状態と考えられ、それをベタで組むことが、やはりもっとも基本的な組み方と考えられます。ですから、そのようなもっとも基本的なグリフの横に、句読点が配置されたからといって、句読点もまたベタで組むことが、やはり基本的な組み方であることに変わりはありません。たとえ、「す」の後に「。」が来た場合に、視覚的に詰めた方が好ましいと感じられたとしても、その「詰めた方が視覚的に好ましい」ということによって、漢字や仮名を等幅全角、ベタ組で組むことの基本的な優位性が失われることはありません。そのため、「詰めた方が視覚的に好ましい」と感じたからといって、即座に全角正方形を基本とする文字の構成とベタ組みが基本であるということを取り崩して、「す」と「。」との間を視覚的・感覚的なスペーシングの目的で詰めてしまって良いということにはなりません(少なくとも、ベタ組みが有効であるという認識が変わらない場合においては) > > > フォントの中で「す」と「。」のカーニングを有効にすると、すべての「す」と「。」の組み合わせのインスタンスにおいてカーニングが動作しますが、「詰めた方が視覚的に好ましい」と感じることを理由にしてカーニングを有効にするのであれば、当然、特に他の仮名文字間の視覚的なスペーシングの不均等もまた、「詰めた方が視覚的に好ましい」と感じるはずです(そう感じない人がゼロではないかもしれませんが、感じてもおかしくないと考えるのが自然でしょう)。しかし、等幅全角でデザインされたグリフのスペーシングの視覚的な不均等というものは、「す」と「。」または「し」と「か」または「ア」と「メ」のような、個別グリフのペア(組み合わせ)の間で生じる不均等をも生み出しているわけですが、その不均等は、プロポーショナルの場合と異なり、グリフごとに固有の字幅を与えられていないことによって、 > *グリフの前後のスペーシングが、どのような文字と組み合わせた場合でも、ある程度は不可避的に不均等になることを余儀なくされている* > ことによって助長された結果なのです。 > > > > > そして、まさにこのことが、全角文字にペアカーニングを設定することが非効率になる理由なのです。この、グリフがプロポーショナルでなく、それぞれのグリフに固有の字幅とサイドベアリングが与えられていないという問題を飛び越えて、一挙に個別のグリフの組み合わせごとのスペーシングの不均等を「カーニング」によって解決しようとするのは、非合理であり、その結果、それが非効率を生むわけです。 > > その本源的な、一次的なスペーシングの不均等は、プロポーショナルの字幅とサイドベアリングをそれぞれのグリフに設定することで可能になります。 > > > > > ペアカーニングは、プロポーショナルのグリフによっても改善されない個別のグリフの組み合わせを補正するために用いられます。その意味では「す」と「。」の場合を含め「し」と「か」または「ア」と「メ」のような、個別グリフのペアを「詰めた方が視覚的に好ましい」と感じた結果、実際にペアカーニングを有効にすることは、等幅全角とベタ組のモードから離脱することを意味しています。そして、視覚的なスペーシングの観点からプロポーショナルグリフを用いることがもっとも有効であるモード、日本語の組版においては「ツメ組」のモードに移行することを意味します。そこではたとえ仮にあるグリフが全角正方形だったとしても、それは、偶然、そのグリフの字幅が全角の文字サイズに等しいようなプロポーショナルグリフと考えた方が自然といえるでしょう。 > > また、’palt’はあくまで、alternateな字幅+サイドベアリングを設定するものであることは重要です。日本語のテキストは、’palt’がOFF > の状態で組むことがデフォルトで可能になっていなければなりません。’palt’がONに指定された場合にはじめて’palt’ > が有効になる必要があります。通常、本文組版はベタで組むことが原則です。他方、商業印刷物や見出し、広告や一部の雑誌記事などでは「ツメ組」=’palt’ > が有効な場合が多くあります。この意味でも、’palt’がONでなければ、’kern’が動作しないことは日本語フォントにおいては合理的と考えられます。 > > 以上、うまく説明できなかったかもしれませんが、20年以上前に考えたことを思い出しながら説明を試みた次第。 > > 山本太郎 > >
Received on Monday, 5 December 2022 04:33:25 UTC