KANOU Hiroki
kanou****@khdd*****
2005年 5月 22日 (日) 21:58:34 JST
狩野です。
伊藤さん、ご指摘たいへんありがとうございます。文字のバランスに
ついてはまだ本格的に手をつけていないので、こういうご指摘は
助かります。
> 字が汚いのにはいくつかの原因があります。大まかに、
> (1) プリミティブの形が悪い。
> （個人的には 刀、力、乙など）
「乙」は「Z」みたいになってしまっているので、kokoro と部品を分けて、
左下に丸みをつけたエレメントを作る所からやりたいですね。他にも、
ten の長いものは別エレメントにして、 3 個の点で定義するとかを
考えています。
刀、力については、tsukurihane の撥ねが美しくないことと、ゴシック体
の場合には右上の角が削られること (ほぼ直角の場合は普通に繋げたほうが
美しい) が原因としてあると思います。それを直してからでないと、いくら
スケルトンの位置だけいじってもうまくいかないと思います。
> (2) 組合せのバランスが悪い。
> （辺、脅、頌、災、臀、宅 など）
これも、原因はいろいろあると思います。
a. 組合せ方向の大きさバランス (上下構造なら縦の、左右構造なら横の大きさ比)
→ 頌、脅、宅、臀
b. 組合せ方向に垂直な大きさバランス
→ 宅 (うかんむりが大きい)、災
c. かまえと内側部品のバランス
→ 辺
a. の場合、大きさ算出で何かを見落としている可能性が高いです。簡単に
言って、yoko の場合縦画の本数を、tate の場合横画の本数を数えて幅を算出
しています。「公」は斜めの線から構成されているので、幅が過小に評価
されているのではないかと推測しています。(この場合は、実質的に、「公」に
含まれる hidari, migi, ten は 縦画に相当すると思います)。それをうまく
検出する処理を追加し、計算のパラメータを調整するとだいぶマシになるの
ではないかと期待しています。
一方、組合せに垂直方向の大きさ調整はまだあまり考えられていないのでは
ないかと思います。例えば「うかんむり」は文字幅一杯に伸ばしてしまうと
恰好悪いのですが、下につく字形が複雑になってきた場合には (縦に縮める
だけではなく) 横に伸ばす必要があります (右上と左上が空いているように
見えるので)。また、単独でなく縦長の文脈で用いる場合 (「腕」とか)は、
ほぼ幅いっぱいになります。このような知識を系統的に与えるにはかなり
時間がかかるものと予想しています。
> (2)については、jointdata の中で xscale とか yscale を使って変更するのが
> よいのか、レンダリングのアルゴリズムを直すのがよいのかよくわかりません。
> jointdata を直す方が簡単ですが美しくないような気もします。例えば、
xscale や yscale を試してみて、ダメならプリミティブ扱いにしてしまう
のがいいと思います。もちろんアルゴリズムの改良も別口で進めるつもり
上で述べましたように問題が複雑なのでいつになるのか分かりません。
> (setq 脅 '(tate 三力 たて月))
> を
> (setq 脅 '(tate (yscale 0.5 三力) (xscale 0.9 たて月)))
> とすると少しいい感じになりますが、これを全部についてやるのかなあ…
> と思っています。レンダリングに使うヒューリスティックに手を入れて
> なんとかなる問題なのかどうかよくわかりませんが。
また、部品に xunit, yunit の値を指定してやれば、ヒューリスティック
部分を手動処理で置き換えたことになります。xunit, yunit は、簡単に
言えば「隣り合う縦画/横画の間隔」で、yoko, tate の処理の時には、
各部品の xunit, yunit が均等になるように大きさの相対比を求めます。
> (4) その他
> (4) で気がついたのは、部品のカーニング（というのかな）の度合いが
> 定義できたらいいのになあ、ということです。例えば、「全」という字は
>
> (setq 全 '(tate ひとかしら 王))
>
> ですが、「ひとかしら」と「王」がくっつき過ぎている感じがします。
> バランスについては
>
> (setq 全 '(tate ひとかしら (yscale 1.5 王)))
>
> ぐらいでいい感じなのですが、部品を離すことができません。
もう一つの問題として、「全」に含まれる「王」は、普通のフォントでは
単独字の「王」と異なり、いちばん上の横線が最も短いということです。
今のところ、組合せ処理でこういう変形を施してやることは考えられて
いませんが、「ひとかしら」形は頻度が高いので、ある程度自動的に
「最も上の横画」を認識してそこだけ縮める処理を施せればなあと思って
います。部品 1 個 1 個ごとに hook で変形を指定してやらなくても
いいようにしたいと思っています。
> 「欲」はもっと深刻です。「欲」の左の「谷へん」は
>
> (setq 谷へん '(tate はのじ ひとかしらへん 口))
>
> ですが、「はのじ」と「ひとかしらへん」と「口」が近すぎます。
> これはそれぞれのプリミティブの大きさを変えても全然解決しません。それぞれ
> の部品の距離をもっと離すことができればいいのに、と思いました。
> （これも、アルゴリズムを変えた方がいいのか、字形記述になんらかの要素を
> 追加して人手で調整した方がいいのかはよくわかりません）
ここまで複雑なものになると、組合せで定義すること自体に無理があると
思います。「はのじ」「ひとかしらへん」の 4 本の斜めの画と、「口」の
上の横画が形作る 5 個の空き領域の大きさバランスが見栄えを決めるわけですが、
斜めのバランスを自動的に整えるアルゴリズムを記述するのはたいへん困難です。
それよりも、プリミティブとして作り込んでやったほうが話が早いでしょう。
例えば、「谷」の「はのじ」は、下に「ひとかしら」が来るわけですから
中間のすき間をある程度大きく取らなければなりません。アフィン変換で
これをやろうとすると、副作用として点が横長になってしまいます。
プリミティブを増やすこと自体は全然難しい作業ではないので、いつに
なったらできるか分からないアルゴリズムの改良より先にやってしまうのが
いいでしょう。
狩野 宏樹 <kanou****@khdd*****>