Alternative Views》 2002年7月6日初出、2005年12月4日SVG修正

パーツ引き2000JIS漢字字典が欲しいのだけれど

内田明 <uchida@happy.email.ne.jp>

活字の制作とパーツ引き字書

例えば「日」と「月」から「明」という字が成り立つなど、数万種存在すると言われる漢字の多くは、偏・旁・冠・脚などのパーツの組合せによって生み出されたものです。パーツの組合わさり方が、会意、形声などに分類されると国語または日本語の授業で習った記憶をお持ちの方も多いことでしょう。

印刷と活字の歴史を扱った本によると、金属活字による印刷術を産業化しようという試みの早い段階で、「半角の日」活字と「半角の月」活字の組合せで「全角の明」を印刷するようなシステム――分合活字――が作られていたそうです。こうした活字を用いれば、思いのほか少ない“半角活字”で、多くの“全角漢字”を表現できます。

もっとも、バランスよくデザインされた文字を眺めると同じ「日偏」と言っても例えば「明」と「晰」では1文字中に占める位置とサイズがずいぶん違っていますから、偏・旁などパーツの大きさが一定とならざるを得ない金属製の分合活字は廃れています。

この“パーツの合成によって漢字字形データを得る”という方法は、金属活字においては廃れましたが、 藤原博文さんの「漢楽街」や和田研漢字分科会による和田研フォントなどの例からは、大規模漢字集合のデジタル活字制作現場において非常に有効に働くように思われます。

実際、Watanabe明朝の拡張作業で私は、同じ種類のパーツをコピーペーストして複数の文字で使いまわしたり、少し変形して流用したりということを、よく行ないました。また、外字の作成などを行なう場合、多くの方が、目的の字に見合うバランスの偏・旁を既存の文字から探し出してきて合成する――といった作業をしていることと思います。

既存の字体データに備わっているパーツのデータを流用して新しい字体のデータを作成しようとする場合――例えば JIS X 0213:2000 の第3水準漢字《人偏に乞》のデータを作る際――、「乾」「吃」「屹」「訖」など JIS X 0208-1997 にある“旁が乞の字”を探すことが出来る漢字字典が利用できると、非常に便利です。部首や総画数だけではなくパーツを鍵にして漢字を探せる字書はパソコン漢字字典として出回っており、私は、主に荒川幸式『ワープロ・パソコン漢字辞典』(日本能率協会マネジメントセンター)を利用しました。

この“旁が乞の字”は、JIS X 0213:2000 では、第3水準漢字《人偏に乞》の他に、《歯偏に乞》が第4水準漢字に含まれています。“旁が乞の字”であれば JIS X 0208-1997 のレパートリに含まれていますから、0208対応のパーツ引きJIS漢字字典で手がかりを得ることができます。けれども、第3・第4水準漢字でのみ出現するパーツといったものについては、“0213対応”の“パーツ引き字書”があるのとないのとでは作業効率に違いが出ます。

また、共通パーツの使いまわしをしないとしても、同じデザイン要素のパーツを修正しようと考えた際に必要な字体を一覧する手がかりになるなど、デジタル活字の制作者にとって、“パーツ引き字書”は強力なツールになります。例えば、書体デザイナーの佐藤豊さんは、モリサワ『たて組ヨコ組み』第51号のインタビューで、パーツ引き字書に相当する独自のデータベースを制作されたことを明かされています。

おそらく、JIS X 0213:2000 のフリーフォント制作を試みているすべての方が、パーツ引き字書を熱望していることでしょう。ひょっとすると、独自のデータベースを既に運用なさっている方がいらっしゃるかもしれません。

XML(SVG)で字形データとパーツ引き字書データベースを同時に作る

ウェブでベクトル画像を扱う規格としてW3C勧告となっているSVGは、ウェブ用にアレンジされたPostScript言語といった仕様になっています。Adobe Illustrator などPostScript系のドローツールで描いた字形データをSVGフォーマットでファイルに保存すると、次のようなデータが得られます。

<?xml version="1.0" standalone="yes"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg viewBox="0 0 128 128"
xmlns="http://www.w3.org/2000/svg">
<desc>
JIS X 0213:2000 1-14-08</desc>
<path fill="black" d="M32,8 L46,14 L46,16 L42,18 S26,55 10,72 L8,70 S 32,24 32,8 Z" />
<path fill="black" d="M26,44 L36,46 L36,48 L34,50 L34,118 L26,120 C25,118 25,112 26,102 C26,96 26,82 26,44 Z" />
<path fill="black" d="M66,8 L78,16 L78,18 L74,18 S56,54 50,52 L48,50 S60,34 66,8 Z" />
<path fill="black" d="M64,30 L98,30 L106,22 L116,32 L114,34 L64,34 Z" />
<path fill="black" d="M50,56 L84,56 L92,50 L100,58 L100,60 L94,62 C72,78 58,94 58,104 C58,110 66,110 84,110 C100,110 112,108 113,106 C115,104 114,96 114,88 L116,90 C116,99 116,104 118,106 C120,108 120,110 119,112 C118,114 102,119 86,119 C56,119 50,114 50,104 50,96 56,82 82,60 L52,60 Z" />
</svg>

実は上記は《人偏に乞》の字形データとなるよう方眼紙を睨みながらテキストエデイタで生成したSVGドキュメントなのですが、AdobeによるプラグインなどのSVGビュアを用いると次のようにレンダリングされます。

SVG画像非対応環境では画像が表示されません《人乞》のPNG画像
sjis8706.svgsjis8706.png

SVGフォーマットの画像は、文字通り“スケール可能なベクトル画像”ですから、外字画像として貼りつける際に拡大縮小が可能であるという利点があります。更に《人偏のアウトラインを1つのグループにし、乞も1つのグループにする。乞は更に乙のグループを含む》といった具合に構造化していくことで、字書データベース化を図れる可能性があります(下記ソースのg要素とそのclass属性に注目)。

<?xml version="1.0" standalone="yes"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg viewBox="0 0 128 128"
xmlns="http://www.w3.org/2000/svg">
<desc>
JIS X 0213:2000 1-14-08</desc>
<g class="ucs4ebb">
<path fill="black" d="M32,8 L46,14 L46,16 L42,18 S26,55 10,72 L8,70 S 32,24 32,8 Z" />
<path fill="black" d="M26,44 L36,46 L36,48 L34,50 L34,118 L26,120 C25,118 25,112 26,102 C26,96 26,82 26,44 Z" />
</g>
<g class="ucs4e5e">
<path fill="black" d="M66,8 L78,16 L78,18 L74,18 S56,54 50,52 L48,50 S60,34 66,8 Z" />
<path fill="black" d="M64,30 L98,30 L106,22 L116,32 L114,34 L64,34 Z" />
<g class="ucs4e59">
<path fill="black" d="M50,56 L84,56 L92,50 L100,58 L100,60 L94,62 C72,78 58,94 58,104 C58,110 66,110 84,110 C100,110 112,108 113,106 C115,104 114,96 114,88 L116,90 C116,99 116,104 118,106 C120,108 120,110 119,112 C118,114 102,119 86,119 C56,119 50,114 50,104 50,96 56,82 82,60 L52,60 Z" />
</g>
</g>
</svg>

SVGで記録した字形データは、単なる外字画像として活用するだけではなく、そのアウトラインデータを利用してSVGフォントを生成することも可能です。SVGフォントには、Type3フォント同様ヒント情報を持てないとかビットマップフォントデータの埋め込みができないなどの不便な点もありますが、実態がテキストファイルですからフォント開発の途中でCVSを利用しやすいといった利点や、オープンソース系のツールだけで作業が出来るという利点もあります。

残念ながら私には、拡張ワタナベワダケン明朝フォントの全グリフをSVGフォーマットに書き替える体力(あるいは変換ツールを作る能力)も、それをXMLデータベース化する能力もありませんし、また、そうした力を身につけようという気力にも欠けています。けれども、それが非常に便利であることは、よく判っています。どなたか、《パーツ引き2000JIS漢字字典ウェブ》づくりにチャレンジしてくださらないものでしょうか。