Open kidayasuo opened 3 years ago
以下に、15:54 p.m., 7/20, 2021付の山本太郎(アドビ)から木田さんとJLREQへのメールの内容を転記します。
• 回転といえば、一般的にプロポーショナルグリフ、例えば英字や記号、を正立で使うと必ずしも重心が真ん中に来るとは限らないように思えます。UAX#50 には EAW=N を正立させる例が多数ありますが、これはどうなんでしょうね?(調査?)
これはNatの方が詳しいとは思いますが、私の考えでは、通常UAX #50でRとされる例えば、プロポーショナルの欧文グリフ(例えばAとかgとか)を回転させない場合には、日本語の縦組みの行においては、そのグリフの字幅の中心を縦組みの日本語の(通常の真ん中揃えの、全角中心を垂直に貫通する)ベースラインに一致させて全角ボディ内で水平方向の中心に配置する必要があると思います。垂直方向は、通常の全角ボディ(Ideographic EM Box)内のそのフォントの欧文ベースライン位置(またはアプリケーションが調整して日本語の行内に設定する横組み時の欧文のベースライン位置)に揃うことになります。そうしないと、縦中横との整合がとれなくなり、また、不必要に縦組み行中に全角・半角以外の字幅の要素を混入してしまうことになると思います。
追記 若干補足ですが、比較的新しい日本語フォントでは、プロポーショナル欧文グリフのデザインを損ねないように、ascenderやdescenderが全角ボディよりもはみ出ている場合があります*。その場合、それを先に述べた方法で縦組中で正立させると、アプリケーションの欧文グリフの配置方法にも依存しますが、多くの場合、グリフのascender/descender部分が縦組み行中の前後のグリフと重なる可能性があります。しかし、これはプロポーショナル欧文グリフを縦組み中で正立させることが必然的に負っている欠点であり、現状では、普通はこのような用法に対するスペーシング上の補償はフォント側ではしていないと思います。
ただし、記号として用いる全角欧文グリフの場合には、フォントによっては(おそらく)OpenTypeのVORGテーブルの情報を用いて、縦組でのグリフの位置を調整してこの問題を回避している場合があります。また、GPOSの’vpal’フィーチャーを使って疑似的なプロポーショナルメトリクス(いわゆる和文でのツメ組)が利用可能な場合には、それを明示的に指定した場合には、縦組みの欧文グリフも縦方向のプロポーショナルメトリクスをもつことが可能なので、それによってこの問題を回避している場合がありますが、これは通常の本文組での全角ベタ組にはあてはまりません。
山本 アドビ *―― ということは、古い日本語フォントに含まれている欧文グリフでは、ascenderやdescenderが全角ボディから、アクセント類を除けば、はみ出さない場合があるということを意味しますが、これは戦後、光学式の手動写植機が普及し始めた比較的初期またはそれ以前にデザインされた書体をデジタルフォントに移植した場合、文字盤からの光束が通過する「写口」部分に全角正方形の開口部をもつマスクが取り付けられていたために、全角からはみ出るとそのマスクに遮断されてグリフのイメージが欠けてしまうため、和文書体に附属する欧文グリフのdescenderを無理やり短くしたデザインにしたことに起因します。ただし、イタリック体のWやfなどの場合など前後方向にはみ出る場合には、イタリック専用写口を用いたりすることが行われました。その後、一部の手動写植機では、写口を廃止する改良がなされ(さらに以後のデジタルフォントを含め)、その技術的制約は意味がなくなりました。しかし、写植書体をデジタルフォントに移植する場合に、かならずしもすべてのフォントで、欧文グリフのdescenderを本来の形に戻して美しくする改良が行われたわけではありません。そのため、そのような欧文グリフのデザインが現在のデジタルフォントに継承されている場合があります。
The vertical positioning @Garamond8 described assumes each character occupying equal "ideographic em box" height. Can it be vertically proportional?
When applications position glyphs in vertical text, it is important that glyphs are properly positioned in the fullwidth box. We should describe recommended method. It would be a candidate content of the new, digital native version of JLReq (#281).