search

jcitpc / CJKFont

0 stars 0 forks source link

VORG .vs. vmtx #4

Open murata2makoto opened 11 months ago

murata2makoto commented 11 months ago

Behdadに聞かれたことをそのまま書きます。縦書きのときの英数字の垂直方向の位置調整を、VORGじゃなくてvmtxを使わないのはなぜと聞いています。まあ、既存のフォントを直すのは無理でVORGを使い続けるしかないのでしょうが、質問に答えられるのなら答えておきたいと思います。

Behdad asked me why we don't use vmtx rather than VORG for adjusting vertical positions of alpha-numeric characters. I suppose that nobody wants to modify existing fonts, but I would like to provide an answer to his question.

I wonder though, why can't they achieve the same effect (adjusted vertical position) by adjusting the top-side-bearing in the vmtx table, which is the mechanism designed for this.

kidayasuo commented 11 months ago

確か、CFF には [vh]mtx が基準とできるような原点の定義がないためこれが使えない？ちょっと不正確だと思いますが、そんな風なことを聞きました。 @macnmm @taroyamamoto-451

murata2makoto commented 11 months ago

TrueTypeでもVORGが欲しいという意見をCITPCの中で聞いた覚えがあります。ますますvmtxとの関係は？

kidayasuo commented 11 months ago

とはいえ、今回の提案は、新しいことをしようとするわけではなく、現在の実装の反映ですので、それは考えなくて良いかと

hatchzo commented 11 months ago

この件に関しては、以前Teamsの部会のところで藤さんがシェアしてくれたサンプルがとてもわかりやすいと思うのですが。

murata2makoto commented 11 months ago

@hatchzo

中内さんのサンプルですね。何をしたいかは分かりますが、メカニズムまでは私には残念ながら分かりません。グリフのy座標位置を決めるには、VORGの値だけを見ればいいんでしょうか。それとも、top sidebearingやbounding box まで考えないといけないんでしょうか？

kidayasuo commented 11 months ago

VORGで直すべきは、CFFに対しては必須、というただ一点という理解だったのですが、本当にそれだけが実装と仕様の食い違いなのか、調べる必要がありますね。

murata2makoto commented 11 months ago

@hatchzo

それと、vmtxだけでもあのサンプルと同じことが可能なのかどうかも私には残念ながらよく分かりません。

murata2makoto commented 11 months ago

VORGは行頭のときにも、空けるべきスペースを要求しているんでしょうか？それとも行頭だと無視される？また、行内で中央揃えをすることを考えます。そのときVORGの要求するスペースを考慮して中央揃えをするのか、無視して中央揃えをするのか。

murata2makoto commented 11 months ago

以前、Teamsで山本さん、服部さん、藤さんが書いてくれた説明を読み返しています。分かりが悪くてすみません（まだ、よく分かりません）。

takaakifuji commented 11 months ago

vmtx-and-vorg-20230922.pdf

仕様の記述の議論とは別に、現状の vmtx/VORG の用途や仕組みを説明する資料に、あまり良いものがない気がしたので、ペライチの資料を作ってみました。フォントを作る立場なので、理解が甘い部分があるかもしれず、内容に間違いがあればすみません。

murata2makoto commented 11 months ago

@takaakifuji

有難うございます！ hmtxのところをウンウン唸りながら読んで、それからvmtxへ行こうとしていました。

確認ですが、(2) NO VMTX/VORG OVERRIDEのところにあるtopSideBearingは、実際にフォントをラスタライズして上部空白の高さでしょうか？そして、yMaxは、ascender からtopSideBearingを引いたものでしょうか？よろしくお願いします。

takaakifuji commented 11 months ago

@murata2makoto ありがとうございます。言葉足らずな部分があり、すみません。

不明瞭な点があれば、補足させていただきます。

murata2makoto commented 11 months ago

@takaakifuji

hhea,hmtxから勉強しなおしてます。分かりが悪くて苦労しています。

全角欧文のようなグリフを縦に並べるときはベースラインを基準とするのではなく、グリフの上端と下端の真ん中の線を基準にする。この線がちょうど中心（ideographic em-boxの中心？）になるように持ち上げるのだと理解しました。

takaakifuji commented 11 months ago

@murata2makoto

ありがとうございます。私も同様の認識です。和文フォントでは、縦組で調和が取れるように、おおむね仮想ボディの中央に揃うような位置をグリフごとに設計して提供しています。その位置情報の格納場所と格納方法として、技術的な経緯から vmtx/VORG の 2 つが存在している、ということになるかと思います。

murata2makoto commented 10 months ago

この件を忘れたわけではなく、調べているんですが未だに苦労しています。

IPA明朝だと、

ｂ(U+FF42)に対するグリフはglyphID: 186で、glyfテーブルを見ると、 xMin,yMin,xMax,yMax: 231, 36, 742, 773 となっています。

htmx [00186] 1000, 231 vmtx [00186] 1000, 107

を見ると、lsbがxMaxと等しく、tsb+yMax = 880 (これはsTypoAscenderの値）です。

他の三つのグリフに対しても同じことが成り立っています。

これはNO VMTX/VORG OVERRIDEのシナリオだと理解しました。実際に、WordでIPA明朝を使ってこのあたりの文字を縦組みしてみると字の空き方がみっともない。ｙの上なんて大きく空いています。

murata2makoto commented 10 months ago

SourceHanSerifJP-Mediumだと

ｂ(U+FF42)のグリフの一番上は、(352, 816) sTypoAscenderは880なので64がem box上端からの距離のはずです。 vmtx [15360] 1000, 83 ここで83になっているのがvmtx overrideだということで合ってますか？ VORG 15360 | ｂ (U+FF42) | 899

ｆ(U+FF46)のグリフの一番上は、(717, 839) sTypoAscenderは880なので41がem box上端からの距離のはずです。 vmtx [15364] 1000, 81 VORG 15364 | ｆ (U+FF46) | 920

ｊ(U+FF4A)のグリフの一番上は、(579, 818) sTypoAscenderは880なので62がem box上端からの距離のはずです。 vmtx [15368] 1000, -46 VORG 15368 | ｊ (U+FF4A) | 772

ｙ(U+FF59)のグリフの一番上は、(?, 532) sTypoAscenderは880なので268がem box上端からの距離のはずです。 vmtx [15383] 1000, 97 ここは思いっきりずれているのは、yの上部がスカスカだからでしょうね。 VORG 15383 | ｙ (U+FF59) | 629

murata2makoto commented 10 months ago

結局、hmtxとvmtxはまったく違うものなのでしょうか？文字を単純に横に並べるとき、hmtxで指定されているlsbは、グリフから生成されたビットマップを繋げていくときに一切使わないはずです。advance widthずつずらしていくだけです。ところが、文字を単純に縦に並べるとき、vmtxで指定されているtsbは、ビットマップを繋げていくときに使わないといけないはずです。そうでないとvmtx overrideは機能しません。この理解で合ってますか？