作業メモとか考えた事とか (2004年6月)
さざなみフォント
リリースしました。
今日の日付が間違ってました。
既知のバグは書体関連 Wiki のページにまとめてあります。
さざなみフォント・補足
昨日は疲れていて寝てしまったのだが、補足説明が必要だと思うので述べてみたい。
過去
私にとっては 2003 年 6 月 15 日がエポックなのだが、世間の多くの人にとっては、古川泰之さんが東風フォントの公開停止を宣言された 6 月 19 日が記憶に残るところだろう。この日までには新たな開発結果を公表したいと思っていた。公開してすぐにいろいろな不具合が見つかるような不完全な状態ではあったが、中間結果発表として見ていただければ (できるなら見続けていただければ) と思う。
現在
昨日公開したばかりで、ずいぶんいろいろな問題点が明らかになっている。かなりの部分は単純ミスだし、未作成のデータに起因する部分もある。まずそれを直すのが先決。
それから、文字定義の整理。内田明さんからいろいろ指摘と提案を頂戴している。「ヰの字メモ」では、「牙」とその類形に関する整理をされている。すっきりとして分かりやすい呼び方だと思う。以前、罫線素片の┌・┬・└を使って区別する案を温めていたのだが、なにぶん読みにくいという欠点があった。どうせなら「むにょうもどき」という言い方も廃止して (「もどき」というのはどこが違うのか曖昧である)、「つのむにょう」とでも呼んだらどうだろうか。
ただ、ファイルの定義だけでなくスケルトンも一緒に作らないとフォントが作れない。スケルトンエディタはまだ移植していない。私の手元で動いているのは、中身も分からずにとりあえず動かせるようにしただけの代物なので、作業効率が悪すぎる。
これが優先順位は最も高い作業なのだが、その方針が未定である。オリジナル版を Common Lisp に移植するか (速度、GUI のプラットフォーム依存性の問題)、FontForge を改造するか (難しそう)、その他の既存のツールで使えそうな物を探してくるか。何か良さそうな案があればぜひ教えていただきたい。
未来
基本的に、文字品質の向上は CLWFK (和田研フォントキットの Common Lisp 移植版) を改善しないと不可能である。いろいろやりたい事はある。現在のところ、これだけある。意味不明かもしれないが、ここは私の作業メモを置く場所でもあるのでお許し願いたい。
1. アルゴリズムの頑健化
1.1. general-section1 (limit.l) で nil が返ってくる問題の対策
nil が返って来ないように、微妙な値の時に判定を誤る複雑な幾何学的アルゴリズムの使用を避ける (本筋)
nil が返って来た場合は誤判定とみなし、orsection しない (対症療法的)
1.2. 重複除去アルゴリズムの頑健化
無限ループに入らないように、アウトラインの交差点が 1 箇所だった場合は無視
肉づけ段階で、ループや点の飛び出しなどの異常な値が出てこないようにする
1.3. 異常なアウトラインを作成しない肉づけアルゴリズム
一般に、点の飛び出しが出てくるアルゴリズムを避ける。
幅が太い肉づけの場合は、スケルトンを直線に近くする変形を強制的に施す (美的観点からも有益)
位相を保持するアルゴリズムの採用 (Elastic Net Algorithm の利用とか) も考えられる
2. 肉づけアルゴリズムの改良
2.1. 太さ (明朝ではウロコの大きさ) のバリエーション
各エレメントが (width . 10.0) のような パラメータを持てるようにする
位置関係によって異なる太さパラメータを付与できる太さ判定アルゴリズム
(平行する線の間隔が込み入っている所だけ細くするとか、国がまえの内側は細くしておくとか)
2.2. ストロークの太さに合わせたスケルトンの変形 (とくに太ゴシックで重要)
卑近な例: hidari や ten のカーブは、Heavy ではきつくできない。
複雑な処理(ふところを小さくするとか)は、それ自体スケルトン生成時に独立した処理として必要
2.3. 例示ストロークへのフィッティングを用いたアルゴリズム
(誰でもカスタマイズできるようにしたい)
複数の例示ストロークから1個乃至複数個の、最も近いストロークを検出して補間・補外
2.4. 新たな具体的肉づけサンプル (明朝・ゴシック)
3. 組合せ自動計算処理の改良
3.1. limitrule の追加
general-section の頑健化が必要。
速度低下の原因となるので、不要な点をペア演算の対象から外すような前処理を導入したい。
3.2. 太さベースの limit 指定
現在は、limit は xunit, yunit で行っている。
[xy]unit は、部分字体の複雑さを平行な[縦横]線の並びで近似したもの。
「部品と部品がくっつかない」という制約条件は、「字体の複雑さに応じてすき間を空けなければならない」
という条件よりも、部品間のスペーシングを定義する上では重要な役割を果たすと思う (特に太さのある場合は) が、それを表現するパラメータが無い。
各ストロークの幅 w1, w2 を導入したい。問題は、組合せのバランス演算を 2 回行わなければならないこと。
最終的に、特定の部品ペアが文字全体の中でどれだけの大きさを占めるかが分からないと、w1, w2 が
xunit, yunit でいくつになるかが確定できないため (もちろん幅そのものも周辺の込み入り具合に影響を受ける)。
今まで前提としてきた素朴な再帰性が崩れて関数的な綺麗な世界ではなくなるため、いろいろ複雑化しなければならない予感。
3.3. ヒントを与えられる演算子の追加
xscale/yscale に加えて、raise/lower のような演算子を加えたい。
3.4. 部品の固有の大きさ計算の改良
論文では、線の長さの比を取るアルゴリズムに比べ、線の本数への換算がよい結果をもたらしていた。
どう改良すればいいか、まだ具体案は無い。
計算だけではなく、かまえなどに変形柔軟性を与える方法についても検討したい。(例えば、「広」と「廬」の「广」バランス差とか)
4. ビットマップからの学習
去年10月で止まっている
その他、学習的インターフェイスをいろいろ (Kage 式のバランス学習とか)
5. データ構造の改良
後の演算のために、上端のエレメントのリスト・左端のエレメントのリストなどを作ってキャッシュする。
組合せを評価した時にプリミティブの組合せに還元するのではなく、組合せ構造との対応づけを保持。
ユーティリティの作成
統計機能
ある部品が組合せ定義に使用されている回数を数える。
ある部分式が組合せ定義に使用されている回数を数える。
smoke sample の作成を簡単にするフレームワーク
先週のシンポジウム
上の小見出しを「過去・現在・未来」としたのは、先週水曜に一日休みを取って聞きに行った、花園大学国際禅学研究所漢字処理研究室の主催したシンポジウム「文字情報処理のフロンティア: 過去・現在・未来」から使わせてもらったもの。
一言で言うと、じつに面白かった。メモを取ったら原稿用紙 120 枚ほどになったが、それでもまだまだ内容の濃さを捉えきれていない。これについては後日、時間があったら、当たり障りの無いようにごくごく薄めた概要をご紹介しようと思う。江渡さんがまとめを公開して下さっているので、あまり付け加える事は無いのだが。
実を言うと、村田真さんの感想のとおり、懇親会ではそこかしこで面白そうな話をしていて、本編に輪をかけて刺激的だった。酒が入っているから記録どころか記憶にも残っていないのが残念だが。伊藤希さんに、ヴィトゲンシュタインをちゃんと読みなさいとお叱りを受けたことを覚えているぞ。引用する者は殆どが自分勝手に曲解しているのだとか。
なぜ疲れるのかなあ
年のせいか、夜行の高速バスで行って高速バスで帰ってくるという日程をこなすと辛い。その後、週末に続けて「文字の文字・平野甲賀と字游工房展」と天理ギャラリー展「近世の文化と活字本 きりしたん版・伏見版・嵯峨本…」に足を運んだかもしれない。これら三つとも入場無料だというのが信じられない。
ご案内の葉書をお送りくださった方々にお礼申し上げます。
あと、忙しさにかまけてここで紹介できずにすみません。遅ればせながらこれからのを書いておくと、これとこれは個人的には見逃せない。
こういう単発のイベントがどうというより、全体の忙しさが慢性的疲労の蓄積には大きそうである。今にして思えば、去年の第 3 四半期がここ 5 年間で特異的に時間に余裕のある時期だったのはなんという好運だったろうか。
解答
2ch Linux 板の「フォントを何とかしてくれ!」スレッドでいろいろ質問・感想が出ているので。
829 名前： login:Penguin [sage] 投稿日： 04/06/19 15:17 ID:rMDGQ+u/
>>828
ずいぶんきれいに寄せ集めましたな。
あとはWindowsユーザーのために「界」と「広」をもうすこし見栄えよく(w
「きれいに寄せ集め」る作業自体は、CVS で公開している kochi-substitute の作成スクリプトでは、昨年の 11 月頃には既にできていました。それが出来るのも、FontForge の自動処理が充実しているから。
「界」と「広」のデザイン改良について。
「界」「広」を単一のスケルトンとしてしまえばバランスを改良することは容易です。だけど、1 文字 1 文字作るのは時間の無駄なのでそういう事をする気はありません。それなら直接フォントエディタで作ったほうが思い通りの物が作れますから。
最終的には 100% 機械生成ではなく、よく使う範囲の文字は人間が手で調整する必要があるとは思いますが、自動処理の品質がある程度のところまで行かないと手間がかかってしょうがないので。
830 名前： login:Penguin 投稿日： 04/06/19 16:36 ID:SJbQ7STk
>>828
プロポーショナルは無いの?
今のところありませんが、ソースとして使っている Oradano 明朝からフォントエディタでコピー&ペーストすれば簡単に作れます。FontForge が TrueType Collection を吐けるようになれば、プロポーショナル版を 1 個のフォントファイルに同時に格納できるのですが、今のところ別フォントを作るしか無いので。要望が多ければプロポーショナル版もリリースすることを考えます。
831 名前： login:Penguin [sage] 投稿日： 04/06/19 17:16 ID:Ojl/frYN
>>828
12dotはM+じゃないのか…
ｶﾞｯｸｼ
明朝・ゴシックの両方が揃っているという理由で東雲ビットマップファミリーを使用しています。M+ に置き換えてビルドすれば M+ 版を作ることは難しくないはずです。香り屋さんで配布している M+ の TTF 版もあることですし。
835 名前： login:Penguin [sage] 投稿日： 04/06/19 18:27 ID:hBPlVOmh
さざなみが漣じゃないのはモロに2004JIS問題の影響を受けるからですか?
838 名前： login:Penguin [sage] 投稿日： 04/06/20 01:04 ID:TG61zA4Z
>>835
初期案では漢字だったみたいね。
いつの間にひらがなになったんだろ。
839 名前： login:Penguin [sage] 投稿日： 04/06/20 01:07 ID:q7QqP4K/
『さざ波通信』：日本共産党と現代日本政治を考える
http://www.linkclub.or.jp/~sazan-tu/
840 名前： login:Penguin [sage] 投稿日： 04/06/20 01:26 ID:gy+Kt8MK
分派主義者トロツキスト狩野を査問せよ！！
841 名前： login:Penguin [sage] 投稿日： 04/06/20 02:50 ID:RWG0WCGm
>>838
単に「難しい」漢字だったからでは。
この場合はさざなみを漢字一字で書いても自己満足にしかならん(w
漢字であることになにか物凄い意味があるならともかく。
基本的に >>841 さんの推測どおりです。「漣」「小波」「さざ波」「さざなみ」程度が有り得るわけですが、「漣」は読めない人がいるだろうと思ったのと、将来的に Unicode で互換分離される日が来ないとも限らないのでやめました。「小波」は確実に誤読されて「厭な事」になりそうなので却下却下却下。「さざ波」は 1 文字しか短くならないし交ぜ書きカコワルイので却下。消去法で「さざなみ」になりました。
分派と言われても、ほぼ一人プロジェクトの状態なので実感無し。まずは協力者が欲しいです。フォントを生成するスクリプト周りを人に任せて、できるだけ和田研フォントキットの改造に労力を注ぎたいので。
833 名前： login:Penguin 投稿日： 04/06/19 17:33 ID:hcBGH92p
フォントは、あるひとつの名前のフォントセットに関しては、
それに含まれている文字の形や描き方に関して統一性が取れて
いないといけないという制約があるために、何万字という字が
あるので、大勢で手分けしてそれぞれ何十個、何百個作るのを
分担するということが出来難い・出来ない。
もしもそうでなければ、どこかにWEBのページでも開いておいて、
字形を募集して、自分に適当に割り当てられた文字を１字ずつ
マウスでクリックして・タブレットペンで描いて、送信をする
ということをボランティアの大勢で行えば、出来てしまうかも
しれないのだが、そういうわけにはいかないだろう。
新聞の紙面を超拡大コピーして、それの活字をスキャンして、
輪郭を抽出し、数式にモデル化して自動的にアウトラインフォント
を作成する、ということも新聞社から訴えられるかもしれない。
しかし、５０年以上前の、新聞紙や書籍から拾った字形を元に
上記のスキャニング・モデリング作業を行った場合には、かりに
フォントに著作権があったとしても、公表後５０年を過ぎているから
著作権の営利に関する権利部分 は切れていると思われる。
やってみれば分かりますが、スキャナで取り込んで自動アウトライン化しただけでは使い物にならないのです。想像力で補わなければならない要素がたくさんあり、普通に部品を並べて新しく書体を作るより手間がかかります。古い書体の復刻でこそ、その人の書体に対する解釈が厳しく問われるし、技倆がバレる物だと思います。
世間の話題
人名漢字の追加案とか Adobe-Japan1-6 とか Office for Mac の新 MS フォントとか、世間でいろいろあった動きについて書きたい事はある、作業に戻るので今日は書けないと思う。
さざなみ更新
sazanami-20040621 を作成。
OpenOffice.org で縦書きのグリフ置換が行われないのは原因不明。気づいた問題点は直したが、どうやら直っていないようである。
どなたか OOo の内部構造に詳しい方、縦書きグリフが認識されるための前提を教えていただければ幸いです。
ダメもとで調べてみた
大量のソースではあるが見つかることを願って、oo_1.1.1_src の下で、GSUB が含まれるファイルを「find . | xargs grep -i GSUB」として調べてみた。無関係な物も若干ヒットするが、
vcl/inc/sallayout.hxx
vcl/source/glyphs/gcach_layout.cxx
vcl/source/glyphs/gcach_ftyp.cxx
vcl/util/defs/wntmsci8
vcl/source/gdi/winlayout.cxx
psprint/source/fontsubset/gsub.cxx
あたりは Glyph SUBstitution の意味で使っているようだ。
grep 結果をもう一度見ると、vcl/source/glyphs/gca_ftyp.cxx の FreetypeServerFont:ApplyGsub() が、処理の核心のようである。GSUB (初心者向けの解説: 縦書き表示の時には、横書き用と形が異なる文字は差し替えてやらなければならないが、「横書き文字の番号→縦書き文字の番号」の対応がこのテーブルの中に入っている。) に関しては、こいつが自前でパースしている模様。
FreeType の機能を使って GSUB テーブルをまるごと読み込んだ後は、ひたすら GSUB テーブルのバイナリにアクセスしてデータを切り分けている。成功時には、maGlyphSubstitution フィールドが参照する配列に GID の対応を書き込むようである。ざっと見たところ、これだと GSUB テーブルに vert ではなく vrt2 を使っているコードでは動かないような気がする。だとすると今回の修正は全く見当違いな事をしていたわけか。
ソースを目で追いかけるよりデバッグコードを挿入してダンプ出力した方が話が良さそう。1.1.2 が出た直後でタイミングが悪いが、とりあえずコンパイルしてみることにする (ports が無ければここで挫折していたところ)。
芦ヶ原伸之さん逝去
詰将棋メモより。トリトのトップにも出ている。やっぱり本当なんだな。昔 2 回ほどお目にかかったことがあるが、最近はパズルに掛ける時間が無く (とくに昨年は意図的に解かないようにしていた)、読者としても縁遠くなっていた。先日京都駅の三省堂で久しぶりに買ったパズル通信ニコリに昔と全く代わり無く連載を続けているのを見て安心した矢先のことで非常に残念である。
最初に知ったのは読冊日記だが、私もこの、Quark の連載をまとめた「究極のパズル」にハマった口である。パズルそのものもさることながら、そのジョークのセンスは、今まで読んだ行儀の良いパズル本とは全く別物だった (ご本人に比べれば大した事はなかったのだが…)。この本とニコリに出会っていなければ、今の自分はちょっと違う人生を送る、ちょっと違った人間になっていたに違いない。
Hiki の脆弱性
かずひこさんがなんとなく忙しそうな感じだなと思ったら、これだったのか。セキュリティホールってのは、修正して発表するまでの閉塞感が辛いということは、体験して初めて分かる事柄である。
きゅうりの開発裏話とか
そのソフトウェアは『かんな』なのだが、その時も含めて本当に何もしていない。開発者に名を連ねておきながら情けないとは思うが、あと 2, 3 年くらいの間は日本語入力関連の開発にかける時間は取れないだろうと思う。将来またやる気になるかも分からないし。
そういうわけで、きゅうり配列のページをちょっとアップデートして、以前話した内容のテキストファイルを加工しないまま出してしまうことにする。きれいに編集するのは諦めた。図が出て来たらアップロードするつもり。
保留
昨日公開した sazanami-20040621 だが、縦書きが出来なくなってしまったので保留にした。原因は sfd ファイルを手でいじった時にまずい事をしたか、~/.PfaEdit/prefs の CoverageFormatsAllowed を 2 に変更したか、vrt2 が TrueType では認識されないかのどれかだと思う。
昨日みたいに昼休みにコンパイルだけしてアップロードすると初歩的なバグが出てきそうなので、今度はきちんとテスト時間を取る予定。早くても今夜、遅ければ明日公開。OOo 関係の対処はまたこの後ということで。
確認結果
Windows に OpenType Font Shell Extension をインストールして眺めてみた。他にも変わっているところがある。まずは、vrt2 は本当に仕様にあるように vert の上位互換なのか。試してみよう。
フォントのバイナリいじりの時のいつもの手順だ。
まず モナーフォントのビルドツールである ttftinkerに含まれている ttfunpack でテーブル単位にほぐす。次に、sed で文字列置換して固め直す。最後に ttfpack で固め直して出来上がり。
FreeBSD でのコマンドラインはこんな感じ。
% ttfunpack sazanami-20040618/sazanami-mincho.ttf min
% cd min
% ls
EBDT GDEF OS_s2 gasp head hmtx maxp post
EBLC GSUB cmap glyf hhea loca name ttfdir
% mv GSUB GSUB.orig; vis GSUB.orig | sed s/vert/vrt2/ | unvis > GSUB
% ttfpack `cat ttfdir` > sznm-min-vrt2.ttf
これで縦書きグリフが出ないフォントができあがった。今度は、バイナリを直接(!) sed で置換。
% sed s/vrt2/vert/ sznm-min-vrt2.ttf > sznm-min-vert.ttf
ヘッダにあるフォントのチェックサムが壊れるが、まあインストールはできる (この点に関しては、テスト結果とは異なるが、ちゃんとアウトラインを含んだフォントと、ビットマップのみの疑似 TTF とでは違うのも当然だろう)。フォント「@さざなみ明朝」の縦書きグリフが復活しているのを確認 (charmapx を使用した)。
上記の手順の中で、GSUB テーブルに 'vert' の文字は 1 箇所にしか現れていないことを付記しておく。縦書き用のメトリクス (vhea, vmtx テーブル) が存在しないのが原因かと思い、FontForge に生成させてみたが、やはり動かなかった。
結論: 互換性について
拡張子 .ttf の TrueType アウトラインをもつ OpenType フォント (つまり、TrueType フォント) では、vrt2 フィーチャは vert フィーチャの上位互換ではなく、Windows では認識されない (Uniscribe API を使ったアプリケーションならどうか知らないが、ここでは旧来の、@ つきフォント名でアクセスする方法のみを問題にしている)。逆に、拡張子は .otf であるところの CFF (Compact Font Format) アウトラインをもつ OpenType フォント (Microsoft 以外の一般人が「OpenType」と呼ぶときには専らこちらの狭義の用法である。日本語フォントの場合は暗黙に Adobe-Japan1 のグリフセットに従ってアウトラインが並んでいると仮定されている) の場合には、vrt2 テーブルのみが認識され、vert テーブルは無効である。
OpenType (広義) のラスタライザは TrueType と OpenType (狭義) で別々になっているが、単にアウトラインの生成だけでなく、メトリックの計算やレイアウトタグの解釈なども別になっている。Microsoft はこれらどちらも OpenType だというが、実際にはこれらは二つの異なるフォントフォーマットなのである。たまたまデータ構造の多くの部分を同じくしているが、機能上の制限や過去の互換性のための制限は差があると思った方がいい。TrueType のラスタライザはさすがに枯れているが、OpenType (狭義) のラスタライザの方はまだ齢ところがあり、CFF テーブルが壊れていると、クリックした途端に OS が落ちたりする。
困ったものである。規格には書かれていない妙な制限だの微妙に事実と違う説明だのがあったり、同じ情報が複数の箇所に格納されていてどちらが参照されるかがプラットホーム毎に異なったり、引用元の規格と異なる解釈をしたり (Panose の OS/2 テーブルでの使われ方とか)、ベンダごとに同じフィールドの扱いが異なるとか。仕様も公開されていない昔に比べれば、各ベンダが検証用のツールを出すなど、だいぶましになったが、それでも未だにちゃんと動くフォントの作成は黒魔術 (black art)の域にあると言わざるを得ない。せめて「バッドノウハウ」という言葉で呼べるようになってほしいものである。
ベンダ毎に同じフィールドに著しく違う値を入れている例としては、sTypoLineGap の値の実際の解釈が MS と Adobe で異なることが挙げられる。仕様書の文面は同じだが、小塚明朝では em の 7〜10% どころか、1000 (つまり 100%) を指定している。理想的な行間は全角であると推奨しているつもりのかもしれないが、実際のソフトの動きを見てやってほしいものである。MS 明朝はこのフィールドは 0 である。つまり、アキを入れなければ文字の上下はぴったりくっつく。普通のアプリケーションでは sTypoLineGap で指定された行間を詰めることができないから、1 行おきに表示されたような不恰好な画面になってしまう。
OO.o コンパイル中
中途半端に ports 以外からバイナリの XFFree86 を入れたりして portupgrade が破綻していたので、/usr/local, /usr/X11R6 を全て空にしてから使用中の全 port を再コンパイル。せっかくだから、X は Xorg にしてみる。うーん、X 入れるのに Perl5.6.1 が必要な時代なのか。
明け方に寝苦しくて目が醒めて、パッチを当てたファイルでコンパイルエラーが発生しているのを見ると凹む。せめてもの救いは、8 箇所のエラーのうち 1 個はコンパイラのせいだったことだ (g++ 3.2.3 は、-fno-for-scope オプションが意図したとおりに動かないようだ)
文法エラー
ついでに、HTML ファイルの文法エラーも直す。基本的には不注意が原因。裏でコンパイルしていてキーの反応が悪いのや湿度でキーボードがチャタりぎみだったりするののも間接的原因だったりするが、いつもそうなわけではない。
タグ名 <ins> を間違えて覚えていた恥ずかしいエラー (18 日にご指摘をいただいていた) を今頃になってやっと直す。先月・先々月と直してから検索をかけてみたらあるわあるわ。あとは一括置換で直した。昔のファイルで今日のタイムスタンプになっているものは、'.bak' つきのファイルがバックアップとして同じディレクトリに転がっているはず (これはわざと残しておくことにする)。
ついでに、先月分のファイルにほんのちょっと追記。
さらに、一昨日公開したつもりで read permission がなかったテキストファイルを修正。(以下、24 日追記) (幻の「きゅうり」配列改良案も、定義ファイルが出て来たので公開)。
考えてみれば、<a href="..."> で http:// を忘れるのは手打ちの時、http://http:// としてしまうのはコピペした時なのだと思う。前者は、コピペがデフォルトになって手が馴染んだ時、後者は、手打ちがデフォルトになって「http://」 まで打鍵してその後 URL を http:// つきでコピペしてしまった時に起きる。当然前者の失敗は、そらで書ける URL でしか起こらない。
<span class="annot"> … を </a> で終えている所が何度もあった。どうしてこういう勘違いをしているのか全くもって不明。
OO.o データ採取完了
FreeBSD 上の OpenOffice.org 1.1.1 で縦書きの内部処理を探ってみた。HTML もエディタで打っているローテク人間であるから、当然 printf デバッグである (とはいえ __LINE__ マクロを思い出さなかったのは情けない)。作業手順は以下の通り。
- oo_1.1.1_src/vcl/source/glyphs/gcach_ftyp.cxx に fprintf を埋め込むパッチを当て、コンパイルする。
- swriter 上で、縦書きで「ー」 1 文字のみを含むファイルを明朝・ゴシックのそれぞれに対して作成する。
- /usr/local/OpenOffice.org1.1.1/share/registry/data/org/openoffice/VCL.xcu で、「Kochi Mincho」「Kochi Gothic」とある項目に「Sazanami Mincho」「Sazanami Gothic」をそれぞれ追加する。
- 東風フォント代替フォントをインストールして xset fp+ /usr/X11R6/lib/X11/fonts/TrueType/ する。
- script を起動し、「openoffice-1.1-swriter vert-min.sxw」でファイルを開いたらすぐ終了する。typescript をリネーム。
- また script を起動し、今度は vert-goth.sxw を開いて typescript を取る。
- 東風代替を pkg_delete して、さざなみを pkg_add する。xset fp rehash
- 同様に script で明朝のデバッグ出力・ゴシックのデバッグ出力を記録する。
東風フォント代替フォントの方では
(略)
subst: 14747 -> 15362
subst: 14748 -> 15363
subst: 14750 -> 15364
のように縦書きから横書きへの対応がメモリに読み込まれるのに、さざなみでは
2042: nCntLookupTable == 2
2047: nOffset == 6
2049: number of nLookupIdx in LookupIndexList == 1
2047: nOffset == 14
2049: number of nLookupIdx in LookupIndexList == 0
2058: nOfsLookupTable == 6
2061: eLookupType == 4
2063: eLookupFlag == 0
2065: nCntLookupSubtable == 1
2069: eLookupType == 4
の形で終ってしまう。
OTF Shell Extension での確認結果
sazanami-gothic.ttf (20040618 版) の OpenType Features
[-] OpenType Layout Tables
[-] DFLT
| [-] Default Language System
| └ Fractions (frac) feature
[-] Kana [Hiragana & Katakana] (kana) Script
[-] Default Language System
| └ Vertical Writing (vert) Feature
[-] Japanese (JAN) Language System
└ Vertical Writing (vert) Feature
sazanami-mincho.ttf (20040618 版) の OpenType Features
[-] OpenType Layout Tables
[-] Kana [Hiragana & Katakana] (kana) Script
| [-] Default Language System
| | └ Vertical Writing (vert) Feature
| [-] Japanese (JAN) Language System
| └ Vertical Writing (vert) Feature
[-] Latin Script
[-] Default Language System
└ Standard Ligatures (liga) Feature
対処
コードを追ってはいないのだが、multiple substitution のフィーチャ (例えば f + f + i → ffi 合字 (liga フィーチャ) とか、1 + / + 2 = ½ (frac フィーチャ) の ようなもの) が含まれている GSUB テーブルを、現在の FontForge は正しく扱えないようである。
これらの機能タグはわざと追加したのではなく、文字を新規定義した時に FontForge が気を利かせて勝手に入れているだけである。必要無いので削ることにした。SFD ファイルに書き出されているものは「Ligature: 」行を削り、実行時に新規に定義される文字はスクリプトに削除処理を追加して対処した。
そうは言っても、必要があって vert 以外のレイアウト機能を GSUB テーブルに定義しているフォントはあるはずだ。そういうフォントが正しく扱えないのは問題である。いつかは修正しなくてはなるまい。OpenOffice.org 内部構造に詳しい方にやっていただければ助かるのだが。私は興味はあってもしばらくは手を出せない。UnOfficial OpenOffice Hackers's guideやワープロコンポーネントの解説 (縦書きの説明)を読んだはいいが、いざソースを見るとフォント名をデバッグ出力する方法すら分からなかった始末 (XubString ってどこで定義されているんだ?)。
古い Windows ではもっと制限が厳しいことを思い出した。これでちゃんとバイナリが出てるのか、後で確認をしなければと思う。ベンダーにとっては「OpenType」というのは、「歴史的事情による制限を気にしないで済む」という利点もあるのだろう。
© は Ⓒ か ⓒ か
突然話は変わるが、恒例となった感のある「Unicode の文字を考える」シリーズ。
〜, … に続いて今日は、© である。
COPYRIGHT SIGN が「丸に大文字 C 」であるのか「丸に小文字 c」であるのか疑問を持った。その代用表記が (C) であるのか (c) であるのかも。どこで教わったのか忘れたが、子どもの頃に呼んで知った知識によるとあれは小文字だったはずである。東風フォント CID 化キットを作った時は何も疑問を持たず「○」と「ｃ」を重ねて © を作っていた。
小文字説の根拠
ぐぐってみると、Universal Copyright Convention (万国著作権条約) の条文が出てくる。
ARTICLE III
1. Any Contracting State which, under its domestic law, requires
as a condition of copyright, compliance with formalities such as
deposit, registration, notice notarial certificates, payment of fees or
manufacture or publication in that Contracting State, shall regard
these requirements as satisfied with respect to all works protected in
accordance with this Convention and first published outside its
territory and the author of which is not one of its nationals, if from the
time of the first publication all the copies of the work published with
the authority of the author or other copyright proprietor bear the
symbol of a lower case "c" inside of a circle accompanied by the name of
the copyright proprietor and the year of first publication placed in
such manner and location as to give reasonable notice of claim of
copyright.
(強調は引用者)
プレーンテキストを <pre> で囲っただけのページだが、アメリカ国務省の InfoUSA に置かれている公式情報である。About InfoUSAにはこう書かれている。
INFORMATION USA is an authoritative resource for foreign audiences seeking information about official U.S. policies, American society, culture, and political processes.
原典
だが、これはあくまでアメリカの解釈にすぎないようである。
UNESCO (著作権のトップページの画像はどう見ても「丸に大文字 C」である) に置かれている Official Text では、
ARTICLE III
1. Any Contracting State which, under its domestic law,requires as a condition of
copyright, compliance with formalities such as deposit, registration, notice,
notarial certificates, payment of fees or manufacture or publication in that
Contracting State, shall regard these requirements as satisfied with respect to all
works protected in accordance with this Convention and first published
outside its territory and the author of which is not one of its nationals, if from the
time of the first publication all the copies of the work published with the
authority of the author or other copyright proprietor bear the symbol ©
accompanied by the name of the copyright proprietor and the year of first publication
placed in such manner and location as to give reasonable notice of claim of
copyright.
(強調は引用者。InfoUSA 版との相違部分を示した。)
となっている。
スペイン語版のページからは 条約原文をスキャンした PDF が置かれていて、スペイン語・フランス語・英語の原文が読める。当該部分を拡大してみた。
余談だが、この 3 ファイルが、ここで初めて公開する gif 画像である。50×50 の白黒画像だと png よりも 50 バイトほど小さくなるようだ。
考えてみれば、当時はまだ © の活字が無かったのだから手書きなのは当然だ。せめて、「 c 」と印刷しておいて、丸だけを手書きにしてくれていたらなあと思うがまあ仕方がない。この手書きの文字だけを材料に「どう見ても小文字だ」と断言する勇気は私には無い。「丸 R や丸 P が大文字なのだから、丸 C だって大文字に決まっているじゃないか」という意見のほうが、ずっと説得力があるように感じる。
実装
実情を見ると、主だった欧文フォントは皆「丸に大文字」の形を採用しているようである。必ずしもフォントの英字とは同じデザインではなく、別の英字書体から C を持ってくることもあるが、常に外側にセリフの突き出た C の形 (小文字が突き出しているのは Courier くらいか?)。明らかに小文字の形をしているフォントなんて、MS-Windows や MS-Office に入っているフォントでは Batang くらいのものではないか。あ、あと Parchment もそうだ (w
Oradano のデザインはやはり適切である。それにしても、内田さんの論考に比べるとずいぶんしょぼいネタばかり書いているものだ。
期待外れ
「Unicode の文字」と題しつつ、今回は Unicode のデータが全く役に立たなかった (Latin Extended-A なんてフォント実装上の注意がこまごまあってすごく親切なのに)。© だけが大文字と小文字の見分けのつきにくい書体で「C」を書いているのはわざとだろうか。© は U+24B8 (Ⓒ) と U+24D2 (ⓒ) に、® (REGISTERED SIGN)は U+24C7 (Ⓡ) に相互参照の「→」をつけるべきだと思うのだが、なぜだか © と U+2117 (℗, SOUND RECORDING COPYRIGHT) が参照し合っている (だったら ® と ™ だって参照し合ってほしいものだが)。正規化の話でもそうだったが、「ISO 8859-1 の文字は特別扱い」という態度が透けて見える。
バグ修正
CLWFK のバグを一つ修正した。自分が去年作り込んだバグなのだが。
「資」の字の 4 画目の hidari に微小な自己交差を持つ曲線が存在した (SFD) ため、重複除去処理でデータが壊れてしまっていた。(defoutline gothic hidari ..) で曲線を定義した時はこの交差は存在しなかったが、skeleton2list の最後で change-tail を行なった変形の結果生じたものである。
ループを構成する原因となったベジェ曲線のセグメントは、両端点から出るハンドルが、曲線の外側方向に向けて突き出ている。もともとは 2 本のハンドル p0->p1, p3->p2 は内側に小さく突き出ていたものであるが、change-bezier が p3 を大きく p0 方向に移動した結果、p1, p2 の移動量が追いつかなかったようである。
change-bezier は、あるベジェ曲線が与えられていて、片方の端点を新しい位置に移動した時に、新しい 2 点の間を結ぶ曲線を (元の曲線とできるだけ似せて) 作成する処理である。端点は確定しているので、中間の制御点を求めればよい。
現在のデフォルトの処理方法で使用しているヒューリスティクスはうまく近似できない場合がある (例えばベジェ曲線の大きさに比べ端点の移動量が大きい場合) が、この時の彌縫策として昨年新たに追加した方法は、元のベジェ曲線を固定された端点を中心に回転・拡縮して重ね合わせて新たな曲線を求める方法であり、デフォルトの方法に比べて曲線のずれが大きくなることはあるが、論理的破綻が起こりにくい。
予備の方法に切り換えるための判定条件を追加した。今までは曲線を延長しすぎていた場合 (t >= 2.0) のみだったが、曲線の処理の結果、性質のよい曲線が性質の悪い (自己交差などを起こす危険がある) 曲線に変化した場合を検出し、予備の方法で置き換えるようにした。
点 p0, p3 を結ぶ線分を延長した直線と、p0, p3 でその直線に垂直に交差する直線でキの字形に平面を分割し、p1, p2 が異なる分割領域に移動したら曲線の性質が変化したものと見なす。現在は、p0-p3 を跨いだかどうかのチェックはしていない。その他に、四角形 p0,p1,p2,p3 が凸かどうかのチェックも考えられるが、現在は調べていない。
この予備の処理 rotscale の内部と、処理を呼び出す関数の両方で引数の順序を間違えているバグが存在した (狩野が作り込んだバグ)。そのため大きな誤差のある結果が出力されていた。昨年のパッチでいくつかの問題が解決していたのは偶然にすぎない。
今回の修正は対症療法にすぎず、本質的な重複除去ルーチンの問題点を回避する物ではない。逆に、今回の修正により、新たに重複除去処理で問題が生じるようになった文字が存在する (ゴシック「鰲」でスタックオーバーフロー)。思いがけない自己交差が含んでいるような数値的に微妙な入力が与えられても正しく処理できるようにすることが今後の課題である。
そういうわけで来週に新バージョンは持ち越されます。
昨日のセミナー
素晴らしかった。言い尽くせないくらいいろいろあるが、何よりも、岡澤さんによる文字制作の実演を見られたのが嬉しかった。縦画の打ち込みはループさせるのか。(上の SFD ファイル の Z のところを見ていただければ分かると思う)
さざなみフォント制作中
今日中に出す予定。深夜にコンパイル開始、明け方にエラーが出てたのを修正して作ったバージョンは、Ayu の外字 (13 区の丸数字とか) が縦書き文字のところに送られてしまっているので、リリースできなかった。
正しい位置に再エンコードするのが不可能なので (BDF の文字名が数字で始まっていると保存時に '$' を頭につけてくるのだが、もう一度開いて文字名 '$13-01' に Goto しようとするとできない)、BDF のソースからすっぱり切り落とすしかなさそう。
何度もタグを打っては動かしているが、夜にまた動かします。すみません。
CLWFK: スタックオーバーフローの修正
今回は見送ることにした。計算結果の座標点を書き出して読み込むだけでエラーが発生しなくなる。
今回の現象は、2 個の閉じたパスがごくわずかな重なり合いしかもっていないため、線分の交差判定が誤差で間違って、1 個しか交点が検出されないために起こっている。2 個の重なり合った輪郭線を融合する時には、片方の交点から初めてもう片方の交点が出てくるまでループをたどり続ける (outline.lのtracecont) ので、1 個しか無ければ無限ループになってスタックが溢れるという単純な話である。データ構造さえ理解すれば簡単に修正できるとは思うが、今回は急いでいるので全ての座標点を丸めて逃げることにする (最終的には全部整数に丸めるわけだし)。
先日杉原厚吉「計算幾何工学」(培風館) を買ったので、ちゃんとやろうかと思ったのだが、実装はかなり難しいことだけはよく分かった。
FontForge の重複除去ルーチンもきちんと動くようにしたい…と言いつつどれだけ経ったことか。『「ノウハウ」自体が「ナリッジ」の中の劣等分子』とは良く言った物で、こういうノウハウを不要にするようなナリッジがこの世に存在することを知るとなおさら、何とかしたい気持ちは強くなる。
SZNM-20040629 出来
sf.jp に置きました。
OpenOffice.org で縦書きができるようにするとともに、細かい修正をいろいろ。
