「Unicodeの基礎知識と異体字について」に行ってきた
IVS技術促進協議会のセミナー「Unicodeの基礎知識と異体字について」があったので、ちょっと聴きに行ってみた。
Unicodeの基礎知識と異体字について
主催：IVS技術促進協議会 後援：日本電子出版協会、電子出版制作・流通協議会
内容
（１）Unicodeに関わる用語や基礎知識、IVSについてご説明します。
講師：Unicode Consortium Director 小林 龍生 氏
（２）外字・異体字に関するプロジェクト等についてご説明します。
講師：凸版印刷株式会社 情報コミュニケーション事業本部 田原 恭二 氏、総合研究所 秋元 良仁 氏 セミナー情報｜IVS技術促進協議会
以下、ざっとレポート。スライドのPDFとあわせてどうぞ。
(1) IVS時代の文字コード入門
charater glyph model
最初に character（「文字」）と glyph（「抽象字形」）の関係（charater glyph model）について、ISO/IEC TR 15285 というTRでの定義をもとに簡単な説明があった。
character は文字というよりも、ただのビット列と考えた方が往々にして意味が摑みやすいとのこと。glyph については、抽象的な字形（デザイン差は吸収される）を指す場合と具体的な字形（実際に表示・印刷される形）を指す場合とがあるが、このTRをはじめ、文字コードに関する精しい議論などでは前者の意味で使われている。この定義を採る場合、具体字形は glyph image と呼ばれる。イメージとしてはこんな感じだろうか。
抽象← character > glyph > glyph image →具体
一方、フォント技術関係では具体字形を glyph と呼ぶ場合も多いので注意。このブログでは、こちらの用法の方が多い。
日本の文字コードと漢字政策
次に日本の文字コードや漢字政策の変遷について、要点を搔い摘んでの説明があった。このあたりはよく知られている通り。改定常用漢字表と同日付で「改定常用漢字表に対するJIS漢字コード規格の対応状況について」が公表されたように、近年は文字コード規格と国語施策の連係がとれるようになってきた。
Windows Vista では JIS X 0213 の改正への対応が話題になったが（JIS2004問題）、マイクロソフトとしては「常に最新の規格に合わせるという方針」を採っているとのこと。
外字・異体字・IVS/IVD
その後は外字・異体字のさまざまな例が紹介された。かの有名なカナダ漢字の話もちょろっと。肝心のIVS/IVDの解説が時間不足でざっくり省略されてしまったのは残念。
なお、今回の内容は以下の論文の中でだいたい述べられている。
- 小林龍生「区別することの必要性を明確化することの必要性ということについて」『じんもんこん2011論文集』pp. 347–352
(2) 「字形共通基盤」プロトタイプによる実証実験のご紹介
字形共通基盤の概要
最初に、字形共通基盤はどういったものなのか、何を目的としたプロジェクトなのかといったことについて説明があった。現在の出版界では、外字・異体字については各社それぞれが独自のワークフローで処理をしている。それらのグリフを整理・収集して共通インフラ（字形共通基盤）を構築すれば、外字・異体字への対応コストが軽減され、データの互換性も高まるのではないか、というアイデア。ちなみに、行政向けの「文字情報基盤」とは（名前が紛らわしいが）無関係。
既存の多グリフ環境としては文字鏡・GT明朝・グリフウィキなどいろいろなものがあるが、これらは学術向けのものが多い。そのため、そのままでは出版用途には向いていないと判断された。そこで、文字情報基盤ではそれらの成果を取り入れつつも、独自のインフラを整備することになる。
仕組みとしては、各グリフにはgi番号（例：gi001125 [＝亜]）という背番号を割り当て、これで管理することになる。これに対して、代表的な明朝体での glyph image、各種文字コードや内部コード、読み・部首・画数、異体字関係など、さまざまな情報が紐づけられている。
課題としては、収録基準の制定や運用組織・運用ルールの整備などがあるようだ。
なお、今年の3月に「平成22年度 コンテンツ配信型・ハイブリッドビジネスモデル実証事業（デジタル・ネットワーク社会における出版物の利活用推進のための外字・異体字利用環境整備調査）」という報告書（PDF）が出ている。
プロトタイプの動作デモ
概要の説明の後に、デモとして実際にプロトタイプでの実演があった。
字形検索では web ブラウザがクライアントとなり、読み・画数・部首・部品・文字コードなどをキーとした検索ができるようになっている。検索結果の詳細画面では、上に挙げたようなさまざまな属性が表示される。
入力方法としては、字形共通基盤との通信機能が実装された、専用のATOKが用意されている。また同様に字形共通基盤と通信できるテキストエディタも用意されており、これらを使うことで実際の字形を見ながらの入力・編集ができるようになっている。字形共通基盤のグリフを入力した箇所は interlinear annotation を利用して表現されるようになっている。
雑感
IVS技術促進協議会のセミナーだったのでIVSについての話が中心になるのかと思ったら、そうでもなかった。でもその分、字形共通基盤の詳しい話を聴けたので満足。特に、実際にプロトタイプが動いているのを見ることができ、なかなかおもしろかった。自分は出版業界の中の人というわけでもないのでこれがどの程度活用されていくのかはよくわからないが、とりあえずあれば（個人的に）便利なことは確か。
あとひとつ、質疑応答の場面などで小林さんがちょっとぶっちゃけ話的なことをおっしゃっていたが、ああいうのは聞いていておもしろいと思った。「あー、この人はこういう風に考えてるんだ」とか「やっぱそうですよねー」というような感じで、規格票からでは読み取れないことがいろいろと見えてきて興味深いな、と。
AFDKO入門《CIDキー方式のOpenTypeフォントの作り方》 後篇：makeotf
2011-12-22: Ken Lunde さんから features, CMap についての補足情報をいただきましたので（ありがとうございます）、それについて追記しました。
前篇では、mergeFonts を利用して2つの素材フォントから merged.raw というファイルを生成しました。
この後篇では makeotf というツールを使い、OpenType の各種テーブルを設定して merged.raw を完全な OpenType フォントに仕上げます。
makeotf
以下では makeotf の使い方を、例を交えて見ていきます。makeotf の使用方法の詳細については、FDK\Technical Documentation\MakeOTFUserGuide.pdf で解説されていますので*1、併せてご覧ください。
とりあえず使ってみる
makeotf では各種テーブルのパラメータを細かく設定することができますが、ここではまず試しに、ごく単純な例で実行してみましょう。
makeotf を実行する際に必ず準備しなければならないファイルは、入力するフォントと features ファイル（後述）の2つだけです。入力フォントには前篇で作成した merged.raw を、features ファイルには下の features_min を使用します*2。
makeotf コマンドの基本的な書式は以下のようになっています。
makeotf -f [入力フォント] -ff [featuresファイル] -o [出力フォント]
そこで、コマンドプロンプトで次のように入力し、makeotf を実行します。
makeotf -f merged.raw -ff features_min -o AFDKOSample-Light_min.otf
すると、すぐに AFDKOSample-Light_min.otf というフォントファイルができあがります。ここでは必要最低限の設定しかしていないので、各種パラメータが適切だとはとても言えませんが、それでもCIDキー方式の OpenType フォントとして普通に利用することができます。
以下の項では、各種パラメータの設定方法についてもう少し詳しく見ていきます。
features
AFDKO入門《CIDキー方式のOpenTypeフォントの作り方》 前篇：AFDKOのインストールとmergeFonts
花園明朝OTプロジェクトでは、フォントの生成に使っている各種スクリプト・設定ファイル類を公開してはいるものの、AFDKO（Adobe Font Development Kit for OpenType）をどのように利用しているかといった詳しい生成方法については、（面倒だったので）あまり文書化していませんでした。
先日、花園明朝OTのページを見た方から「AFDKOの使い方の例を教えてほしい」とのメールをいただいたので、これを機に簡単な入門記事を書いてみたいと思います。テーマは、《CIDキー方式の OpenType フォントの作り方》。ごく単純なCIDキー方式 OpenType フォントの作成方法を、サンプルファイルとともに順を追って解説していきます。
ただし、わたし自身AFDKOやフォントフォーマットについて熟知しているわけではないので、以下の内容には怪しい記述があるかもしれません。誤りなど発見された場合には、ご指摘いただけると助かります。
この入門記事で扱う内容
この記事では、AFDKOに含まれる mergeFonts, makeotf を利用して、通常の名前キー方式の OpenType フォント（name-keyed OpenType font）からCIDキー方式の OpenType フォント（CID-keyed OpenType font）を生成する方法を簡単に解説します。あくまでも入門なので、ヒントや feature などについては扱いません*1。
なお、この記事ではコマンドプロンプトの基本的な操作*2を身に着けていることを前提としています。Windows 環境を想定して手順の解説をしていますが、Mac の場合でも（コマンドプロンプトがターミナルに変わるぐらいで）手順は同一です。
AFDKOのインストール
mashabowのweb本棚「しろもじライブラリ」のご紹介
以前ちょろっとブログに書いただけでちゃんとした紹介をしていなかったので、ここらであらためてご紹介。
文字に興味を持ってこのブログを始めて以来、文字関係の本をいろいろと自分で漁るようになった。高い本にはなかなか手を伸ばす勇気がないので（というか要するにケチなので）比率としてはかなり古本が多いのだが、累計金額を見てみるとそれでも文字関係の本だけで20万円以上も使っているらしい。各種イベントでもらってきたようなフォントのパンフなども含めると、蔵書数は合計300点程度。そのうち漢字に関係するのは約90点、書体見本に関係するのは70点、文字コードに関係するのが30点、……。
こんな感じに蔵書を把握できるのは、メディアマーカー（MediaMarker）という本棚サイトのおかげ。わたしは2009年3月から、このサイトを利用して蔵書の管理をしている。それがこちら。
続きを読むスーパーの商品に見るミリリットル・mℓ・ml・mL
体積の単位「ミリリットル」は、記号では mℓ や ml、mL などと書かれる。要はリットルのエルをどう書くかの違いだが、Wikipedia ではこのエルについてこう解説されている。
本来、リットルを表す記号は小文字の l だけである。SIにおいては、人名に由来する単位のみ記号の一文字名を大文字にし、それ以外の単位は全て小文字で書くことになっている。
リットル - Wikipedia
しかし、多くの英語圏の国では、筆記体のアラビア数字の1を単に垂直の線のみで示すのが一般的となっており、これとラテン文字の小文字の l はまぎらわしい。
1979年、第16回CGPMで、大文字の L をリットルの新たな記号として用いることが採択された。また、将来この2つのうちのどちらか1つのみを正式なものとして選択されるべきであると表明されたが、1990年の会議ではまだその時期ではないとされている。現在では、産業技術総合研究所やアメリカ標準技術局 (NIST) は、大文字の L を使用することを推奨している。
また、1979年以前には、小文字の l の筆記体である ℓ (U+2113) が日本をはじめとするいくつかの国でリットルの記号として使用されていた。この記号は、現在でも非英語圏の国のいくつかで見ることができる。日本の小学校教育では、現在でも ℓ を用いるように教えている*1。しかし、多くの国ではこの記号は用いられておらず、国際度量衡局 (BIPM)、国際標準化機構 (ISO) やその他の国際標準機関はこの記号を公式なものと認めていない。
近所のスーパーに行ったときにどの表記が多いのかふと気になったので、商品に書かれている「ミリリットル」がどうなっているのかちょっと調べてみた。
小さなスーパーといえどもいろいろな商品があるが、今回チェックしたのは栄養ドリンク・ペットボトル飲料・調味料（醤油や酢など）の3品目のみ。商品のラベルには原材料名や製造者名を書いた枠があるが、その中にある内容量の項の表記を見て調べた。母数が少なく、また定量的な調査でもないが、だいたい次のような傾向が見て取れた。
- 栄養ドリンク
- mL が多い
- ペットボトル飲料
- ml が多い
- 調味料（醤油や酢など）
- ミリリットル・mℓ が多い
栄養ドリンクに mL が多いのというのは、見るからに理系っぽくて納得できる。逆に調味料ではミリリットルや mℓ といった表記が多く、庶民的で昔ながらといった直観的なイメージと合致している。
ただし、この調味料に関しては別の要因もあるかもしれない。というのも、醤油や酢のラベルは縦書きのものが多く、縦中横を使うのが面倒・困難なためにカナの「ミリリットル」や組文字の「mℓ」*2が使われている、という推測もできるからだ。
学習指導要領の改訂（*1 参照）もあり、将来は mL 表記が増えていくかもしれない。個人的に好きなのもこの mL 表記だ。果たして mℓ はいつまで生き残っていくのだろうか。
IVS入力ツールsvivsを公開しました
前回のエントリで「試作中」と書いたIVS入力ツールの svivs だが、とりあえずある程度までできあがったので、このへんで一旦公開してみる。バージョン1.0.0。Windows XP でしか動作確認をしていないが、Adobe AIR で動くので一応 Mac でも大丈夫。
残念ながら、前回のエントリで書いた「動作が思ったよりも重い感じ」はそれほど改善されていない。テキストエリアの処理がもっさりげな感じ。しかもこのテキストエリア、実のところハイライトさせる処理で Splitting a surrogate pair
とかいってコケることがある*1。実際のコードではサロゲートペアをちゃんとペアとして扱っている（はず！）にも関わらず。この問題をどうにかしたかったのだが、コケる条件がよくわからないのでとりあえずそのままになっている*2。
今後の予定としては、
みたいなのが一つずつでもできたらいいなーという感じ。
