墨入れしてみた #かな書いてみる
前回で下書きが一通りできた(上の記事参照)。もう一回下書きを書き直して改良するか、それとも次の段階に進むか迷ったが、「とりあえずどんどん進んで困ったらそのとき考えよう」という楽天的な方針で行くことにした。というわけで、次の工程である清書(墨入れ)に進んでみる。
作業としては、下書きを透かして輪郭をトレースし、それを墨で塗っていくだけ。トレースには一番安かった*1下のトレース台を使ってみた。安いなりの造りだが、この用途で使うにあたっては今のところ特に不満もない。
サンコー LEDバックライトUSBトレース台 COTRSTA4
- 出版社/メーカー: サンコー
- 発売日: 2015/07/02
- メディア: Personal Computers
- この商品を含むブログを見る
輪郭を鉛筆で方眼紙にトレースしたら、それに墨入れをしていく。墨は墨汁をそのまま使った。筆は家にあった漢字書用の小筆を使ったが、本当は面相筆の方がいいのかもしれない。コシが強い筆の方が、線がフニャらずに良さげ。輪郭は筆の腹で描くとぶるぶるになるので、穂先側で描くようにする。また、自分の描きやすいように紙の向きを変えて描いていくと楽。といっても慣れないとやっぱりなかなか難しい。
一枚書き終わったら、出来を確認する。遠くから見てみたり角度を変えて眺めてみたり、いろいろと方法はあるだろうが、自分の場合、スキャンした画像を縮小表示で見てみると欠点がよくわかった。凹んでいる箇所やはみ出た箇所を墨と修正液で直したりして、何度かこの修整作業を繰り返す。
で、出来上がったのがこちら。
まだまだ統一感に欠けるところもあるが、とりあえずは一通り終わった。
さて次はどうしようか。
明朝体かな書体を制作中 #かな書いてみる
きっかけ
何年も前から「オリジナルの明朝体かな書体作ってみたいなー」と思っていたが、思っているだけでどうも踏ん切りがつかず、結局のところ特に何も作ってはいなかった。
そんな中、先月大曲都市さんのタイプデザインセミナーに参加した際に、いろいろなお話を聴いて「やっぱり自分も何か手を動かして作ってみないと」と感じたり、懇親会で「最近何やってるの?」と訊かれて「そういえば特にこれといってやってないな」と気づいたりで、ちょうどいい機会だと思ってスパッと始めてみることにした。
計画
今回の目的としては、「書体制作の各過程を実際に経験する」ということがまず挙げられるが、それと同時に自分の実力の把握や、技術の体得もある程度できるかと思う。他の書体と比較することで、その書体の設計をより深く知ることにもなるだろう。
制作する書体は、前述のとおりオリジナルの明朝体かな書体。「まず作ってみる」ことが目的なのでコンセプトのようなものは特に考えていないが、普通の縦組み本文に使えるようなごくオーソドックスなかな書体を想定している。自分としてはクラシックなかなの方が好きだが、何も考えずに書いてみたところそれほどクラシッククラシックな感じにはならなかった。
全体の大雑把な手順はこんな感じだろうか。
- 方眼紙に下書き
- 下書きを基にして清書
- スキャンしてアウトライン化
- フォント化
これの各所に調整の作業が入ることになるだろう。まずは早めに全体像や作業の感覚を摑みたいので、清音(+ん)のひらがな48文字だけで作っていきたい。
和文書体の分類方法いろいろ ―後篇
あいだが空いてしまったが、前篇のつづき。
IPSJ-TS 0013:2011 の分類方法
2011年11月14日に、情報処理学会の試行標準である IPSJ-TS 0013:2011「フォントリソース参照方式」が公表された。
この中の「5.3 書体分類および分類ノード」において、書体の分類方法が以下のように定められている。
- 伝統書体(漢字のあるもの)
- ディスプレイ書体(漢字のあるもの)
- かな書体(独立)
詳しい内容や分類例については試行標準の本文を参照のこと。
欧文書体の分類と PANOSE 1.0
ちょっと横道にそれて、欧文書体の分類方法を見てみよう。
Vox-ATypI classification
欧文書体にも分類方法はいろいろとあるようで、例えば有名なものに Vox-ATypI classification がある。Wikipedia によれば、現在は以下のような分類になっている。
和文書体の分類方法いろいろ ―前篇
書体を分類する
書体を分類(=整理、体系化、ラベルづけ)すると、いろいろなメリットが生まれてくる*1。カテゴリから書体を検索したり、雰囲気の似た書体を探したり。もちろん、研究や分析もしやすくなる。ちょっと考えてみればわかるが、「明朝体」というカテゴリ名称がなかっただけでも一大事だ。
書体の分類方法にはいろいろな種類があるが、例えばモリサワのサイトの書体分類では以下のようになっている。
- 和文書体
- 明朝体
- ゴシック体
- 丸ゴシック体
- デザイン書体
- 装飾書体
- 筆書体
- 新聞書体
- かな書体
- かな明朝体
- かなゴシック体
- かな丸ゴシック体
- かなデザイン書体
- かな筆書体
- UD書体
- UD書体
- 学参・筆順
- 学参書体
- 学参かな
- 筆順書体
このように、各ベンダーのサイトやカタログといった書体の総数が少ない場においては、そこまで大規模な分類は必要にならない。
大規模な分類方法
これに対し、例えば全ベンダーの書体を網羅した見本帳など、多数の書体を扱う必要がある場合には分類も大規模なものになってくる。近年のデジタルフォントの充実によって大型の見本帳がいくつか発行されているが、そこで採用されている大規模分類を以下に紹介する。
小宮山分類
『基本日本語活字見本集成 OpenType版』*2(2007年)において、小宮山博史は「デジタル書体の分類試案」として次のような分類方法を提唱した。
「Unicodeの基礎知識と異体字について」に行ってきた
IVS技術促進協議会のセミナー「Unicodeの基礎知識と異体字について」があったので、ちょっと聴きに行ってみた。
Unicodeの基礎知識と異体字について
主催:IVS技術促進協議会 後援:日本電子出版協会、電子出版制作・流通協議会
内容
(1)Unicodeに関わる用語や基礎知識、IVSについてご説明します。
講師:Unicode Consortium Director 小林 龍生 氏
(2)外字・異体字に関するプロジェクト等についてご説明します。
講師:凸版印刷株式会社 情報コミュニケーション事業本部 田原 恭二 氏、総合研究所 秋元 良仁 氏 セミナー情報|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 フォントとして普通に利用することができます。
以下の項では、各種パラメータの設定方法についてもう少し詳しく見ていきます。