KANOU Hiroki
kanou****@khdd*****
2003年 11月 21日 (金) 22:09:10 JST
狩野です。 まだ PfaEdit の話で申し訳ありませんが、xAvgCharWidth() を どうするべきかについて、ちょっと調べてみました。 Apple の TrueType Reference Manual http://developer.apple.com/fonts/TTRefMan/RM06/Chap6OS2.html より: ) The xAvgCharWidth parameter specifies the arithmetic average of ) the advance width of all of the 26 lowercase letters of the Latin ) alphabet and the space character. If any of the 26 lowercase ) letters are not present, this parameter should equal zero. とあり、 ・小文字 26 文字と空白の幅の算術平均 ・小文字 26 文字のどれかが存在しなければ、0。 と明確に定義されています。 ところが、次の段落の中には、 ) The weighting factors provided in Table 44 below are only valid for ) Latin lowercase letters. If other character sets, or capital letters ) are used, different frequency of use values should be substituted. とあり、「大文字や、他の文字集合を用いる時は、別の頻度表を用いよ」と 注記しています。明らかに前の段落と矛盾していますね。 Microsoft/Adobe の、OpenType Specification Version 1.4 http://www.microsoft.com/typography/otspec/os2.htm#acw http://partners.adobe.com/asn/tech/type/opentype/os2.jsp#acw では、 ) Description: The Average Character Width parameter specifies the ) arithmetic average of the escapement (width) of all ) non-zero width glyphs in the font. ) Comments: The value for xAvgCharWidth is calculated by obtaining ) the arithmetic average of the width of all non-zero ) width glyphs in the font. Furthermore, it is strongly ) recommended that implementers do not rely on this value ) for computing layout for lines of text. Especially, for ) cases where complex scripts are used. となっています。 ・非ゼロの文字幅を持つ全ての文字の送り幅の算術平均 ・アプリケーションは、テキスト行の長さの計算にこの値を用いるべきではない。 (とくに、複雑な用字系 [訳註:ペルシャ文字、インド系文字など] においては) ということで、明らかに定義が異なります。 古い規格 (TrueType 1.0) まで戻ると、 http://www.microsoft.com/typography/tt/ttf_spec/ttch02.doc?fname=%20&fsize= ) Description: The Average Character Width parameter specifies the ) arithmetic average of the escapement (width) of all ) of the 26 lowercase letters a through z of the Latin ) alphabet and the space character. If any of the 26 ) lowercase letters are not present, this parameter ) should equal the weighted average of all glyphs in ) the font. For non-UGL (platform 3, encoding 0) fonts, ) use the unweighted average. ということで、 ・重みつきの小文字・空白の送り幅の平均 ・小文字のどれかが無い時には単純平均を用いる ・Symbol エンコーディングのフォントでは単純平均を用いる という事だったようです。 あまり意味の無い値だったので単純な定義に置き換えられたのでしょう。 現在の PfaEdit の処理は、 http://cvs.sourceforge.net/viewcvs.py/pfaedit/pfaedit/pfaedit/tottf.c によると、tottf.c:1.166 で修正された物のようです。 その処理は、 ・デフォルトとして 500 を設定する ・幅が 0 でない文字が 1 文字でもあるならその単純平均で置き換える というものです。 古いバージョンは、 ・空白と小文字の計 27 文字が全て存在するならその単純平均で置き換える ・それ以外なら幅が 0 でない文字 (あれば) の幅の平均で置き換える ・それ以外なら初期値のまま (おそらく 0) という物でした。 どちらも微妙に仕様書と違うんですけど、どちらかと言えば、古いバージョン の処理で妥当だったと思います (500 という幅には根拠が無い。せめて em の 半分とかにするべき)。commit コメントには「MS Font Validator の警告に 対応」と書かれてますけど、どういうことなんでしょうね? 個人的意見ですが、小文字だけの平均を取るように変更するなら、重み つきの平均にした方がいいように思います。また、フラグ alwaysgenapple の値を見て処理を切替える方が望ましいでしょう。 もう一度、[Mplus-fonts-dev 77] でいまづさんが報告された >・kochi-gothic.ttfにmplusのepsをインポートしたところ、 > フォントのスペーシングがおかしくなった件 > > 1.PfaEditでkochi-gothicにmplusのepsをインポートしTTFを作成。 > 2.TTFをメモ帳@WindowsXPで確認してみたところ日本語のスペーシングがおかしい > (一文字分の余計な空白が入る、Konqueror@RedHat9では問題なし。 > 比較条件が異なるのがなんですが・・・。) > 3.元のkochi-gothicと比較した結果、OS2テーブルのxAvgCharWidthの値が異なる。 > (kochi=512, mplus=900) という現象が、本当に xAvgCharWidth が原因なのか確かめたほうがいいの では無いでしょうか。 狩野 宏樹 <kanou****@khdd*****>