は じ め に
PDF が生まれて約 20 年になるが、PDF は HTML と並んで現代における情報流通のた
めの 2 つの柱であり、情報化社会をささえる最重要インフラのひとつとなったといって
も過言ではない。
PDF についてエンドユーザの立場で書かれた活用本は多数ある。一方、PDF 仕様書は
公開されており、また、ISO 標準にもなっているので PDF 製品を実装するための技術情
報は不足していない。しかし、制作者や情報技術者のために PDF の技術的側面を解説し
た書籍は少ないように思われる。PDF をシステム的に活用するには一定の前提となる
知識が必要なのだが、そのような情報はあまり多くない。
本書は PDF についてバランスのとれた技術的解説書とすることを目指している。第
一段階として、2005 年 10 月から 2008 年 7 月にかけて 1000 日間にわたって連載した
ブログ「PDF 千夜一夜」の記事を整理する。なお、ブログで取り上げなかった項目、現
在までに新たに課題になった項目についても追加する。
本書は完成するまで間、随時、EPUB、PDF 版を公開する予定である。また、Facebook
上に本書についての意見を交換するための「PDFinterest」グループを開設している。
PDFInterest: http://www.facebook.com/groups/PDFinterest/
不明点またはご意見はそちらにお寄せいただきたい。読者からの要請により記事を追
加するとともに、「PDF 千夜一夜」連載中および連載終了後の PDF 技術の変化を加筆
し、また全体的にバランスの欠けている部分を補う予定である。
できるだけ多く方々に「PDFinterest」グループに参加していただき、本書に関して
活発な議論をしていただくことを期待している。また、本書は完成した段階で印刷した
書籍としても販売することを計画している。
iii
目
次
はじめに
iii
第 1 章 PDF ってどんなもの？
1
1.1 PDF とは
1
1.2 PDF の歴史
6
第 2 章 PDF の国際標準
11
2.1 PDF の国際標準仕様
11
2.2 ISO 32000
11
2.3 PDF をベースとするプロファイル仕様
12
2.4 PDF/E (ISO 24517)
13
2.5 PDF/UA (ISO 14289)
14
第 3 章 デスクトップで PDF を作成する
17
3.1 全体の仕組み
17
3.2 PostScript から PDF を作る
18
3.3 PDF 生成ライブラリー
23
3.4 Windows の印刷機能で PDF 作成
25
3.5 仮想 PDF ドライバで対話機能を設定する
27
3.6 直接 PDF 作成
30
3.7 スキャナー・複合機による PDF 作成
34
3.8 いくつかの技術的課題
38
第 4 章 PDF・Web・電子書籍
41
4.1 コンテンツとレイアウト
41
4.2 XSL-FO によるレイアウト指定
42
v
4.3 CSS によるレイアウト指定
48
4.4 TeX と PDF
50
4.5 コンテンツ活用のベストプラクティス
50
第 5 章 PDF のナビゲーション機能
5.1 ナビゲーション機能とは
53
5.2 サムネイル
53
5.3 しおり
54
5.4 リンク
57
第 6 章 サーバーサイドで PDF を作る
6.1 on-the-fly で PDF
第 7 章 文字コードと文字の表示形
61
61
63
7.1 言語の表記手段としての文字
63
7.2 文字コードとテキスト
66
7.3 Unicode 以前の文字コード
67
7.4 Unicode の歴史
76
7.5 漢字の文字コードと字形
80
7.6 漢字の大文字セット
84
7.7 グリフとグリフセット
85
7.8 ハングル
92
7.9 ラテンアルファベットと結合文字
94
7.10 アラビア文字
95
7.11 リガチャ
99
第 8 章 スクリプト処理
vi
53
103
8.1 スクリプト処理エンジン
103
8.2 結合文字と文字の合成
104
目次
8.3 アラビア文字の処理
106
第 9 章 PDF とデータ交換
109
9.1 テキストによる情報交換
109
9.2 PDF における構造表現
109
9.3 タグ付き PDF
110
第 10 章 PDF とフォント
113
10.1 フォントとは
113
10.2 アウトラインフォントの種類
116
10.3 フォントによるテキストの表示
126
10.4 フォント埋め込み
128
第 11 章 図形の取り扱い
11.1 カラー空間
第 12 章 PDF のファイルサイズ
141
141
143
12.1 PDF の中のデータ圧縮
143
第 13 章 PDF のメタデータ
145
13.1 ドキュメント情報辞書
145
13.2 メタデータストリーム
145
13.3 XMP 仕様について
146
第 14 章 PDF の配布と閲覧
151
14.1 PDF を Web 表示用に最適化
151
14.2 PDF のアクセシビリティ
153
14.3 PDF における JavaScript
155
vii
第 15 章 PDF を編集・加工する
157
15.1 PDF のページ内容を編集する
157
15.2 PDF を用紙として使う
157
15.3 PDF の注釈
157
第 16 章 PDF の利用を制限する
161
16.1 PDF のパスワード方式セキュリティ
161
16.2 公開鍵と秘密鍵でセキュリティ設定
164
16.3 PDF 配布物の著作権保護
165
第 17 章 印刷ワークフローにおける PDF
167
17.1 印刷と PDF
167
17.2 PDF/X ファミリー
167
17.3 PDF/X-1、PDF/X-1a
169
17.4 PDF/X-3
179
17.5 PDF/X-2
184
17.6 PDF/X-4
187
17.7 PDF/X-5
188
第 18 章 電子政府と PDF
191
第 19 章 PDF と電子書籍
193
19.1 電子書籍
193
19.2 PDF と EPUB の関係
193
19.3 自炊
193
第 20 章 電子帳簿保存法と e 文書法
195
20.1 電子帳簿保存法
195
20.2 e 文書法
195
viii
目次
第 21 章 PDF の真性性・証拠性の確保
197
21.1 電子署名の仕組み
197
21.2 タイムスタンプの仕組み
200
21.3 PDF 電子署名（ISO 32000-1）
201
21.4 PDF タイムスタンプ
203
第 22 章 PDF の長期保存
205
22.1 長期保存とは
205
22.2 PDF/A ファミリー
206
22.3 PDF/A-1
206
22.4 PDF/A-2
208
22.5 PDF/A-3
209
22.6 PDF/A の作り方
211
22.7 PDF 長期署名（PAdES）
215
第 23 章 PDF を他の形式に変換する
223
23.1 PDF から HTML に変換する
223
23.2 PDF からオフィス形式へ
223
23.3 PDF を画像にする
223
第 24 章 PDF の代替形式
225
24.1 SVG
225
24.2 XPS
225
24.3 Flash
232
謝辞
233
図表一覧
235
参考資料
239
索引
247
ix
第 1 章 PDF ってどんなもの？
1.1 P D F と は
1.1.1 PDF は紙の電子的な模倣
PDF（Portable Document Format）は、HTML、JPEG などと同じような電子ファ
イルの形式である。PDF は、よく Acrobat と混同されることがあるが、Acrobat はアド
ビシステムズ社（アドビ）が開発・販売する PDF 処理ソフトウェアの「製品名」であ
る。PDF を Acrobat というのは、宅配便を宅急便と呼ぶのに近い。
電子ファイルの形式としての PDF を大雑把にいうと紙のページを電子的に表現した
ものである。人間が一枚の白紙の紙に鉛筆で文字を書いたり、線を引くときは、頭の中
でどの位置に、どんな大きさで、どんな文字や絵を描こうかと考え、考えたとおりに手
を動かして、文字と絵を書く。これと同じように PDF のファイルの中には、頭の中で考
えた状態と同じような情報がプログラムへの「命令」として記述されている。即ち、
PDF ファイルには 1 枚の紙の左上を原点にして、下方向と右方向に座標軸をとってでき
る平面を定義し、その平面のどこに、どんな大きさで、なんという文字を書くか、どん
な太さで、どんな種類（直線、点線、…）の線を引くか、どんな画像をどこにどんな大
きさで配置するか、といった命令が１ページ毎に記録されている。
この PDF ファイルを画面に表示するには、PDF リーダ（Reader）または PDF ビュ
ーア（Viewer）と呼ばれるプログラムを使う。PDF リーダは PDF ファイルの内部に記
述されている命令を読み取り、解釈・実行して、コンピュータの画面やプリンタにペー
ジを描き、表示するものである。代表的な PDF リーダが Adobe Reader（以前は、
Acrobat Reader という名称であった）であり、Adobe Reader は PDF の代名詞になる
位広く使われている。
PDF がデジタル情報交換のインフラとして普及するにつれて PDF リーダ機能を OS
やブラウザのレベルでサポートする動きが広がっている。アップルの Mac OS X は
PDF 表示機能を OS の機能としてサポート開始している。Mac OS による PDF のサポ
ートは iOS にも引き継がれており iPhone や iPad では OS の標準機能によって PDF を
表示することができる。さらに 2012 年に発売された Windows8 でも OS の機能として
PDF が表示できるようになった。OS に加えてブラウザのレベルでも PDF 表示機能の
1
サポートが始まっており、グーグルの Chrome ブラウザには PDF リーダが組み込まれ
ている。FireFox も 2013 年 2 月にリリースしたバージョン 19 から PDF リーダ機能を
実現した。
1.1.2 PDF の仕様は公開されている
PDF ファイル中にどのように命令を記述するかをまとめたものが PDF の仕様書であ
る。一般にソフトウェアを開発する上で最も重要なものはその設計図に相当する仕様書
であるが、PDF が普及した要因のひとつは、PDF の仕様書が「PDF Reference」とし
て PDF 誕生当初から公開されてきたことである。PDF Reference は、すべて英語で記
述されているが、第 2 版は日本語版も書籍として出版されている（アドビシステムズ
『PDF リファレンス第 2 版』（p. 243））。
1.1.3 国際標準となった PDF 仕様書
さ ら に 2008 年 に は PDF 仕 様 は 国 際 標 準 化 機 構 ISO （ International Standard
Organization）が定めるところとなった。これにより PDF はデファクト標準からデジ
ュール標準となった。これについては、第 2 章 PDF の国際標準（p. 11）で詳しく説
明する。
1.1.4 仕様をだれでも利用できる
PDF の仕様書は公開されているだけではなく、それを誰でも開発に使えるとされてき
た。例えば、PDF Reference 第 5 版の最初の章には次のように明記されている。
「この本は PDF のファイル形式についての説明を提供し、第一に、PDF ファイルを直
接生成する PDF Producer アプリケーションの開発者のためのものである。また、開発
者が既存の PDF ファイルを読んで、内容を解釈し、変更する PDF Consumer アプリケ
ーションを記述するのに十分な情報を含んでいる。」
（Adobe Systems.“PDF Reference,
fifth edition.” p.1（p. 239））
このようにアドビの製品のみではなく、サードパーティの開発者が自由に PDF を作っ
たり、読んだり、修正することができることが明瞭に意図されている。仕様書を公開し
たこと、そして、この文章があることにより、アドビ以外のソフトウエア会社が PDF 関
連製品を出すことができ、非常に沢山の PDF 関連製品が生まれた。
アドビという会社は印刷・DTP の世界の専門家向けの製品を得意としてきた。アドビ
によって、この 20 年間で出版や印刷業界の仕事のやり方ががらっと変わってしまった、
といっても言い過ぎではないほどである。しかし、出版・印刷以外のビジネス・教育分
2
第 1 章 PDF ってどんなもの？
野、あるいは一般消費者にとってアドビはそれほど身近な存在ではなかった。おそらく、
第三者のソフトウェア会社から多数の PDF 関連製品が出なければ、PDF が印刷業界を
超えて広い分野における電子文書の標準形式として広く普及するのにはもっと時間がか
かったと考えられる。
日本製 PDF 製品はまだまだ少ないが、海外では、PDF 関連製品はそれこそ星の数ほ
どある。アドビを含めたすべてのソフトウェア製品の提供者にとって、PDF 関連製品の
分野の競争は非常に厳しいが、この結果、使用者・消費者にとっては良いものを安く手
に入れることができる。これも、PDF の仕様書が公開されているお陰である。
1.1.5 ポータブルとは
PDF はその名をポータブル（可搬）な文書形式（Portable Document Format）とい
うように、文書をお互いに交換する場合に最適な電子ファイル形式である。このことに
ついて説明したのが、図 1 ポータブルの意味（p. 3）である。ここでは A さんが自分
のパソコンで作成したファイルを B さんに渡して、B さんが表示して内容を確認するこ
とを図式化している。
A さんが自分のパソコンでマイクロソフト Word を使って文書を作成し、それを「文
書ファイル.doc」という名前をつけて保存する。すると、A さんのパソコンのハードデ
図 1 ポータブルの意味
3
ィスクの中には「文書ファイル.doc」というファイルが新しく作成される。
この内容を B さんに見てもらうために、「文書ファイル.doc」を電子メールの添付フ
ァイルとして B さんに送るとする。このとき、B さんが A さんから受け取った「文書フ
ァイル.doc」の内容を、自分のパソコンで読むには、通常は、パソコンにマイクロソフ
ト Word がインストールされていなければならない。これは、
「文書ファイル.doc」の内
部がマイクロソフト Word 専用の形式になっているためである。他のソフトウェアが
Word ファイルを読むにはマイクロソフト Word と互換のリーダを作成する必要があ
る。しかし、完全なマイクロソフト Word 互換リーダを作るのは困難である。
これに対して、A さんが、「文書ファイル.doc」の内容を PDF 形式（「文書ファイ
ル.pdf」
）にしてから、B さんに送ることもできる。そうすると、B さんは Adobe Reader
などの PDF リーダを使って「文書ファイル.pdf」の内容を読むことができる。
このように PDF ファイルを交換すれば、受け取った側ではオリジナル文書を作成した
アプリケーションが無くてもファイルの内容を読むことができるが、これが、PDF ファ
イルがポータブル（可搬）であるということの基本的な意味である。
1.1.6 Word 文書はポータブル？
「Excel とか Word を読取るフリーソフトとかもあるので、実質的に Word と PDF は
等価じゃないかと思うのですがどうなんでしょう。」という疑問をもたれるかもしれな
い。実際のところ Word 文書と PDF では、可搬性において大きな差がある。このことを
少し詳しく説明してみたい。
確かに、マイクロソフトは Word 文書のリーダ（Word Viewer）を無償で配布してい
る（マイクロソフトサポート「最新の Word Viewer の入手方法」（p. 244））。しかし、
それだけでは、Word 文書が可搬であるとは言えない。
動作・閲覧環境
Word 文書を作成した環境以外で読む方法は次のようにかなり整備
されている。
①Word Viewer がサポートするオペレーティングシステムはマイクロソフトの
Windows XP 以降、Windows 2000 Service Pack 4 以降の Windows である。それより
も前の Windows を載せた PC では使えない。②PC には、アップルの Macintosh、Linux
などで動くものもある。これらでは Word 文書を読もうとすると、Mac OS 用の Office
for mac を購入するか、Libre Office などの Office 互換ソフトを導入する必要がある。
しかし、新しい端末は次々に発売されるので、将来に渡って Word 文書を任意の端末
で読むことができるかどうかは不安が残る。
再現性
4
Word で文書を編集する際には文字毎にフォントを指定できる。では、作者
第 1 章 PDF ってどんなもの？
が指定したフォントが、その文書を読みたい PC にインストールされていなかったら、
どうなるか？　次に、簡単な例を示す。
1)　まず、Word で文字に「HGP 創英角ポップ体」を指定した文書を作る。
図 2 HGP 創英角ポップ体
2)　次に、その Word 文書を「HGP 創英角ポップ体」がない Windows 上の Word で
表示すると次のようになる。
図 3 フォントの置換
マイクロソフト Word は、自動的に近いフォントに置き換えて表示していることがわ
かる。指定されたフォントがないとき、勝手に別のフォントで表示するというのは、便
利そうに見えるがトラブルの元にもなる。可搬であるというためには、フォントがなく
ても元と同じように表示できる仕組みが必要である。PDF にはこの問題を解決するた
めにフォントの埋め込みという仕組みがある（10.4 フォント埋め込み（p. 128）を参
照）。
1.1.7 PDF の用途は？
PDF の用途は大きく、①印刷分野での使用、②ビジネス・教育・官公庁などでの一般
用途、に分けて考えると良い。以下に述べるように印刷分野の PDF と一般用との PDF
5
では要求される機能が相当に異なり、適用される PDF ソフトウェアも異なることが多
い。
印刷分野での使用 雑誌や書籍を初め、パンフレット・ちらし、マニュアルなどの印
刷物制作に関わる、制作担当、デザイナー、校閲担当者、印刷会社、広告会社などの間
で印刷物の制作・進行過程でやりとりする電子データ形式として PDF が使用されてい
る。関係する人達は専門家であり、使用者が比較的限定されている。印刷は画面表示と
比べて解像度が高いので、写真のような画像は高解像度のものを用意する必要がある。
また、PDF をカラー印刷に使う場合は、インクを使って印刷するためのカラー設定やそ
の設定情報の交換が必要である。印刷分野で PDF を使うための標準として PDF/X と
いう特別な取り決めもなされている（17.2 PDF/X ファミリー（p. 167）を参照）。
一般用途での使用
ビジネス、教育、官公庁などでは、ビジネスレター、月次報告書、
申告書、報告書などを電子的に配布するために PDF を利用する。例えば、アメリカの銀
行には、日本と違って通帳がなく、毎月利用実績（Statement）が PDF の形で毎月送ら
れてくる。通信・電話・電力・ガス会社、クレジットカード、証券会社からの報告書は
日本ではまだ郵便物で送られてくることが多いが、遠からず、アメリカのように PDF で
配布されるようになるだろう。
一般用途では、現在のところ、上に述べたような、電子文書の一方的な配布形式とし
ての使用が中心であるが、将来は、申告書などの入力用の形式としても使われるように
なるだろう。PDF が入力用の形式として普及するには、PDF の帳票に簡単にデータを入
力する方法をもっと普及させる必要がある。
1.2 PDF の歴史
1.2.1 PDF の元祖・PostScript
PDF の元祖はアドビの PostScript である。現在では PDF と PostScript とは関係が
疎遠になっているが、これは孫の相貌がお爺さんとは似ても似つかぬものになっている
ようなもの。PDF は依然として PostScript の遺伝子を濃厚に引き継いでいる。
ページ記述言語とは
PostScript はページ記述言語の一種である。ページ記述言語
は紙のようなページの概念をもつ媒体上に文字や図形を描画するためのプログラム言語
であり、多くの場合ページプリンタ用で、用紙の上に印刷する内容を記述するために使
用する。ページプリンタはページ記述言語で書かれた内容をプリンタがもつメモリの上
にイメージとして展開し、そのイメージをレーザーや LED でドラムに転写し、次いでド
6
第 1 章 PDF ってどんなもの？
ラムから紙に転写・焼き付ける。主要なプリンタメーカは、それぞれ独自のページ記述
言語をもっており、PostScript のほか、エプソンの ESC/Page、キヤノンの LIPS、ヒュ
ーレット・パッカード（HP）の PCL などが有名である。PostScript はプリンタメーカ
が自社のプリンタのために開発したものではなくて、アドビというソフトメーカが開発
してプリンタメーカに提供したものであり、ハードウェアから独立している。
PostScript は高級プリンタ用として多くのメーカに採用されるとともに、Unix 上で
PostScript を作成するソフトウェアが作られた。これが PDF を誕生させるきっかけに
なったと考えられる。
ページプリンタが最初に脚光を浴びたのはアップルの Macintosh のための Laser
Writer である。Laser Writer には PostScript が採用されており、Macintosh の上で動
く PageMaker というページアップ・ソフトとともに売り出され、DTP（デスクトップ・
パブリッシング）という新しい出版物制作方法を生み出した。DTP は Macintosh と共
に華やかに登場し、大人気となり、約 20 年を経た今日で印刷物を制作するための標準
的な方法となった。DTP で制作したページを印刷するために使われたのが PostScript
技術なのである。アドビは、アップルを含む多くのプリンタメーカに対して PostScript
技術を供給したことで、PostScript は 1990 年代には高級なレーザプリンタ向けのペー
ジ記述言語として標準的な地位を占めるようになった。さらに高品質が要求される印刷
分野では、ほぼ独占的な地位を占めるようになり、ひいては印刷業界の仕事をがらっと
変えてしまった。
ちなみに、PageMaker は 1985 年にアルダス社が発売したものだが、1994 年にアド
ビがアルダス社を買収し、アドビより販売されることとなった。しかし、その後、アド
ビが新たに開発した InDesign にその地位を譲ることとなり、2005 年に PageMaker の
開発が終了したとアナウンスされている（Adobe Systems. "FAQ for Adobe PageMaker
Users."（p. 239））。
PostScript による情報流通の開始
DTP と PostScript 搭載プリンタによる出版物の
印刷は次の過程で行なう。①パソコン上で DTP データから PostScript ファイルを作成
する。②その PostScript ファイルをプリンタに搭載した PostScript インタープリター
に入力する。③PostScript インタープリターは PostScript 言語で記述されたページの
内容をメモリ上にイメージとして展開する。この仕組みを利用すれば PostScript ファ
イルを出版物情報の交換に使うことができる。
アドビは PostScript の言語仕様を公開し、第三者の開発者がいろいろなアプリケーシ
ョンを開発することを奨励したので、パソコンのいろいろなアプリケーションから
PostScript ファイルを出力することができるようになった。こうして、特に Unix のユ
7
ーザーを中心に、PostScript ファイルでドキュメントを流通させるようになった。Web
に PostScript ファイルでは資料を公開しているケースも見られるようになった。この
ようにして、前 PDF 時代には、PostScript ファイルが流通していたのである。
1.2.2 PDF の誕生
PostScript ファイルがアプリケーションから独立したデータとして流通するように
なった。情報の出し手側が PostScript ファイルを作成するのは比較的簡単である。し
かし、受け手側がこれを読んで解釈するには PostScript 言語を解釈するプログラムが必
要だが、このプログラムを作るのはとても大変である。加えて、PostScript 言語は紙へ
の印刷用の出力のために設計されたものなので、例えば画面に表示して、内容をナビゲ
ーションしたり、注釈をつけたりする機能は標準では備わっていなかった。
そこで、PostScript を元に、データを交換する形式として適切なように、またナビゲ
ーションなどが簡単にできるように設計されたのが PDF である。そして、PostScript を
PDF に変換するプログラムとして Acrobat Distiller が用意された。Acrobat Distiller
を使うと、PostScript ファイルを PDF に変換することができる。
distill というのは英語で蒸留するという意味なのだが、Distiller を使って Postscript
図 4 Acrobat Distiller で PDF を作成
8
第 1 章 PDF ってどんなもの？
から PDF への変換することを distill と表現する業界人もいる。こんな具合に：「In the
distilled version, there is... This is using Acrobat 6 for distilling.」
Acrobat2 のパッケージ
たまたま書庫に Acrobat2 のパッケージがあったので、もは
や歴史的な意味しかないかもしれないが簡単に紹介する。このパッケージは、当時、米
国のラスベガスで行われた Comdex というショウを見に行った機会に購入してきたも
のだが、145 ドルのラベルが張ってある。
図 5 Acrobat2 のパッケージ
145 ドルは、「ん？安いな」と感じるかもしれないが、当時は、Acrobat、Acrobat
Pro、Acrobat Wordkgroup の 3 製品に分かれていて、このパッケージは一番目の
Acrobat なのである。Acrobat2.0 には次のプログラムが入っている。
●
PDF を作成するための PDF Writer
●
PDF を表示したり編集するための Acrobat Exchange
●
PDF を表示するための Acrobat Reader
●
PDF ファイルの全文検索機能を提供する Acrobat Search
Acrobat Pro には、Distiller が追加になり、Acrobat Wordkgroup は 10 人分のライセ
ンスをセットにしたものである。なお、Acrobat2 は、1994 年に発売されたもので、
Windows3.1 で動作し、英語版のみで日本語版はない。日本語を扱うこともできない。
日本語版が出たのは次の Acrobat3.0J からとなる。
9
1.2.3 PDF の機能拡張
PDF の仕様は、初期のころから PDF Reference として公開されている。そしてアド
ビ は Acrobat の バ ー ジ ョ ン ア ッ プ と 平 行 し て PDF Reference を 改 訂 し て き た 。
Acrobat のメジャー・バージョン番号と PDF Reference の版番号は、Acrobat 8 までは
次のような対応関係がある。次項で説明するとおり、PDF 1.7 が ISO 32000-1 となった
ので、Acrobat 9 以降は PDF のバージョン番号と Acrobat のバージョン番号は 1 対 1 対
応の関係はなくなっている。
表 1 Acrobat のバージョンと PDF Reference の版番号
Acrobat のバージョン番号
PDF 仕様書
Acrobat 8
PDF Reference, Sixth Edition, Version 1.7
Acrobat 7
PDF Reference, Fifth Edition, Version 1.6
Acrobat 6
PDF Reference, Fourth Edition, Version 1.5
Acrobat 5
PDF Reference, Third Edition, Version 1.4
Acrobat 4
PDF Reference, Second Edition, Version 1.3
PDF Reference は PDF の専門家にとってはいわば聖書に匹敵するものなので、古い
版にも歴史的価値がありそうだが、残念ながら、古いのは消してしまっているようだ。
1.2.4 ISO 標準 ISO 32000-1
2007 年 1 月から 2007 年 12 月にかけて、PDF Reference 1.7 を基に PDF 仕様を
ISO 標準にする作業が行なわれた。この結果、2008 年 7 月に PDF の仕様書は国際標準
ISO 32000-1：2008 として出版された。2.2 ISO 32000（p. 11）を参照。
アドビ拡張
PDF の仕様の策定主体がアドビから ISO に移ってからも、アドビは
Acrobat 用に機能を追加しており、アドビが追加した機能はアドビ拡張として位置づけ
られている。
1.2.5 PDF の今後、インフラへの統合
現在、PDF は電子の紙として、情報交換・流通のためのなくてはならないインフラと
なっている。今後は、PDF はより一層システムの中に組み込まれて無色透明な存在にな
っていくだろう。1.1.1 PDF は紙の電子的な模倣（p. 1）で紹介したとおり、すでに、
PDF の OS への統合は進んでいる。次の段階として Web ブラウザやアプリケーション
への統合も進み、紙と同じようにいつでもどこでも使えるようになるだろう。
10
第 2 章 PDF の国際標準
2.1 PDF の国際標準仕様
PDF 仕様は、現在は主に、国際標準化機構（ISO : International Organization for
Standardization）において標準化が進められている。
大きく分けると PDF の全機能を定める仕様である 32000 と PDF の用途別に機能の
使 い 方 を 定 め る プ ロ フ ァ イ ル 仕 様 （ 2.3 PDF を ベ ー ス と す る プ ロ フ ァ イ ル 仕 様
（p. 12）参照）といわれるいくつかの仕様がある。
2.2 ISO 32000
2.2.1 ISO 32000 の動向
ISO は 2008 年に PDF1.7 を元にして「ISO 32000-1, Document management Portable document format - Part 1: PDF 1.7」を ISO 標準とした（ISO 32000-1:2008
（p. 240））。
その後、ISO は 2009 年に PDF2.0 の新規開発プロジェクトを開始した。TC 171 SC
2 作業委員会が開発を行い、2012 年 12 月までに「ISO/DIS 32000-2 Document
management - Portable document format - Part 2: PDF 2.0」となった。しかし、開
発期間を延長するため当初プロジェクトはキャンセルされ、再提起されるようだ。
2.2.2 アドビ PDF1.7 が ISO 標準になるまで
2007 年 1 月 29 日に、米国アドビは、PDF Reference 1.7 を ISO の標準とすべく
AIIM に提供し、AIIM 経由で PDF の ISO 標準へ向けて作業をすすめると発表した。そ
の後、PDF Reference 1.7 を ISO 標準にするために次のような作業が行なわれた。
●
ISO の草稿の形式になるように雛形を使って、PDF Reference を書き直した。
●
技術的な内容はそのまま維持して、表現を変更した。
●
Adobe の製品についての情報への参照を削除し、ベンダー中立とした。
○
最初の 2 章は Adobe の製品に関連するものなので削除した。
○
付録 C、付録 H の大部分は Acrobat の実装に関するものなので削除した。
11
●
廃止した内容を削除した。
○
主に Adobe の製品の歴史的な理由から維持されている廃止した仕様を削除し
た。
●
ISO の用語規定に従って、誤解を招くことが少なくなるように記述を変更した。
○
shall、should、may、can の使い方など。
●
アメリカ英語から国際英語に変更。
●
ノルマ（規定）的と情報的な内容の分離。
PDF Reference 1.7 は、1,310 ページあったが、ISO 32000 のドラフト仕様書
(DIS32000) は全文で 748 ページ。厚さにして 6 割位に圧縮された。このドラフト仕様
について 2007 年 7 月 2 日から 12 月 2 日にかけてファースト・トラック手続きでの投票
が行なわれた。ISO DIS32000 は 2007 年 12 月に ISO の投票を賛成多数で通過した。
総投票数 14 国のうち、13 国（93%）がポジティブ、1 国がネガティブ。
●
コメントなしの賛成国：オーストラリア、ブルガリア、中国、日本、ポーランド、
南アフリカ、スペイン、スウェーデン、ウクライナの 9 カ国。
●
コメント付きの賛成国：英国、米国、ドイツ、スイス
●
反対国：フランス
●
保留：ロシア
コメント総数は 205 件あり、直ちにコメントを反映して DIS 32000 の改訂が行われ、
2008 年 1 月に行われた ISO DIS32000 の作業委員会で改訂版が承認された。DIS への
国際投票で反対したフランスも改訂案の最終投票では賛成に回り、正式仕様としての出
版手続きにはいり、ISO DIS 32000 プロジェクトは終了。2008 年 7 月に ISO 32000-1
として出版された。
2.3 PDF をベースとするプロファイル仕様
PDF には様々な機能が取り込まれており、PDF の全機能は余りにも大きく、多様で自
由度が高いものとなっている。このため、利用目的によっては作成した PDF が不適切に
なってしまうことがある。
そこで、主に利用者の立場から、用途を絞った使い方に関する仕様が様々に提案され
ている。これらは PDF を元にして機能の使い方を定めるものでプロファイル仕様と呼
ばれる。主要な標準仕様には次のようなものがある。
12
第 2 章 PDF の国際標準
表 1 PDF の使い方に関する仕様
用途
仕様名
備考
印刷（プリプレ PDF/X ファミ PDF/X（ISO 15930）ファミリーには PDF/X-1～PDF/X-5 ま
ス）
リー
である。歴史が古く、見直しが行われたり、廃止されたものが
ある。
長期保存
PDF/A ファミ PDF/A（ISO 19005）ファミリーは 2005 年 9 月に PDF/A-1
リー
が発行され、2012 年 12 月までに PDF/A-3 まで策定されてい
る。
工学
PDF/E
2008 年 5 月時点で、PDF 1.6 をベースとする ISO 24517-1 が
策定済み。
アクセシビリ
PDF/UA
ティ
PDF をアクセシブルにするための使い方を定める。2012 年 8
月 ISO 14289-1 として策定
健康・保健
PDF/H
印刷
PDF/VT
PDF/X については第 17 章 印刷ワークフローにおける PDF（p. 167）で解説する。
また、PDF/A については第 22 章 PDF の長期保存（p. 205）で解説する。
2.4 PDF/E (ISO 24517)
PDF/E は正確には「ISO 24517-1:2008 - Document management - Engineering
document format using PDF Part 1:Use of PDF 1.6 (PDF/E-1)」という。ISO 24517
も 19005、15930 同様に複数のパートからなるマルチドキュメントであるが、現時点
で ISO の 仕 様 と な っ て い る の は PDF/E-1 （ ISO 24517-1 ） の み で あ る （ ISO
24517-1:2008（p. 241））。
エンジニアリングワークフローに PDF を適用するための仕様であり、PDF 1.6 をベー
スとして 2008 年に制定されている。
目的はエンジニアリングワークフローにおけるドキュメントの確実な作成、交換、レ
ビューを可能とすること。具体的な例として、仕様書内のユースケースに上げられてい
る項目の一つに、住宅設計図面のメーカによる作成、第三者機関による審査、監督官庁
による承認がある。この中で、作成された図面を審査した第三者機関が差し戻しを行う
場合に注釈等を用いて具体的な不具合箇所の指示を行い、審査に合格した場合は図面に
デジタル署名を行って監督官庁に提出、監督官庁では図面の承認後、デジタル署名を行
った承認図をメーカに戻す、というようなワークフローが説明されている。
この過程で、表示・印刷されるドキュメントが環境によって異なった表示とならない
13
よう、PDF/E においても PDF/A、PDF/X などと同様に、フォントの埋め込み、カラー
スペースの制限などが規定される。また、上記ワークフローで登場するとおり、注釈の
使用が許可されている。ただし、PDF の注釈には、ディスプレイ上では非表示となる、
あるいは印刷時には印刷対象外となる、といった機能が使用できる、PDF/E-1 ではこの
ような機能の使用は許可されていない。また、組立手順書、保守マニュアルといったド
キュメントで、使用されるパーツや組立て手順の説明などに有効な 3D 注釈なども使用
可能である。承認図等でデジタル署名が使用されるので、デジタル署名機能についても
その使用方法が指定されている。
PDF/E-1 は PDF 1.6 をベースとした規格であるが、現在、ISO 32000-1 をベースと
した PDF/E-2 も検討が進められている。
2.5 PDF/UA (ISO 14289)
PDF/UA は PDF におけるアクセシビリティの向上を目的とする仕様である。
現在、PDF は最も広範に利用されている電子文書形式であり、多くの人に使いやすい
ものであることが求められる。障害を持つ人、高齢者にも簡単に使える必要があり、次
のような点に配慮する必要がある。
たとえば視覚に障害を持つ人が利用する場合、音声読み上げソフト等によって、確実
にテキストが読み上げ可能である必要がある。画面に文字が表示されている PDF でも、
読み上げが確実に可能とは限らない。コピー＆ペーストで他のアプリケーションに文字
がコピーできない PDF が配布されていることがあるが、このような PDF は文字コード
がファイル内に格納されていないため、読み上げソフトでも文字が取得できない。また、
同じ漢字でも日本語と中国語では読み方が異なるので、そのテキストがどの言語のもの
なのか、といった情報も必要となる。また、画像、図形等が使用されている場合、それ
がどのような意味を持つものなのか、テキストによる説明があると、利用しやすい。
PDF/UA は、このような点を考慮して、PDF の利用方法（作成側、読み込み側の双
方）を定義したものである。PDF/UA は 2012 年に国際標準 ISO 14289-1 となってお
り、規格書初版は 2012 年 7 月 25 日に初版、2012 年 8 月 1 日修正版が発行されている。
規格書のタイトルは、Document management applications — Electronic document file
format enhancement for accessibility — Part 1: Use of ISO 32000-1 (PDF/UA-1)
（p. 240）である。
14
第 2 章 PDF の国際標準
2.5.1 規格書の主な内容
ISO 14289-1 は 、ISO 32000-1 をベースとし、その機能のなかから、使用してはい
けない機能、使用方法に制限のある機能などを定めている。この規格に関連する仕様と
して、W3C の Web Content Accessibility Guidelines (WCAG) 2.0 が記載されている
（14.2 PDF のアクセシビリティ（p. 153）を参照）。仕様書では PDF/UA ファイルのバ
ージョンの識別方法、準拠レベル、ファイルフォーマットに関する要件が記載されてい
る。
ファイルフォーマットの要件の主な規定は、ドキュメントをその構造に沿って解釈で
きるように、タグ付けされていることにある。このタグの使用方法、論理構造の表現な
どについて、テキスト、画像、表、リストなどの各項目についての規定が説明されてい
る。タグ付き PDF については、9.3 タグ付き PDF（p. 110）を参照）。
フォントの埋め込みが必須とされている。一方、注釈やアクションについては、印刷
時の再現性等を求めるための規格でははないので、用法に制限があるが、完全に禁止と
はなっていない。
続けて、この規格に準拠するリーダ (Conforming Reader) に対する要件が記載されて
いる。
ファイルフォーマットに関する要件は主に PDF/UA ファイルの作成者（書き手）側に
対する要件であるが、こちらは、PDF/UA ファイルが持つアクセシビリティ機能を利用
可能とするためにリーダ (読み手) に必要とされる要件が提示されている。
最後に AT に対する要件が定義されている。AT とは、障害をもつ人によって使用さ
れ、代替えのコントロールや表示を提供したり、有効な機能の使用方法や情報を提供す
るソフトウェアあるいはハードウェアといった定義がされており、準拠リーダと統合可
能と記載されている。
15
第 3 章 デスクトップで PDF を作成する
3.1 全体の仕組み
3.1.1 PDF 作成方法を分類する
まず、PDF ファイルを作成する仕組みを整理してみる。仕組みを知らなくても使うこ
とはできるが、PDF 製品を選択する上でも、仕組みを知っておいても損はないだろう。
PDF ファイルを作るソフトは世界中に一杯あるが、それぞれの仕組みは公開されていな
い。また、使いやすいソフトは内部が複雑な仕組みになっていても、それをユーザーに
隠して簡単に使えるようにしているので、ユーザーに表面的に見える名前からだけでは
仕組みはなかなかわからない。また、ソフトウェアは機械と違って分解して仕組みを調
べることができないし、それにリバースエンジニアリングは禁止されている。しかし、
基本を理解していれば仕組みは大よそ推測できる。
まず、PDF を作成する方法を大別すると、次の３通りに分けることができる。
1） デスクトップのアプリケーション・ソフトで作成した内容を PDF にする
2） 紙をスキャナーやデジタル複合機（MFP）などで取り込んだ内容を PDF にする
3） サーバサイドで PDF を生成する
デスクトップアプリケーション・ソフトで作成した内容を PDF にしたものを「電子文
書」
（ボーンデジタル）という。一方、紙をスキャナーで取り込むと画像になるが、その
画像を PDF にしたものを「電子化文書」
（ターンドデジタル）という。電子文書 PDF と
電子化文書 PDF ではその特性がまったく異なる。
3.1.2 アプリケーションソフトで作成した内容を PDF にするとき
大雑把に言って、Windows の環境では、次の図の①と②の組み合わせ、③、④、⑤
の経路のどれかで作成する仕組みになっていると考えて間違いない。但し、アップルの
Mac OS X では、Quartz という描画エンジンから PDF への直接変換ができるし、また、
Unix、Linux でも異なる。
図の①から⑤の経路の概略は次の通りである。
1） アプリケーションから PostScript プリンタ・ドライバを使って PostScript ファイ
ルを作る。（図①）
17
図 1 アプリケーションソフトから PDF を作る
2） PostScript ファイルを PDF ファイルに変換する。Web などで流通している
PostScript ファイルを使うこともできる（図②）。
3） PostScript プリンタ・ドライバを使わずに、PostScript を作成し、あとは、
PostScript を PDF ファイルに変換する（図③）。
4） アプリケーションから、プリンタ・ドライバを通さずに PDF を作成する（図④）。
5） アプリケーションから PDF 作成用の GDI 型プリンタ・ドライバを使って PDF フ
ァイルを作成する（図⑤）。
まず、この 5 種類を説明し、次に 3.7 スキャナー・複合機による PDF 作成 （p. 34）
で電子化文書 PDF について説明する。
3.2 PostScript から PDF を作る
PDF の作成方法のひとつめは、PostScript ファイルを経由して PDF を作成する方法
である。この方法は 1.2.1 PDF の元祖・PostScript（p. 6）で説明したように第一段階で
PostScript ファイルを作成し、第二段階で、PostScript ファイルから PDF への変換を行
う。
3.2.1 PostScript ファイルを作る
PostScript ファイルを作る方法は二通りある。第一はアプリケーションソフトから
18
第 3 章 デスクトップで PDF を作成する
PostScript ファイルをプログラムで書き出す方法である。高品質なページ組版を行な
う DTP ソフト、あるいは、Unix の上で動作する DTP ソフトは PostScript ファイルを直
接書き出すものが多いようだ。それに対して、マイクロソフト Windows では、アプリ
ケーションの印刷機能から使える標準的な PostScript プリンタ・ドライバが同梱されて
いた。
また、多くのプリンタメーカが各社専用の PostScript プリンタ・ドライバを提供して
いる。また、Acrobat を含めて、アドビの製品には同社製の PostScript プリンタ・ドラ
イバが付いていた。しかし、アドビは PostScript プリンタ・ドライバの新しいバージョ
ンの開発は終了しているのではないかと見られる。アドビのサイドから配布している
PostSctipt プリンタ・ドライバは Window 用が Universal PostScript Windows Driver
V1.0.6 が 最 新 で 2002 年 更 新 （ Adobe Systems. "PostScript Printer Drivers for
Windows."（p. 239））、Macintosh 用は PostScript Printer Driver AdobePS 8.8 が最新
で 2002 年更新（Adobe System. "PostScript Printer Drivers for Macintosh."（p. 239））
となっている。
アプリケーションの印刷メニューは、普通、プリンタで紙に印刷する時に使うものだ
が、プリンタに出力する代わりに、PostScript プリンタ・ドライバでファイルに出力す
ると PostScript ファイルができる。
具体的には、図 2 PostScript ファイルを出力（p. 19）で示すように「ファイルへ出
力」にチェックする。
図 2 PostScript ファイルを出力
なお、Windows の「印刷ダイヤログ」で表示されるプリンタの名前は、分かりやす
い名前をつけることができるので「PostScript プリンタ・ドライバ」と表示されないこ
とがあるかもしれない。
PostScript をファイルに保存するはもう使えない？
PostScript プリンタ・ドライバで「ファイルに出力」することで PostScript ファ
イルを作成する方式は WindowsXP あたりまでは利用できたが、Windows7 では使
19
えなくなっているようだ。マイクロソフトの Web ページでは「[ファイルへ出力] オ
プションは、コンピューティングの初期の時代からの残存物」とされている（マイ
クロソフト「ファイルへ出力」（p. 244））。
3.2.2 PostScript を PDF に変換する
アドビの Distiller を使って PostScript ファイルを PDF ファイルに変換する方法は、
図 4 Acrobat Distiller で PDF を作成（p. 8）で紹介した。
3.2.3 仮想 PDF ドライバ
以上の説明は PostScript を出力することを前提としているが、エンドユーザが簡単に
使うだけなら、PostScript について特に意識する必要はない。例えば Acrobat9 では、
アプリケーションの「印刷」メニューで表示される「印刷ダイヤログ」で、プリンタ名
Adobe PDF を選んで「OK」ボタンを押せば、PDF ができる。Windows アプリケーシ
ョンの印刷メニューは本来プリンタを動かして紙に印刷するために用意されているもの
である。プリンタを駆動するために Windows に組み込まれた特別なソフトをプリン
タ・ドライバと呼ぶ。この仕組みをつかって PDF を作る方式を仮想 PDF ドライバ方式
と呼ぶことにする。
Acrobat の仮想 PDF ドライバ名
プリンタの名前はメーカが分かりやすく付けるこ
とができるが、Acrobat4 以降の仮想 PDF ドライバの名前の変遷を辿ると表 1 Acrobat
の仮想 PDF ドライバ名（p. 20）のようになっている (以下は Windows 版について）。
表 1 Acrobat の仮想 PDF ドライバ名
バージョン 仮想 PDF ドライバ名 インストール時カスタマイズの既定値
●
20
Acrobat4
Acrobat Distiller
既定値で on
Acrobat4
Acrobat Writer
既定値で on
Acrobat5
Acrobat Distiller
既定値で on
Acrobat5
Acrobat Writer
既定値で off
Acrobat6
Adobe PDF
Acrobat7
Adobe PDF
Acrobat8
未確認
Acrobat9
Adobe PDF
AcrobatX
未確認
Acrobat4 では、PDFWriter と Distiller の 2 種類のプリンタ・ドライバがあり、両
第 3 章 デスクトップで PDF を作成する
方とも既定値でインストールされた。
●
Acrobat5 で、Acrobat Distiller がプリンタ・ドライバの主流になり、Acrobat Writer
は既定値ではインストールされなくなった。
●
Acrobat6 以降では、プリンタ・ドライバは Adobe PDF という名前のものひとつだ
けになった。
最初、アドビは Distiller を PostScript から PDF への変換を行うアプリケーションと
して用意し、Acrobat4、5 ではプリンタ・ドライバの名前にも使っていたが、Acrobat6
以降、Distiller という名前はプリンタの名前ではなくなり、PostScript から PDF への変
換を行うアプリケーションのみとなった。Acrobat6 から PDF を作成するプリンタ・ド
ライバの名前は Adobe PDF になっているが、これは PostScript プリンタ・ドライバと
Distiller を連続で動かすものである。
これを確かめてみる。まず、Word で簡単な文書を作成し「印刷」メニューから Adobe
PDF を選ぶ。Adobe PDF の印刷ダイヤログで、「ファイルに印刷」を選択する。
●
Acrobat6(英語版）、Windows は XP。
図 3 Adobe PDF の印刷ダイヤログで、「ファイルに印刷」をチェック
出力されたファイルをテキスト編集ソフトで開くと、先頭の部分は図 4 Adobe PDF
で作成したファイルの先頭（p. 22）のようになっており、PostScript レベル 3 のファ
イルであることがわかる1）。
つまり、Adobe PDF は、PostScript プリンタ・ドライバと同じ機能をもつことがわ
かり、さらに、このファイルを Distiller で PDF に変換することもできる。また、Adobe
PDF で「ファイルに印刷」にチェックしない（既定値）で実行すると PDF ファイルが
できる。以上のことから、Adobe PDF プリンタを指定すると、ユーザに見えないとこ
1） Windows7（日本語）上で Acrobat9 の Adobe PDF ドライバで同じことを行なうとマイクロソフト
Word2003, PowerPoint2003 ともに印刷ダイヤログとファイル保存先のダイヤログが同じように表示され
るが、そこでプログラムがフリーズしてしまって先に進めない。これは PostScript をファイルに保存するは
もう使えない？（p. 19）で説明したようにマイクロソフトが、サポートをやめてしまったことが原因と見ら
れる。
21
図 4 Adobe PDF で作成したファイルの先頭
ろで PostScript を作り出し、それを Distiller を使って、PostScript から PDF 変換を行
なっている推測できる。ということは、Acrobat Distiller プリンタ・ドライバの後継が
Adobe PDF で、Acrobat PDFWriter はなくなったということなのだろう。
3.2.4 Distiller 互換ソフト
アドビは PostScript インタープリタをいろいろなプリンタメーカに対して提供して
いるが、アドビのライセンス料が高額だったことから、他のソフトウェア開発会社から、
PostScript ファイルの内容を解釈・描画してイメージにできる互換ソフトがいくつか提
供されるようになった。それらの PostScript インタープリタ互換ソフトをベースにし
て PDF 作成ソフトも提供されている。Acrobat Distiller 互換の PDF 作成ソフトという
ことができる。
Ghostscript と PrimoPDF PostScript イ ン タ ー プ リ タ ー 互 換 ソ フ ト で は
Ghostscript が有名である。Ghostscript には無償で入手できるライセンス版と商用の
有償ライセンス版がある。また、Ghostscript には PDF 作成機能も同梱されている。こ
の Ghostscript の無償版を利用して、PostScript から PDF 変換を行なっているのが、無
償の PDF 作成ソフトとして良く紹介される PrimoPDF である。PrimoPDF は、米国の
サーバサイド PDF のメーカ ActivePDF 社が開発し、自社の宣伝を主な目的として作
成・配布していた（Impress Watch「PDF 日本語版」（p. 243））。その後、Nitro が配布
するようになった。
Jaws PDF Creator Global Graphics Software 社は PostScript 互換のインタープ
リターを開発販売している会社である。同社の Jaws PDF Creator は Windows 用のプ
リンタ・ドライバと PostScript から PDF 変換を行なうプログラムを組み合わせたもの
22
第 3 章 デスクトップで PDF を作成する
である（Global Graphics Software Jaws PDF Creator（p. 240））。同社の PDF 変換ソフ
トはジャストシステムから JustSystem PDF Creator として販売されていたことがあ
る。しかし、ジャストシステムは、2013 年初頭の時点では別の PDF 作成ソフトを採用
している。
3.3 PDF 生成ライブラリー
3.3.1 PDF 生成ライブラリーの必要性
「PDF の仕様は公開されているのだから、自分のプログラムの中から直接 PDF ファイ
ルを書くことはできないだろうか？」と考える人がいるだろう。もちろん、PostScipt
を 経 由 し な い で 、 直 接 PDF を 作 る こ と が で き る 。 一 番 原 始 的 な 方 法 は 「 PDF
Reference」を参考にしながら、自前のプログラムで、直接 PDF ファイルを書くことで
あり、スキルのあるプログラマならやればできる。しかし、実際に、自分でゼロから
PDF を書くプログラムを開発しようとすると PDF に関する深い知識が必要であり、さ
らに PDF の仕様は膨大（PDF1.6 の Reference は、本体だけで、1200 ページ強）なの
で、高度な PDF を作ろうとすると、やらなければならないことが多くなり、開発に多大
な工数が必要となる。
こうしたことから、PDF に関することをまとめて任せてしまえる部品の必要性が生ま
れる。一般に、こういうプログラム部品をライブラリーといい図 1 アプリケーションソ
フトから PDF を作る（p. 18）の「PDF 出力ライブラリー」が該当する。
PDFLib
この種のライブラリーで昔から有名なもののひとつが PDFLib である。
PDFLib 社の創業者 Thomas Merz 氏は、PDF に関する著書もいくつかあり、PDF 業界
では有名人だろう。PDFLib は、最初のころはソースプログラムが公開されていたが、
現在ではバイナリのみの配布されていて試用であれば無料、実際に使用するときはライ
センス料金を払う仕組みになっている。なお、PDFLib Lite 版という限定版はソースプ
ログラムも公開されている（PDFlib. “Source Code of PDFlib Lite”（p. 242））。
Antenna House PDF 出力ライブラリー
アンテナハウスは、「PDF 出力ライブラリ
ー」を独自に開発しており、様々な製品に組み込んでいる。また、OEM 製品としてラ
イセンス販売を行なっている（アンテナハウス 「PDF 出力ライブラリー」（p. 244））。
3.3.2 PostScript を使わないメリットとデメリット
「PDF 出力ライブラリー」で上位のプログラムから指示された命令によって PDF を作
23
り出す方法には次のようなメリットがある。
●
PostScript と比べて軽い処理であり、処理速度が速くなる。
●
アプリケーション→PostScript→PDF という 2 段階からアプリケーション→PDF
の 1 段階になり、しくみが単純になる。
●
PostScript に規定されていない機能を、PDF に追加することが簡単になる。PDF
の機能拡張がやりやすい。
逆に、PostScript に依存しないデメリットとしては、次のようなことがある。
●
EPS という高度なグラフィックス・ファイルの読み込みができない。EPS について
は、3.8 いくつかの技術的課題 （p. 38） で触れる。
このように PostScript を使う PDF 作成と PostScript を使わない PDF 作成にはそれ
ぞれ一長一短がある。
3.3.3 PDF 生成ライブラリーの用途
PDF 生成ライブラリーは、企業内の帳票システムなどに組み込んで、ユーザから入力
されたデータ、あるいはデータベースから取り出したデータを使って、サーバサイドで、
即時に PDF を作り出すというシステムを構築するのに使われることが多い。詳しくは、
第 6 章 サーバーサイドで PDF を作る（p. 61）で説明する。
ここでは、DTP から PDF を作りだすという従来の出版・印刷の流れとは別の流れと
して、インターネット・システム、イントラネット・システムの中で PDF を大量に生
産・消費する仕組みが普及してきている、ということを強調しておきたい。そして、こ
の場合、PostScript に依存しない技術の方が適切である。
製造業の製品マニュアル、サービス・マニュアルは、数千～数万ページに昇ることも
多い。こうした大規模なマニュアルなどを出版する際には、XML でコンテンツを制作
し、自動組版により PDF を作成する仕組みが使われる。これについては 4.2 XSL-FO に
よるレイアウト指定（p. 42）を参照。自動組版システムでは高速な PDF 生成処理が必
要であり、PDF 生成ライブラリーを使っている。
3.3.4 DTP ソフトと PDF 生成ライブラリー
1.2 PDF の歴史（p. 6）で説明したとおり、DTP は誕生当初には PostScript ファイル
を作り出していた。しかし、PDF が普及するにつれて、また PDF 出力ライブラリーの
機能が高度になることによって、DTP ソフトは PDF 出力ライブラリーを使って PDF を
生成するようになってきた。PostScript よりも PDF の方が、シンプルなので同じことが
実現できるなら PDF が有利なのである。PostScript 言語の機能強化はすでに終了して
24
第 3 章 デスクトップで PDF を作成する
いる。
3.4 Windows の印刷機能で PDF 作成
3.4.1 GDI 型 PDF プリンタ・ドライバ
PDF を作成するプリンタ・ドライバには、PostScript を経由せず、PDF を直接書き
出す方式を採用しているタイプのものがある。これを PostScript を経由する方式と比
較して、GDI 型 PDF プリンタ・ドライバと呼ぶことにする。GDI というのは、マイク
ロソフト Windows 専用の言葉で、Windows でディスプレイへの描画やプリンタへ出力
する情報を統合的に扱うプログラム・モジュールのことである。Windows の上で動く
アプリケーションは、画面などに絵を描画するときは、GDI に対して命令を発行する。
簡単にいうと GDI 型の PDF プリンタ・ドライバは、この GDI 命令を受け取って PDF の
命令にして出力する仕組みをとっている。
2007 年に発売された Windows Vista では新しいプリント基盤技術である Windows
Presentation Foundation（WPF）が導入された。このため Vista 以降では、GDI 技術
は Windows の最新技術ではなく、過去との互換機能になる。但し、Windows アプリケ
ーションのほとんどは、現在も GDI に依存している。
GDI 型プリンタ・ドライバは次のような特徴をもつ。
●
PostScript を経由するものと比べて比較的シンプルなので高速にできる
●
マイクロソフト Windows の上で動く任意のアプリケーションの印刷機能から使
える
○
●
マイクロソフト Office などのアプリケーションから使うのが便利
マイクロソフト Windows の GDI に依存しており、その弱点を引き継ぎやすい
このような GDI 型のプリンタ・ドライバは、一般ビジネスの用途で、配布・閲覧・資
料保存用の PDF を作るのに適しており、様々なものが販売・配布されている。
「いきなり PDF」 GDI 型 PDF プリンタ・ドライバでは 2004 年春にソースネクスト
が発売した「いきなり PDF」は、それまで 3 万円以上していた Adobe の Acrobat に代
わるものとして、1,980 円という衝撃的な価格の製品として登場した。
「いきなり PDF」
はソースネクストの販売力もあって発売と同時に爆発的に売れた。これは、なんの変哲
もない Windows 用の GDI 型 PDF プリンタ・ドライバをパッケージ化したものだが、次
の点で大きな功績があった。
●
それまで高価な印象があった PDF 作成ソフトを安価で提供し、PDF 普及のはずみ
25
をつけた
●
PDF を印刷業界から一般のビジネスマンにとっても身近なものにした
●
PDF 作成ソフトの市場をアドビシステムズ独占状態から、サードパーティのものを
含め乱戦状態に変えた
振り返ってみれば、なんの変哲もない PDF プリンタ・ドライバが数十万本も売れると
いうのは、PDF を作りたいが Acrobat は高いということによる需要と供給にギャップが
あったということなのだろう。
ドラッグ＆ドロップで PDF を作成
GDI 型 PDF プリンタ・ドライバの種類は多いが、
それらには、ファイルをドラッグ＆ドロップ操作でウィンドウに落とすだけで PDF を作
成する一括 PDF 作成機能が備わっている。アンテナハウスの「瞬簡 PDF 作成」ではプ
ログラムの内部は次のようになっている。
1） ファイルを作成したアプリケーションの種類を判別する。
2） 判別した結果が、例えば、マイクロソフト Word のファイルなら、「瞬簡 PDF 作
成」のプログラムが Word を起動して、そのファイルを読み込ませる。
●
Word に PDF プリンタ・ドライバを使って印刷動作をさせる。
1） PDF の印刷ができたら Word を終了する。
こうしたソフトの内部では PDF プリンタ・ドライバで PDF を作っているが、
「印刷メ
ニューからプリンタ・ドライバを選択する」という初心者に分かり難い操作はなくなっ
ており、あたかも自動的に PDF ができるように見える。
Acrobat Elements の登場と退場 廉価の GDI 型 PDF プリンタ・ドライバが市場を席
捲するのをみてか、アドビも 2005 年 4 月から Acrobat 7.0 Elements を税込み 4,900 円
（アドビストア価格）で出した。ソースネクストの「いきなり PDF」対抗と見られて注
目を集めたが、Acrobat Elements は 2007 年 5 月の事業説明会で次期版を発売しないと
発表された（染原 睦美（p. 245））。
3.4.2 PostScript プリンタ・ドライバと GDI 型 PDF プリンタ・ドライバの相違
PostScript を経由する PDF プリンタ・ドライバと GDI から PDF を作り出す PDF プ
リンタ・ドライバには次のような違いがある。
●
GDI 型のプリンタ・ドライバは Windows の GDI の機能に依存しているので、
WindowsGDI の機能的制約を受ける。
●
PostScript プリンタ・ドライバを使う場合、WindowsGDI をバイパスすることがで
きるので、WindowsGDI の機能制限を回避することができる2）。
26
第 3 章 デスクトップで PDF を作成する
この大きな違いの理由は、PostScript プリンタ・ドライバは、Windows のシステム
の中で別格扱いされており、アプリケーションは、GDI を経由しないで、PostScript プ
リンタ・ドライバに対してデータを送り出すこともできることである。両者の方式では、
マイクロソフト Word などでビジネス文書を作成している間は、大きな違いはないが、
例えば、商業印刷などでプロ向けのグラフィックス・ソフトを使う場合には大きな差が
出ることがある。
例えば、テレビなどでカラーを表示するときは、RGB（Red, Blue, Green 3 原色）で
表現するが、Windows の GDI も、テレビと同じように、カラーを全て RBG として表現
している。そして、GDI を経由する PDF プリンタ・ドライバを使って作成した PDF の
中ではカラーは RBG で表現されることになる。しかし、印刷でのカラー表現は CMYK
方式であり、印刷用のアプリケーション・ソフトではカラーを CMYK 方式で指定できる
ものもあるが、CMYK 方式で表現したカラーは、WindowsGDI では表示できないため、
GDI 型のプリンタ・ドライバで作成した PDF の中では、CMYK カラーを使えない。
また、アプリケーションによっては、PostScript プリンタ・ドライバに出力するとき
と、GDI 型のプリンタ・ドライバに出力するときで、内容を変えてしまうものがある。
例えば、マイクロソフトの Visio は、PostScript プリンタ・ドライバに対しては、ベク
トル・グラフィックス形式でデータを出し、GDI 型のプリンタ・ドライバに対しては、
ラスター・イメージ形式でデータを出す3）。
なお、以上は PDF を作成するプリンタ・ドライバとしての差異であって、PDF 作成
方法一般に該当することではない。すなわち、①アプリケーションから、直接 PDF 作成
ライブラリーを使って（つまりプリンタ・ドライバを経由しないで）PDF を作れば、
RGB 以外のカラー表現方式を使うことも可能である。②また、印刷時に指定したプリン
タ・ドライバが PostScript プリンタ・ドライバかどうかを認識して、PostScript プリン
タ・ドライバなら GDI を迂回して出力するのはアプリケーションの機能である。従っ
て、Adobe PDF ドライバを PostScript プリンタ・ドライバとして認識できないアプリ
ケーションは、PostScript 出力の機能を生かすことはできない。
3.5 仮想 PDF ドライバで対話機能を設定する
実際のプリンタには接続しない仮想的なプリンタ・ドライバで PDF ファイルを作成す
2） Windows Vista、Windows7 のような WPF が主となった OS でも、この機能を継承しているかどうかは
未確認である。
3） Visio のバージョンによる相違がないかどうかの確認を要する
27
る、という仮想 PDF ドライバ方式には制限がある。すなわち、もともと、ワープロソフ
トなどのアプリケーションの印刷機能は、紙に印刷するプリンタにデータを出すことを
想定しているものなので、紙にはないが PDF には用意されている次のような便利な機能
を設定できないのである。
●
しおり。詳細は 5.3 しおり（p. 54）を参照。
●
リンク。詳細は 5.4 リンク（p. 57）を参照。
仮想 PDF ドライバは、アプリケーションが紙に印刷するつもりでプリンタ・ドライバ
に対して出力したデータを取り込んで PDF ファイルを作成する。アプリケーションは、
プリンタに出力するつもりなので、しおり、リンクはデータとして出力されず、PDF フ
ァイルに設定できない。PDF にしおりやリンクを設定するには何らかの工夫が必要で
ある。
3.5.1 PDFMaker
アドビの Acrobat の初期のバージョンには PDFMaker が用意されていた。この
PDFMaker には、
「PDF の便利な機能の中で紙にないためプリンタに印刷する操作では
設定できない機能をどうやって設定するか」
、という課題についてのアドビの回答であろ
う。
PDFMaker でマイクロソフト Office から PDF ファイルを作るとき次のようなことが
できる。
●
Aodbe PDF にしおりを追加
●
(Word) 見出しをしおりに変換
●
(Word) スタイルをしおりに変換
●
Adobe PDF にリンクを追加
●
(Word) 相互参照と目次をリンクに変換
●
(Word) 脚注と文末脚注のリンクを変換
●
タグ付 PDF でアクセシビリティと折り返しを有効にする
●
表示されたコメントを PDF のノート注釈に変換
PDFMaker で具体的にどうやっているか、内部は詳しく分からないが、Office ソフト
と PDF プリンタ・ドライバの間に介在して、Office ソフトに印刷動作させながら、同時
に PDF ファイルに設定したい情報を取り出して、PDF プリンタ・ドライバに渡してい
るのではないかと推測する。この問題点は、アプリケーション依存となってしまうこと
である。実際に PDFMaker が使えるのは、現在、マイクロソフト Office のみであり、
さらに、Acrobat のバージョンにより対応可能な Office のバージョンが違っている4）。
28
第 3 章 デスクトップで PDF を作成する
3.5.2 アンテナハウス PDF Driver のアドインボタン
アドビ以外の PDF プリンタ・ドライバのメーカも同じような解決策に基づくプログラ
ムを製品に同梱しているケースが増えている。アンテナハウスの「瞬簡 PDF 作成」で
も、マイクロソフト Word、Excel、PowerPoint 用のアドインボタン機能を用意してお
り、このアドインボタンを使用することで文書作成元のアプリケーションからボタンを
押すだけで PDF ファイルを作成でき、アドインボタンを使用して PDF 出力する際には
変換元ファイルに含まれているリンクやしおり等が PDF ファイルに反映される。
図 5 アドインボタンで PDF を作成
「Antenna House PDF Driver 5.0」のアドインは任意のアプリケーションに対応とい
うことはできない。2011 年 12 月現在で対応しているアプリケーションは次の通りで
ある。
●
マイクロソフト Word 2000/2002(XP)/2003/2007/2010
●
マイクロソフト Excel 2000/2002(XP)/2003/2007/2010
●
マイクロソフト PowerPoint 2000/2002(XP)/2003/2007/2010
たとえば、Word のアドインでは、次のことが設定できる。
●
変換元の Word ファイルを PDF に添付する
●
Word 文書の見出しやスタイルを PDF の Acrobat のしおりに変換する
●
Word 文書で使用されているハイパーリンクを PDF ファイルのリンクに反映する
●
変換元文書で使用されているコメントをノート注釈として PDF ファイルに反映
する
●
変換元文書で使用されている相互参照や目次をリンクとして PDF ファイルに反映
する
4） 最新の状況を調べる必要がある
29
●
変換元文書で使用されている脚注への参照をリンクとして PDF ファイルに反映
する
図 6 Word アドインの設定
3.6 直接 PDF 作成
マイクロソフト Windows のアプリケーションから PDF を作成する機能は、仮想 PDF
ドライバを使う方式から PDF ライブラリーによる「直接 PDF 作成」方式に変わりつつ
ある。
3.6.1 Office 文書を PDF にする
2010 年 6 月にパッケージ版が発売されたマイクロソフト Office 2010 は、作成した
文書を保存するとき「名前をつけて保存」のダイヤログでファイル形式を PDF にすると
PDF 形式で保存できる。この機能は仮想 PDF ドライバを使うのではなく、Office の内
部で文書を PDF 形式に書き出しているものと見られる。
3.6.2 Office 2007 の PDF 保存を巡る騒動
その前のバージョンであるマイクロソフト Office 2007（Office 12）は 2007 年 1 月
に新 OS Windows Vista と同時に一般に販売開始となった。この Office 12 でも当初は
「名前をつけて保存」で PDF 形式の保存できるようにしようとする計画があった。しか
し、この時点ではアドビとの間の調整がつかず、2007 年 1 月の発売当初は PDF 保存機
能は標準では組み込まれず、PDF 保存はアドオン（ダウンロードで別途配布）の方式で
提供された。結局、2009 年に 4 月に発売された Office 2007 SP2 になって PDF 保存機
能が組み込まることになった。
Office12 の PDF サポート計画
30
Office 12 の PDF 保存を巡るアドビとマイクロソフ
第 3 章 デスクトップで PDF を作成する
トの騒動は既に歴史の一こまとなったが、簡単に振り返っておきたい。Office 12 が
PDF をサポートするという話はマイクロソフトの上級副社長の Steven Sinofsky が、
2005 年 10 月 2 日に MVP の会議で明らかにしたものである（Microsoft News Center,
02 October 2005（p. 241））。
この記事によると、マイクロソフト Office Word, マイクロソフト Office PowerPoint,
マイクロソフト Office Excel, マイクロソフト Office Access, マイクロソフト Office
InfoPath, マイクロソフト Office Publisher, マイクロソフト Office Visio で、「SaveAs
（名前をつけて保存）」で、PDF を出力できるようになる、と発言していた。特徴は次の
ことである。
1） PDF の仕様は 1.4 となっていて少々古い
2） 他のプロダクティビティ製品でも PDF をサポート
3） ハイパーリンクをサポート
4） 読み上げソフトでアクセス可能（タグ付き PDF と見られる）
5）（DTP ソフトでは）CMYK カラーモデルやトンボ出力をサポート
これを見ると PDF 出力機能を何らかの共通の基盤の上に乗せていると見られる。上
の機能は単に PDF プリンタ・ドライバで PDF を出力するだけではできないからである。
2005 年から 2006 年はソフトウェア・ベンダの開発担当者やエバンジェリストがブログ
を開設することが流行っており、マイクロソフト関係者のブログの発言でも PDF 作成の
ことに触れたものが見られた。
Brian Jones: Office XML Formats のブログ
Brian Jones はブログで次のような発
言をしている（Jones. “Follow up on questions around PDF support in Office ‘12’.”
（p. 241））。
1） タグ付き PDF をサポートをサポートするか、との問いに対して、「text flow（テ
キストの流れ）、 ALT text（代替テキスト）と Unicode text をサポートする（但
し、InfoPath、Access、OneNote を除く）。」、「特別なオーサリングを必要としな
い基本的なタグだけをサポートし、自動的にタグを」生成する」と回答している。
2） プリンタ・ドライバを使わずに直接 PDF を書く。その理由は、内部リンク、外部
リンクなどの対話性、透明や諧調の品質向上。
3） PDF の作成のみであり、PDF リーダは出さず、PDF 読み込みもサポートしない。
4） フォントの埋め込みはサポートするが、アウトライン化はサポートしない。
Cyndy Wessling
Cyndy Wesslings 氏は Office12 の PDF サポートに直接携わった
人のようだが、PDF に 1 年を費やしたという発言がある（Wessling（p. 243））。
1） PDF をネイティブに作成する（プリンタ・ドライバではない）
31
2） 設定は標準と最小サイズ設定の 2 種類。但し、Publisher は商業印刷設定がで
きる
3） 内部ハイパーリンク、外部ハイパーリンクを PDF に保存
4） タグとアクセシビリティは、読みの順序、画像と画像化したテキストの代替テキ
スト、非標準グリフの Unicode 表現をサポートする
5） ブックマーク（しおり）を出力する
6） 文書のメタデータを出力する
ブログの発言へのコメントやマイクロソフトの人間の発言を読むと、タグ付き PDF に
よるアクセシビリティへの配慮が大きな課題になっていることがわかる。
3.6.3 OpenOffice の PDF 保存
Open Office.org (以下、OpenOffice) は、マイクロソフト Office に先行して PDF 保
存機能を実装している。Open Office は、ワープロソフト、表計算ソフト、プレゼンテ
ーション・ソフトなどからなる Office スイートであるが、マイクロソフト Office の置き
換えを狙っていて、操作性もマイクロソフト Office にかなり近い。また、マイクロソフ
ト Word、Excel、PowerPoint などのファイルを高い互換性をもって読み込むことがで
きる。OpenOffice は、2003 年にリリースした OpenOffice.org 1.1 から PDF のネイテ
ィブ保存を実現した。マイクロソフト Office12 の PDF ネイティブ保存も OpenOffice
に刺激されるところが大きいだろう。
OpenOffice の変遷
OpenOffice は、オープンソース・ライセンスで提供されている
ことで注目を集めた。つまり、だれでも Web サイトからソースプログラムを含めてダウ
ンロードでき、バイナリを自分で無料で使うほか、再配布することもできたわけだ。
Office スイート製品を開発するのは、相当多額な投資が必要だが、そのような多額の
開発費を掛けたものを無償で提供できた理由は、実際は当初は Sun Microsystems
（Sun）がプロジェクトを運営していたからである。Sun は、1999 年夏、ドイツの
StarDivision という Office ソフトを買収して、2000 年 6 月に StarOffice5.2 を出し
た5）。その後、StarSuite6.0、StarSuite7.0 とバージョン・アップを重ね、2006 年時点
で StarSuite8.0 を出していた。
OpenOffice は、2005 年 10 月から V2.0 が正式リリースされているが、これに Sun
独自の付加価値をつけたものが StarSuite8.0 である。OpenOffice は、Sun の StarSuite
の普及促進策の一環であり、Sun の方は、無償であってもユーザ数が増えていくこと
5） StarOffice は海外での商品名である。日本では、商標権の関係上、StarSuite という名前でリリースさ
れた
32
第 3 章 デスクトップで PDF を作成する
で、マイクロソフト Office のシェアを奪っていくことができると考えていたようだ。マ
イクロソフト Office の独占によって、Office スイート製品分野で競争がなくなり、その
結果、停滞する可能性もあった。実際、マイクロソフト Office は、Office97 以降、大
きな進歩はしていなかった。しかし、Office2003 で XML 保存を取り入れ、Office12 で
はネイティブ・ファイル形式を XML 形式にするなどのファイル形式のオープン化を推
進、さらに Office12 でユーザ・インターフェイスの大幅な刷新などを行なって、
OpenOffice の追撃を必死で突き放そうとしたように見える。このように独占によるマ
イナスの側面をなくしただけでも OpenOffice は大きな貢献をしているといえる。
しかし、Sun の経営難に伴い、2009 年に Sun が Oracle に買収された。この買収をき
っかけに、OpenOffie の主要開発者が The Document Foundation というコミュニティ
を 作 っ て 、 LibreOffice を 開 発 開 始 し た 。 ま た 、 Oracle は 2011 年 6 月 に 、
OpenOffice.org のコードを Apache 財団に寄贈すると発表、2011 年末の時点では、
OpenOffice.org のコードは Apache 財団のプロジェクトに移管する過程にある。
3.6.4 InDesign, Illustrator の PDF 作成
Illustrator や InDesign なども、プリンタ・ドライバを使わず、直接 PDF を出力する
機能をもっており、Illustrator も InDesign も PDF 作成機能は充実している。
Illustrator(CS2) で PDF を作成するのは、「印刷」メニューではなく、「別名で保存」
または「複製を保存」を使う。また、InDesign では「書き出し」メニューでファイルタ
イプを「Adobe PDF」に指定する。それぞれで PDF を作って、プロパティを見ると図
のようになる6）。
図 7 Illustrator で作成した PDF のプロパティ
通常、Acrobat で PDF を作成すると、PDFProducer（作成者）は Distiller になる、
Illustrator と InDesign で作成した PDF ファイルはいずれも作成者が Adobe PDF
Library になるので、これらのアプリケーションはプリンタ・ドライバ方式ではなくて、
PDF を直接作成する方式を取っていると推測できる。Illustrator と InDesign では、
6） 最新の情報を確認して追加したい
33
図 8 InDesign で作成した PDF のプロパティ
PDF を作成する時に、様々な PDF の機能をきめ細かく設定する必要があるためだろう。
例えば、Illustrator では、PDF 作成時に、レイヤー化された PDF、カラーマネジメント
と PDF/X 準拠の PDF 作成、トンボと断ち落としの設定などができるが、これらはプリ
ンタ・ドライバ経由で PDF ファイルを作成する方法では難しい。このように PDF では
様々な機能を使うことができるが、高度な印刷用の PDF ファイルを作ろうとすると、仮
想 PDF ドライバ方式では実現が難しい。
一般に商用印刷などに使う PDF を作るアプリケーションは、①高度な機能をもつ
PDF 作成ライブラリーを使い、②PDF を作成するアプリケーション側から、PDF 作成
ライブラリーをきめ細かく制御して PDF ファイルを作成することが必要である。
3.7 スキャナー・複合機による PDF 作成
3.7.1 書面の電子化
紙に印刷された文書（書面）を電子化するにはドキュメント・スキャナー（以下、ス
キャナー）で読み取るのが一般的である。スキャナーで読み取ったデータは画像の一種
であり、PDF が普及する前は、TIFF や JPEG などの画像形式で保存していた。しかし、
現在は、スキャナーで読み取った結果を PDF で保存するのが主流になっている。高機能
な複合機は無論のこと、最近は低価格のスキャナーにも PDF 保存ソフトがついており、
スキャナーで読み取ったデータをパソコンで受け取って PDF ファイルにして保存でき
る。
仮にスキャナに PDF 化するソフトが添付されていなくても、サード・パーティのソフ
トウエア製品で PDF 保存機能を使うこともできる。例えば、アンテナハウスの「書けま
っせ PDF」や「瞬簡 PDF バインダー」
（2012 年 2 月「瞬簡 PDF 編集」に名称変更）で
はスキャナーと連携してスキャン操作を行い、取り込んだデータを PDF として保存する
ことができる。
スキャナーで PDF を作る方法には、TIFF や JPEG ではできない次のようなメリット
34
第 3 章 デスクトップで PDF を作成する
図 9 「瞬簡 PDF バインダー」のスキャナー連携メニュー
がある。
1） PDF にすることで、無料配布の Adobe Reader で誰でも内容を見ることができ
る。これに対して TIFF には様々な種類があり、あらゆる形式の TIFF を表示するの
は困難で、TIFF の形式によっては表示できない可能性がある
2） PDF 化する際に、画像の上に透明テキストを重ねる形式の「透明テキスト付き
PDF」とすれば PDF を検索可能にできる
3） PDF で保存すると TIFF と比べてファイル形式を小さくできる（リコー「ファイ
ル形式とデータ量について」（p. 244））
3.7.2 Fax 受信の PDF
画像系 PDF のもうひとつの作成方式として、FAX で受信した内容を PDF 保存する方
式がある。PDF が普及する前は、FAX ソフトは FAX 受信内容を TIFF や JPEG などで
保存していたが、最近の FAX 受信ソフトには、受信データを PDF にする機能がついて
いるものがある。例えば、メガソフトの「StarFax」は、受信データを PDF 化して電子
メールに転送できる。インターコム社の「まいとーく FAX Server」は、受信 FAX の
PDF エクスポート機能がついている。インターネット FAX サービス「F@xEm@il サー
ビス」は受信した FAX を PDF にしてメールで受け取ることができる。
アンテナハウスのアメリカ法人でも、しばらくの間、FAX 受信にはインターネット
FAX(eFax.com) を利用したことがある。お客様からアメリカ法人の FAX 番号宛に送ら
れた注文書を PDF 化して、電子メールで受信、その PDF ファイルは日本に転送されて
35
きて、出荷担当に回す際に、インターネット FAX サービスを使っていた。ただし、FAX
原稿は手書きが多いため、判読困難で困ることもあった。FAX の受信データを PDF 化
しても、そのメリットはビューアとして Adobe Reader を使えるということぐらいで、
それ以外には大きなメリットはない。
3.7.3 デジタル複合機
FAX、スキャナ、プリンタ、複写機を統合したデジタル複合機でも PDF の作成につ
いては、既に述べたスキャナーや FAX 受信と同じである。デジタル複合機は、コンピュ
ータと同じように OS（オペレーティング・システム）を搭載していて、いろいろなア
プリケーションを連携して動作させることができる。そして単純な PDF 化だけではな
く、さまざまなセキュリティ設定をした PDF ファイルを作成したり、作成した PDF フ
ァイルを電子メールに添付して送信したり、OCR にかけて透明テキスト付き PDF にし
たり、画像を圧縮したり、アプリケーションを増やしていくことで機能の追加は自由自
在となる。ビジネス用の高級機だけではなく、例えば、ブラザーのデジタル複合機
MyMio DCP-110C は、Amazon で 9,480 円（税込み）なのに、ドキュメント管理ソフ
トまでついていて、色々なフォーマットのファイルから PDF ファイルを作成したり、複
数枚の原稿を 1 つの PDF ファイルにまとめることができる（製品名・価格などは 2005
年 12 月時点のもの）。
パソコンで Office 文書から作成したボーンデジタル PDF の場合、PDF の内部は命令
の集合になる。これに対してスキャナーやデジタル複合機で作成したターンドデジタル
PDF ファイルは基本的にはビットマップの画像データである。透明テキストをつけて
検索可能にしたといっても、このテキストは書式を持っているわけではない。表示した
見かけは似ていても中身はまったく違うものなので、PDF ファイルを再利用したり、検
索したり、印刷したりという観点からは異なることに注意したい。
3.7.4 透明テキスト付き PDF
紙に印刷された書類をスキャンしたイメージから PDF ファイルを作成するとページ
全体が画像になってしまう。コンピュータで文字情報を取り扱うためには、文字をコー
ド化されたデータとして扱わなければならない。しかしスキャンしたページでは文字も
画像の一部になり、文字がコンピュータで扱える文字コードになっていない［文字コー
ドについては 7.2 文字コードとテキスト（p. 66）を参照］
。
この問題を解決するのが透明テキスト付き PDF である。透明テキスト付 PDF とは、
スキャナーで読み取った画像を OCR 機能をつかって文字を認識しコード化した情報
36
第 3 章 デスクトップで PDF を作成する
（テキスト）とした上で、透明属性を持たせてとして画像の上に重ねて PDF を作成した
もの。PDF ファイルの内容である文字情報を利用したいときは、テキストを取り出して
利用できるし、PDF ファイルの中を検索してヒットした文字列の該当部分を反転表示す
ることもできる。
OCR ソフトと透明テキスト付き PDF
透明テキスト付き PDF のアイデアは、恐らく
OCR 関係者が考えたものだろう。こういうアイデアを初めて考え出した人は、なかなか
すごいものだ。一昔前のスキャナソフトは、OCR で文字認識した結果を、マイクロソフ
ト Word、Excel あるいは一太郎に変換できるのが売りだったが、いまの OCR ソフトは
すでにそのレベルは超えて、多くのものは、透明テキスト付き PDF まで作ることができ
る。
ところで OCR で文字認識した結果を、もとの画像に重ねるといっても、実は、完全
には重ならないことがある。次の例は、透明テキスト付き PDF を Acrobat6 で表示し
て、
「消費電力」という文字列を検索したものであるが、検索対象は、透明な文字で、ヒ
ットした文字列に相当する部分が白黒反転されているが、地の「消費電力」という文字
と検索でヒットした文字の位置（白黒反転されている範囲）がずれているのが分かる。
図 10 透明テキストを検索
このように画像と文字がずれてしまうこともある。画像と認識した文字をぴったり重
ねるのは技術的には可能だろうし、完全に重なるような OCR ソフトもあるのだろう。
高圧縮 PDF また、カラー・スキャナーで読みとったカラー画像はファイルサイズが
大きくなるので、文字と画像を分離しした上で別々に高度な圧縮を施した上で重ね合わ
せて PDF を作成する「高圧縮 PDF」という方式も様々なメーカから提供されている。
37
3.8 いくつかの技術的課題
3.8.1 PostScript にない機能は
PDF は PostScript にはない、データの交換・共有機能をもたせるために発明されたも
のであり、PDF には、しおり、注釈、ハイパーリンクなど PostScript にはない機能があ
る。そこで PostScript ファイルから PDF を作成する場合は、当然のことながら、
PostScript フ ァ イ ル の 中 に 存 在 し な い 情 報 は 、 PDF に 入 れ る こ と が で き な い 。
PostScript を経由して PDF を作る場合、
「PDF を作るのに、古い PostScript に依存する
やり方で十分なのだろうか？」、
「PostScript が持っていなくて、PDF で必要とする情報
はどうやって受け渡しているのだろうか？」という疑問がある。
そのためには、原理的に、次のようなことが必要になるはずだ。
●
PostScript ファイルに、PostScript の印刷処理では不要だけれども、PDF 作成では
使う情報を持たせる仕組みが必要
●
前段で PostScript ファイルを準備するとき、予め PDF を作ることを意識してそう
いう情報を出力する
●
PostScript から PDF への変換プログラムは、PDF を作成するとき、そういう PDF
専用の命令をも解読して、PDF に出せる必要がある
これについては、
「PDFMark」という、しおり、注釈、ハイパーリンクなど PDF 独自
の機能を PostScript ファイル内に記述する仕組みが用意されている。但し、アプリケー
ションから PDF を作成するときに、この仕組みを実際に使えるかどうか、となるとまた
話は別で、仕組みは仕様として用意されていても、プログラムがそれを使えるように作
られていないと、ユーザーは実際に使うことはできないのである。
PDFMark に関する仕様は（Adobe Systems. "pdfmark Reference Manual"（p. 239））
を参照すると良い。
3.8.2 EPS（Encapsulated PostScript)
EPS は、PostScript を使わないで PDF を作る技術の、恐らく一番の泣き所である。
EPS という言葉は、グラフィックス・デザイナーや DTP の仕事をしている人なら良く
知っている言葉なので、今更、説明することもないようなものだが、アンテナハウスの
「AH Formatter」の技術サポートへの質問は、EPS 関係の問題が時々寄せられることか
ら、その仕組みを知らない人が意外に多いことが推測できる。
38
第 3 章 デスクトップで PDF を作成する
アドビの Illustrator を初めとしてプロ向けのグラフィックス処理ソフトは、データ交
換用に EPS 形式を使うものが多い。このため、2000 年代初めには EPS 形式は高度なグ
ラフィックスの標準的な形式となっており、商業印刷のソフトには EPS 処理機能が必須
になっていた。グラフィックス標準形式 SVG がそれに変わることが期待されている。
（24.1 SVG（p. 225）を参照）
商業印刷のみではなく、マニュアルなどの技術文書を作成する際にも、グラフィック
ス・データを EPS 形式にして使うことが多い。イラストを別のソフトで作成し、それを
EPS ファイル化して持ってきて、マニュアル本文中に図形として組み込むのだ。
EPS のファイルは、PostScript によるページ記述命令と、そのページのプレビュー・
イメージの両方を１パッケージ化できるようになっている。プレビュー・イメージは
PostScript 命令からページ内容をレンダリングする機能をもたないソフトでも、EPS フ
ァイルの内容を表示できるようにするためのもの。EPS ファイルを作成する時に、オリ
ジナル作成ソフトが用意して埋め込むのが普通である。そこで、Web などで配信する
PDF を作成する際は、グラフィックス部分には EPS ファイルからプレビュー・イメー
ジを取り出して PDF に埋め込めば良い。しかし、プレビュー・イメージでは解像度が低
すぎて、綺麗に印刷できないため、印刷用の PDF を作成するには、EPS ファイルから
プレビュー・イメージを取り出して埋め込むのは不適切である。
また、EPS ファイルにはプレビュー・イメージがないものがあるため、その時は、
EPS ファイルの PostScript 部分からプレビュー・イメージを作り出さねばならない。こ
の場合、EPS の中の PostScript 命令を解読してページをレンダリングするために
PostScript（または互換）インタープリタが必要である。PostScript 非依存にしたつも
りなのに、EPS があると PostScript（または互換）インタープリタが必要になってしま
うのである。
この問題をどうやって回避するか。PostScritp に依存しない PDF 作成ソフトを提供
しているベンダーにとって、EPS 対策は知恵の絞りどころである
EPS（Encapsulated PostScript) 問題の解決策
印刷用 PDF を作る際に、EPS 対策
として考えられることは次の通りである。
1） EPS の中の PostScript 部分を取り出して、それを PDF 中に埋め込んでしまう
2） EPS 画像を予め SVG などのほかのベクトル画像に変換しておく。あるいは、
EPS ではなく、SVG で画像を用意してもらう
3） EPS 画像を別処理で PDF 化して、本文の PDF の中に画像部分の PDF を埋め込む
第一の方法は、PDF の中に、画像部分だけ、PostScript XObjects 機能を使って
PostScript 命令を埋め込んでしまう。しかし、これは、PDF Reference では、非推奨の
39
方法とされている。PDF Reference Version 1.6 の 4.7.1 PostScript XObjects には、
「PDF1.4 以降、アドビの PostScript 言語のイメージ・モデルの特徴を全て包含したの
で、PostScript XObjects の存在理由はなくなった。この機能は将来のバージョンで削
除されることになるだろう」とある（Adobe Systems. “PDF Reference, fifth edition”
（p. 239））。
第二の方法は、理論的には一番適切だろう。SVG もベクトル画像で、PDF と親和性
も高いので、SVG で書かれたグラフィックスを PDF 中にベクトル画像として埋め込む
のは簡単であり、PostScript インタープリタは完全に排除できる。SVG については 24.1
SVG（p. 225）を参照。
第三の方法は、EPS ファイルを別処理でまとめて PDF 化する過程で、Acrobat または
PostScript 互換のインタープリタを使う PDF 作成ソフトが必要である。しかし、一旦
EPS 形式のイラストを PDF 化して用意しておけば、後は、もう、PostScript インター
プリタは不要となる。アンテナハウスの「AH Formatter」を初めとする PDF 作成ソフ
トには、PDF 中に PDF を埋め込むための機能を用意している。マニュアルなどの PDF
をオンデマンドで作成する、という応用の際には、現時点で、一番実用的な方法だろう。
PostScript は既に過去の技術になっているが、EPS があるために PostScript インター
プリタを手放せないという事態はまだ継続している。EPS に変わるものとして SVG に
期待するところが大きい。
40
第 4 章 PDF・Web・電子書籍
4.1 コンテンツとレイアウト
4.1.1 PDF と Web、そして電子書籍
15 世紀にヨハネス・グーテンベルクによる活版印刷の発明以来、これまでの情報流通
と共有において、紙に印刷した出版物がその中核的が地位を占めてきた。1.2 PDF の
歴史（p. 6）で延べた通り PDF は紙と印刷を継承し、徐々に紙に変わる情報流通の柱の
一つとなりつつある。それとほぼ時を同じにして、20 世紀の終わりに Web が発明され
た。そして 21 世紀の初めである現時点では Web が情報流通と共有のもう一つのイン
フラになっている。さらに、2010 年は電子書籍元年と言われるように、今後、電子書
籍が増えるという期待が高まっている。現在の時点では、PDF と Web はその起源の違
いもあり、水と油に近い状態になっていると言っても過言ではない。しかし、PDF と
Web、そして電子書籍で同一の内容を表す場合が多いので、それらの情報流通手段をば
らばらに扱うよりも、統合的に扱うことで情報の生産と流通の効率が高まるだろう。
PDF と Web の相違点
PDF は DTP でレイアウトしたページを印刷するためのペー
ジ記述言語から発展してきたため、PDF で表す情報はページの概念から切り離すことが
できない。現在、高度なページレイアウトを制作する方法としては DTP ソフトによる方
法が全盛となっている。DTP ソフトのページレイアウトの基本は、コンピュータ（パソ
コン）の画面上でページのレイアウトを綺麗に整え、画面で見たままを PDF の上に再現
するという方法である。この方法は WYSIWYG（What You See Is What You Get）と
して知られている。
一方、Web は分散コンピュータ上に配置された情報を次々にナビゲーションするもの
である。ナビゲーションした情報を表示するのは様々な画面であり、解像度も縦横比も
ば ら ば ら な ペ ー ジ の 上 で 情 報 を 見 る こ と に な る 。 Web ペ ー ジ の レ イ ア ウ ト に は
WYSIWYG の概念は適用できない。
コンテンツとレイアウトの分離
しかしながら、PDF も Web も基本技術はコンピュ
ータによる情報処理であり、共通事項も多い。すなわち、テキストをコンピュータで取
り扱うための文字コードに関する技術、画面上に文字を可視化するフォント技術などで
ある。図 1 コンテンツ・レイアウトと成果物（p. 42）で見る通り、PDF も Web もコ
41
ンテンツを表す基本は同じであり、異なっているのはレイアウトを指定する方法なので
ある。
図 1 コンテンツ・レイアウトと成果物
冊子書籍・PDF、電子書籍、Web を統合的に扱うためには、コンテンツとレイアウト
が渾然一体となっている状態を変えて、コンテンツとレイアウトを分離して扱うことが
できるようにする必要がある。このためにはコンテンツを表現する方法とレイアウトを
指定する方法の両方について精通しなければならない。
4.1.2 レイアウト指定の方法
現在、実用的に仕えるレイアウト指定の方法は CSS と XSL-FO の 2 種類がある。次
に、この 2 種類のレイアウト指定方法について概略を説明する。
4.2 XSL-FO によるレイアウト指定
4.2.1 XSL-FO とは
XSL-FO は多数のページを綴じた冊子を作りだすためのレイアウト指定方法である。
W3C（World Wide Web Consortium）において 1998 年に開発開始され、開発の途中
で XSLT あるいは XPath という仕様と分離された上で、XSLT の勧告よりも約 2 年遅れ
て、2001 年 10 月に勧告となった。さらに 2006 年 12 月にバージョン 1.1 に改訂され
42
第 4 章 PDF・Web・電子書籍
た。
XSL-FO 仕様書
英文オリジナルは W3C の Web ページで公開されている。また、
XSL-FO の仕様書は日本語に翻訳され 2010 年 10 月に JIS 規格（JIS X 4179）として公
示された。
●
W3C.
“ Extensible
Stylesheet
Language
(XSL)
Version
1.0,
W3C
(XSL)
Version
1.1,
W3C
Recommendation.” 15 October 2001（p. 243）.
●
W3C.
“ Extensible
Stylesheet
Language
Recommendation.” 05 December 2006（p. 243）
XSL-FO 仕様では組版オブジェクトを定義しており、これをどのように実際のページ
に配置するかを、組版特性（Formatting Property) によって指定する。組版オブジェク
ト毎に、どのような組版特性を指定できるか、その結果をどのようにページの上に配置
するかを決めるレイアウト・モデルをもっている。
4.2.2 XSL-FO におけるページの概念
ページマスター
XSL-FO では単純用紙マスター fo:simple-page-master にページの
大きさや領域を指定する。fo:simple-page-master の内部には本文領域 fo:region-body
を も ち 、 こ こ に 本 文 の 文 章 が 配 置 さ れ る 。 マ ー ジ ン は fo:simple-page-master と
図 2 fo:simple-page-master
43
fo:region-body の両方に属性として指定する。
ページの大きさやマージンを変更するには fo:simple-page-master を別のものに切り
替える。例えば左右ページのマージンを対称にするには、右ページ用のマージンを定義
し た fo:simple-page-master と 左 ペ ー ジ 用 の マ ー ジ ン を 定 義 し た fo:simple-pagemaster を用意し、その出現順序を指定した fo:page-sequence-master を定義してこれ
を新たな用紙マスターとして使用する。用紙マスターを組み合わせてひとつの冊子の中
で使う用紙の組として fo:layout-master-set を規定する。
コンテンツをページに流し込む
XSL-FO のページ生成は用紙マスターで定義した本
文領域にコンテンツを流し込んでいき、コンテンツが一杯になったら新しいページを作
り出す。ぺージの中に配置する内容である組版オブジェクトは fo:page-sequence とし
て用意する。各 fo:page-sequence をどの用紙マスターに流し込むか関連付けておくこ
とで、レイアウトの異なるページを生成できる。
図 3 用紙マスターに流し込むコンテンツを対応つける
流し込むコンテンツのフロー
XSL-FO を受け取って、fo:page-sequence の内容オブ
ジェクトを用紙マスターで規定された本文領域に流し込み、レイアウト済みのページを
作り出す処理を行なうのは「Formatter AH Formatter」のような XSL-FO 組版エンジ
ンの仕事である。本文領域に流し込むのはフロー（fo:flow）で指定する。XSL-FO V1.0
では一つのフローしか指定できなかったが、XSL-FO V1.1 では本文を複数のフローで構
成するマルチプル・フローを定義できるように強化された。
44
第 4 章 PDF・Web・電子書籍
4.2.3 組版オブジェクト
XSL-FO では次のような組版オブジェクトが定義されている。組版オブジェクト毎
に、内容領域、パディング、境界線、マージンをどう決めるかというレイアウトモデル
があり、その大きさや配置を組版特性とその値によって指定する。以下に組版オブジェ
クトを簡単に紹介する。
ブロック領域とインライン領域の組版オブジェクト
XSL-FO では領域を複数の行を
含む矩形であるブロック領域（fo:block）、マイクロソフト Word などでいう枠に相当す
るブロックコンテナ（fo:block-container）とインライン領域に分類している。インラ
イン領域には次のオブジェクトがある。
●
fo:bidi-override
●
fo:character
●
fo:initial-property-set
●
fo:external-graphic
●
fo:instream-foreign-object
●
fo:inline
●
fo:inline-container
●
fo:leader
●
fo:page-number
●
fo:page-number-citation
●
fo:page-number-citation-last
●
fo:folio-prefix
●
fo:folio-suffix
●
fo:scaling-value-citation
表の組版オブジェクト
●
fo:table-and-caption
●
fo:table
●
fo:table-column
●
fo:table-caption
●
fo:table-header
●
fo:table-footer
●
fo:table-body
●
fo:table-row
XSL-FO の表は HTML の表に似ていて次の 9 種類がある。
45
●
fo:table-cell
リスト組版オブジェクト
XSL-FO のリストは、リストのラベル部分（list-item-
label）とリストの本体部分（list-item-body）を別々に指定できるのは特徴である。
●
fo:list-block
●
fo:list-item
●
fo:list-item-body
●
fo:list-item-label
リンク組版オブジェクト
basic-link は、PDF を生成したとき、内部リンク（例：
<basic-link internal-destination="appendix-a"> ） や 外 部 リ ン ク （ 例 ： <basic-link
external-destination="http://www.antenna.co.jp/...">）を設定するのに使用する。
●
fo:basic-link
行外組版オブジェクト 次の 3 つのオブジェクトが定義されている。
●
fo:float
●
fo:footnote
●
fo:footnote-body
その他の組版オブジェクト
change-bar は、改訂された箇所の欄外に印の線を引く機
能である。retrieve-table-marker によって、表が前のページから続いていたり、次のペ
ージに続いていることを示すことができる。
●
fo:wrapper
●
fo:marker
●
fo:retrieve-marker
●
fo:change-bar-begin
●
fo:change-bar-end
●
fo:retrieve-table-marker
索引のための組版オブジェクト
索引オブジェクトにより、書籍などで使う高度な巻
末索引を作成することができる。
●
fo:index-page-number-prefix
●
fo:index-page-number-suffix
●
fo:index-range-begin
●
fo:index-range-end
●
fo:index-key-reference
●
fo:index-page-citation-list
●
fo:index-page-citation-list-separator
46
第 4 章 PDF・Web・電子書籍
●
fo:index-page-citation-range-separator
しおりのための組版オブジェクト
XSL-FO は PDF 作成のために使われるケースが
多いので、PDF のしおりを作成するための機能がある。
●
fo:bookmark-tree
●
fo:bookmark
●
fo:bookmark-title
4.2.4 組版特性（Formatting Property)
組版の対象となる FO に対して、どのようにレイアウトするかを指定するのが組版特
性である。それぞれの組版オブジェクトに対して適用できる組版特性が決まっている。
例えば、fo:block という段落を囲む領域については、背景の色、四辺の境界線の種類・
色・太さ、インデントやマージン、前後のブロックとの空き量、フォントファミリー、
フォントサイズなど、様々な特性を指定することができる。
fo:block-container についても同じように背景、境界、マージンなどの特性を指定で
きるが、fo:block-container には直接テキストを含むことができないので、フォント関
連のようなテキストに対する特性は指定ない。fo:block-conatiner の中に fo:block を配
置して、fo:block にテキストを含める。一方、fo:block-container には、referenceorientation 特性を指定して、周囲に対して回転させることができ、writing-mode 特性
を使って縦書きも指定できる。block-progression-dimension (または height) 特性で
高さを指定したり、inline-progression-dimension (または width) 特性で幅を指定でき
る。
空き量 (space）の指定は、スペース指定子という仕組みで指定する。スペース指定子
は、最小値，最適値及び最大値の 3 つの値を同時に指定することで、組版ソフトが、ペ
ージ内に入る行数などの調整を行なうことを許す。さらに前後のスペースをページの先
頭や最後に来たときは無視するかしないかなどの条件付けをしたり、前後の空き量との
優先順位も指定できる仕組みになっている。
行内レベルのオブジェクトや表のセル、箇条書きの項目を行の上、下、各種のベース
ラインの位置などに対してどのように配置するかをきめ細かく指定するための領域配置
特性が定義されている。このように組版特性とその値はきめ細かい設定ができるので高
品質な印刷用のページレイアウト指定が可能である。
47
4.3 CSS によるレイアウト指定
4.3.1 CSS によるコンテンツとレイアウトの分離
Web ページは、HTML という言語によって表現される。HTML は、分散したコンピ
ュータに存在する情報をナビゲートするために開発されたもので、当初はテキストで表
示されていたが、ブラウザの登場で Web ページの見栄え・レイアウトが重要になってき
た。この結果、HTML の記述内容にレイアウトの要素・属性が入り込み、Web ページの
表現がコンテンツとレイアウトが混然一体としたものになってしまった。コンテンツと
レイアウトが混然一体となっていると、Web ページを PC の画面のような特定の媒体に
表示する時は良いが、それ以外の媒体に表示するのは不向きになる。セマンティック（意
味・文脈）を重視するマークアップを行なううえでもレイアウトが混在しない方が単純
明快になる。こうしたことから、現在の Web ページの記述では、コンテンツとレイアウ
トを分離する方向に向かっている。HTML ではコンテンツだけを記述し、レイアウトは
CSS（Cascading Style Sheets）によって指定する。
4.3.2 CSS による Web の表示と印刷の統合
Web ページは多くの場合、画面上に短時間だけ表示されるだけである。しかし、中に
は、じっくり読みたい情報を提供しているものがあり、こうした Web ページは、PDF
にして読書端末で閲読したり、紙に印刷することが望まれる。こうした Web の制作者は
画面表示だけではなく、印刷を意識しなければならない。CSS では、CSS のメディア特
有のスタイルシート機能を使うことで、一つの HTML に画面と印刷のレイアウトを指定
することができる。
印刷/PDF 用 CSS の作成で注意すべき点
●
印刷は用紙サイズがあり、用紙寸法は絶対寸法指定である。そしてその用紙サイズ
に最適なページデザインが必要を行なう。これに対してブラウザで表示画面の解像
度・サイズなどがばらばらなので絶対寸法指定は望ましくない。
●
行の折り返し、段組などの段の折り返しは、印刷では 1 ページの寸法の中で折り返
す。ブラウザでは表示ウインドウの中で段の折り返しをしないと見ずらい。
●
メニューなどのナビゲーション、検索ボックスなどは印刷用では削除する。
●
フォントのサイズ。画面ではポイント指定は良くないと言われるが、印刷ではポイ
48
第 4 章 PDF・Web・電子書籍
ント指定が適切である。
●
マージンのとり方は画面か印刷かで異なる。
●
背景色や背景のイメージの扱い。画面には背景を表示し、印刷では背景を出さない。
●
リンク（絶対リンク、相対リンク）。ブラウザの表示では URL を表示する必要はな
いが、印刷では URL を明示的に印刷したり、リンクのアンダーラインを削除する必
要がある。
●
マストヘッド（Web サイトの各ページの上部に表示されるロゴや共通要素）の扱い
CSS におけるページ概念
CSS2 では巻物のような表示媒体と、紙などのページの概
念をもつ媒体のふたつの種類の媒体の概念が導入されている。このうちページ媒体につ
いては@page ルールを使って定義する。CSS2.1 では@page ルールには size プロパテ
ィがないため、ページの大きさを指定することができない。現時点では、ブラウザの
@page サポートは弱く、PDF や専門の印刷のような高品質な印刷用ページのレイアウ
ト指定はできない。
CSS3 ではページ媒体向けのレイアウト指定機能が強化されており、CSS2.1 ではでき
ないような印刷レイアウト指定ができるようになる。これにより画面表示と印刷を
CSS で統合した Web ページの制作へ向けて前進している。
CSS3 で印刷レイアウトをしたとき、それを実際に印刷したり PDF 化するには、CSS3
をサポートする組版ソフトウェアが必要であるが、AH Formatter は CSS でレイアウト
指定した HTML 組版して PDF にすることができる。
4.3.3 CSS の発展
CSS は、PDF とほぼ同時期に登場したので PDF と同じ位の歴史を有している。しか
し、PDF と比べると技術の進歩は遅い。CSS2 が 1998 年に W3C 勧告となったのにも
関わらず、ブラウザへの採用が遅れ、再度、CSS2.1 として開発を行なって漸く 2011 年
7 月に勧告となったところである。
現在は CSS3 の開発が精力的に進んでいるが、CSS3 になっても印刷用のレイアウト
指定機能は XSL-FO と比べてかなり低レベルに留まっている。現状では標準的な CSS
でできる冊子形式の出版物はかなり限定されたものに留めざるを得ない。
しかし、ニューズレターのような簡単なページで構成されるものは CSS3 によるレイ
アウト指定で十分であり、こうした簡単な出版物であれば十分な効果を発揮できる (ア
ンテナハウス「日刊経済情報誌（17 種類）の自動組版システム」（p. 244）)。
49
4.4 TeX と PDF
TeX は数学者であるドナルド・クヌース (Donald E. Knuth) により 1978 年にリリー
スされた組版処理ソフトウェアであり、数式を含む専門書の組版などで普及している。
近年は、PDF を作成する重要な手段の一つになっている。
TeX の問題点や代替技術などについて説明したい。
4.5 コンテンツ活用のベストプラクティス
出版物の配布が紙からデジタルへと移行する潮流の中で、配布形式も PDF、Web に
加えて電子書籍と多様化する。多様化した配布形式を自由に使いこなすにはコンテンツ
とレイアウトを分離しておき、想定する媒体に応じて、レイアウトを指定するのが良い。
出力する出版物の形式に応じて次のように使い分けるのが、現状でのベストプラクテ
ィスと言えよう。
図 4 レイアウト指定のないコンテンツから出版物を作る
●
Web ページするときは、コンテンツを HTML 化して、CSS スタイルシートを付加
する。
●
EPUB による出版物を作るときは、コンテンツを XHTML 化して、CSS スタイルシ
ートを付加する。
50
第 4 章 PDF・Web・電子書籍
●
PDF で出版物を作るときは、コンテンツを XSL-FO 経由で PDF に変換する。
残念なことに、現時点では CSS のレイアウト機能はまだ十分強力ではなく、XSL-FO
も DTP と比べるとまだまだ発展途上という状態である。上記のベストプラクティスが
適用できる分野は限られており、任意のコンテンツに適用できるとはいえない。それで
もコンテンツによっては大きな効果を発揮できるので適用分野を十分に検討して進める
と良いだろう。
51
第 5 章 PDF のナビゲーション機能
5.1 ナビゲーション機能とは
PDF は紙を模倣したものである。ページは一枚の紙の上に印刷され、多数のページを
一束に製本すると冊子・書籍となる。冊子や書籍は手にもってぱらぱらとめくることで
全体を見渡したり、目次を見てその項の場所を探して、ページ番号で求めるページを開
いたりする。また、関連する情報は見出し・ページ番号によって探す機能がある。
書籍には独自の閲読とナビゲーション支援のための機能が用意されてきた。目次、索
引をはじめ、柱やノンブルなどもその一種である。
一方、PDF は画面の上で紙と同じページを読み進めるものなので紙を読むときとは異
なる方法で読みやすくする仕組みが必要である。ここではナビゲーション機能というこ
とにする。PDF のページをナビゲーションするには次の方法がある。
●
サムネイル
●
しおり
●
リンク
5.2 サ ム ネ イ ル
PDF のページをサムネイルと呼ぶ小さな画像にしてウインドウに一覧表示する。こ
のサムネイルを目的のページを見つけ出す手がかりに使うことで簡単なナビゲーション
を行なうことができる。
サムネイルは冊子の中で目的のページを探し出す目的につかうだけではなく、ページ
の入れ替えや回転などの操作のためのインターフェイスに使われることもある。
53
図 1 サムネイルウインドウを表示
5.3 し
お
り
しおりは一般には書籍の読みかけのページにはさんでおく目印のことであるが、PDF
のしおり（BookMark）は文書のアウトラインを表すものである。PDF ファイルにしお
りが設定してあると、Adobe Reader は次の図のようにしおり専用のサブ・ウィンドウ
図 2 しおり
54
第 5 章 PDF のナビゲーション機能
にアウトライン・ツリーを表示する。そしてアウトラインのある項目をクリックすると、
その項目に設定されたリンク先にジャンプしてメイン・ウインドウにリンク先のページ
を表示する。Adobe Reader 以外の PDF リーダでもほぼ同じである。
5.3.1 しおりの作り方
一般的には、文書の見出しを階層化してアウトラインを作る。しおりの項目に設定す
るジャンプ先は、表示している PDF ファイル内でも外部でも構わない。書籍、操作説明
書、仕様書などページ数の多い PDF ファイルを作成する場合、しおりを設定すること
で、読み手が常に文書全体の構成を確認することができ、また見出しを辿ってナビゲー
ションし易くなる。
5.3.2 サムネイルとしおり
サムネイルは PDF の中に画像を用意していることもできるが、PDF リーダが PDF 表
示と同時に作り出すこともできる。それに対してしおりは PDF に予め設定しておかな
ければならない。
例えば、現在、有価証券報告書が PDF で公開されているケースが多いが図 1 サムネ
イルウインドウを表示（p. 54）に示したサムネールで目的の情報を探すと、図 3 しおり
のある有価証券報告書（p. 55）を比較するとしおりがある方が目的の情報を探しやすい
図 3 しおりのある有価証券報告書
55
のは明らかだろう。
しかし、しおりは往々にして無視される。例えば、アップルの iBooks リーダ（V1.5）
でも PDF に設定されたしおりはまったく表示されない。
5.3.3 しおりの追加
しおりは、PDF ファイルの中ではドキュメント・アウトラインという情報として管理
されている。
図 4 PDF ファイル構造（しおり関連）
ドキュメント・アウトラインのデータは、PDF の本文ページのデータなど他の情報と
は別に管理されているので、PDF にしおりを、後から追加したり、また、削除したりし
ても PDF の本文ページの表示には影響がない。そこで、PDF 作成後にしおりを付けて
ナビゲーションし易いようにすることができる。
多くの場合、PDF にしおりを付けるかどうかは、PDF を作成するツール依存になって
おり、マイクロソフト Office などの「印刷」メニューから PDF を作成すると、できた
PDF にはしおりが付かないことが多い。しおりの付いてない PDF を作成後してしまっ
てから、しおりを付けるのは煩わしい作業である。こうしたことから、PDF のしおりは
便利な機能に係わらず、普及していないのだろう。
しおりを PDF に付ける作業が必要になるのは、制作会社などで職業的に PDF のコン
テンツを作成する場合だろう。こうした用途には、アンテナハウスの「アウトライナー」
のような PDF にしおりをつけるための専門ツールもある。
56
第 5 章 PDF のナビゲーション機能
5.4 リ
ン
ク
5.4.1 リ ン ク 注 釈
リンクは PDF ファイルの中に参照（ジャンプ）先のアドレスを埋め込んでおき、PDF
ファイルを Adobe Reader などで表示したとき、そのリンクを埋め込んだホットスポッ
トをクリックすることで、埋め込まれたアドレスへジャンプするものである。リンクの
ジャンプ先は、同一の PDF ファイルの中が普通であるが、別の PDF ファイルやその中
の特定の箇所でも良いし、外部の Web ページとすることもできる。PDF では「リンク
注釈」によって PDF 文書内の「宛先」へのハイパーテキストリンク、または「アクショ
ン」を指定する。
宛先
宛先にはページ番号とその表示方法の指定ができ、表示方法は 8 種類が用意さ
れている。例えば Acrobat 8 Pro の「リンクツール」を使用してリンク注釈の表示方法
を編集すると、ダイアログでは「ズーム」として 5 種類の表示方法（「全体表示」、
「100%
表示」、
「幅に合わせる」、
「描画領域の幅に合わせる」、
「ズーム設定維持」）が用意されて
いる。
図 5 宛先の設定
アクション
アクションでは宛先と同じこともできるが、他文書内への宛先や URI 指
定、Sound、Movie 再生といった PDF の仕様に用意されている様々なアクションを指
定することができる。以下のキャプチャは、Acrobat 8 Pro の「リンクツール」に用意
57
図 6 アクションの設定
されているアクション項目である。
5.4.2 PDF ファイル内のリンク
PDF ファイル内リンクの使い方は、②目次から本文へのリンク、②索引から本文への
リンク、③本文内の中で注や参照先へのリンク、などが主なものとなる。
5.4.3 PDF から別文書へのリンク
マイクロソフト Word 文書で他の Word 文書や Word 文書内のブックマークへ飛ぶ
リンクを作成することができる。Office 文書から PDF へ変換する場合、このリンクの扱
いには注意する必要がある。例えば、Antenna House PDF Driver で Word 文書を PDF
にしたとき、このリンクは次のようになる。
1） Word 文書内でその Word 文書と同一フォルダーにある文書（PDF や Word など）
にハイパーリンクしているとき、この Word 文書を PDF Driver のアドインボタン
から PDF 出力すると、その PDF から他の文書へのリンクはフォルダー名を含む絶
58
第 5 章 PDF のナビゲーション機能
対パスになる。このためフォルダー名を変更したり、フォルダーをよそへ移動する
と、リンクをクリックした際にエラーになる。
2） Word 文書が他の Word 文書の内部への外部リンクを持っているとき、その Word
文書を PDF 化してもリンクを正しく反映することができない。これは PDF 内部で
は、別文書（PDF や Word 文書）へのリンクを「リンク注釈」（Link annotation）
で設定するが、
「リンク注釈」は別文書に関連付けされたアプリケーションが開ける
ように「起動アクション」（Launch Action）を利用する。「起動アクション」辞書
内で内部リンクを指定しても PDF リーダがそれを解釈できないためである。
別文書への内部リンクを実現するには、これらの解釈が可能な PDF リーダが必要とな
る。あるいは、別の対応方法として、リンク先の文書も PDF 化した上でその PDF に対
して明示的な宛先、或いは名前付き宛先でリンク先を指定するというような方法をとる
必要がある。
このように PDF のリンクは必ずしも万全の機能を持っている訳ではない。リンクを
うまく使うには、自動設定で作るだけではなくて「PDF 編集ソフト」でリンクの編集を
行なって、きめ細かい調整をする必要があるだろう。
59
第 6 章 サーバーサイドで PDF を作る
6.1 on-the-fly で PDF
6.1.1 on-the-fly は高速応答が必要
企業内システムや Web システムに組み込んで、ユーザから入力されたデータ、あるい
はデータベースから取り出したデータを使って、サーバサイドで、即時に PDF を作り出
すことを on-the-fly で PDF と表現をすることがある。この場合は、PDF 作成機能には高
速なレスポンスが要求される。特に、今では、Web システムで PDF を作成するという
考えがかなりポピュラーになってきているが、一般に Web システムでは、高速な応答性
が要求される。このため、on-the-fly で PDF を作るためには、PDF 生成ライブラリーに
も高速な応答が要求される。この点、PostScript ファイルは大きく、また、それを解読
するにも処理時間がかかるため Web システムで使うにはあまり適切ではない。
61
第 7 章 文字コードと文字の表示形
7.1 言語の表記手段としての文字
世界には、数千種類（一説には 6000 種類）といわれる言語がある。それぞれの言語
は表記方法である文字がなければ記録として残すことができない。表記の手段として文
字をもつということは、その言語の文化を伝え、あるいは遠くの人と意思を伝えていく
ために大変重要なものである。PDF が紙に代わるインフラであるためには、PDF であら
ゆる文字と言語を扱えなければならないことを意味する。そこで、世界にどのような文
字と言語があるかを最初に簡単に概観してみる。
7.1.1 日 本 文 字
私たち日本人は、日常会話では日本語を話し、そして日本語で書かれた新聞、雑誌、
書籍、インターネットのページ、ブログページを書いたり読んだりしているが、このよ
うな日本語の記事は、漢字、ひらがな、かたかな、句読点、括弧類などの記号を使って
表記している。長い年月でみれば、特定の言語の表記に使う文字の種類はかなり変遷す
る。例えば、江戸時代より以前、墨と筆で文字を書いていたときは句読点や括弧類はな
かった。句読点が定着したのは明治三九年、文部大臣官房図書課が『句読法案』を発表
してからとされている。最近の携帯電話には、いろいろな絵文字が登録されているが、
このような絵文字も市民権を得て、皆が使う日がいずれ到来するだろう。中には文字と
認めて良いかどうか、意見が分かれる記号も沢山ある。
7.1.2 韓
国
お隣の韓国・北朝鮮の言語である朝鮮語ではハングル文字による表記が主流である。
ハングル文字は 1443 年に発明された比較的新しい文字で、それ以前は朝鮮語の表記は
漢字によっていた。
7.1.3 中
国
漢字の本家、中国では、漢字簡易化政策の下に 1950 年、1960 年代に漢字を簡体字に
した。このため、漢字には、現在、大陸で使われている簡体字と、台湾を中心に使われ
63
ている繁体字の 2 種類がある（藤井 久美子 p. 64（p. 245）
）。
7.1.4 CJK 統合漢字
コンピュータの世界で、CJK 文字といえば漢字のことを言い、Unicode では「CJK 統
合漢字」という用語もある。漢字は中国で生まれ、中国の文化と共に周辺の国に渡って、
その国の言語を表記するのに使われるようになったのだが、現在は、上述のように日本、
中国、韓国の漢字事情はそれぞれ相当に異なっており、漢字を CJK という表現で到底一
括りにはできないだろう。
7.1.5 ラ テ ン 文 字
英語は 26 種類のアルファベットの大文字と小文字、カンマ、ピリオド、感嘆符、引
用符などの記号類を使って表記する。
フランス語ではアクセントを多用するため、26 種類のアルファベットでは足りず、
Accute accent, Grave accent, Circomflex accent, Diaeresis, Cedilla の 5 種類のアク
セントをつけた 15 文字を追加して使い、括弧記号も英語とは違う。
ドイツ語は、26 種類のアルファベットに加えて、ドイツ語特有のウムラウト付き文字
（A with diaeresis, O with diaeresis, U with diecresis) とエスツェット （Sharp S) を
追加している。
7.1.6 アラビア文字
漢字と同じように、文化圏の広がりと共に周辺地域に普及し、その地域の言語表記に
使われるようになった文字にアラビア文字がある。アラビア文字とアラビア語を英語で
表すといずれも Arabic となるため混同し易く、よく間違えるが、この二つは別の概念で
ある。アラビア語は聖典クルアーンの言語として、世界各地のイスラム教徒に親しまれ
ている。このイスラム教とアラブ文化圏の広がりに伴い、アラビア文字はペルシャ語（イ
ラン・イスラーム共和国）、ウルドゥ語（パキスタン）、現代ウイグル語（中国新疆ウイ
グル自治区）などの表記にも使われている。アラビア文字の場合も、ラテンアルファベ
ット同様に、アラビア語以外では、その言語特有の音を表記するための文字・記号類が
追加されている（「アラビア系文字」（p. 243）、道広 勇司 2005（p. 245））。
7.1.7 キ リ ル 文 字
キリル文字もロシアをはじめスラヴ系の多数の言語の表記に使われている。ソヴィエ
ト連邦の解体にともない、キリル文字で表記していた言語の中でラテン文字表記に変更
64
第 7 章 文字コードと文字の表示形
しているものもあるようだ。このように表記する文字を変更することは世代間のコミュ
ニケーションに深刻な問題をもたらす可能性がある。
7.1.8 タイ文字・ラオス文字・クメール文字
東南アジアのタイ語、ラオス語、カンボジア語は、それぞれ特有の文字（ タイ文字、
ラオス文字、クメール文字）で表記される。日本語のひらながとカタカナは 50 音とい
うくらい、音節と文字が一対一の関係があるが、これに対して、タイ文字、ラオス文字、
カンボジア文字は、発音の音素と文字字形 (グリフ）が一対一に対応せず、並び順も発
音順でないという複雑な関係になっている（峰岸 真琴 「タイ語，ラオス語，カンボジ
ア語（クメール語）の文字処理と組版における課題」（p. 245）、峰岸 真琴 「東南アジ
ア大陸部のインド系文字」（p. 245））。
7.1.9 インド系文字
インドには 850～1700 の言語があるようだが、その中でもヒンディー語は人口の約
4 割で使われているとのこと。ヒンディー語を表記するのに使われているデーヴァナー
ガリー文字は、組み合わせによる表示形の変化（リガチャ）の種類が極めて多いため、
コンピュータ処理の難関である。
7.1.10 政 治 と 言 語
簡体字は中華人民共和国の漢字簡単化政策によって作り出された、というように文字
は政治や経済と密接な関係がある。その際立った例をいくつか紹介する。
まず、イスラエルの国語である現代ヘブライ語は、もともと古代パレスチナ人が使っ
ていた言葉だが、2000 年以上前に誰も使わなくなってしまったもの。現代ヘブライ語
は、いったん誰も使わなくなった言語をイスラエル建国の際に復活したものであり、こ
のヘブライ語を書き表すために使う文字がヘブライ文字である。
ベトナム語は、現在は、ラテンアルファベットに文字種を追加した文字で記述されて
いる。この文字は 19 世紀にフランスの宣教師が考案したものらしい。東南アジアの南
方はインド文化の影響を受けているが、ベトナムとはもともと「越南」の読みなのだそ
うで、ベトナム語は漢字の偏旁を独自に組み合わせて作ったチュノムで表記されていた
が、現在ではチュノムは使われていない。
フィリピンの公用語のひとつであるタガログ語も昔はインド起源の文字を用いていた
らしいが、現在は、ラテンアルファベット表記に変わっている。
政治的理由から比較的短い期間に、文字政策が変わった地域もある。例えば、新疆ウ
65
イグル自治区は、1949 年に人民政府に帰順して中華人民共和国の一部になった。その
当時は、ソ連と中国の蜜月時代ということもあり、ウイグル語をキリル文字で表記しよ
うとしたそうだが、中ソ緊張の時代になるとともにキリル文字はあっさり解消、次は、
漢字のピンイン法案によりラテン文字表記をしようとした。しかし、その後、1982 年
になって元のアラビア文字に基づく表記にもどった（菅原 純 p. 66（p. 245））。
7.1.11 文字と言語の関係
上に述べた例でも明らかなように文字と言語は 1 対 1 の関係ではないことに注意する
必要がある。言語を表記する手段が文字であるが、一つの言語を書き表す文字は長い歴
史の中で変遷することがある。また、ラテン文字、漢字、アラビア文字のような広く伝
播してさまざまな異なる言語を表記するのに使われる文字がある。
7.2 文字コードとテキスト
電子メール、Web ブラウザなどで文字コードという用語を良く見かける。平易な言い
方をすると、コンピュータで言語を処理する際に文字をデータとして扱うために文字に
番号をつけて取り扱うが、その番号が文字コードである。コンピュータによる情報処理
のために文字コードに関する様々な標準がある。そういう標準化においては文字コード
はもう少し厳密に定義されている。
7.2.1 JIS X 0221 による定義
標準規格の代表的なものである JIS X 0221 は文字（Character）とは、「データの構
成、制御または表現に用いる要素の集合の構成単位」と定義している。文字にはデータ
の表現用のものだけでなく、データを制御するためのものも含むということで、具体的
には改行するためのものや、ワープロなどで桁揃えするためのタブなども文字に含んで
いる。
文字を集めたものを文字集合（Character Set）と言う。そうして、集めた文字にはひ
とつづつ番号をつけ、番号のついた文字を符号化文字（Coded Character)、文字集合と
符号化の規則をあわせて、符号化文字集合（Coded Character Set）と言う。平たく言
うと多数の文字を集めて、整理して番号をつけ、その文字の集まりと番号のつけ方につ
いて標準化していることになる（JIS X 0221 p. 67（p. 243））。
文字集合というのは英語の Character set の訳語とすると数学的な集合と考えている
ように見える。特に、X 0221 の定義では数学的に厳密にやろうと努力している傾向が
66
第 7 章 文字コードと文字の表示形
うかがえる。このように、文字集合が数学的な集合なのか、単に文字を集めた収集
（Collection）なのかについては専門家の間でも議論がある。
7.2.2 テ キ ス ト
テキスト（プレーンテキストと言われることもある）は飾りのない本文文字の文字コ
ードの並びのみで構成されるデータである。テキストは次のような処理の対象になる。
●
全文検索やテキストマイニングの処理対象とする
●
ビューアなどで範囲を指定してコピーして、他のアプリケーションに文字列として
貼り付ける
●
テキスト抽出機能で文字列として取り出すことができる
7.2.3 情報処理のための文字やテキストと言語表記の関係
情報処理のために文字コードで表した文字とテキストの表記のための文字の関係は非
常に複雑である。PDF ファイルにおける文字は言語情報の表記であるとともに検索や
テキストの抽出などの処理対象になるという二面性をもつ。
7.3 Unicode 以前の文字コード
7.3.1 世界各国の文字規格
文字に関する標準規格には、主に各国の機関が定めている国別標準が昔から使われて
きた。一番古くから使われていて、有名なものに ASCII コードがある。ASCII コードは
アルファベットを含む 128 種類の文字を定義している。ASCII コードをベースに国際
標準化したものが ISO 646 であり、これはさらに、主に西欧言語用に文字コードを拡張
して ISO 8859 シリーズとなっている。
（下の表では、Latin Alphabet, Latin/ と表記し
たもの）。日本では JIS の文字コード規格があり、中国、台湾、韓国などでも同様の文字
コード規格が定められている。
表 1 地域別文字規格
言語コ
ード
言語名称
言語名称 (日本語)
使用する文字
の種類
ar
Arabic
アラビア語
Arabic
bg
Bulgarian
ブルガリア語
Cyrillic
地域別文字規格
ASMO 449, Latin/Arabic
Alphabet
Latin/Cyrillic Alphabet
67
zh-CN
zh-TW
Chinese
北京中国語（標準中国 簡体字（漢字） GB2312, GB18030
(Simplified)
語マンダリン）
Chinese
中国語
繁体字（漢字） BIG5
(Traditional)
hr
Croatian
クロアチア語
Latin
Latin Alphabet No.2,10
cs
Czech
チェコ語
Latin
Latin Alphabet No.2
da
Danish
デンマーク語
Latin
Latin Alphabet No.
nl
Dutch
オランダ語
Latin
Latin Alphabet No.1,5,9
en
English
英語
Latin
Latin Alphabet No.1..10
et
Estonian
エストニア語
Latin
Latin Alphabet No.4,6,7,9
fi
Finnish
フィンランド語
Latin
Latin Alphabet No.
1,4,5,6,8,9
4,6,7,9,10
fr
French
フランス語
Latin
Latin Alphabet No.9,10
de
German
ドイツ語
Latin
Latin Alphabet No.1..10（7
除く）
el
Greek
ギリシャ語
Greek
Latin/Greek Alphabet
he
Hebrew
ヘブライ語
Hebrew
Latin/Hebrew Alphabet
hu
Hungarian
ハンガリー語
Latin
Latin Alphabet No.2,10
is
Icelandic
アイスランド語
Latin
Latin Alphabet No.1,6,9
id
Indonesian
インドネシア語
Latin
Latin Characters
it
Italian
イタリア語
Latin
Latin Alphabet No.
1,3,5,8,9,10
ja
Japanese
日本語
Latin、漢字、 JIS X0201, JIS X0208, JIS
かな、カタ
X0212
カナ
kk
Kazakh
カザフ語
Cyrillic
Extended Latin/Cyrillic
Alphabet (Cyrillic Asean)
ko
Korean
韓国語
ハングル、
KS C5601, KS X1001,
漢字
Johab
lv
Latvian
ラトビア語
Latin
Latin Alphabet No.4,7
lt
Lithuanian
リトアニア語
Latin
Latin Alphabet No.4,6,7
no
Norwegian
ノルウェー語
Latin
Latin Alphabet No.1,4..9
fa
Persian (Farsi)
ペルシャ語
Arabic
Extended Latin/Arabic
Alphabet (Arabic
Character 28+ Original 4
Characters)
pl
Polish
ポーランド語
Latin
Latin Alphabet No.2,7,10
pt
Portuguese
ポルトガル語
Latin
Latin Alphabet No.
68
第 7 章 文字コードと文字の表示形
1,3,5,8,9
ro
Romanian
ルーマニア語
Latin
Latin Alphabet No.10
ru
Russian
ロシア語
Cyrillic
koi8-r, Latin/Cyrillic
Alphabet 32 Chars (not
compatible with
Ukrainian)
sr
Serbian
セルビア語
Cyrillic
Latin/Cyrillic Alphabet
(Serbian)
sk
Slovak
スロバキア語
Latin
Latin Alphabet No.2
sl
Slovenian
スロベニア語
Latin
Latin Alphabet No.
2,4,6,10
es
Spanish
スペイン語
Latin
Latin Alphabet No.1,5,8,9
sv
Swedish
スウェーデン語
Latin
Latin Alphabet No.
1,4,5,6,8,9
th
Thai
タイ語
Thai
TIS 620, Latin/Thai
tr
Turkish
トルコ語
Latin
Latin Alphabet No.5
uk
Ukrainian
ウクライナ語
Cyrillic
koi8-u, Latin/Cyrillic
Alphabet
Alphabet 33 Chars
vi
Vietnamese
ベトナム語
Latin
Extended Latin
Characters
言語コードは国際標準化機関 ISO が、ISO 639 規格を定めている。主に 2 文字コード
が使われているが、現在は、より多くの言語を表すことができるように 3 文字コードも
決まってる（小林 龍生ほか（p. 244））。
7.3.2 日本の JIS コード規格
日本では、日本工業規格（JIS： Japanese Industrial Standard）で定めている日本
独自の文字集合規格として、次の４つの規格がある（「日本の文字コード」（p. 245））。
●
JIS X 0201　７ビット及び８ビットの情報交換用符号化文字集合
●
JIS X 0208　７ビット及び８ビットの２バイト情報交換用符号化漢字集合
●
JIS X 0212　情報交換用漢字符号－補助漢字
●
JIS X 0213　７ビット及び８ビットの２バイト情報交換用符号化拡張漢字集合
なお、これとは別に ISO 10646 という国際規格の日本語版として、JIS X 0221 国際
符号化文字集合 (UCS) －第 1 部：体系及び基本多言語面がある。
JIS X 0201 は、ラテンアルファベットや記号類、およびカタカナ文字を定めている。
69
ラテンアルファベットと記号類については ISO 646 をベースに一部の文字を日本特有
にし、さらに独自にカタカナを追加したものである。実用上、大きな問題は、ISO 646
でバックスラッシュを定義していた文字番号を、X 0201 では円記号を定義するように
代えたことである。このため、X 0201 は完全な国内規格であってインターネット時代
には不適切になってしまった。日本語で円マークを書いたつもりでも、海外の人がみた
らバックスラッシュになってしまう。逆にバックスラッシュを入力する方法がない。
JIS X0208 は、漢字類を定める基本的な規格で、4 回の改訂が行なわれた。
●
1978 年に第一次規格　JIS C 6226-1978
●
1983 年の第二次規格　JIS C 6226-1983(1987 年に X 0208 に移行）
●
1990 年の第三次規格　JIS X 0208-1990
●
1997 年の第四次規格　JIS X 0208-1997
第二次規格で文字の番号の入れ替え（第一水準、第二水準間）を行い、罫線記号や特
殊文字類 71 文字、漢字 4 文字の追加を行ったために 1980 年代後半には、旧 JIS、新 JIS
というような言葉が生まれるなど大きな混乱をもたらした。1990 年の第三次規格でさ
らに 2 文字を追加し、合計文字数は 6,879 文字になった。第四次規格では文字の番号や
追加削除は行わず、規定の明確化に努めている。
シフト JIS と Windows-31J JIS X 0201 と JIS X 0208 を同時に使うための工夫と
して、マイクロソフトなどが 1980 年代に考案したのがシフト JIS コードである。JIS X
0208-1997 ではじめて、シフト JIS コードが JIS 規格（付属書）に盛り込まれた。シフ
ト JIS 系の文字コードは広く普及したが X0201 の円記号・バックスラッシュ問題を抱え
ており、大きな混乱を招いている。
なお、マイクロソフトのアプリケーションが出力するシフト JIS は、丸囲数字など
NEC 拡張文字や IBM 拡張漢字など JIS X 0208 にない文字を追加しており、JIS 規格で
定めているシフト JIS コードとは異なる。マイクロソフトのアプリケーションが出力す
るシフト JIS コードの正式名は、Windows-31J である。
全角文字と半角文字について
JIS X 0201 で実際に使う文字はすべて X 0208 に収
容されているため、文字の種類だけを考えるのであれば重複している。慣例的に X
0201 の文字は半角文字、X 0208 の文字は全角文字などとも呼ばれるので、シフト JIS
コードでは、ラテンアルファベットや数字記号類、およびカタカナ（ANK 文字）には、
同一文字に半角文字と全角文字があることになる。たとえば、IME で文字を入力すると
き全角・半角の選択メニューが表示される。
このメニューで半角文字を選ぶと X 0201 の文字コードが入力され、全角文字を選ぶ
と、X 0208 の文字が入力される。全角と半角は日本語の表記で大きな混乱の元となっ
70
第 7 章 文字コードと文字の表示形
図 1 IME のメニュー
ている。
●
インターネットのアドレスなどは半角文字で入力する
●
海外とのやりとりをする場合、メールの本文、あるいはワープロの文書本文でも、
空白、数字やアルファベット類は半角文字を使うべき。海外のパソコンで文書を開
いてみる可能性がある場合、全角文字を使用すると相手先で文字が化けてしまう可
能性が大きい。
●
特別な事情がある場合を除いて、半角のカタカナは使わずに全角カタカナを使う。
X 0201 でなされた半角カタカナの拡張は、昔、コンピュータで使える資源が少な
かった時代の名残で、将来はなくなるべきものである。
全角、半角という言葉は、文字の種類ではなくて、キャラクタディスプレイで文字を
表示したり、あるいはドットマトリックス・プリンタに文字を印刷するときの幅に由来
している。現在のような複数のアウトライン・フォントを自由に使って文章を書く使う
時代にはそぐわないが、代替するわかりやすい表現もなく、慣例的に使われているのが
実情である。
日本語の縦組み書籍では、NHK、OECD のような頭文字を垂直に立てる一方、英語
などの単語は横に寝かせる。この使い分けは、シフト JIS を使うアプリケーションでは、
前者を全角文字で、後者を半角文字で表すという方法を取っている。しかし、Unicode
と OpenType により、このような方法は過去のものとなっている。これについては 10.3
フォントによるテキストの表示（p. 126）を参照。
7.3.3 JIS X 0212
JIS X 0208-1997 で決めているのは 6,879 文字数で、そのうち漢字が 6,355 文字であ
る。これでは当然漢字の種類が少なすぎるとして JIS X 0208:1990 と同時に、JIS
X0212 で追加の文字を「補助漢字」として規格化したが普及しなかった。
71
7.3.4 JIS X 0213
JIS X 0213 は 2000 年に制定され 2004 年に改正された。この規格書（2000 年版）
の先頭には、JIS X 0208 の 6,879 文字と同時に運用する 4,344 文字を含め、11,223 文
字を定めたとある。もともと X 0212 も X 0208 の補助漢字として定められたわけで、
この文章を読むと、X 0212 は止めて、X 0213 で、X 0208 の拡張をやり直したという
ことがわかる。
JIS X 0213 では、94×94 の大きさの表を 2 面使って文字の番号表を定義している。
ひとつの面には理論上 94×94=8,836 文字が収容できるが、第 1 面には、JIS X 0208 で
定義されていた文字を同じ位置にそのま収容し、さらに、JIS X 0208 で空きになってい
た位置に新しい文字を追加している。第 2 面は新しい面で、2,436 文字を定義しており、
第 2 面にはだいぶ空きが残っている。実装水準 3 が 8,787 文字ですべて第 1 面に割り
当てられており、実装水準 4 では、第 2 面の 2,436 文字を含む全文字を実装することに
なる。
JIS X 0213 は、2004 年 2 月の改正で 10 文字を追加し、4,354 文字を JIS X 0213 で
新たに追加、X 0208 とあわせて合計 11,233 文字を定めている。
1 文字 4 バイトの取り扱いが必要
JIS X 0213：2004 では、文字の種類が 11,233 文
字と非常に多い。最近のパソコンのアプリケーションは、内部的には Unicode を使うも
のが多いと推定されるが、Unicode で JIS X 0213：2004 の全文字を正しく扱うには、
一部の文字については 1 文字 4 バイトを使って表現しなければならない。JIS X 0213：
2004 を完全に取り扱うには、アプリケーションの内部で 1 文字を 4 バイトで表現する
ように改造するか、2 バイトと 4 バイトを混在させることを可能にするように改造する
か、どちらかの対策が必要となった。
該当する文字は JIS X 0213：2004 の付属書 6 の表で、UCS の番号が２ｘｘｘｘに対
応されているもので、32 項に 302 文字、33 項（2004 年版で追加した文字）に 1 文字
の合計 303 文字である。実際の文字は次で確認できる。
●
「Vista で化ける字，化けない字」（p. 243）の図 6 に示されている 26 文字
●
「Vista で化ける字，化けない字（続報）」（p. 243）の図 9 に示されている 277 文字
Unicode では合成が必要な文字
JIS X 0213 の付属書 4 の 2004 年版には、JIS X
0213 では一文字であるが、Unicode では二つの文字の並びから合成して表示する文字
が 25 文字ある。
これらの文字は Unicode では 1 つのコードポイントが与えられていないため、図 3
72
第 7 章 文字コードと文字の表示形
図 2 Unicode では結合文字で表す文字
結合文字の仕組み（p. 74）のように２つのコードポイントの文字（または記号）を合
成して表さなければならない1）
（8.2 結合文字と文字の合成（p. 104）を参照）。
1） Unicode のバージョンアップで変更になっていないかどうか、確認するべき。
73
図 3 結合文字の仕組み
7.3.5 Windows Vista 用に JIS X 0213 を実装
マイクロソフトは、Windows Vista 用に JIS X 0213：2004 をサポートする新しいフ
ォント「メイリオ」を標準搭載した、また Windows に標準搭載されていた MS 明朝、
MS ゴシックをバージョンアップし X 0213：2004 対応とした。これに伴い次の文字コ
ード関連の課題が浮上した。
1） Vista に標準搭載されるフォントで表せる文字を全部正しく扱おうとすると、1 文
字 4 バイトの取り扱いが必要（p. 72）、Unicode では合成が必要な文字（p. 72）で
指摘した対応策が必要である。
2） メイリオの搭載により字形変更の影響、MS 明朝、MS ゴシックのバージョンアッ
プによる字形変更の影響。これらは以下に解説する。
メイリオの字形変更の影響
メイリオは、Window Vista に標準で搭載される表示用
フォントで他の Windows 環境には提供されない。Windows Vista で作成した文書を、
XP などほかの OS で表示したときに文字化け問題が起きるということが話題になった
が、そのうち大部分（前述の 303 ＋ 25 文字を除くもの）は文字の字形の変更によるも
のである。現在のマルチフォントを使う文書作成ではフォントが違えば、文字の字形デ
ザインは違うということが前提である。マイクロソフト は「Windows の次期バージョ
ン Windows Vista(TM) において日本語フォント環境を一新」（2005 年 7 月 29 日）で、
メイリオは「画面上での可読性を大幅に向上させるまったく新しいデザインのフォント
（フォント名：メイリオ）」と発表している（マイクロソフト 「Windows の次期バージ
ョン Windows Vista …」（p. 244））。Windows Vista で「メイリオ」を指定した文書は、
「メイリオ」以外のシステムフォントをもつ環境では、そのまま表字することができな
い。「メイリオ」を指定した文書を他の環境で同じ字形で表示したいときは PDF にフォ
ントを埋め込むべきである。
MS 明朝、MS ゴシックのバージョンアップ
Windows Vista と同時に MS ゴシックと
MS 明朝のバージョンアップが行なわれた。
1） Windows Vista 用の標準搭載 MS 明朝、MS ゴシックは、バージョン 5.0
74
第 7 章 文字コードと文字の表示形
2） Windows XP 用の標準搭載 MS 明朝、MS ゴシックは、バージョン 2.3
3） 次の２つのフォントパッケージが、無償提供される。
①
Windows XP SP2 以上、Windows Server2003 SP1 以上用の MS 明朝、MS
ゴシックバージョン 5.0
②
Windows Vista、Windows Server Longhorn 向け MS 明朝、MS ゴシック、
バージョン 2.5 各フォント・パッケージの概要は次の通りである。
1） MS 明朝、MS ゴシック バージョン 2.3 —　初版は 1998 年 2）。JIS X 0208　6,355 文字と JIS X 0212 の 5,801 文字　合計 12,156 文字、その他。
2） MS 明朝、MS ゴシック バージョン 2.5 —　バージョン 2.3 に、JIS X0213:2004
の追加文字とバージョン 2.3 のバグを修正したもの。字形の変更は行っていない。
3） MS 明朝、MS ゴシック バージョン 5.0 —　JIS X 0213:2004 の文字セットをサ
ポート。JIS X 0208+X 0212 と重複しない文字を追加。Unicode 4.0 の通貨記号
を追加。さらに字形変更を行った。この中で JIS X 0213:2004 の例示字形に準拠
するように字形を変更した 122 字形については、OpenType の'jp90'タグで旧字形
にアクセス可能とした。既定値では新字形であるが、'jp90'タグで旧字形を取り出
すことが可能。
字形変更を行ったのは 122 字のみでなくもっと広範に行っているようだが、バージョ
ン 5.0 で字形を変更した部分が、以前のバージョンとの非互換なバージョンアップであ
って、印刷・DTP 業界で混乱を引き起こす可能性がある。
'jp90'
タグに
OpenType は、フォントの様々な組版特性をアプリケーションから使用でき
る。これがタグ（正確には feature tag）で、様々な OpenType フォントで共
ついて 通に付けるべきタグのほか、各フォント独自タグを自由に追加できる。マイク
ロソフトは自社開発したフォントに、様々な独自タグを付けていて Uniscribe
などから使っている。こうした、フォントに内蔵する組版特性を利用すれば、
フォントの特性を使った綺麗な組版ができる。
'jp90'タグは OpenType Layout tag registry に登録されて公開されている
（“Tag: 'jp90'”（p. 241） ）。
アプリケーションは'jp90'タグを使うことで、MS 明朝・ゴシックのバージョ
ン 5.0 フォントの中から旧字形を取り出すことができる。但し、このためには、
アプリケーションの改造が必要である。
2） 確認を要する
75
7.3.6 中国の文字規格
中国では文字規格には国家標準の略である「国標」のピンイン表記（Guo Biao) の頭
文 字 を と っ て 、 GB ｘ ｘ と い う 番 号 が 付 い て い る 。 1 バ イ ト の 文 字 集 合 に は 、
GB11383-89(8 ビット)、GB1988-89(7 ビット) がある。また、簡体漢字を含む主要な
標準規格には、GB2312、GBK、GB18030 などがある。
また、ISO 10646 の中国語版である GB13000-1-93 という規格もある。
GB2312-80 は、簡体字 6,763 文字、記号 682 文字の合計 7,445 の文字と記号を定め
ていて、従来、最も良く使われてきた文字集合だが、2005 年時点では GB18030 に置
き換えられつつある。
GBK 文字集合は、GB2312 の拡張版である。GB という頭文字が付いているが、標準
規格ではなく指導的な規範とされており、マイクロソフトの Windows95 中国語版の内
部コードとして実装された。しかし、これも GB18030 への過渡的な存在となりそうで
ある。
2005 年時点で、重要な存在になっているのが GB18030 で、これは、GBK に基づい
て文字を追加して策定した国家標準で、2001 年 01 月 01 日から発売する製品は必ず、
この標準をサポートしなければならないと発表されている。GB18030 には 1 バイト、
2 バイト、4 バイトの 3 種類の長さで文字を収容している、4 バイトの文字コード領域も
あるため 160 万のコードをエンコーディングできるという巨大な収容量がある。ただ
し、GB18030-2000 の仕様書に字形が記載されている文字の数は 28,522 文字で、文字
を追加する計画もあるようだ3）。
参考資料：アンテナハウス「中国の文字規格（メモ）」（p. 244）
中国政府は、この標準で定める文字を実装したフォントを開発して中国国内で販売す
る製品用に売り込んでいる4）。
7.4 Unicode の歴史
7.4.1 Unicode の誕生
これまで説明したのは、主に国別・地域別の文字コードである。地域別に符号化文字
集合が異なるということは、コンピュータ・ソフトウエアの国際化にとっては非常に面
3） 2005 年時点での話なので、その後どうなったかを追跡する必要がある
4） 2005 年時点での話なので、その後どうなったかを追跡する必要がある
76
第 7 章 文字コードと文字の表示形
倒なことになる。コンピュータ・ソフトウエアにとってはテキスト処理は基本的なもの
なのだが、そのテキスト処理を地域毎に変更しなければならなくなってしまうからであ
る。また、インターネットの普及に伴い、地域を超えて、全世界で情報交換を行なわれ
る時代では、地域別に符号化文字集合が異なると、国境を越えたコミュニケーションの
上でも大変不便となる。こうしたことから地球上の全ての文字を網羅するグローバルな
符号化文字集合が必要なことは容易に理解できる。
こ の 要 請 に 応 え て 生 ま れ た の が Unicode で あ る 。 Unicode に つ い て の 情 報 は
Unicode コンソーシアムのホームページで見ることができる。Unicode のアイデアが
生まれ、実際に活動が始まったのは 1980 年代の終わり頃のこと。
Mark Davis によると Unicode の基本設計は、1987 年にゼロックスにいた Joe
Becker と Lee Collins およびアップルにいた Mark Davis が検討した。ゼロックスは、
Star5）の日本版 J-Star を作る過程で、また、Apple は Kanji Talk（Macintosh の日本語
環境）を作る過程で、日本語化の問題に直面した、こんなことから Unicode のアイデア
について意見を交換した（Unicode "Early Years of Unicode."（p. 242））。
誕生時の経過は次のように説明されている。
1） 1988 年 4 月に初めてアップルが Unicode テキストのプロトタイプを出し、
TrueType で Unicode をサポートすることを決めた。また、1988 年 7 月にアップ
ルは Research Libraries Group から中国語、日本語、韓国語 (CJK) の文字データ
ベースを購入し、CJK 漢字の統一化（Unification）をはじめた。これが、当初日本
で悪名高かった Unicode の CJK 統合漢字問題の始まりというわけだ。こうして、
Unicode 制定への活動が始まり、その後、Sun、IBM、マイクロソフトなどの米国
メーカの賛同を得て、次第に大きな動きになった。
2） Unicode1.0 の仕様書は 1991 年に出版され、1992 年には、仕様書の第 2 巻が追
加され Unicode1.0.1 となった。
3） 1987 年から始まった Unicode1.0 の歴史は「Chronology of Unicode Version
1.0」（Unicode Version 1.0 年代記）にある（Unicode（p. 242））。
Unicode はコンピュータ・ソフト分野における 20 世紀最大の偉業のひとつであるが、
こういう歴史が作られる過程をまざまざと見られるのは大変に興味深い。
7.4.2 Unicode と ISO 10646
2005 年末時点では Unicode の仕様は 4.1.0 が最新であり、印刷された出版物の最新
5） Xerox の研究所で Star を見た Steve Jobs が Macintosh のアイデアを得たのは有名な話
77
版は 4.0 版の書籍であった（Unicode Consortium（p. 243））。
Unicode は一方で ISO 10646 という文字コード規格になっている。Unicode4.0 の
仕様書の Appendix C に Relationshipt to ISO/IEC 10646（付属 C　ISO/IEC 10646
と の 関 係 ） と い う 項 に は Unicode と ISO 10646 の 関 係 に つ い て 次 の 説 明 が あ る
（Unicode Consortium. Appendix C（p. 243））。
1） ISO/IEC 10646-1: 1993 と Unicode Version 1.1 は、正確に一致する。
2） ISO/IEC 10646-1: 2000 と Unicode Version 3.0 は、正確に一致する。
3） ISO/IEC 10646-2: 2001 で初めて、補助面 (Supplimentary Plane) を規定した。
4） Unicode 3.1 は、ISO/IEC 10646-2: 2001 と同期を取った。
5） Unicode 4.0 は、ISO/IEC 10646: 2003（予定) と一致する。なお、ISO/IEC
10646: 2003 は、10646-1 と 10646-2 を合併したもの。
なお、Unicode コンソーシアムの Web ページには、Unicode and ISO 10646 という
ページもあり、次のような Q&A が掲載されている（Unicode. “Unicode and ISO
10646.”（p. 243））。
Q. じゃあ、この二つは同じものなの？
A. いいえ。
文字コードと符号化方式は同期を取っていますが、Unicode は実装上の適合性を重
視しています。このため、ISO/IEC 10646 で規定していない、拡張した機能文字、
文字データ、アルゴリズム、背景資料などを提供しています。
なお、ISO 10646 を翻訳し、JIS の国内規格との関係について解説を追加したものが
JIS X0221 である。
7.4.3 Unicode 仕様の文字数と割り当て
番号付け
Unicode は文字に番号をつけて収録している。この番号のことをコード
ポイント (Code Point) と言い、番号の範囲をコードスペース (CodeSpace) と言う。コ
ードスペースは 0 から 10FFFF（16 進表記、以下、コードポイントは全て 16 進表記）
で、1,114,112 個のコードポイントを収容可能である。コードスペースは便宜上 64K ず
つのサイズの面に分けており、主な面には次のものがある。
●
基本多言語面（BMP、すなわち Basic Multilingual Plane)：0000～FFFF まで。
ここに通常使う文字の大部分が収容される。
●
第１面、または補助多言語面 (Supplementary Multilingual Plane)：10000～１
FFFF まで。Lenear B(線状文字Ｂ) など歴史的な文字、音楽表記用の文字、数学表
記用の文字 (記号) のような特殊用途の文字用の面。
78
第 7 章 文字コードと文字の表示形
●
第 2 面、または補助表意文字面 (Supplementary Ideographic Plane)：20000～
2FFFF まで。BMP 面に入りきらなかった CJK 文字 (漢字) を収容する。
収録文字数
Unicode の V1 から V5 までの各バージョンで収容されている文字数は
次の通りである。
表 2 Unicode の収録文字数
面
分類
アルファベット・記号
漢字
V1.0
V2.0
V3.0
V4.0
4,748
6,509 10,236 11,649 16,486
20,902 20,902 20,902 20,902 20,902
漢字 (URO 拡張）
BMP
ハングル音節
図形文字 (小計)
アルファベット・記号
補助面
漢字拡張 B
互換補助漢字
図形文字 (小計)
合計
●
22
漢字拡張 A
互換漢字
V5.0
302
302
6,582
6,582
6,582
302
361
1,009
2,350 11,172 11,172 11,172 11,172
28,302 38,885 49,194 50,666
2,465
42,711 42,711
542
45,718
28,302 38,885 49,194 96,384 98,884
Unicode 1.0 から 4.0 の収録文字数については Unicode Consortium.“The Unicode
Standard, Version 4.0. ”（ p. 243 ）（ Appendix D. Versions of the Unicode
Standard, p. 1356）による。
●
Unicode 5.0 の 収 録 文 字 数 に つ い て は Unicode Consortium. “ The Unicode
Standard, Version 5.0.”（p. 243）（D.2 Versions of the Unicode Standard, p.
1101）による。
各文字の字形は、The Unicode Character Code Charts By Script で見ることができ
る。たとえば Linear B というのは考古学上の有名な文字だが、Unicode のコードチャ
ートに Unicode. “Linear B Syllabary”（p. 242））、（Unicode. “Linear B Ideograms”
（p. 243））として掲載されている。
79
7.5 漢字の文字コードと字形
7.5.1 日本における文字に関する用語
コンピュータで情報処理するときのデータはコードで表現された文字（符号化文字）
であるが、人間が目で見るのは画面や紙に描かれた文字（字形）である。同じ文字と言
ってもこの二つの文字はかなり異なるものである。漢字に関しても文字コードと字形に
関しては議論が多い。この詳細に立ち入る前に文字関係の用語を整理しておきたい。
7.5.2 公 式 の 規 定
日本語、特に漢字については、字体、字形という言葉がもっとも一般的である。一般
の社会生活における漢字の使用の目安となるのは「常用漢字表」であるが、平成 22 年
告示の常用漢字表には字体が 38 回、字形が 22 回出現する。字種が 7 回、書体が 2 回出
現する。字体とは「文字の骨組み」であるとし、字体に関する解説が付属している。字
体が文字に関する中核概念であり、字体中心主義と言ってもよい（文化庁 常用漢字表
（p. 245））参考6）。
国語審議会の「表外漢字字体表」は「印刷文字において標準とすべき字体である」印
刷標準字体を定めるものであるが、文字に関する用語についてもう少し詳しい説明をし
ている（国語審議会（p. 244））。
この文書では字体、書体、字形について説明しており、字種、異体字、別字という言
葉も使用している。文書から定義を拾うと次のようになる。
字体
文字の骨組み。ある文字をある文字たらしめている点画の抽象的な構成のありか
た。他の文字との弁別にかかわるものである。文字は抽象的な形態上の概念である
から、これを可視的に示そうとすれば、一定のスタイルをもつ具体的な文字として
出現させる必要がある。
書体
文字の具体化に際して、視覚的な特徴となって現れる一定のスタイルの体系が書体
である。例えば、書体のひとつである、明朝体の場合は、縦画を太くして横画の終
端部にウロコという三角形の装飾を付けたスタイルで統一されている。すなわち、
現実の文字は、例外なく、骨組みとしての字体を具体的に出現させた書体として存
6） 付）第 2 の 3 筆写の楷書字形と印刷文字字形の違いが，字体の違いに及ぶもの、という意味が分からない
80
第 7 章 文字コードと文字の表示形
在しているものである。書体の例としては、明朝体、ゴシック体、正楷書体、教科
書体など。
字形
印刷文字、手書き文字を問わず、目に見える文字の形そのものを総称していう場合
に用いる。
異体字
地名・人名など固有名詞を表すのに使う、常用漢字の字体とは別の字体のことを指
しているようだ。
別字
異体字で使い分け意識があるものを、特に別字と言う。
字種
字種についてはあまり整理されておらず、文字の種類を表すという程度の意味で使
っているようだ。
字体の違いとデザインの違い 「表外漢字字体表」では、字体の違いとデザインの違い
については、
「デザイン差とは、活字設計上の表現の差」として、文脈上、デザイン差と
対比させる形で字体の違いという言葉を使っているので、デザイン差の範囲での字形の
相違は同じ字体と見なし、デザイン差に収まらないものは別の字体と考えていることに
なる。そして、デザイン差について具体的な分類と例をあげている（国語審議会 三.参
考（p. 244））。
「デザイン差があてはまっても字種を分ける場合は、デザイン差には該当しない。」と
いう表現もあり、デザイン差は字種の同じものの範囲で意味をもつとしている。
●
「しんにゅう／しめすへん／しょくへん」は、(a)
を用いるものと、(b)
を用いるものがある。これらを「3 部首許容」とし、印刷字体では標
準は (a) だが、(b) を使っても良いとする。特に「3 部首許容」と言う表現を使って
いるのは、これらはデザイン差でなく、別の字体だが、標準として許すことのようだ。
●
「くさかんむり」については、明朝体では 3 画を標準とする。しかし、明朝体以外で
は 4 画も制限しないとして、書体によって、デザイン差の許容範囲が違う。
俗字と正字
JIS 規 格
漢字関係の用語では他に俗字と正字という言葉も使われる。
JIS X 0213 の 用 語 定 義 は 次 の よ う に な っ て い る （ JIS X 0213 p.3
（p. 243））
字体
図形文字の図形表現としての形状についての抽象的概念
81
字形
字体を、手書き、印字、画面表示などによって実際に図形として表現したもの
JIS X 0213 規格（JIS 規格）の用語定義は文字を視覚的に表記することを想定し、視
覚的表記には文字を表す図形を使うということを想定している。Unicode ではコード
ポイントに相当するのが、JIS 規格の面区点位置である。JIS 規格 (漢字部分) は、コード
ポイントに漢字の字体を一つづつ割り当てる。この時、字体は抽象的なものなので、割
り当て表は、具体的な例として例示字体を示し、字書の音訓、用例などを添えて定めて
いる。例示字体で示されている図形はあくまで例であり、JIS 規格では字形については
規定していないと明記されている。なお、Unicode の用語では、抽象的形状（abstract
shape）という言葉が使われているが、これが JIS 規格の用語では字体に相当する。
JIS X 0213 は、コードポイントとそこに対応付けられる抽象的概念としての字体を定
めており、ひとつのコードポイントには複数の字体が割り当てられていて、それを包摂
（Unification）という。「6.6.2　この規格は、字体の図形的実現としての字形について
は規定しない」とあるように字形を定めているわけではない。
図 4 コードポイント・字体・字形
包摂の基準にはいろいろあり、たとえば「表外漢字字体表」で、３部首許容とした「し
んにゅう、しめすへん、しょくへん」は、JIS　X0213 では、包摂される部分字体とさ
れている。つまり、JIS X 0213 では、しんにゅう、しめすへん、しょくへんは同一のコ
82
第 7 章 文字コードと文字の表示形
図 5 包摂基準の例
ードポイントに割り当てられることになる。
7.5.3 書 家 の 考 え
JIS 規格、常用漢字表、表外漢字字体表はいずれも字体という抽象的な形態上の概念
を中核においており、書体はデザイン上のスタイル体系としている。これは、いわば字
体中心主義であると述べた。字体中心主義では、任意の字体に対して、例えば、隷書体
をデザインできるという考え方になりかねない。それに対して漢字の生い立ちから考え
ると書体が先にあるという意見もある。
以下は、第 5 回もじもじカフェ「正字体の正体とは？！」（2007 年 2 月 11 日開催）
における書家（出版デザイナー）の大熊肇氏のお話をまとめたものである。
現代の印刷書体は、明朝体、ゴシック体、教科書体というような書体に分類されるが、
昔からの書体として、正書体、行書体、草書体がある。
正書体
石碑などに彫るかしこまったものにつかう書体。秦の篆書、漢の隷書、唐の楷書を
指す。
行書体
日常の筆記体（通行体）
草書体
省略体。草書の字体は、前漢の時代に発生した。
そして、唐の時代に作成された楷書の字体が正字体というものとなる。書家は、お客
さんから字体を示されて特定の書体で書いてほしいという依頼を受けるのだが、要望に
83
応えることのできない文字が偶にあるのだそうだ。つまり、ある字体を隷書で書いて欲
しい、という依頼があっても、その字体を隷書で書くと、まったくおかしなもの、つま
り、そのような隷書の文字は存在していなかったもの、あるいはまったく格好悪いもの
になってしまうことがあるとのこと。
歴史的には、まず書体がある。つまり、格好よく文字を書く、あるいは、その時代の
政治的な意図で、まず書体ができ上がり、その書体向きの字体が固定化したという考え
方になるのだろうという。
大熊氏の Web には同様のことが整理されている（大熊 肇（p. 244））。
7.6 漢字の大文字セット
7.6.1 大文字セットとは
「文字コードは、できるだけ密な網の目にもとづいて作られるべきだと考える。」とい
う考え方がある（加藤弘一 「２．小文字セットと大文字セット」（p. 244））。こうした
考えにもとづいて作った文字集合を大文字セットという。大文字セットに近い考え方で
集められている文字のデータベースをいくつか紹介する。
今昔文字鏡
今昔文字鏡には、諸橋轍次著『大漢和辞典』に収録されている約 5 万の
見出し漢字を含め、日本・中国・台湾・韓国・ベトナムの漢字 12 万字を収録しており
（2006 年 1 月 12 日時点）、他に、梵字・甲骨文字などまで入っている。
「文字鏡研究会」
の文字収集活動により文字が追加・更新されている。2013 年 4 月時点では約 17 万字を
収録している（「今昔文字鏡」（p. 244））。
GT フォント
GT フォントは東京大学多国語処理研究会が作成しているもので、漢字
が約 67,000 字 TrueType フォントとして作成されている。Windows 上や BTRON を
OS に使っている超漢字も GT フォントを使っている（東京大学多国語処理研究会
（p. 245））。
e-漢字データベース
島根県立大学の e-漢字データベースは次の漢字コードから字形
を検索できる（島根県立大学（p. 245））。
●
大漢和辞典（（株）大修館書店発行）　５０３０５字
●
康煕字典の４９１８８字
●
Unicode の２０９０２字
●
新字源（（株）角川書店発行）　約９９００字
84
第 7 章 文字コードと文字の表示形
7.7 グリフとグリフセット
7.7.1 グ
リ
フ
PDF Reference には次のような説明がある。
「文字は抽象的な記号なのに対して、グリフは文字を特定の形状で可視化するもので
ある。．．．歴史的に、コンピュータによる組版の世界では、この二つは交換可能な用
語として使われてきた。しかし、この領域の進歩によりだんだん意味の違いが明確
になってきた。」（Adobe Systems "PDF Reference, fifth ed." p. 358（p. 239））
このようにグリフは文字を図形としてみたときの単位であり、字体と字形の区別をす
るならば字形に近いものである。
7.7.2 Adobe-Japan1 グリフセット
漢字を図形としてみて集めた「大文字セット」を前に紹介したが、アドビは CJK 文字
についてグリフセットを規定している。グリフセットは一種の「大文字セット」である。
日本の文字については、Adobe-Japan1 というグリフセットがある。これは 0 から 6
までの版があり、版数が大きくなるに従い、新しいグリフが追加されている。最新の
Adobe-Japan1-6 に は 、 合 計 23,058 種 類 の グ リ フ を 集 め て い る （ Adobe Systems
"Adobe-Japan1-6 Character Collections for CID Keyed Fonts."（p. 239））。
表 3 Adobe-Japan1 各版に追加されたグリフの概要
領域
セクション 3
CID 範囲
0～8283
Adobe-Japan1 のセット
Adobe-Japan1-0
説明
JIS X 0208 1978 と 1983、
JIS X 0201-1997、アップル、
富士通、NEC の文字セット。
セクション 4
8284～8358
セクション 3～4 で Adobe- マッキントッシュの漢字
Japan1-1 になる
Talk7.1 用文字、JIS
X0208-1990、富士通と NEC
が追加したグリフなど。
セクション 5
8359-8719
セクション 6
8720～9353
セクション 3～5 で Adobe- Windows3.1J 用のグリフを追
Japan1-2 になる
Japan1-3 になる
セクション 7
9354～15443
加。
セクション 3～6 で Adobe- 半角とプロポーショナルグリ
フの回転済のもの。
セクション 3～7 で Adobe- 専門的、商業印刷に使うグリフ
85
Japan1-4 になる
セクション 8
15444～20316
を追加
セクション 3～8 で Adobe- JIS X 0213:2004 標準を完全
Japan1-5 になる
にサポートするためのグリフ
を追加
セクション 9
20317～23057
セクション 3～9 で Adobe- JIS X 0212-1990、共同通信の
Japan1-6 になる
U-PRESS 文字集合をサポート
するためのグリフを追加
Adobe-Japan1 は、例えば、セクション 3 に 90 度回転済の半角文字のグリフが収容
されていたり、セクション 4 にも回転済みのグリフが収容されている。これらは
OpenType フォントにおける縦書用のグリフを提供するものである。また、セクション
7 には商業印刷用の漢字と異形字（kanji variants）が 2,124 個収容されている（同 p.
96）。
これらの回転済みのグリフはもちろんのこと、漢字の異形字には JIS や Unicode で規
定されていないものを含んでおり、これらは OpenType フォントでないと使うことがで
きないとされている。
Adobe-Japan1 は、アドビシステムズが、各種の国内標準規格や、主要なメーカ、ユ
ーザが必要とする文字のグリフを集めてこれに CID という番号をつけてフォントの開
発者向けに提供しているものである。
Adobe-Japan1 の用語 CID
以下に、Adobe Japan1 の仕様書の中から、用語に関連
しそうな部分をピックアップしてみよう。
A character collection contains all gryphs required to make fonts for a
particular language.（ひとつの文字の収集には、ある言語のためのフォントを作る
のに必要なグリフの全てを含んでいる。）
Each CID (Character ID) in a character collection is associated with a class of
chracter shape. （文字の収集における CID は、文字形状の種別に関連付けられて
いる。）
The specific shape of a character from a given class is dependent on the
typeface style, the language, orientation, writing direction of the font,.. (与えら
れた種別の文字の特定の形状は、書体、言語、方向、フォントの記述方向に依存する。）
Character instances (glyphs) for all CIDs are shown in this document, giving a
specific example of the correspondence between CID number and its
character chape class. （この文書には、全ての CID について、文字の例（グリ
フ）が示されていて、CID 番号とその文字形状の種別との対応関係の例を与えてい
86
第 7 章 文字コードと文字の表示形
る。
この上の部分で言っていることを図示すると図のようになる。Adobe-Japan1 の文字
には、CID という番号がついていて、CID には一定の種類の文字の形状が対応してい
る。グリフがその対応関係のひとつの例として示されているということになる。但し、
ここで言っているグリフは日本語でいう字体に相当するものなのか、字形に相当するも
のなのかが、いまひとつ分かりにくい。
図 6 Adobe-Japan1 の CID とグリフの関係
グリフセットの仕様書は、アドビシステムズの Font technical notes のページの
CJK/CID-Keyedfonts として公開されている（ Adobe Systems. "Adobe CMap and
CIDFont Files Specification"（p. 239））。
Adobe-Japan1 では、「CID は文字形状の種別に対して付けられている」と説明され
ているが、図 7 Adobe-Japan1 のグリフ重複（p. 88）のようにまったく同じ字形の文
字に対して別の CID が割り当てられていることがある。これは、歴史的な要因、および
JIS90 規格との互換性を維持するためと説明されている。
また、Adobe-Japan1 では、他にも微妙な字形差のグリフが別の CID で登録されてい
るケースがある。例えば、安岡孝一氏が作成した「Adobe-Japan1 の漢字 (部首画数順)」
には、次の図のようにまったく同じグリフと思われるものが別の CID になっているもの
が頻繁に見つかる（安岡 孝一（p. 245））。
例えば「次」の異形字の CID はそれぞれ、2253、13799、13800 と別であるが、
Unicode は 3 文字とも U+6B21 で、Adobe Reader の検索では 3 文字とも同一の字とし
てヒットする。
さらに半角の文字や括弧類などは、横書き用と縦書き用が別々の CID に登録されてい
87
図 7 Adobe-Japan1 のグリフ重複
図 8 Adobe-Japan1 のグリフ重複２
る。結局、CID、すなわち、文字形状の種別とは何か、意味が大変に分かりにくい。こ
れは、Adobe-Japan1 は、標準規格として、きちんとした考証を経て作成されたもので
はなく、フォントのデザイナの便宜のために字形を収集して適当に番号を付けたものの
ためだろう。
7.7.3 中国・韓国のグリフセット
アドビは Adobe-Japan1 の他に、Adobe-GB1, Adobe-CNS1, Adobe-Korea1 の 3 つ
のグリフセットを公開している。
Adobe-GB1
88
Adobe-GB1 は、中国の簡体字用のグリフセットで、GB 2312-80、GB
第 7 章 文字コードと文字の表示形
図 9 異なる CID と検索
1988-89、GB/T 12345-90、GB 13000.1-93、GB 18030-2000 用のグリフ 29,063 種
類を含んでいる（Adobe Systems. "Adobe-GB1-4 Character Collection for CID-Keyed
Fonts."（p. 239））。
表 4 Adobe-GB1
CID 範囲
領域
追補 0 0～7716 (7,717
Adobe-GB1
Adobe-GB1-0
個)
説明
GB 2312-80、GB1988-89 文字規格用のグリフ。
GB/T 12345-90 で規定する縦書グリフを含む
追補 1 7717～9896
Adobe-GB1-1
GB/T 12345-90 のグリフ。Adobe-GB1-0 に繁
Adobe-GB1-2
GBK と UnicodeV2.1 の 20,902 漢字をサポート
(2,180 個)
体字を追加する。
追補 2 9897～22126
(12,230 個)
追補 3 22127～22352
するためのグリフ
Adobe-GB1-3
半角とプロポーショナルグリフの回転済のもの。
Adobe-GB1-4
大部分は、UnicodeV3.0 の CJK 統合漢字拡張 A
(226 個)
追補 4 22353～29063
(6,711 個)
Adobe-CNS1
用
Adobe-CNS1 は、台湾の繁体字用のグリフセットで、主に Big-5 と
CNS 11643-1992 規格をサポートするためのもの。一部に香港用の文字を含んでいる
89
（ Adobe Systems. "Adobe-CNS1-4 Character Collection for CID-Keyed Fonts."
（p. 239））。
表 5 Adobe-CNS1
CID 範囲
領域
追補 0 0～14098
Adobe-CN1
Adobe-CN1-0
(14,099 個)
説明
Big-5 と CNS 11643-1992 の 1 面、2 面、およ
び Big-5 の ETen 拡張用
追補 1 14099～17407
Adobe-CN1-1
(3,309 個)
香港政庁の漢字文字セット、モノタイプ、ダイ
ナラブ社の文字の一部
追補 2 17408～17600
Adobe-CN1-2
(193 個)
半角とプロポーショナルグリフの回転済のも
の。
追補 3 17601～18845
Adobe-CN1-3
香港の追加文字セット
Adobe-CN1-3
香港の追加文字セット（追加）
(1,245 個)
追補 4 18846～18964
(119 個)
Adobe-Korea1
Adobe-Korea1 は、韓国の KS X 1001:1992 (旧 KS C 5601-1992)、
KS X 1003:1992 (旧 KS C 5636-1993) をサポートするためのグリフセットである
（ Adobe Systems. "Adobe-Korea1-2 Character Collection for CID-Keyed Fonts."
（p. 239））。
表 6 Adobe-Korea1
CID 範囲
領域
Adobe-Korea1
説明
追補 0 0～9332 (9,333 Adobe-Korea1-0 KS X 1001:1992、KS X 1003:1993 とアップル
個)
追補 1 9333～18154
のマッキントッシュ用の拡張
Adobe-Korea1-1 KS X 1001:1992 の Johab と Windows 95 の統
(8,822 個)
合ハングルコード拡張 (UHC)
追補 2 18155～18351 Adobe-Korea1-2 半角とプロポーショナルグリフの回転済のもの。
(197 個)
CMap：CID と文字コードの対応表
Adobe-Japan1、Adobe-GB1 などのグリフセッ
トでは、ひとつひとつのグリフに CID という番号が付いている。CID を採用するフォン
ト・ファイルには、文字を画面表示したり印刷するためのグリフ・データを収容してい
るが、フォント・ファイルに収容されているグリフ・データにアクセスするときは CID
番号を使う。組版ソフトなどのプログラムは、テキストを Unicode、または機種専用の
文字コードを使って表しているので、CID フォントにあるグリフを使ってその文字を表
90
第 7 章 文字コードと文字の表示形
示・印刷するには、文字コードから CID に変換しなければならない。この文字コードと
CID 間の変換を定義するのが CMap である。
図 10 CMap で文字コードから CID へ変換
アドビシステムズは Adobe-Japan1、Adobe-GB1 などのグリフセット毎に多数の
CMap フ ァ イ ル を 提 供 し て い る 。 古 い CMap に は NEC の PC 、 富 士 通 の PC 、
Windows3.1、マッキントッシュなど機種依存文字コードから CID への変換用が沢山あ
るが、最近の CMap は Unicode から CID への変換用が中心になっている。例えば
Adobe-Japan1 用の比較的新しい CMap には次のようなものがある。
表 7 Adobe-Japan1 用 CMap
CMap 名称
内容
UniJIS-UTF8-H
Unicode 3.2 (UTF-8) から CID
UniJIS-UTF8-V
UniJIS-UTF8-H の縦書用
UniJIS-UTF16-H
Unicode 3.2 (UTF-16) から CID
UniJIS-UTF16-V
UniJIS-UTF16-H の縦書用
UniJIS-UTF32-H
Unicode 3.2 (UTF-32) から CID
UniJIS-UTF32-V
UniJIS-UTF32-H の縦書用
UniJISX0213-UTF32-H Unicode 3.2 (UTF-32) から CID Mac OS X Version 10.2 互換
UniJISX0213-UTF32-V UniJISX0213-UTF32-H の縦書用
各 CMap ファイルには、次の理由から横書用 (-H) と縦書用 (-V) の 2 種類がある。
1） 文字によっては横書と縦書で表示・印刷用の字形が異なる
2） グリフセットには、これらの文字に相当するグリフは横書用と縦書用の 2 種類が
あ る （ Adobe Systems. "Adobe-Japan1-6 Character Collections for CID Keyed
Fonts." p. 12, p. 76（p. 239））
91
図 11 Adobe-Japan1 の縦書き用グリフと横書き用グリフ
末尾に-H の付く CMap を使うと、文字コードから横書用グリフの CID 番号に変換す
ることになり、同-V の付く CMap を使うと、縦書用グリフの CID 番号に変換すること
になる。OS やアプリケーションの文字コードを内部コードとすると、CID 番号の付い
たグリフは表示層になる。この内部コードと表示層を分離して、CMap で仲立ちをさせ
ているのである。この仕組みを使ってフォントをプラットフォームの文字コードから独
立にした、ということが CID フォントの意義である。
但し、CMap 方式で入力値として指定できるのは単一コードであり、縦書と横書に対
して CMap を切り替えることで、単一の入力コードからそれぞれ異なるグリフを得る
CID フォント方式は、漢字やかなのような単純な記法の文字を使う日本語や中国語など
しか適用できない。例えばアラビア文字や南インド文字、あるいはラテン文字の結合や
リガチャには別の仕組みが必要である。
7.8 ハ ン グ ル
漢字の場合は、ひとつの字体にひとつの文字コードを与えるのが原則になっているが、
そう単純ではないしくみの文字も世界には沢山ある。お隣の韓国・北朝鮮の言語である
朝鮮語を書くための文字ハングルもそのひとつである（三上 喜貴 pp. 165～174
（p. 245））。
ハングルは、李氏朝鮮の世宗大王が 15 世紀に学者の協力を得て定めた文字とされて
いて、比較的新しいこともあり、科学的な発想による仕組みをもつ文字と言われている。
ハングルでは、頭子音 (初声)、母音 (中声)、終子音 (終声) を表す 3 つの字母 (Jamo) を組
92
第 7 章 文字コードと文字の表示形
み立てて音節文字を作る。頭子音は 19 種類、母音は 21 種類、終子音は 27 種類の形が
ある。但し、頭子音と終子音には同じ形状のものがある。音節文字の数は、理論的には
次の (1) と (2) の合計 11,172 種類である。
1） 頭子音と母音で組み立てる文字：19×21=399 種類
2） 頭子音、母音、終子音の 3 つを組み立てる文字：19×21×27=10,773 種類
ハングル文字の符号化方法には、字母を符号化する方法と、組み立て済の文字を符号
化する方法の 2 種類がある。韓国の国内文字規格には、この両方の方法に基づくものが
あり、それぞれ、かなり頻繁に改訂されたため、大変分かりにくい。Unicode にも 2 種
類の符号化方式を採用したものが盛り込まれている。Unicode のハングル・ブロックは
次の通りである。
ハングル字母（Jamo）：U+1100～U+11FF
組み立て前の字母を登録している。コードチャートには、頭子音が 90 種類、母音
が 68 種類、終子音が 82 種類ある。ここの字母は、UnicodeV4.0 仕様書の 3.12 節
に組み立てる方法が説明されており、この範囲のハングル文字コードの並びが表れ
た時は、それを表示したり、印刷、PDF 化するときは、その並びを判断して音節文
字に置き換える必要がある。
ハングルの互換字母（Compatibility Jamo) 全角形：U+3130～U+318F
韓国の文字規格 KS X1001:1998 のハングル字母に準拠する全角形 94 種の文字が
定義されている。このブロックの互換字母は組み立てなくても良い。
ハングルの互換字母半角形：U+FFA0～U+FFDF
ここに半角形の互換字母がある。
ハングル音節：U+AC00～U+DA73
韓国の文字規格 KS C 5601-1992 から収録した組み立て済の音節文字が 11,172 個
登録されている。これを Johab 文字セットと言い、ハングル字母の並びから対応つ
けることができる。対応付けのロジックは、Unicode 仕様書 3.12 節にある。また、
プログラムで字母を組み立てて、音節文字の字形を作ることができる。
但し、古ハングル文字には Johab 文字セットにないものもあり、その場合は、ハング
ル字母の並びで表すしかないようだ。この場合は、プログラムで音節文字の字形を作り
出すことになるのだろう。
93
7.9 ラテンアルファベットと結合文字
7.9.1 ラテンアルファベット
ラテンアルファベットは、英語のアルファベット 26 文字の大文字 A～Z、小文字 a～
z である。英語はアルファベット 26 文字で表記できるが、他の言語ではこれに様々な発
音符（diacritical mark ダイアクリティカルマーク）をつけた文字を追加している。
Unicode では、ラテン文字は次のブロックに規定されている。
基本ラテン (Basic latin)：U+0041～U+007A
アルファベット 26 文字と基本的な記号類
ラテン-1 追補 (Latin-1 Suppliment)：U+00C0～U+00FF
ヨーロッパの主要言語で使用するダイアクリティカルマーク付きの文字
ラテン拡張 A (Latin Extended-A)：U+0100～U+017F
さらにその他の欧州言語で使用するラテンアルファベット系の文字
ラテン拡張 B (Latin Extended-B)：U+0180～U+024F
中欧から東欧にかけての言語で使う特別な文字など
ラテン拡張追加 (Latin Extended Additional)：U+1E00～U+1EFF
ダイアクリティカルマーク付きの文字各種、ベトナムの文字など
上で定義されているラテンアルファベットの多くは、基本ラテン文字とダイアクリテ
ィカルマークを結合したものに対してコードポイントを与えているものである。
7.9.2 ダイアクリティカルマークマーク
ダイアクリティカルマークは、単独でもコードポイントを与えられている。
結合ダイアクリティカルマーク (Combining Diacritical Marks)：U+0300～U+036F
結合グレーブアクセント（U+0300)、結合アキュートアクセント (U+0301)、結合
サーカムフレックス (U+0302) などの一般的なものを初め、他の文字の上に乗せる
アルファベットのようなめったに使いそうもないような文字まで 107 種類のマー
クが網羅されている。
結合ダイアクリティカルマーク追補 (Combining Diacritical Marks Supplement)：U
+1DC0～U+1DFF
使用頻度の少ないマークが 4 種類、Unicode 4.1 で追加されている。
ラテン文字の表示・印刷・PDF 作成と言う点で注意しなければならないのは、この結
94
第 7 章 文字コードと文字の表示形
合ダイアクリティカルマークおよびリガチャである。結合ダイアクリティカルマークの
ブロックに収録されているマークは、一般に、結合文字といい、結合文字は先行する基
底文字と結合されるという属性をもつ。そして、Unicode のラテン関係ブロックで結合
済の形でコードポイントを与えられている文字の多くは、基底文字と結合文字の並びで
表すこともできる。例えば、グレイブアクセント付きラテン大文字 A は、ラテン大文字
A と結合グレイブアクセント文字の並びでも表すことができる。
図 12 結合文字の例
従って次の疑問がある。
●
結合済の文字とそれを分解した文字は、同等の扱いになるのかどうか
●
同等とするならば同じ文字を 2 通りの符号化ができるということなのか
●
同等か同等でないかの判断をどうしたら良いか。
7.10 アラビア文字
7.10.1 Unicode におけるアラビア文字コード
Unicode でアラビア文字が定義されているブロックは、アラビア文字（U+0600～U
+06FF)、アラビア文字追補（U+0750～U+076D）、アラビア文字表示形-A (U+FB50
～U+FDFF)、アラビア文字表示形-B (U+FE70～U+FEFF) の 3 ブロックである。アラ
ビア文字はアラビア語以外の表記に使われるが、その際、各言語の表記のために文字が
追加されている。Unicode のアラビア文字ブロックには、拡張アラビア文字（Extended
Arabic Letters）という見出し付きで、ペルシャ語（イラン）、ウルドゥ語（パキスタ
ン）、パシュトゥー語（アフガニスタンほか）、シンディー語（インド）など各種の言語
用に追加された文字が規定されている。
アラビア文字の書法は印刷でも cursive、日本語でいう連綿体（書道で、草書や仮名
の各字が次々に連続して書かれている書体）であり、多くの文字は、単語の中で出現す
る位置によって形 （form） が変わり、単独形、左接形、両接形、右接形の 4 つの形を
もつ。文字を単独形で並べたものと単語の中の文字を接続させたものを図 13 アラビア
95
図 13 アラビア文字の単独形と接続形
文字の単独形と接続形（p. 96）に示す。
Unicode のアラビア文字はコードポイント U+0600～U+06FF に、ISO/IEC 8859-6
(Part 6 Latin/Arabic Alphabet) 規格と同じ順序で文字を並べている。Unicode 独自で
追加した文字もあるが、掲載している文字の形は単独形のみである。
アラビア語の表記では、主にフランス語系統の句読点や括弧類を使用する。括弧類は
ラテンアルファベット用のものを鏡に写した像の形になり、形が大きく違っているもの
は独自のコードポイントが与えられている。アラビア文字ブロックにコードポイントの
ある句読点は次のもので、これ以外の句読点はラテン文字と共用になる。
表 8 アラビア語の句読点
名称
96
コードポイント
Arabic Comma
U+060C
Arabic Date Separator
U+060D
Arabic Semicolon
U+061B
Arabic Question Mark
U+061F
Arabic Percent Sign
U+066A
Arabic Decimal Separator
U+066B
Arabic Thousands Separator
U+066C
形
第 7 章 文字コードと文字の表示形
Arabic Five Pointed Star
U+066D
Arabic Full Stop (ウルドゥ語用)
U+06D4
アラビア文字の数字は 2 種類が定義されている。
表 9 アラビア文字の数字
数字の名称
Arabic Indic
コードポイント U+0660～U+0669
Eastern Arabic-Indic
U+06F0～U+06F9
0
1
2
3
4
5
6
7
8
9
参考資料：AbFares（p. 239）、アンテナハウス「Unicode と XSL によるアラビア語の
組版」（p. 244）、「アラビア系文字」（p. 243）、道広 勇司（p. 245）
97
7.10.2 アラビア文字表示形
Unicode には、アラビア文字表示形のブロックが二つある。
●
表示形 A（Form-A）：U+FB50～U+FDFF
●
表示形 B（Form-B）：U+FE70～U+FEFF
表示形 B
表示形 B にはアラビア文字が 140 種類あり、先頭の U+FE70～U+FE7F
には、１文字（U+FE73) を除いて、Harakat（母音記号など）を基底文字と分離した形
で表示・印刷する形式、および Harakat をカシーダ（Tatwee ｌ：U+0640）の上下に
配置した形式の文字がある。次の U+FE76 から U+FEF4 の区間は、アラビア文字の基
本形（U+0621～U+064A）に対して、単独形、左接形、両接形、右接形を全て登録し
ている。その後ろの U+FEF5 から U+FEFC は、ラームとアリフのリガチャのいろいろ
な形を掲載している。すなわち、この部分は、プログラムによる Cursive 接続とリガチ
ャの処理を施したあとのグリフ（以下では、これを文脈依存のグリフと言う）を登録し
ている。ここの文字は過去の規格との互換用として用意しているとされており、通常は、
適切なグリフをプログラムで選択するべきものである。
カシーダ
カシーダとはアラビア文字の単語を左右に伸ばすときに接合部を引き伸ば
すために挿入する横線である。アラビア語の文章を両端揃え（Justification）するとき
は、単語にカシーダを挿入して単語を横に伸ばす。カシーダは文字と文字の間に挿入す
ることになっているが、どこにいくつのカシーダを挿入するべきかは分かっていない。
Unicode 仕様書にはフォントと可視化ソフトに依存する、とのみ説明されている7）。
図 14 単語にカシーダを挿入してない状態
図 15 単語にカシーダを挿入した状態
表示形 A
表示形 A(U+FB50～U+FDFF) はまさにアラビア文字の符号化の難しさを
象徴している部分である。現在の時点で、このブロックをすべて実装したものはない、
7） 最新の仕様書をチェックする必要がある
98
第 7 章 文字コードと文字の表示形
とされている（Unicode Consortium. “The Unicode Standard, Version 4.0.”p. 204
（p. 243））
●
ペルシャ語、ウルドゥ語、シンディ語などで拡張された文字に対する文脈依存のグ
リフ：U+FB50～U+FBB1
●
中央アジアの言語で拡張された文字に対する文脈依存のグリフ：U+FBD3～U
+FBE9
●
2 文字のリガチャ：U+FBEA～U+FD3D。ラームとアリフの 2 文字が連続した場合
はリガチャが必須になるが、それ以外の 2 文字にもオプションのリガチャを使うこ
とができる。ここではそれらのリガチャのグリフにコードポイントを与えている。
●
3 文字のリガチャ：U+FD50～U+FDC7。3 文字の並びからできるリガチャを文字
として扱っている。ちなみに、ラテンアルファベットの 3 文字のリガチャについて
は ffi（U+FB03）、ffl（U+FB04）の二つにコードポイントが与えられている。
最後の方では、ほとんどロゴマークといってよさそうなリガチャにまでコードポイン
トを与えている。例えば、Arabic Ligature Jallajalalouhou は、U+062C, U+0644, U
+0020(空白), U+062C, U+0644, U+0627, U+0644, U+0647 の、実に 8 文字の並び
からできるリガチャを文字として扱っていることになる。
図 16 Arabic Ligature Jallajalalouhou：U+FDFB
7.11 リ ガ チ ャ
7.11.1 リガチャとは
リガチャは、2 つ以上の文字の組み合わせが出現するとき、文字のデザイン上の配慮
から、二つ以上の文字を合成した別の形状のグリフに置き換えるものである。ラテンア
ルファベットだけではなく、アラビア文字でも使われる。リガチャをもっとも多用する
のはインド系の文字である。
7.11.2 ラテンアルファベット
ラテンアルファベットのリガチャはもっともシンプルである。Unicode では次にコ
99
ードポイントが与えられている。
●
ラテンリガチャ：U+FB00-U+FB06
具体的には次の 7 文字である。
U+FB00：ff
U+FB01：fi
U+FB02：fl
U+FB03：ffi
U+FB04：ffl
U+FB05：ft
U+FB06：st
AGaramond、Paratino Linotype, Minion Pro の３つのフォント・ファミリーについ
て、リガチャなしの文字の組と U+FB00～U+FB06 を対比させると、AGaramond のよ
うな Type1 のフォントは、U+FB01、U+FB02 しかグリフがないことが分かる。他の
フォントでも U+FB02 については、f と l の 2 文字の配置とわずかな相違しかない。
図 17 リガチャ（フォント別）
Wikipedia（英文）のリガチャの説明では、他にも挙げている。例えば、次の文字は、
Wikipedia ではリガチャとされている。Unicode でも文字の名前にリガチャという文
100
第 7 章 文字コードと文字の表示形
字を含んでいる。
U+00C6：Æ　Latin capital ligature AE
U+00E6：æ　Latin small ligature ae
U+0132：IJ　Latin capital ligature IJ
U+0133：ij　Latin small ligature ij
U+0152：Œ　Latin capital ligature OE
U+0153：œ　Latin small ligature oe
次の文字の起源はリガチャとされているが、Unicode の文字名ではリガチャという名
前は付いていない。
U+0028：&　Ampersand　（文字の起源は Et のリガチャ）
U+00DF：ß　Latin small letter sharp s (文字の起源は、ſ Latin small letter long s と s のリ
ガチャ)
この他、ラテン拡張 B[U+01C4～U+01CC] には、クロアチア文字としてラテンアル
ファベット 2 文字を組み合わせて 1 文字にした文字がある。この他にも 2 文字を組み合
わせて 1 文字にしたものが幾つかあり、これらの 2 文字のセットにコードポイントを与
えた文字とリガチャの境界は曖昧なようだ。リガチャについては、２つの文字が 1 行に
入りきらない時は、必ずしも合成形に置き換えないこともあるので、本質的には文字コ
ードというよりは、特別な表示形と言うべきではないだろうか。また、これらのリガチ
ャの形状の中には、Unicode で互換分解マップが与えられているものがある。これらの
互換分解マップが与えられる文字は、例えば検索では、互換分解した文字列でヒットさ
せることが望まれると考えられる。こうしてみるとリガチャはひとつの文字として扱う
ものではないと言える。
7.11.3 アラビア文字のリガチャ
アラビア文字ではラームとアリフの 2 文字が連続したときは、リガチャにするのが必
須である。ラテンアルファベットのリガチャと比較すると、アラビア文字のリガチャは
文脈依存のグリフとの組み合わせになるため複雑である。
ラームとアリフのコードポイント
名称
コードポイント
ラーム
アリフ
101
ラームは、文脈依存のグリフを 4 つもつのに対して、アリフは常に単独形となる。こ
の二つの文字が連続する場合、リガチャがなければラームの左にアリフが接続した U 型
のカーブをもつ文字になりそうだが、リガチャにより別の形になるとされている。
図 18 ラームとアリフのリガチャ
フォントは Arabic Typesetting を指定した。アリフは次の文字（左）に接続しないの
で、ラームとアリフのリガチャは、単独形と右接形 (FinalForm) しかもたない、という
べき。図でリガチャなしは無理やり作成したもので正しくないことに注意。Unicode
にはゼロ幅接合子（Zero Width Joiner：U+200D)、ゼロ幅非接合子（Zero Width NonJoiner：U+200C) という文字があり、これを使うことで擬似的に接続状態を制御して
文脈依存のグリフの切り替えを行うことができる。例えば、ラームとアリフのリガチャ
の図では対象文字の接続する側に U+200D、接続しない側に U+200C を配置した。
102
第 8 章 スクリプト処理
8.1 スクリプト処理エンジン
8.1.1 スクリプト処理エンジンの役割
漢字に関わる議論では文字コードと字体が 1 対 1 であることを想定する。しかし、ア
ラビア文字やタイ文字では文字コードと画面表示・印刷される字形は 1 対１ではない。
つまりこの仕組みを次のような簡単な絵で表すことができる。
図 1 スクリプト処理の役割
この図の中の言葉の意味は次の通りである。
●
プレーンテキストは符号化文字の並び
●
グリフ描画データとは文字の形を描画するためのデータまたはプログラムである。
グリフポジションデータとは、そのグリフをどの位置に描画するか、というデータ
を意味する。PDF の中には、テキストを表示・印刷するためのグリフ描画データと
103
グリフポジションデータが収容されている。
漢字は多くの場合、プレーンテキストをそのまま字形に置き換えて画面に印刷・表示
すれば良いが、世界の文字の中にはプレーンテキストをそのまま並べただけでは印刷・
表示される文字にならないものが多い。このためプレーンテキストから印刷・表示用の
字形に置き換えるプログラムが必要となる。これを「スクリプト処理エンジン」と呼
ぶ1）。スクリプト処理エンジンで最も普及しているのはマイクロソフトの Uniscribe で
ある（Microsoft “Uniscribe.”（p. 242））。
8.2 結合文字と文字の合成
ラテンアルファベット、アラビア文字を初めとして、世界の文字にはひとつの文字の
上下、あるいは左右に別の文字または記号をつけて発音の変化や声調の変化を表すもの
が数多くあり、Unicode では結合文字 (Combining Character) と言われている。結合文
字とはプレーンテキストの文字列を表示・印刷・PDF にするとき、文字列の中で先行す
る基底文字にくっついて図形的にひとつの塊になる文字ということができる。
結合文字には次のようなものがある。
●
アラビア文字の Harakat：2）
●
ラテンアルファベットのダイアクリティカルマーク 7.9 ラテンアルファベットと
結合文字（p. 94）
●
キリルアルファベットのダイアクリティカルマーク：例えば、ロシア語の
は、基底文字 E、e に結合ダイエレシス（ウムラウト）
を付加したもの
●
デバナガリ文字の母音記号：
、
●
タイ文字の母音や声調記号など：
、
結合文字は、一般に、次のような特徴を持つ。
1） 原則として単独では使われない
2） 点線の円の位置には基底文字が置かれることを想定している
3） 文字の大きさやスタイルは基底文字と同じになる
1） この定義で妥当だろうか？
2） 2006 年 01 月 22 日 PDF と文字 (30) – アラビア文字 Harakat の結合処理
104
や
第 8 章 スクリプト処理
ラテンアルファベットでは、基底文字と結合文字を組み合わせて合成した文字につい
ても沢山のコードポイントが与えられいる。これらは合成済み文字 (pre composed
character) と言う。任意の基底文字に結合文字を組み合わせる処理ができれば、コード
ポイントが与えられている合成済み文字は、基底文字と結合文字の組み合わせで作成で
き、合成済み文字は、既存の様々な文字規格に収録されていたものから、既存の文字規
格との互換性のために採用されていることになる。
結合文字の中には、基底文字の表示位置と同じ位置に表示されるものがあり、この属
性をもつ結合文字は字幅のない記号 (non spacing mark) といわれることもある。
図 2 字幅のない結合文字
結合文字には字幅を取るものもあり、これは字幅のある記号 (spacing mark) である。
現在、多くのパソコンのキーボードには、チルダ、サーカムフレックスなどの結合文字
と似た形をもつ文字のキーが幾つかあるが、これらの文字は字幅のある文字 (spacing
character) とされており、Unicode の仕様では結合文字として扱わない。対応する結合
文字には別のコードポイントが与えられている（Unicode Consortium. "The Unicode
Standard, Version 4.0." p. 167, pp. 70-71（p. 243））。
表 1 結合文字
字幅のある文字
類似の形の結合文字
Circumflex Accent U+005E Combining circumflex accent U+0302
Low Line
U+005F
Combining macron below
U+0331
Combining macron low line
U+0332
105
Grave Accent
U+0060 Combining grave accent
Tilde
U+007E
Small Tilde
U+02DC
Diaeresis
U+00A8 Combining diaeresis
Macron
U+00AF
Accute Accent
U+00B4 Combining accute accent
U+0301
Cedilla
U+00B8 Combining cedilla
U+0327
Degree Sign
U+00B0
Ring Above
U+02DA
Combining tilde
Combining macron
U+0300
U+0303
U+0308
U+0304
Combining macron over line U+0305
Combining ring above
U+030A
8.3 アラビア文字の処理
8.3.1 アラビア文字のプログラム処理
アラビア文字は右から左に書き進めるが、数字は左から右に書く。また、ラテン文字
用の句読点、あるいは数字を共用する。右から書き表す文字や記号と、左から書き表す
文字や記号が混在すると、画面表示や印刷時の、文字の進行方向を決定するために特別
な処理が必要となる。
またアラビア文字を表示・印刷・PDF に処理するプログラムは、文字コードから字形
（グリフ）への対応で次のような必須処理を行わねばならない。Unicode の仕様書に標
準のアルゴリズムが掲載されているので、これを忠実に実装すれば、アラビア語を全然
知らなくても、最低限のアラビア文字処理ができる。
文字の結合 (Cursive Joining)
アラビア文字は接合に関して次の 6 つのクラスにな
るので、プログラムはアラビア文字自身がどのクラスに属するか、及び、左右の文字の
クラスを見て、その文字の表示・印刷・PDF 作成用のグリフを選択する。
●
接合しない文字：ゼロ幅非接合子（Zero Width Non-Joiner U+200C）など
●
右接形のみ：印刷の際に右の文字にのみ接合する文字
●
両接形：両方の文字に接合する文字
●
接合を起こす文字：ゼロ幅接合子（Zero Width Joiner U+200D）など
●
接合に対して影響を与えない文字
●
左節形しかない文字はない
Harakat の処理
106
アラビア文字には基底になる文字の上、または下につけて発音を表
第 8 章 スクリプト処理
す Harakat（母音記号など）がある。Unicode では、Harakat に基底の文字とは別のコ
ードポイントを与えているので、表示・印刷・PDF 作成では、プログラムで基底文字と
結合し、Harakat を基底文字の上あるいは下に配置しなければならない。
リガチャの処理
アラビア文字を筆記するには、必須とされている 2 文字のリガチャ
があり、必須リガチャについては、単に接合させるだけではなく、2 文字を組みにした
新しいグリフに入れ替えなけばならない。
107
第 9 章 PDF とデータ交換
9.1 テキストによる情報交換
PDF リーダが表示するのは字形であるが、コンピュータで電子ドキュメントを処理す
る場合、字形よりも文字コードで表されたプレーンテキストを扱うことになる。このよ
うに、文字コードと画面表示・印刷される字形とは分離させて考えることが必要となる。
9.1.1 プレーンテキストによる情報交換
プレーンテキストレベルで交換した場合、受け手の側に、送り手と同じスクリプト処
理エンジンが必要となる。例えば Windows では Uniscribe というスクリプト処理エン
ジンがあり、これが Unicode のテキスト文字列を受け取って正しいグリフの列や位置を
割り出す処理をしている。そこで Windows 同士のプレーンテキストによる情報交換が
成り立つ。Linux などでこのプレーンテキストを表示するときには、同等の機能をもつ
エンジンを使わないと正しく表示できない。携帯電話などで読もうとするときも同じで
ある1）。
PDF による交換
PDF のレベルであれば、スクリプト処理エンジンの出したデータを
交換することになるので、オリジナルの情報を、例えば、Windows で Uniscribe で作成
したとしても、受け手には同じ機能は不要となる。漢字については、2000 字も使えれ
ば、一般的のコミュニケーションは可能だろうし、さらに、5000 字を使えれば相当な
もの。1 万文字を使いこなせる人は日本にも殆どいない。このような現実に対して、7
万を超える文字にひとつづつ情報交換用のコードポイントを与えても情報交換という意
味ではあまり意味がない。どうしても文字の形状を交換したいのであればグリフデータ
を交換することを考えるのも有益だろう。
9.2 PDF における構造表現
PDF は紙に印刷するレイアウトをデジタルで表現したものであり、その限りではドキ
ュメントの論理構造を表現する必要がない。しかし、PDF のデータを音声で読みあげる
1） Android 携帯では現在どうなっているのか？調べて記述を追加する
109
など印刷以外の目的で活用したり、再利用するためには論理構造が付与されている方が
良い。
PDF の構造ツリーは、ドキュメント内容に情報構造を付加する汎用の仕組みであり。
PDF 内のオブジェクトをドキュメントカタログの構造ツリールート（StructTreeRoot）
をルートとする構造要素のツリー構造として表現する。仕組みは XML に似ており、構
造要素は内容と属性も持つことができる。
構造要素は、章、段落、脚注などの構造型をもつ。また、構造要素は対応する内容を
もつことができる。内容はコンテントストリームにマーク付けした内容の並び、もしく
は注釈や XObject のような PDF オブジェクトである。
9.3 タグ付き PDF
タグ付き PDF は、PDF 中に埋め込んだ標準的なタグによって PDF 文書を構造化する
ものである。タグ付き PDF はオプション機能なので、すべての PDF 作成ツールがサポ
ートしているとは限らない。
タグ付き PDF にすることで次のようなメリットがある。
1） PDF は、通常、内容に文書構造を持たない。例えば、文章は行ごとに千切れてい
て、段組では、左の段の第１行目に右の段の第１行目が続いていたりする。タグ付
き PDF にすることでテキストを抽出したり、テキストをコピーして他のアプリケー
ションに貼り付けて再利用できる。
2） PDF のページサイズを変更したとき、オリジナルのレイアウトを変更してテキス
トや画像を適切な順序でリフローさせることができる。
3） 検索やスペルチェックにテキストを利用する。
4） PDF ドキュメント内の構造を利用して、PDF を HTML、XML などの他の形式に
変換する。
5） 視覚障害者などが、何らかの音声リーダを用いて PDF を読もうとするとき、正し
い順序で文章を読むことができる。
タグ付き PDF の目的はテキストの意味を回復するとき、言語の自然な読み順に定義さ
れるような語句の並びになることを保証し、文書の論理構造に関して、高度なレベルの
意味的な情報を回復できることを意図するものであり、単にタグをつけるということで
はないことに注意しなければならない。
110
第 9 章 PDF とデータ交換
9.3.1 タグ付き PDF の作成
もとの文書が XML などで構造化されていれば自動的にタグ付 PDF に変換すること
ができる。しかし、通常のオフィス・アプリケーションで作成した文書をタグ付き PDF
に出力するのは、もともとオリジナルに構造がないだけに難しい。米国では「Word で
タグ付き PDF をうまく作る方法」というセミナーも開催されている。
9.3.2 タグ付き PDF の概要
タグ付き PDF は、PDF の論理構造の枠組み（9.2 PDF における構造表現（p. 109））
を利用して、標準的な構造要素型と属性の組を定義したものである。
111
第 10 章 PDF とフォント
10.1 フォントとは
パーソナル・コンピュータやスマートフォンを初めとする電子機器で文字を画面に表
示したり、印刷したり、PDF にして電子的に文書を交換する際にはデジタル・フォント
が必須である。現在、このデジタル・フォントの主流になっているのはアウトライン・
フォントと呼ばれる技術である。
10.1.1 用 語 の 整 理
フォントに関連する用語に書体とグリフがある。書体については 7.5.1 日本における
文字に関する用語（p. 80）で検討したが、「文字のセットに対し、印刷や表示のコンセ
プトに基づいて統一的に施されたデザイン」である。グリフは新しい比較的用語なので
文献によって定義が少し異なるが、本書では「グリフとは文字を可視化した形状である」
と定義する（7.7.1 グリフ（p. 85）を参照）。そうするとフォントは同一書体のグリフを
集めたものであるということができる。
10.1.2 文字の可視化方法
フォントの説明の前に文字を可視化する方式について整理する。
点滅するドットのパターンで文字を可視化
ランプの点滅のパターンで文字を表す仕
組みの電光掲示板がその典型的な例である。例えば、新幹線の車両や JR の車両のニュ
ースを伝える電光掲示板や、野球場のスコアボードに使われている。コンピュータの画
面、携帯電話の画面、またはプリンタでの印刷などにおいて文字を表す仕組みは電光掲
示板方式を精密にしたものであり、点滅させるドットを小さくなると精密さが増す。
ストロークで文字を可視化する方式
コンピュータを使ってペンや筆に相当するツー
ルを制御して文字を書くという方式もある。典型的な例がプロッタ（ペンプロッタ）と
呼ばれる出力装置を使うものある。この方式は、建築や機械などの設計図面を紙に出力
するのに使われる。
その他の可視化方法 文字の可視化の伝統的な方法である活字はグリフそのものであ
る。活字の発展形として日本で開発された独自技術に写真植字（写植）がある。これは、
113
文字盤に記載された文字を、写真の技術を使って、拡大・縮小して印画紙に焼き付けて
いく方法である。活字や手動写植は、コンピュータ技術以前のもので、いわばアナログ
方式であり、現在は使われることが少ない。
この中で光学的方法で可視化する方式をコンピュータで自動化したものとしてはデジ
タルフォント＋電算写植機があり、現在でも新聞の印刷などに使われているようだ。
10.1.3 ビットマップフォント
文字を可視化する方法の中で現在主流になっているのは「点滅するドットのパターン」
で表す方法である。グリフをドットの ON/OFF のパターンとして表したデータを一文
字ずつ用意するしたフォントが、ビットマップフォントである。次の例は、縦方向 12
行、横方向 12 列（12×12 ドット）の塗り潰しパターンで「阿」という文字を表したも
のである。
図 1 ビットマップフォントの例示
ビットマップフォントでは、このようなパターンデータを文字毎に用意する。ビット
マップフォントの問題は、拡大、縮小をすると汚くなってしまうことである。12×12 ド
ットで最適な形になるようにデザインされたフォントを、例えば 1 文字あたり 24×24 ド
ットで表示すると奇麗ではなくなる。文字を表示・印刷する装置のドット密度と表示し
たい文字の大きさ毎に適切なドット数のフォントを選択しなければならない。このため
フォント供給者は、様々なサイズのフォントを品揃えしている。例えば、リコーのビッ
トマップフォントの案内をみると日本語ゴシック系は 9×9～64×64 までの多段階のフ
ォントデータが提供されている。それ以外に、丸ゴシック系、明朝系など系列別に多段
階のドット数のデータを提供している（リコー「ビットマップフォント 」（p. 244））。
ビットマップフォントは、パソコンの画面表示、携帯機器（PDA）、携帯電話、複写
機、FAX などの情報機器でテキストの表示に使われているほか、家電製品や住宅・厨房
機器なども液晶画面でメッセージを表示するようになっており、利用範囲は非常に多岐
114
第 10 章 PDF とフォント
に渡っている。
10.1.4 アウトラインフォント
アウトラインフォントのアウトラインとはグリフの輪郭のことであり、アウトライン
フォントのファイルには、各グリフのアウトラインを描くためのデータ（パラメータ）
が収録されている。そこで、文字の可視化は次のステップで行う。
1） 可視化したいグリフのデータを取り出す
2） データを元にグリフのアウトラインを描く
3） アウトラインで表現したグリフの状態から塗り潰すべき領域を決定する
4） 塗り潰すべき領域のドットを塗り潰す
アウトラインフォントをコンピュータのディスプレイに表示するには、全てのグリフ
について、（1）～（4）のステップで点滅するドットのパターンに置き換える。この処
理を行うプログラムをフォントのラスタライザと言い Windows の GDI や Postscript
を印刷するプリンタなど様々な機器にフォントのラスタライザが搭載されている。
グリフのアウトラインを記述する方法の中で、現在、最もポピュラーなのは、
PostScript（Type1）フォントで使われている 3 次ベジエ曲線、および TrueType フォ
ントで使われている２次ベジエ曲線のふたつである（「アウトラインフォントエディタ
概要」（p. 243））。
アウトラインフォントではグリフの輪郭を多数の線分に分割し、各線分をベジエ曲線
で表す。ベジエ曲線は、二つの端点とそれに加えて曲線の曲がり具合を制御する制御点
のデータで表現することができる。アウトラインフォントのグリフデータの中核は、多
数の線分の端点と制御点の集合である。
アウトラインフォントの優れた良い点は、グリフをベジエ曲線という数学的な曲線で
表しており拡大・縮小が自由にできるということである。一方、曲線からラスタライズ
する際に、1 文字のドットが少ないときドットの点滅の最適化が難しいことである。
10.1.5 エレメント方式フォント
その他の方式のフォントとしては、リコーのエレメント方式フォントがある（「リコー
「エレメント方式フォント RT Font 」（p. 244））。これは、文字を書き表すストローク
を、約 700 種類に分類しておき、そのストロークを組み合わせて文字を表す仕組みであ
る。漢字のように何万種類もの文字があるときは、小さな部品から組み立てていく方式
は有効だろう。RT Font は漢字だけではなく、ラテン系の文字やハングルなども文字と
して用意している。このフォントは、フォントデータとラスタライザ（ソースプログラ
115
ム）で提供されるようなので Linux などにも載せて使えそうだ。
10.2 アウトラインフォントの種類
10.2.1 アウトラインフォント形式
アウトラインフォントはグリフのアウトラインを数学的な曲線で表わすものであり、
曲線で囲まれた領域のドットを塗り潰すことで文字を可視化する。そしてアウトライン
フォントの中核はグリフのアウトラインデータであるが、フォントファイルには、グリ
フの幅や高さを表すメトリック情報、あるいは、文字コードとグリフ番号の対応表、な
どのデータも含まれる。アプリケーションがフォントを利用するための様々なデータを
含めて、フォントファイルにどのような状態で収容されているかを定めた仕様がフォン
トファイル形式である。
主なアウトラインのフォントファイル形式には次のものがある。以下に概要を紹介す
る。
●
Type1 フォント
●
TrueType フォント
●
CFF/Type2 フォント
●
マルチプルマスター Type1 フォント
●
Type3 フォント
●
Type0 フォント
●
CID-Keyed フォント (PostScript)
●
CID-Keyed フォント (PDF)
●
OpenType フォント
注記（p. 75）
10.2.2 Type1 フォント
最初に普及したアウトラインフォントは、Type1 フォントである。Type1 フォントは
次のような特徴がある（Phinney. “TrueType, PostScript Type 1, & OpenType: What’s
the Difference?”（p. 242））。
●
1980 年代にアドビシステムズが、PostScript 言語用のフォント形式として開発し、
1985 年アップルのレーザライターに採用されて普及した。
●
116
Type1 は 、 PostScript で ア ウ ト ラ イ ン フ ォ ン ト を 効 率 的 に 表 現 し た も の 。
第 10 章 PDF とフォント
PostScript の仕様は公開されて、サードパーティがクローン製品を作ることができ
た。しかし、Type1 フォントの仕様は公開されず、それらのクローン製品で Type1
フォントをラスタライズすることができなかった。
●
Type1 フォントは、印刷用に用意されたもので PS プリンタ用に使われた。
●
1989 年 12 月に出た ATM（Adobe Type Manager：Type1 フォントのラスタライ
ザ）によって、初めて Type1 フォントをパソコンの画面やビットマップ・プリンタ
で出せるようになった。それに続いて、1990 年 3 月に Type1 フォントの仕様が初
めて公開された。Windows9x/ME、MacOS 8/9 で、Type1 フォントを表示するに
は ATM が必要である。
●
Windows2000 以降、アップルの MacOS X 以降では、Type1 フォントのラスタラ
イザが標準搭載されているので ATM は不要になった。
●
Type1 フォントは、グリフのアウトラインデータを収録した PFB (Printer Font
Binary) ファイルとフォントのメトリックス情報を集録した次のファイルのペアで
使う。このためフォントファイルが OS 独立でない。
○
Windows の場合は、PFM (Printer Font Metrics) ファイル
○
Unix などでは AFM(Adobe Font Metrics) ファイル
Type1 フォントはパソコンのアウトライン・フォントの草分けとして大きな影響を及
ぼした。しかし、1996 年には Adobe とマイクロソフトは共同開発した OpenType フォ
ントを発表し、Type1 フォントは技術的に古いものになった。
Type1 から OpenType へ
Thomas W. Phinney によると、2005 年時点でアドビの
フォントの売上げは圧倒的に OpenType フォントになっていて、Type1 フォントの売上
げはどんどん減っている。アドビは Type1 フォントの販売を終了し、ユーザが早い時期
に Type1 フォントからそれに対応する OpenType フォントに移行することを望んでい
る（Phinney. “Phasing out ‘PostScript’ Type 1 fonts.”
（p. 242））。
●
アドビシステムズは、既に 1999 年に新しい Type1 フォントの開発を終了し、2000
年から OpenType フォントを発売している。
●
マイクロソフトは Windows の新しいグラフィックスとテキストシステムである
Presentation Foundation Engine（開発コード名 Avaron）を開発した。この
WinPFE では Type1 フォントをサポートしていない。
○
Windows Vista には、WinPFE と旧来の GDI の二つのグラフィックシステム
が搭載される。GDI ベースのアプリケーションでは、Type1 フォントが引き続
き使える。しかし、WinPFE ベースのアプリケーションでは、Type1 フォント
はフォントのメニューにも表示されない。
117
他のフォント・ベンダも Type1 フォントの販売を終了しつつあるようで、Type1 フォ
ントは歴史的な存在になりかけている。
PDF に埋め込んだ Type1 フォント
PDF ファイルにフォントを埋め込めば作成した
環境と同じフォントが表示したい環境になくても文字を表示することができる。しか
し、肝心の Type1 フォントのラスタライザが存在しなければ、Type1 フォントの文字を
表示することはできない。この点について Thomas W. Phinney は次のように述べてい
る。
●
アドビのアプリケーションは OS とは独立のフォント・エンジンをつかっているの
で Type1 フォントはサポートできる。
●
PDF に埋め込まれた Type1 フォントは、恐らく永久にサポートされるだろう。
アドビのアプリケーションは、フォントのラスタライズを Windows に依存しないで
独自でやっており、Adobe Reader は、独自のフォント・ラスタライザを使っているの
で、Windows から Type1 フォントのラスタライザがなくなっても大丈夫ということの
ようだ。
10.2.3 TrueType フォント
TrueType フォントは、マイクロソフト Windows に標準搭載のフォント技術という
印象があるが、TrueType フォント技術はもともと Apple が OS レベルで拡大・縮小可
能なフォントを実現しようとして開発を始めたものである。マイクロソフトは別途
TrueImage と い う 技 術 を 開 発 し て い た 。 TrueImage は 、 Cal Bauer と Bauer
Enterprises が開発して、1989 年にマイクロソフトが買収した PostScript 互換のインタ
ープリタとされている。マイクロソフトとアップルは、TrueImage と TrueType をクロ
ス ラ イ セ ン ス し て TrueType が Windows で 使 え る よ う に な っ た 。 TrueImage は 、
PostScript 互換のプリンタ用に商品化されたが、結局あまり成功することなく終わった
（Penney（p. 242））。
TrueType と Type1 のアウトラインデータの形式の特性、ラスタライザの性能特性な
どのグリフのデザインとその可視化の技術的な優劣については、いろいろな議論がある。
TrueType フォントのファイル形式としての特徴は次の通りである（Microsoft. “What
is TrueType?”（p. 242））。
●
Type1 フォント形式と違い、アウトライン情報とメトリック情報はひとつのファイ
ルに収容されている。
●
アップルの Macintosh System7.0 と Windows3.1 以降の OS に、TrueType ラスタ
ライザが標準で搭載されていて OS レベルでサポートされている。この点で、
118
第 10 章 PDF とフォント
Type1 は PostScript プリンタという高品位印刷の領域から始まったのと違い、
TrueType は最初から非常にポピュラーな存在である。
●
マイクロソフト Windows には、多数の TrueType フォントファイルがバンドルさ
れている。このファイルの拡張子は、.TTF、と.TTC がある。.TTC は、True Type
Collection の略でひとつのフォントファイルに複数のフォントを含んでいるもの。
CJK フォントにこの形式が見られる。例えば、MS 明朝と MS P 明朝がひとつのフ
ォントファイルにまとめられていたり、MS ゴシックと MS P ゴシックがひとつの
フォントファイルまとめられているなど。
10.2.4 CFF/Type2 フォント
CFF (Compact Font Format) は、Type1 フォントのグリフアウトラインなどのプロ
グラム容量を小さくするために開発されたものである。CFF は通常 Type2 文字記述手
続き (charstring) と一緒に使い、Type1 フォントは、CFF/Type2 セットと完全に（情
報のロスなしで）相互変換ができる。Type1 フォントから CFF/Type2 に変換すると容
量が 30%～40%少なくなる。
CFF/Type2 と PDF
CFF/Type2 フォントは Acrobat3.0（PDF1.2）の PDF に Type1
フォントを埋め込むのに使われており、Type1 フォントを PDF1.2 に埋め込む時は、
CFF/Type2 に変換してから埋め込む。逆に、PDF に埋め込まれている CFF/Type2 の
フォントは、PDF から取り出した後、Type1 に変換してからリーダで表示したり、プリ
ンタで印刷される。なお、CFF/Type2 というフォントの形式は、単独のフォント形式
ではなく、OpenType の中で Type1 フォントを保存する形式として使われることで普及
している（Adobe Systems Incorporated. “CFF / Type 2 Q & A”（p. 239））。
10.2.5 マルチプルマスター Type1 フォント
マルチプルマスター・フォント（MMType1）は、Type1 フォントの拡張で、ひとつ
のフォント・プログラムから様々な書体のフォントを作りだすことができるものである。
FontForge の（「マルチプルマスターダイアログ 」（p. 244））によると、アドビとアッ
プルはそれぞれ独自の技術を開発している。マルチプルマスター Type1 フォントはア
ドビが開発した方法で、アップルのは TrueType 用である。
アドビの方法では、フォントのウエイト（ライトから極太）、幅（コンデンスからエク
スパンド）、幅、サイズなどのデザイン軸について、両極端の全てのフォントを用意して
おき、その間に入るものを自動的に生成する（Adobe Systems Incorporated. “Multiple
Master Fonts”（p. 239））。
119
中間のデザイン特性をもつフォントの生成は、ATM などのフォントのラスタライザが
行う。PDF にマルチプルマスター・フォントを埋め込む場合は、実際にラスタライザが
補完して作り出したフォントを埋め込み、マルチプルマスター・フォントそのものを
PDF に埋め込むことはない。
（Leurs. “The History of Fonts.”（p. 241））によると、アドビは 1999 年にマルチプ
ルマスター・フォントの開発を止めるとアナウンスしており、今までに制作されたマル
チプルマスター・フォントは約 50 種類と少ない。マルチプルマスター・フォントはあ
まり成功したフォント形式とは言えない。
Thomas W. Phinney は、成功しなかった理由として、サポートする（MMType1 を
読んで、ラスタライズ、画面表示できる）アプリケーションが少なかったことを挙げて
いる。MMtype1 を実現するには、各軸にそった極端なグリフセットを作らねばならな
いが、3 軸だと 8 種類になり、最初から、8 家族からなるフォント・ファミリーを制作
するほうが手っ取りばやい（Phinney “TrueType, PostScript Type 1, & OpenType:
What’s the Difference?”（p. 242））。
10.2.6 Type3 フォント
Type3 フォントは PostScript でグリフを表現するものである。Type1 フォントのフ
ァイル形式は当初は非公開であったが、Type3 のファイル形式は最初から公開されてい
たことから、一般の人が PostScript ベースでアウトライン・フォントを開発しようとす
ると Type3 を使うしかなかったのである。Type3 フォントの仕様は、“PostScript
Language Reference Manual, 2nd Edition; Addison-Wesley”に記述されている。
Type1 と Type3 の比較
Type1 と Type3 の違いは次のようなことである。
●
Type3 フォントの文字の字形は、標準の PostScript の命令で記述できる。
●
作るのは簡単で、複雑な形状の文字を作ることもできる。
●
アドビは Type3 フォントの仕様を公開したが、自社で Type3 フォントを作成した
ことはなく、配布したこともない。
●
Adobe Type Manager などのアプリケーションは Type3 フォントをサポートして
いない。
PDF Reference の 5.5.4 項に Type3 フォントの説明がある（Adobe Systems. PDF
Reference, fifth edition. pp. 389～395（p. 239））。
10.2.7 Type0 フォント
Type0 フォントは、複合（Composit）フォントと言い、もともとは PostScript の仕
120
第 10 章 PDF とフォント
様書で定義されている複数のフォントを束ねて高度なフォントを作る仕組みである。
Type1 フォントは 1 バイトなので CJK の文字を扱うことができない。そこで、アドビは
Type0 フォントの仕組みを利用して OCF（Original Composite Font) を開発し、その
後 CID-Keyed フォントを開発した。OCF フォントは PostScript でのみ使えるもので、
日本の DTP 分野で一時期に流行したが CID-Keyed フォントが取って代わった。既にフ
ォント・メーカはサポートを終了し、PDF ではサポートしていない。PDF で使えるの
は、CID-Keyed フォントであり、composite font = Type0 フォント= CID-Keyed フォ
ントとされている。
10.2.8 CID-Keyed フォント (PostScript)
CID-Keyed フォントは、PostScript Type1 形式の複合フォントとして OCF の後継と
して規定された。基本的に CJK 用なので日本のフォントベンダも CID フォントを多数
出している。CID フォントは次の３つの要素から構成される。
●
CID 文字集合
●
CMap ファイル
●
CID フォントファイル
CID 文字集合
日本語、中国語（繁体字、簡体字）、韓国語についてグリフを集めて
CID 番号をつけたものである。7.7 グリフとグリフセット（p. 85）を参照。
CMap
さまざまな符号化文字集合の文字コード番号から CID への対応表である。ア
ドビが用意した標準の CMap は無償配布されており、フォントベンダなどが独自に定義
することができるとされている。
CID フォントファイル
フォントのグリフを記述するプログラム（データ）を収録し
たファイルで、フォントベンダが開発するものである。Type1 のグリフアウトライン形
式と互換の形式になっていて、Adobe Type Manager や PostScript インタープリタで
解釈してラスタライズすることができる。
CID-Keyed フ ォ ン ト に つ い て は Adobe Systems “ CID-Keyed Font Technology
Overview”（p. 239）に概要がある。本資料では、CID フォントの特長として次のよう
なことを挙げている。
●
CMap ファイルを使って、複数の CID-Keyed フォント、OCF フォント、Type1、
Type3 フォントを参照して使える。
●
文字を追加して、拡張するのが簡単。
●
Type1 よりフォントを取り出してラスタライズするのが速い。
●
広範な機器に使える。
121
●
OCF と比べてフォントのファイル数が少なくて済み、コンパクトになる。
10.2.9 CID-Keyed フォント（PDF)
PDF Reference の 5.6.1 CID-Keyed Font Overview を み る と 、 PDF で は
CIDFontType0 と CIDFontType2 の 2 種類がある（Adobe Systems. PDF Reference,
fifth edition. pp.403-405（p. 239））。
PostScript を想定する CID-Keyed フォントと PDF のそれでは微妙に違いがある。
PDF Reference ではフォントを 1 バイトの simple フォントと複数バイトの composite
フォントの二つに大別している。composite フォントのことを Type0 フォントと言い、
CID－Keyed フォントのみ使うことができる。CIDfont からグリフを選択する仕組みが
PostScript とは異なっている。CID-Keyed フォントは次のものから構成される。
●
CID
●
CMap
●
CIDFont
CID は PostScript と同じものである。CMap も同じような役割だが PDF では少し機
能を限定している。一番の違いは CIDFont で、PostScript の時とは違い、PDF では
CIDFont に Type0 と Type2 の２種類がある。
●
CIDFont Type0 は、アドビの Type1 フォントの形式でグリフを記述したもの
●
CIDFont Type2 は、TrueType フォントの形式でグリフを記述したもの
PDF では、1 バイトの TrueType フォントを simple フォントの 1 種類として扱い、
CJK などの複数バイトの TrueType フォントは composite フォントとして、Type0 フォ
ントの仕組みを使って扱っている。この影響で PDF では CMap によるグリフ選択の仕
組みに TrueType の取り扱いが追加されている。このことは、1 バイトの TrueType フ
ォントと 2 バイトの TrueType フォントが、Acrobat の PDF のフォント・プロパティ情
報で、表示が違うことからも確かめることができる。
10.2.10 OpenType
歴史
OpenType は、最初マイクロソフトによって TrueType Open として開発され
た。その後、1996 年にアドビが開発に参加、1997 年 4 月に共同で発表された。1990
年代前半まで、アドビの PostScript Type1 フォントと、マイクロソフト/アップルの
TrueType という 2 大アウトライン・フォントがしのぎを削るという状況であったが、
この両陣営が協力して OpenType というフォントファイル形式を開発したのは、アウト
ライン・フォントの歴史上では、非常に大きなできごとになる。
122
第 10 章 PDF とフォント
OpenType は、TrueType と Type1 フォント技術の後継として位置付けられており、
さらに、OpenType は ISO の"Open Font Format"として標準化された（Levantovsky.
“Open Font Format.”（p. 241））。
普及の見通し
アウトライン・フォントの普及には、フォント制作者が提供するフォ
ントファイルと、それを使うアプリケーション、フォントファイルからアウトラインを
取り出して文字を可視化するラスタライザの 3 つが大きな要因となる。OpenType は
もともと TrueType の延長として開発されたので、TrueType フォントの多くについて
は、大きな変更なく使用できる。アドビも Type1 フォントを全て OpenType 形式に変
換し、OpenType フォントに集中している。いずれにしても、フォントファイルの供給
という面からは、今後、OpenType が圧倒的に増えることになるだろう。
フォントファイルとしての OpenType OpenType のフォントファイルとしての主
な特徴について整理する。
グリフのアウトライン記述形式
OpenType のグリフアウトラインは、TrueType アウトラインと、PostScript アウト
ライン（CFF/Type2 形式）のどちらかを使用できる。また、アウトライン形式に加え
て、ビットマップのグリフを含めることもできる。
OpenType フォント・ファイルの拡張子は次のようになる。
●
TrueType アウトラインの場合：.OTF、または、.TTF（過去のシステムでも使用可
能にしたいとき）
●
TrueType コレクションの場合：常に.TTC
●
PostScript アウトラインのみを含む場合：.OTF
cmap テーブル
フォントを使用するアプリケーション・OS で使う文字コードからグリフ番号（GID）
への対応表を cmap と言う。cmap は、一つのフォントファイルに複数のテーブル
(cmap サブテーブル) を持つことができる。サブテーブルは、プラットフォーム ID
（Windows：3、Macintosh:1）と、プラットフォーム毎の符号化方式（2 バイトの
Unicode:1、4 バイトの Unicode:10 など）の順で並べる。フォントファイルに様々な
OS 別のサブテーブルを用意することで、一つの OpenType フォントをマルチ・プラッ
トフォームで使うことができる。cmap サブテーブルは 7 種類（Format：0, 2, 4, 8, 10,
12）あり、各サブテーブルの先頭に該当する種類がセットされる。
Unicode サポートについて
Unicode から GID への cmap サブテーブルは、次の 3 種類が使える。
●
Format4：[U+D800 - U+DFFF]（サロゲートペア）以外の Unicode 領域をサポー
123
トする文字コードから GID への対応表（マイクロソフトの標準）
●
Format8：16 ビットと 32 ビット混在。サロゲートペアの文字コードは 32 ビット。
それ以外が 16 ビット。
●
Format12：32 ビット固定長（UCS-4）の表。（サロゲートペアをサポートする時
のマイクロソフトの標準）
サロゲートペアをサポートできるのは Windows2000 以降となるが、サロゲートペア
をサポートする OpenType フォントは、過去の OS でも使えるようにするため Format4
の cmap サブテーブルも用意しておかなければならない。cmap は Unicode の全領域
をサポートできるが、OpenType のひとつのファイルに収容できる glyph の数は 64k
（65,536 個）とされているので、UnicodeV4 で定義されている全文字をひとつでサポ
ートする OpenType フォントを作ることはできない1）。
参考資料：
●
Microsoft. “OpenType specification.”（p. 242）
●
Microsoft. “cmap - Character To Glyph Index Mapping Table.”（p. 242）
OpenType によるグリフのレイアウト
OpneType では、OpenType レイアウトとい
うコンセプトをもっており、OpenType レイアウトはフォントファイル中には特性テー
ブル (feature table) として用意される。これは、グリフを行にそって配置していく際に
次のようなことを行うためのものである。
●
複数のグリフのリガチャ、文字の位置によるグリフの変化など
●
文字の配置方法に依存するグリフの入れ替え
●
2 次元平面上でのグリフの配置、グリフの付加
具体的には日本語では縦書と横書での句読点・括弧類のグリフの入れ替え、アラビア
文字では単語の中での文字の位置によりグリフの形を変更するなどの処理を行なう。
OpenType レイアウトには次のような幾つかの共通テーブルがある。
●
BASE　ベースラインについてのデータ
●
GDEF　グリフの定義データ
●
GPOS　グリフの配置データ
●
GSUB　グリフの入れ替えデータ
●
JSTF　グルフの均等配置のためのデータ
文字・言語によってそれぞれのテーブルの中に用意されているデータを使って、グリ
フに対する操作・配置を行う。フォントファイルから取り出したグリフの操作や配置は、
1） 要確認
124
第 10 章 PDF とフォント
Windows は Uniscribe というグリフ・レイアウト・エンジンを使って行う。サードパー
ティが自前のグリフ・レイアウト・エンジンを使用することもできる。アンテナハウス
の AH Formatter は、アラビア文字、ヘブライ文字、タイ文字、デバナガリ文字について
自前のグリフレイアウト・エンジンを使ってグリフの配置を行っている。このように
OpenType のレイアウト・テーブルを使うことで、組版ソフトなどのアプリケーション
が高度なタイポグラフィを実現することができる。
10.2.11 フォント技術の将来
アウトラインフォントの技術については、アドビシステムズとマイクロソフトがほと
んどを握ってしまっている。アウトラインフォントではフォントデータとラスタライザ
がセットでないと役に立たない。フォントデータは、フォントベンダが沢山あり、ツー
ルを使えば新しいフォントを作り出すことができる。従って、問題はアウトラインフォ
ントのラスタライザである。例えば、OpenType では、TrueType アウトラインと、
CFF/Type2 アウトラインの 2 種類があるので、OpenType を可視化するにはその 2 種
類のフォントのラスタライザが必要になる。
OpenType の仕様書には、次のように説明されている。
PostScript data included in OpenType fonts may be directly rasterized or
converted to the TrueType outline format for rendering, depending on which
rasterizers have been installed in the host operating system. (Microsoft.
“OpenType Overview.”（p. 242）)
Windows で文字を表示するのであれば、ラスタライザはマイクロソフトとアドビが
提供しているので問題ないが、Windows 以外の OS、例えば、Linux、あるいは携帯電
話などで表示するには専用のラスタライザが必要である。PDF にフォントを埋め込む
と表示環境にフォントがなくても PDF を見ることができることになっているが、PDF
に埋め込まれているのはラスタライズした（可視化した）文字ではなく、フォントのア
ウトラインデータである。表示環境にラスタライザがなければ、PDF にフォントが埋め
込まれていても可視化することはできない。OpenType が普及した場合、マイクロソフ
トまたはアドビの協力がなければ PDF を表示することができないことになる可能性が
ある。
125
10.3 フォントによるテキストの表示
10.3.1 グリフデータ
コンピュータ間で交換するデータは文字コードであって文字の形ではない。画面に表
示したり、印刷する文字の形を表すためのデータはフォントファイルに含まれている。
アウトラインフォントで文字の形を現すためのデータをグリフデータという。フォント
ファイルには多数の文字のグリフデータを収容しており、各文字を表示するためのグリ
フデータには、識別番号がついている。OpenType フォントの識別子を GID という。
フォントファイルの中には、文字コードから GID への対応表を含んでおり、これを
cmap と言う。cmap は文字コードから代表的な GID に対応させており、アプリケーシ
ョンは、該当の文字に、縦書き用の字形、異体字、などがあるときは、フィーチャテー
ブルを使って他の GID に置換できる。この仕組みは図のように表すことができる。
図 2 文字から GID への対応
図では、文字コード X に対して GID は 1 番が対応するが、アプリケーションは
OpenType のフィーチャテーブルを使って、2 番、3 番に切り替えることもできること
を示している。パソコンの OS は、選択された GID に該当するグリフデータを使って文
字を画面上に可視化する。Adobe-Japan1 の CID は、上の図の 1 番～3 番の GID に相当
し、フォントファイルの中には、CID の文字をデザインした字形描画データが入ってい
126
第 10 章 PDF とフォント
る。
10.3.2 縦書きの字形の入れ替え
OpenType のフィーチャーテーブルの別の利用例として日本語の文章を横書き表示
から縦書き表示に切り替えるときのことを示す。例として日本語の中にアルファベット
と数字が混じった文章を横書きから縦書きに切り替えて表示することを考える。
図 3 英数字混在文章の横書き
図 4 英数字混在文章の縦書き
図を見ると直ちに分かるように日本語文章を横書きから縦書きに切り替えるとき、一
部の文字の形を入れ替える必要がある。その主なものは句読点・括弧類と英数字である。
句読点・括弧類
横書きでは括弧類は正立するが縦書きでは括弧類は横に寝かせる。
句読点の位置は横書きでは左下になるが、縦書きでは右上になる。このような字形の入
れ替えは、OpenType ではグリフの切り替え（グリフが正方形ではないときは縦と横の
寸法の入れ替えも伴う）で解決できる。
127
英数字
日本の縦組み書籍で多く採用されている英数字の組版方法は、一般には英語
の単語や文章の範囲を横に寝かせ、その他の NHK、OECD などのような頭文字からな
る単語や数字は正立させる方法（図 4 英数字混在文章の縦書き（p. 127）の C）が主流
である。現在は、縦書きで正立する文字は全角文字を使い、縦書きで横倒しする文字は
半角文字を使う（全角文字と半角文字について（p. 70）を参照）ことでこの切り替えを
実現している。しかし、この方法は縦書きと横書きで英数字を使い分けることが必要で
あり、縦書き用のテキストと横書き用テキストが異なるものとなる。また、フォントに
よっては全角文字と半角文字の字形を区別しにくい場合もあるため著者が原稿を書く段
階できちんと使い分けができず混乱しやすい。そこで文字を使い分けるのではなく字形
（グリフ）を切り替えることで実現する方法がより生産性が高くなるだろう。すなわちテ
キストでは半角文字と全角文字を区別しないで同じ文字コードで表しておき、テキスト
へのマークアップとスタイルシートの組み合わせなどの方法で文字を立てるか寝かせる
かを指示するのである。OpenType フォントには全角グリフと半角グリフの切り替え
のできるものがあるので、これを使って正立する文字は全角のグリフで表示し、寝かせ
る文字は半角のグリフで表示することができる。すなわち著者や編集者は文字を立てる
か寝かせるかを指定するだけで良くて、縦書きのためにテキストを作り直す必要がなく
なる2）。現在は、まだこうした方法は主流ではないが、いずれはこのようになるだろう。
10.4 フォント埋め込み
10.4.1 PDF のテキスト表示の仕組み
PDF で文字を表示する基本は図 5 PDF で文字を表示する方法（p. 129）のようにな
っている（Adobe Systems. “PDF Reference, fifth edition.” Chapter 5 Text（p. 239））。
●
図で「文字列」と表した部分が表示したい文字である。ラテン・アルファベットは
ABC のような文字のまま保存できる。CJK 文字は文字コードの並びで表現するの
が一般的だが、フォントのグリフ ID の並びで表すこともできる。
●
文字列には、使用するフォント・オブジェクト、文字の大きさ、文字を表示する位
置など様々な情報が付随している。
●
フォント・オブジェクトは、ページに付随する資源辞書の中のフォント辞書に詳し
い情報が定義されている。フォント辞書は、Type1、 TrueType、CID フォントな
どのフォントの種類によって若干の差があるが、フォントの種類や PostScript 名、
2） 2012 年 1 月現在、MS 明朝、MS ゴシックはこの機能を使うことができない。
128
第 10 章 PDF とフォント
図 5 PDF で文字を表示する方法
標準の幅、などを規定しているものである。
●
実際に文字を表示するためには、文字を表すグリフ・データ、フォントのメトリッ
クスなどが必要で、これらの情報はフォント・ファイルの中に含まれている。
●
フォント・ファイルは、コンピュータ上（Windows 環境であれば、Windows/Fonts
フォルダ内）にあったり、あるいは、アプリケーション独自のインストール・フォ
ルダやアプリケーション内部にある。
PDF リーダが PDF の中の文字を表示するときの動きは次の通りである。
1） PDF 中で指定されているフォント・オブジェクトとフォント辞書から、PDF 表示
環境である PC にインストールされているフォント・ファミリーに対応付けする。
同一のフォント・ファミリーが存在すれば問題ないが、存在しないと別のフォント・
ファミリーの中で適切なものを決定する。
2） フォント・ファミリーの中で、コードポイント⇒グリフ ID に対応つける。
3） 当該のグリフ ID に対応するグリフデータを使って文字を可視化する。
上のような仕組みのため、PDF リーダが文字の可視化に使うフォントが、PDF 作成時
のものと異なることがあり、その時、字形が元とは異なる字形になったり、文字の表示
位置がずれることがある。
10.4.2 フォント埋め込みとは
PDF にはフォント埋め込みという機能があり、多くの PDF 作成ソフトでこの機能を
129
使うことができる。例えば「Antenna House PDF Driver」では PDF に変換する文書中
で使われているフォントの埋め込み方法を様々に指定できる（図 17 埋め込みフォント
の選択（p. 139）参照）。PDF にフォントが埋め込まれているかどうかは、例えば Adobe
Reader で PDF を開いて「ファイル」メニューで「プロパティ」を選択すると表示され
る文書のプロパティ・ダイヤログの「フォント」タブをクリックすると確認できる。
図 6 フォントを埋め込んだ PDF の「フォント」プロパティの例
10.4.3 PDF へのフォント埋め込みで文字化けを防止
最初にフォント埋め込みの仕組みを簡単に説明する。フォントを埋め込んでいない
PDF では、文字を表示するのに必要なフォント・ファイルが PDF の外側にある。これ
に対して、PDF を作成する際にフォントを埋め込むと、埋め込み処理の際に PDF を作
成したコンピュータ上のフォント・ファイルから必要最小限の情報が取り出されて PDF
ファイルに取り込まれる。そこで PDF リーダが埋め込んだフォントで文字を表示でき
るならば文字化けなどが発生することがなくなる。
フォントを埋め込んだ PDF では、原則として、文字列オブジェクトは文字コードでは
なくグリフ ID の並びとなり符号化方式（Adobe Reader のプロパティに表示される
Encoding) は Identity となる。
10.4.4 フォントを埋め込まない PDF の表示の問題
PDF リーダは、フォントを埋め込んでいない PDF を表示するときには、コンピュー
130
第 10 章 PDF とフォント
図 7 フォント埋め込み PDF の表示
タ上のフォントを使う。PDF を作成した環境と PDF を表示する環境でコンピュータに
インストールされているフォントが異なる場合には、文字の字形が正しく表示されない
ことがある。以下にフォントを埋め込まない PDF で起きる可能性がある問題を例示す
る。
MS 明朝の字体変更
字形を正しく表示できない現象を引き起こす例として、MS 明朝
の字体変更によるものがある。
1） Windows2000 や XP には MS 明朝と MS ゴシック Version2.3 が標準で添付さ
れていたが、これに対して、Windows Vista に標準で搭載されている MS 明朝
Version 5、MS ゴシック Version 5 は、グリフ ID が変更になり、JIS X0213:2004
の例示字体変更を反映して一部の文字の標準グリフが変更になった。
2） この結果、Windows Vista の普及に伴って、Vista 上で MS 明朝、MS ゴシックを
指定して作成した PDF を、XP などの環境で表示したり、あるいは、その逆に XP
で作成した PDF を Vista で表示することが増える。この時、MS 明朝や MS ゴシッ
クで、字体変更になった文字は、フォントを埋め込まないと作成した環境と表示す
る環境で別の字体となる。
日本語 PDF を英語版 Windows の Adobe Reader で表示したとき
フォントを埋め
込まない日本語 PDF は英語版 Windows 上の Adobe Reader7 では表示できない3）。
3） 以下は、新しい Adobe Reader と Windows7 ではどうなっているか、確認する必要がある
131
1） WindowsXP のロケールが英語の状態で、英語版の Adobe Reader 7 をインスト
ールした直後の状態では、フォントを埋め込んでない日本語文字の入った PDF はま
ったく表示できない。このことは、英語圏ではフォントを埋め込んでいない日本語
PDF は内容を正しく表示できない、ということを意味する。
「平成丸ゴシック」を指定した日本語文字を含む文書を PDF にして、Adobe Reader
英語版で表示した結果を図 8 日本語文字を含む PDF の表示（p. 132）に示す。
図 8 日本語文字を含む PDF の表示
上がフォントを埋め込まない場合、下がフォントを埋め込んだ場合であるが、このケ
ースでは、Windows 環境に「平成丸ゴシック」フォントがインストールされているに
も関わらずフォントを埋め込まない限り文字が表示されない。WindowsXP のロケール
が英語の状態ではこのままの状態から改善されない。WindowsXP のロケールを日本語
に切り替え、日本語フォントのファイルを表示すると、今度は次のように、Adobe
Reader がアップデートされて、アップデート後はフォントを埋め込んでない PDF ファ
イルも正しく表示できるようになる。
このように、Adobe Reader 7(英語版）は、MS 明朝を指定した日本語文字は、
Windows システムにフォントがあっても表示できない。では、日本語以外はどうなる
か。
132
第 10 章 PDF とフォント
図 9 WindowsXP のロケールを日本語に切り替え
フォントを埋め込まない中国語 PDF の表示
中国語簡体字に SimSun フォントを指
定して、フォントを埋め込まずに PDF を作成してみる。右が Word のオリジナル画面、
左が、フォントを埋め込まずに作成した PDF の Adobe Reader 英語版で表示したもの。
これを見ると中国語も同じように表示することができないことがわかる。
図 10 フォントを埋め込まない中国語 PDF
フォントを埋め込まないアラビア文字の PDF は作成できない
アラビア語（アラビア
文字）の場合を試してみると、アラビア文字は、PDF を作成するとき Acrobat にフォン
トを埋め込まないを指定してもフォントを強制的に埋め込んでしまう。これはアラビア
文字は、文字が単語内のどの位置にあるかで字形が変更になるため、フォントを埋め込
まないと Adobe Reader では正しく表示できないため強制的に埋め込んでいるのだろ
う。
フォントを埋め込まないラテン文字 PDF
フォントを埋め込まないと指定しても、文
書中にアラビア文字が入っているとラテン文字についてもフォントが埋め込まれてしま
う。そこで、ラテン文字だけならどうなるかを調べた。
ラテン文字だけだとフォントの強制埋め込みは行なわない。このため Arabic Type
133
図 11 アラビア文字は強制的に埋め込む
図 12 フォント・プロパティ（アラビア文字埋め込み）
図 13 フォントを埋め込まないラテン文字 PDF
134
第 10 章 PDF とフォント
図 14 フォント・プロパティ（ラテン文字非埋め込み）
Setting を指定した部分が Adobe Sans MM フォントに置換されて表示されている。
このような結果を見ますと、Adobe Reader のフォントの選択は次のような問題があ
る。
1） Windows 環境にどのようなフォントがあるかをチェックして適切なフォントを
選択することを行っていない。
2） フォントを埋め込まずに PDF を作成すると、Arabic Type Setting のような特殊
なメトリックスをもつフォントが、まったく異なるメトリックスのフォントに置き
換えられている。
図 15 プロポーショナルフォントの縦書き
135
プロポーショナルフォントを使用した縦書き文書
Word 等でプロポーショナルフォ
ント MS P 明朝を使用した縦書き文書を Antenna House PDF Driver から PDF 出力
し、Acrobat（Acrobat 8 Pro）で表示すると、次のキャプチャのように文字がきれいに
揃わない（目立つ部分を赤い丸で囲っている）。
この問題は Adobe Reader の表示の問題のようで、Acrobat 6 ではこの問題は発生せ
ず元文書どおりに表示されますが、Acrobat 7 や 8 で表示すると上図のようになってし
まう。PDF Driver から出力した PDF だけではなく、Acrobat の Adobe PDF で作成し
た PDF でも同じ現象がおきる。プロポーショナルフォントは本来縦書きに使用するべ
きではないのだが、どうしても使用する場合はフォントを埋め込むことで問題を回避で
きる。
図 16 プロポーショナルフォントの縦書き（フォント埋め込み）
10.4.5 フォント埋め込みとフォントの権利保護
フォント埋め込みに関連して、
「フォント埋め込みは仮に部分埋め込みであっても著作
権侵害にあたるのではないか」という懸念がある。この問題について検討する。
フォントの著作権
まず、前提としてフォントに著作権があるのかということだが、
これについては著作権を認める判例がある。
136
第 10 章 PDF とフォント
海賊版フォントに対する判決
プログラムとしてのフォントデータの著作権を対象
平成１６年５月１３日大阪地裁　平成１５年（ワ）第２５５２号　著作権侵害に基
づく差止等請求事件
モリサワ勝訴
出典：大阪地裁「海賊版フォント搭載ＰＣ販売事件」（p. 244）
フォントの意匠・デザインに著作権がないと、万一の仮定をおいたとしても、アウト
ラインフォントはプログラムとデータから成り立っているので、プログラムと同じよう
に著作権で保護されてしかるべきだろう。
ビットマップフォントについても、
「東風明朝」の制作の元になったビットマップフォ
ントが無断で複製されたものであったことが判明したことにより、
「東風明朝」の制作・
配布活動が中止になったという例もある（「32 ドットビットマップフォントの無断複製
について」（p. 243））。
マイクロソフトは自社製品に同梱しているフォントには著作権があると判断している
と見られる。日本語フォントの取り扱いについては「フォントの再頒布や、お客様のソ
フトウェアでの使用等の権利処理については」フォントベンダーに相談して欲しいと述
べている。また、英文フォントについては各フォントの著作権者に相談して欲しいと述
べている4）。
このようなことからフォントについては著作権法が適用されると考えるのが妥当だろ
う。従って、PDF へのフォント埋め込みは、フォントのグリフデータ（アウトラインデ
ータ）の複製と再頒布にあたり、著作権者の許可なくフォントの埋め込みを行えば権利
侵害と看做されることになる。
著作権者は節度のあるフォント埋め込みは認める傾向
PDF のフォント埋め込みで
は、この問題をどのように解決しているのだろうか？
5）
まず、日本タイポグラフィ協会は、
「電子ドキュメントデータへのフォント埋込み機能
に対するタイプフェイス／フォントの権利保護に関する声明書」を出している。声明の
概要は次の通り（日本タイポグラフィ協会（p. 245））。
1） ユーザの立場においては、フォントの埋め込みは非常に有効かつ利便性が高い技
術革新である。
2） 配布されたＰＤＦに埋め込まれたフォントセットのプロテクトを外して使用し､
編集・校正することは、新たな文字組みを行うことになり、タイプフェイスの複製
4） 2012 年 1 月時点でリンク先がなくなっているので、再確認を要する
5） 以下の各情報について、最新の状況をチェックすること
137
行為が行われることを意味する。
3） 埋め込まれたフォントセットにより、タイプフェイスの複製・改変・二次的使用
がより一層簡単となる。
そして、ユーザには、
「埋め込んだフォントを用いて編集・校正などの新たな文字組を
行う行為」、フォント埋め込みを不可としているタイプフェイス権利のフォントを埋め込
まない、フォントが埋め込まれた PDF を配布するに際して、当該フォントの使用許諾契
約書に従うこと、を求めている。また、PDF へフォント埋め込み機能を有するプログラ
ムの供給者に対しては、ユーザに対して禁止されている行為を助けるようなソフトウェ
アを開発しないことを求めている。
PDF へのフォント埋め込みの提唱元であるアドビは自社でも多数のフォントを制作
して販売しているが、アドビの Web ページの「アドビ製フォントライセンス契約に関す
る FAQ（よくあるご質問）」にフォントのライセンスについての以下の情報が掲載され
ている。
「アドビからライセンスを受けたすべてのフォントは、電子ファイルに埋め込みが可能
です。」「しかし。。」として幾つか細かい条件が記述されていますが、原則として、埋め
込みして配布するだけであれば問題ないようようだ（アドビ・ソフトウェア使用許諾契
約書 Adobe Systems. “Adobe Far Eastern Fonts.”（p. 239））。
欧文フォント、和文フォントともフォント埋め込みに関する契約条項の文章は同じで、
次のようになっている。
お客様は、お客様の電子文書を印刷および閲覧するため、フォント・ソフトウェア
のコピーをその文書に埋め込むことができます。埋め込むフォント・ソフトウェア
が Adobe の ウ ェ ブ サ イ ト http://www.adobe.com/type/browser/legal/
additional_licenses.html で「編集可能な埋め込みのためのライセンス供与済」と
指定されている場合は、さらに電子文書の編集の他の目的のためにもそのフォン
ト・ソフトウェアのコピーを埋め込むことができます。
フォント埋め込み許可の分類
フォント埋め込みの許可には次の段階がある。
1） 埋め込みを許可しない — アドビのフォントには埋め込みを許可しないフォント
は見あたらないが、フォント・ベンダによっては許可していない場合もある。
2） 表示と印刷 — フォントを PDF に埋め込んで配布し、表示したり印刷に使うこと
ができるが、PDF を編集するのに用いたり、他の PDF を作成したりするのに用い
ることができない。アドビのフォントはこの分類が多い。
3） 編集可能 — 表示と印刷のほか、PDF の受け手がその PDF の文書や構造を編集す
るに用いることができる。
138
第 10 章 PDF とフォント
4） インストール可能 — 受け手が PDF に埋め込まれたフォントを PC にインストー
ルして、新しい PDF を作成するのに用いることができる。これは PDF の受け手は
フォントに関してオリジナルと同じ権利をもつことを意味している。商業フォント
ではこの分類に属するフォントは少ないだろう。
フォントファイルの埋め込み許可フラグによる制御 さて、以上のようにフォントの
埋め込みを許可したり、禁止したりするのは、フォントの権利者（ベンダ）の許諾事項
である。しかし、エンドユーザがフォントの使用許諾契約をチェックしたり、あるいは、
権利者にいちいち確認するのは手間が掛かる。これを自動的に行うために、TrueType
や OpenType といった新しいフォントでは、フォントファイルのフォーマットの中に
「埋め込み許可」に関する上記の (1)～(4) の分類情報がセットされるようになっている。
そして、PDF を作成するソフトウエアは、この「埋め込み許可」の情報をチェックし
て、埋め込みするかどうかを判断することができる。
Antenna House PDF Driver では「フォント」タブで、Windows にインストールさ
れているフォントの一覧を表示するとき、埋め込みが禁止されているかどうかをチェッ
クして鍵のマークで表示している。
図 17 埋め込みフォントの選択
比較的新しいフォントであれば、このようにプログラムで埋め込み許可状態をチェッ
クできるが、Type1 のような古いフォントには、こうしたフラグはないので、権利者が
許可しているかどうかを個別に確認する必要がある。
139
10.4.6 フォント埋め込みについての Q&A
＜質問＞ PDF への出力におきまして「帳票の印字を MS 明朝の太字で統一したい」と
いう要求がありますが、私の認識では「対応するためには、市販のフォントを購入し、
PDF の表示を行なう PC 上にインストールする必要がある」と考えていますが、何か対
応策は、あるのでしょうか？
＜回答＞ PDF 作成時にフォントを埋め込むことで、PDF を表示する環境にフォント
は不要となります。
但し、前提条件があります。
（１）PDF 作成ソフトが、フォント埋め込み機能を実装していること。
（２）PDF 表示
ソフトが、埋め込んだフォントを使って表示する機能を実装していること。
＜質問＞フォント埋め込みをおこなった場合は、対象フォント全体が PDF ファイルに
埋め込まれることになり、ファイルサイズがかなり大きくなりますか？その PDF で使用
しているフォントだけが埋め込まれるということでは無いですね？＜回答＞　フォント
埋め込みは、ソフトによって実装方法は違うと思いますが、アンテナハウス製品の場合
は、欧文フォントは文書の中で使用しているフォントの全文字を埋め込みます。
和文フォントの場合は、文書中で使用しているフォントの中で、さらに使用している
文字のグリフアウトラインデータのみを PDF に埋め込みます。（サブセット埋め込み）
従いまして、PDF ファイルは、それほど大きくはなりません。なお、他社の製品でフ
ォントをどのように埋め込んでいるかは、その会社にご確認いただく必要があります。
140
第 11 章 図形の取り扱い
11.1 カ ラ ー 空 間
PDF では次の種類のカラー空間を使うことができる。
デバイス・カラー空間
DeviceCMYK、DeviceRGB、DeviceGray
CIE ベース・カラー空間
CalGray、CalRGB、Lab、ICCBased
特色空間
Pattern、Indexed、Separation、DeviceN
※参考 PDF Reference Fifth　Edition 4.5.2 Color Space Families
デバイス・カラー空間とは、出力デバイスが出力する色や陰を直接指定するものであ
る。
※参考 PDF Reference Fifth　Edition 4.5.3 Device Color Space
CIE ベース・カラー空間とは、Commission Internationale de l’Éclairage という
国際機関が決めた色の標準で指定する方式である。
141
第 12 章 PDF のファイルサイズ
12.1 PDF の中のデータ圧縮
12.1.1 PDF で扱える圧縮方式
表を作ってみると次のようになる。
表 1 PDF で扱える圧縮方法
PDF で使える圧縮方法
種類
カラーとグレースケール
JPEG
白黒イメージ
CCITT (G3、 G4)、 RunLength, JBIG2
テキスト、線画、イメージ LZW、 Flate (ZLIB)
※PDF Reference Fifth Edition　2.2.2 Compression　p.15
JBIG2 は、Joint Bi-level Image experts Group（p. 241）が開発したモノクロイメー
ジの圧縮方式である。
LZW, Flate (ZLIB), RunLengh, CCITT, JPEG
※PDF Reference Fifth Edition 4.8.6 Inline Images　pp 322- 325
143
第 13 章 PDF のメタデータ
13.1 ドキュメント情報辞書
PDF のメタデータは二通りの持ち方がある。ひとつはドキュメント情報辞書として
もつものであり、他のひとつは、メタデータ・ストリームとしてもつものである。
13.1.1 ドキュメント情報辞書
ドキュメント情報辞書に登録した情報の多くは、Adobe Reader で PDF を表示した際
に文書の「プロパティ」に表示される。次の項目を設定できる。
●
Title（タイトル）
●
Author（著者）
●
Subject（主題）
●
Keywords（キーワード）
●
Creator（オリジナルのドキュメントを作成したアプリケーション）
●
Producer（PDF を作成したアプリケーション）
●
CreationDate（作成日）
●
ModDate（修正した日）
●
Trapped（トラップ処理が行われたかどうか）
トラップ処理が行われたかどうかはちょっと異色である。これは印刷のワークフロー
で使うものなので、一般向けではなく、Adobe Reader では確認できない。
13.2 メタデータストリーム
PDF には、ドキュメント情報辞書を使ってファイルにメタデータを付与するのとは別
の方法で、「metadata stream」によってメタデータを付加することができる（ ISO
32000-1:2008. “14.3.2 Metadata Streams.”（p. 240））。
PDF のコンテンツの種類の一つにストリーム・オブジェクトという一塊のデータに相
当するものがあり、metadata stream はストリーム・オブジェクトの中の一種類である。
metadata stream の内容にはメタデータを「Extensible Metadata Platform (XMP)」
145
という XML 形式で記述する。
PDF ドキュメント全体を管理する部分に metadata stream を付けることもできるし、
PDF ドキュメントを構成する部品単位でもメタデータを付与することができる。
metadata stream の作成方法は、XMP 仕様書の中の XMP パケットを PDF に埋め込む
という項に説明されている。
原則として、実際の情報を含むような、あらゆる PDF のストリームや辞書にはメタデ
ータを付与することができるが、このため、却って、どのストリームにメタデータを付
与するべきかが曖昧になってしまう。そこで、データを実際に持っているオブジェクト
にできるだけ近い位置にメタデータをつけるべきとされている。
このように metadata stream を PDF 中のコンポーネント・データ毎に付与して、大
きな文書の中に埋め込む部品単位メタデータを持たせることができるのは、PDF ワーク
フローを構築する際に部品の管理などに使うことを意図している。メタデータ仕様
XMP が、PNG、JPEG、GIF などのグラフィックスファイルに付与できるものとなって
いることとも関係する。
13.3 XMP 仕様について
XMP の仕様書とツールキットは、アドビシステムズから公衆特許ライセンスで提供さ
れている。ツールキットについては誰でもソースコートを改良してアプリケーションに
組み込んで再頒布できるとされている（Adobe Systems. Adobe XMP Developer Center.
（p. 239））。
XMP は、次のような XML テキストである。
●
ルート要素は xmpmeta（オプション）でその下位の唯一の要素として rdf:RDF を
もつ。恐らく、xmpmeta は旧バージョンとの互換性のために残されているもので、
最新版では、rdf:RDF がルート要素として取り扱われる。
●
rdf の名前空間宣言は、xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntaxns#'。XMP では W3C の RDF（Resource Description Framework）を利用してい
る。
●
rdf:RDF の 子 供 の 要 素 と し て rdf:Description を 複 数 記 述 で き る 。 こ の
rdf:Description 毎にひとつのメタデータ・スキーマを利用して、リソースの属性を
記述することができる。
146
第 13 章 PDF のメタデータ
13.3.1 メタデータ・スキーマ
XMP の仕様書には、メタデータ・スキーマとして次のものが定義されている。
●
“Dublin Core Schema”
●
“XMP Basic Schema”
●
“XMP Rights Management Schema”
●
“XMP Media Management Schema”
●
“XMP Basic Job Ticket Schema”
●
“XMP Paged-Text Schema”
●
“XMP Dynamic Media Schema”
●
“Adobe PDF Schema”
●
“Photoshop Schema”
●
“Camera Raw Schema”
●
“EXIF Schemas”
これ以外にも、独自の新しいスキーマを定義したり、既存のスキーマを拡張すること
ができる。
記述例
XMP 仕様書には、EXIF リソースの XMP による記述例が掲載されている。
EXIF はデジタルカメラで使用するイメージファイルの標準であり、EXIF で作成された
リソースの特性について、TIFF のスキーマによる属性、EXIF のスキーマによる属性の
ふたとおりの記述がなされている。
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntaxns#">
<rdf:Description xmlns:tiff="http://ns.adobe.com/tiff/1.0"
about="" tiff:Make="Canon" tiff:Model="Canon PowerShot S300"
tiff:Orientation="1"
tiff:XResolution="180/1" tiff:YResolution="180/1"
tiff:ResolutionUnit="2"
tiff:DateTime="2001-07-25T20:18:27-07:00"
tiff:YCbCrPositioning="1">
</rdf:Description>
<rdf:Description xmlns:exif="http://ns.adobe.com/exif/1.0"
about=""
147
exif:ExposureTime="1/60" exif:FNumber="27/10"
exif:ExifVersion="0210"
exif:DateTimeOriginal="2001-07-25T20:18:27-07:00"
exif:DateTimeDigitized="2001-07-25T20:18:27-07:00"
exif:CompressedBitsPerPixel="3/1"
exif:ShutterSpeedValue="189/32"
exif:ApertureValue="93/32" exif:ExposureBiasValue="0/3"
exif:MaxApertureValue="187820/65536"
exif:SubjectDistance="913/1000"
exif:MeteringMode="5" exif:Flash="1"
exif:FocalLength="173/32">
<exif:ComponentsConfiguration>
<rdf:Seq>
<rdf:li>1</rdf:li>
<rdf:li>2</rdf:li>
<rdf:li>3</rdf:li>
<rdf:li>0</rdf:li>
</rdf:Seq>
</exif:ComponentsConfiguration>
</rdf:Description>
</rdf:RDF>
13.3.2 メタデータをリソースに埋め込むための仕様
XMP の仕様書でメタデータを埋め込む方法を説明しているリソースの種類は次のと
おり。
●
TIFF
●
JPEG
●
JPEG 2000
●
GIF
●
PNG
●
HTML
●
PDF
148
第 13 章 PDF のメタデータ
●
AI (Adobe Illustrator)
●
SVG/XML
●
PSD (Adobe Photoshop)
●
PostScript と EPS
●
DNG（Digital Negative）
これらのリソースに XMP メタデータを埋め込むときは、次のように XMP メタデータ
の前後を<?packet ..?>という命令で囲ってパケット化する。
<?xpacket begin="バイト・オーダー・マーク"
id="W5M0MpCehiHzreSzNTczkc9d"?>
XML テキスト化した XMP メタデータ
<?xpacket end="w"?>
上のバイト・オーダー・マークの部分は、U+FEFF を XMP メタデータと同じ符号化
方式（UTF-8、UTF-16、UTF-32）で符号化したデータである。
13.3.3 メタデータの取得方法
パケット化したデータは、各リソース・ファイルの中に埋め込むことが推奨されてい
る。画像ファイルのようなバイナリ・ファイルに埋め込んだ場合、画像ファイルの形式
について知らない場合でもファイルのバイナリ・データをスキャンして XMP パケット
を見つけ出すことができなければならない。XMP 仕様書には、<?packet ..?>命令を見
つけて XMP メタデータを認識するための、スキャンの方法についても説明されている。
また必要であれば、XMP メタデータを埋め込まずに、リソースの外部においてリソー
スと関係つけることもでる。外部に置く場合、XMP メタデータ・ファイルの拡張子
は.xmp とし、MIME タイプが必要な場合は、application/rdf+xml を使うことになって
いる。
149
第 14 章 PDF の配布と閲覧
14.1 PDF を Web 表示用に最適化
14.1.1 PDF の表示が遅い、重いのはなぜ？
Web ページで配布されている PDF をブラウザで開いてみるとき、PDF のページが表
•
•
示されるまでに時間がかかって重いという現象をもつことがある。PDF が重くなって
しまう原因には様々なことが考えられる。
多くの PDF 作成ソフトには Web 表示用に最適化という設定がある。これを「オフ」
の状態で作成した PDF を Adobe Reader などで表示するには PDF ファイルの最後まで
読まないと表示開始できない。ページ数が多くファイルの容量が大きい PDF だと目の
前の画面に内容が表示されるまでの待ち時間が長くなる。これが PDF が重いという印
象を持たれ敬遠される理由のひとつである。
14.1.2 Web 表示用に最適化とは
Web 表示用に最適化は、リニアライズド PDF とも言い、Web 経由で PDF をできるだ
け早く表示するために PDF1.3（PDF リファレンス 1.2）から導入された機能である。
リニアライズしていない PDF では PDF リーダがファイルの内容を表示する際は、PDF
ファイルの最後まで読まないと表示を開始できない。このため、ファイルの容量が大き
い（ページ数の多い）PDF を Web 経由で表示しようとすると、ファイルを全部ダウン
ロードするまで、画面には内容がまったく表示されない。この対策として追加されたの
がリニアライズド PDF である。
Web 表示用に最適化は次のような意図で追加された（ISO 32000-1:2008. Annex F.
（p. 240））。
●
PDF を開くとき、最初のページを可能な限りすばやく開く。最初のページとして、
先頭ページでなくて任意のページを指定できる。
●
ユーザが開いたページから別のページを要求したとき、可能な限りすばやくそのペ
ージを開く。
●
文書を遅い通信回線を使って配布するとき、ページを少しづつ順に表示できるよう
にする。
151
●
リンクを辿るときに、全てのページを受信して表示しなくても良いようにする。
なお、オプション機能なので Web にアップする PDF を作る時はこれを意識して作成
しなければならない。
Web 表示用に最適化されているか確認するには
Web ページで配布されている PDF
のページが表示されるまでに時間がかかると感じた場合、リニアライズド PDF かどうか
を確認してみると良い。
Adobe Reader で PDF のプロパティを見ると「Web 表示用に最適化」という項目が
ある。
図 1 PDF のプロパティ
14.1.3 リニアライズの仕組みと利用方法
PDF をリニアライズする処理では、出来上がった PDF ファイルの内容を並び替え処
理を行い、先頭に PDF の内容の場所を知るための情報を追加する。このため、リニアラ
イズ処理済の PDF を暗号化したり、PDF の内容を書き換えたりすると、リニアライズ
ド PDF でなくなってしまうので、再び、リニアライズし直しすることが必要となる。
指定ページの直接表示
PDF がリニアライズ（Web 最適化）されていると、クライ
アントから Web 上の PDF の指定ページを高速に表示することもできる。例えば、Web
ブラウザで PDF の 100 ページをいきなり表示したいならば、ブラウザの URL に次のよ
うにページ番号を指定する。
PDF ファイルの URL#page=100
リニアライズしてない PDF で、ページ番号を指定すると PDF ファイル全体をダウン
ロードしてから Adobe Reader が 100 ページ目にジャンプして表示するが、リニアライ
ズした PDF では全体をダウンロードすることなく 100 ページ目を表示できるので、表
示するまでの待ち時間が短くなる。
152
第 14 章 PDF の配布と閲覧
バイトサービング
通信回線が遅く、また、端末のメモリ容量が小さいときなどは、
リニアライズした PDF をページ単位で端末に送信するバイトサービングを使うことが
できる。但し、バイトサービングを使うにはサーバ側で PDF を 1 ページずつ送り出して
くれる機能が必要である。
NTT ドコモの FOMA には、PDF ビューア（Acrobat LE）が搭載されているものがあ
り、こうした端末で大きな PDF を表示しようとすると、リニアライズとバイトサービン
グを組み合わせてページ単位にダウンロードするようなことが必要である1）。
14.2 PDF のアクセシビリティ
14.2.1 アクセシビリティとは
W3C の「ウェブコンテンツ・アクセシビリティ原則 2.0」
（“Web Content Accessibility
Guidelines (WCAG) 2.0, W3C Recommendation.”（p. 243））は、広範な障害をもつ人
々がウェブの内容によりアクセスしやすくするためのガイドラインを定めている。この
ガイドラインに従うことで高齢者にもウェブの内容を使いやすくなり、さらには一般の
人にとっても利用し易くなる。
WCAG 2.0 ではウェブページとは、単なる静的な HTML だけではなく、動的なウェ
ブページをも含むものとしている。そして、ウェブコンテンツ技術には、マークアップ
言語、データ形式、プログラミング言語を含み、その例として、HTML、CSS、SVG、
PNG、PDF、Flash、JavasScript を挙げている。
WCAG 2.0 は最上位に①認知しやすさ、②操作しやすさ、③理解しやすさ、④確固と
していることの 4 原則を掲げている。
●
認知しやすさとは、画像・オーディオ・ビデオのような非テキスト・コンテンツに
代替テキストを提供すること
●
操作しやすさとは、ユーザーインターフェイスやナビゲーションがキーボードなど
で操作できなければならないこと
●
理解しやすさとは、情報やユーザーインターフェイスの言語・単語・略語などが理
解できなければならないこと
●
確固としているとは、内容が多様なユーザーエージェント（ブラウザや支援技術な
ど）で期待通りに解釈できること
各原則の下にウェブの制作者が守るべき詳しいガイドラインを示している。また、
1） この記事は 2006 年のものなので 2012 年の時点では事情が変わっていると思われる。
153
WCAG2.0 勧 告 に 適 合 す る 方 法 の ガ イ ド が 実 装 方 法 集 と し て 提 供 さ れ て い る
（“Techniques for WCAG 2.0”（p. 243））。実装方法ガイドには一般的な項目と技術別の
項目がある。PDF 技術の実装については次の 23 項目のテクニックを挙げており、それ
ぞれの作成テクニックや PDF の辞書の作り方に関して詳しい解説がある。
1） PDF の構造関連
①
しおりを作成する（5.3 しおり（p. 54））
②
ドキュメント情報辞書内の Title エントリに文書のタイトルを指定する
（13.1 ドキュメント情報辞書（p. 145））
③ ドキュメントカタログ内の /Lang エントリを使用してデフォルト言語を設
定する
④
Lang エントリを使用して節や句の言語を指定する
⑤
ランニング・ヘッダーとフッターを提供する
⑥
一貫性のあるページ番号を指定する
⑦
/Link 構造エレメントを使用してリンクとリンクテキストを提供する
⑧
略語には構造エレメントの E エントリによって定義を提供する
2） 代替テキスト
①
画像には、Alt エントリによって代替テキストを適用する
②
スキャンされた PDF 文書では OCR を実行し、テキストを生成する
③
リンクに対しては、Alt エントリを使用して代替テキストを提供する
3） タグ付き PDF
① 正しいタブ順序と読み上げ順序を確保する
② 装飾的な画像は、Artifact タグ2）によってタグ構造から削除する
③
テーブルのマークアップにはテーブルエレメントを使用する
④
コンテンツを見出しタグでマークアップすることによって見出しを作成する
⑤
間違ってタグ付けされているテーブルを修復する
⑥
文書のリストにリストタグを使用する
4） フォーム関連
①
フォームでは、必須項目のフォーム・コントロールを特定する
②
インタラクティブなフォーム・コントロールには、ラベルを付ける
③
フォームフィールドには、名前、役割、値情報を提供する
④
フォームには、送信フォームアクションのある送信ボタンを提供する
2） 作者が意図的にいれたものではなく組版処理などで機械的に作成したもの、例えば柱や本文と脚注の区切
り罫など、をアーティファクトと言う。
154
第 14 章 PDF の配布と閲覧
⑤
ユーザーの入力が PDF フォーム内の必須形式または必須値の範囲外になる
場合を指定する
⑥
インタラクティブなフォーム・コントロールを提供する
上記のリストは“Techniques for WCAG 2.0”のウェブアクセシビリティ基盤委員
会・実装ワーキンググループによる日本語訳をもとに作成したものである。
上述の 23 項目のテクニックの中で、OCR によるテキスト化とリンクの代替テキスト
以外は「タグ付き PDF」に対して適用することになっている。このようにアクセシブル
な PDF 作成で中心になるのはタグ付き PDF である。
14.2.2 スクリーン・リーダへの許可
この 23 項目には掲げられていないが、スクリーン・リーダが PDF を読み上げるには
テキスト情報を取り出す必要がある。そこでデータの利用を禁止した PDF はアクセシ
ブルではないことになる。PDF にはオーナーパスワードによりデータを取り出したり
利用することに制限をつける機能がある。これについては、PDF1.4 以降（128 ビット
暗号方式）は、オーナーパスワードを設定するとき、テキストの再利用禁止の例外とし
てスクリーン・リーダなどのデバイスに対してはテキストの抽出を認める設定もできる
ようになった。
14.2.3 PDF が備えるアクセシビリティ支援機能
この他、PDF には視覚障害者がスクリーンリーダや TTS（テキストツースピーチ）エ
ンジンを使いやすくするために、自然言語の指定、画像などのための置換テキストの指
定、略語や頭字語を展開するための指定の機能がある。
14.3 PDF における JavaScript
PDF の動作を制御する方法について整理する予定
155
第 15 章 PDF を編集・加工する
15.1 PDF のページ内容を編集する
15.2 PDF を用紙として使う
15.3 PDF の注釈
PDF の注釈はメモ、音声、動画などを PDF の特定の位置に関連付けてマウスやキー
ボードで対話する方法を提供する（ISO 32000-1:2008 12.5 Annotations（p. 240））。次
のような特長をもつ。
●
注釈はページ単位に管理されている。
●
注釈は境界線の属性、アイコンの背景とタイトルバーなどへの色、を設定すること
ができる。
●
注釈の外観（見え方）のデータを添えることができる（PDF1.3 から）。
注釈は PDF ファイル上は本文とは別になっていており、PDF を作成したあとにコメ
ントを付け加えたり、削除したりといった編集が簡単にできるように配慮されている。
15.3.1 注釈のタイプ
PDF では表に示すような沢山の種類のコメント（注釈）機能が規定されている。
表 1 主な注釈
注釈の種類
テキスト注釈
特長
PDF の指定位置に貼り付けるメモ。閉じるとアイコンとして表示。開
くとポップアップ・ウインドウとしてテキストを表示する。
リンク注釈
ハイパーリンクまたはアクションを表す
フリーテキスト注釈
ページの上にテキストを表示する。閉じた状態はなく、常にテキストが
見える。①フリーテキスト、②吹き出しテキスト、③タイプライター・
テキストの 3 種類がある。
線
直線を表す。キャプションを置くことや終端の形状の指定ができる。
開くとポップアップ・ウインドウとしてテキストを表示する。
矩形と楕円
矩形と楕円を表す。線の幅やダッシュの形状を指定できる。開くとポ
157
ップアップ・ウインドウとしてテキストを表示する。
多角形と折れ線
折れ線で最初の点と最後の点を結合すると多角形となる。開くとポッ
プアップ・ウインドウとしてテキストを表示する。
テキストマークアップ
ハイライト、下線、消し線。開くとポップアップ・ウインドウとしてテ
キストを表示する。
スタンプ注釈
ゴム印のようなスタンプ外観をもつ注釈。外観データを使って様々な
スタンプ形状を持たせることができる。開くとポップアップ・ウインド
ウとしてテキストを表示する。
インク注釈
フリーハンドの落書き。開くとポップアップ・ウインドウとしてテキス
トを表示する。
ファイル添付注釈
PDF に埋め込むファイルなどへの参照を含む。
音声注釈
録音した音声を含み、開くと音声が流れる。
動画注釈
アニメや動画を含み、開くと動画を再生する。
スクリーン注釈
マルチメディアを再生する場所を示すための注釈。印刷するための外
観データの参照も規定する。
ウィジット注釈
対話フォームのフィールドの外観を示す。
プリントマーク注釈
トンボに付随するシンボルなどを表すための注釈。
トラップ・ネット注釈
ページを印刷する際のカラー効果などの問題をなくすためのトラッピ
ング特性を規定するための注釈。
ウオーターマーク注釈
ページの上に固定サイズの透かしを印刷するための注釈。
3D 注釈
3 次元の図柄を表示するための手段を規定する注釈。3 次元データへ
の参照や初期表示のためのデータなど規定する。
削減のための注釈
文書から削除を意図するための注釈。
PDF 注釈の機能をほかの機能と組み合わせて高度な機能を規定できる。たとえばス
タンプ注釈には、外観規定機能を使って様々なスタンプの形状を添えたり、注釈機能の
カスタム化ができる。
大部分の注釈にはテキストを添えることができる。こうしたタイプは、マークアップ
注釈という。マークアップ注釈でないものの多くは、アクセシビリティの観点からコン
テンツに代替テキストを含める機能が用意されている。
また、スクリーン注釈、ウィジット注釈、トラップ・ネット注釈、3D 注釈など、注
釈とは異なる他の機能と一緒になって、それを実現するための補助的な情報を記録する
ために用いるものもある。
15.3.2 注 意 事 項
注釈は PDF の本文オブジェクトとは別扱いになっているので、既存の PDF に簡単に
付加できるメリットもあるが、一方で、注釈を表示できない PDF リーダもある。たと
158
第 15 章 PDF を編集・加工する
図 1 スタンプ注釈（Acrobat 9 Pro）
えば、iBooks の PDF 表示機能では注釈を表示することができない1）。このように注釈
による情報交換には注意が必要である。
1） iBooks 3.1 まで確認。
159
第 16 章 PDF の利用を制限する
16.1 PDF のパスワード方式セキュリティ
PDF にはセキュリティ設定の仕組みが標準で規定されている。もっとも代表的なも
のはパスワード方式（共通鍵暗号方式）である。PDF を作成する人と、PDF を利用する
人の間で取り決めた共通のパスワードを使って、PDF の内容へのアクセスを制御する。
なお、サーバを使って、個々の PDF へのアクセスをきめ細かく制御する方式も様々に
提供されている。これは PDF に標準で用意されている方式ではない。
本節では PDF でセキュリティを、①どうやって実現しているかということと、②何が
できるのか、ということについて整理する。
PDF のファイルには、さまざまなテキスト文字列、イメージ、線画などのコンテンツ
情報が入っている。そのコンテンツを整理して、ランダムにアクセスするための構造情
報がある。
PDF にセキュリティをかける場合は、一定の暗号化アルゴリズムを使って PDF を暗
号化するが、PDF のファイル全体に暗号をかける訳ではない。通常は、コンテンツにな
るデータのみに暗号をかけ、構造情報は暗号化しない。こうすることで、暗号が掛かっ
ている PDF ファイルを認識して、暗号を解くことができるようになっている。
16.1.1 暗号辞書とセキュリティ・ハンドラ
PDF のセキュリティの方式は次のようになっている。
暗号辞書
PDF に暗号が掛かっているときは、PDF ファイルのトレイラに暗号辞書が
登録される。PDF を利用するときは、作成ソフトと消費ソフトが異なるので、お互いに
暗号の方式についての情報を交換する必要があり、この交換すべき情報を暗号辞書の内
容に設定する。PDF にこの暗号辞書がないならば、暗号化されていないことになる。
セキュリティ・ハンドラ
暗号辞書には、セキュリティを処理する方法（セキュリテ
ィ・ハンドラ）についての情報を登録できる。セキュリティ・ハンドラとは、文字通り
PDF に 対 す る セ キ ュ リ テ ィ を 取 り 扱 う プ ロ グ ラ ム ・ モ ジ ュ ー ル で あ る （ ISO
32000-1:2008（p. 240））。
PDF 仕様には、①パスワード方式の暗号化を扱う標準セキュリティ・ハンドラ（ 7.6.3
161
Standard Security Handler の項）と②公開鍵－秘密鍵ペアによる暗号化を扱う公開鍵
セキュリティ・ハンドラ（7.6.4 Public-Key Security Handlers の項）が規定されてい
る。また、それ以外の独自セキュリティ・ハンドラを使うこともできる。
標準セキュリティ・ハンドラ
パスワード方式で、PDF へのアクセス許可を設定可能
とし、それを処理する。PDF の仕様では次の 2 種類のパスワードを設定できる。
1） オーナーパスワード—編集パスワードとも言い、PDF の内容を修正したり、デー
タを取り出したりなどの制限事項を設定する。
2） ユーザーパスワード—閲覧パスワードとも言い、PDF を表示して読むことができ
るための閲覧許可を与える。
PDF を作成する人が、PDF 作成時にパスワードを設定する。
もし、ユーザーパスワードが設定されていると、PDF を利用する人が正しいパスワー
ドを入れないと、PDF を表示することができない。
オーナーパスワードが設定されている場合は、パスワードを入力しなくても、制限事
項に設定されている範囲で PDF を利用することができるが、それ以外の目的に利用する
ためには、正しいオーナーパスワードを入力することが求められる。
この制限事項は、セキュリティ・ハンドラのリビジョンによって、具体的に設定でき
る内容が異なる。作成する PDF のバージョンによって、設定できる標準セキュリティ・
ハンドラのリビジョンが決まり、そして、その PDF を正しく閲覧・処理できるかは、
Adobe Reader なり PDF ビューアが内蔵している標準セキュリティ・ハンドラのリビジ
ョンで決まる。
標準セキュリティ・ハンドラがなにをなすべきかは PDF の仕様書（ISO 32000-1:2008
（p. 240））に規定されている。あるソフトウエア製品が PDF のパスワード方式セキュリ
ティを正しく処理できるとは、PDF 仕様で規定する標準セキュリティ・ハンドラのリビ
ジョン（の機能）を、その製品に実装していることを意味していることになる。
16.1.2 PDF の利用許可制御
PDF 作成者は、PDF にオーナーパスワードを設定するときに、PDF を受け取ったユ
ーザが PDF に対してできることを設定する。PDF 利用許可の内容は、PDF に保存され
る暗号辞書中のフラグのある桁をオンにすることで設定する。
標準のセキュリティ・ハンドラには、リビジョン番号 2、3、4 の 3 種類がある。リビ
ジョン 2 は 40 ビットの暗号方式、リビジョン 3 は PDF 1.4 から使用可能になった 128
ビットの暗号方式、リビジョン 4 は PDF 1.5 から使用可能である。
次の表はリビジョン 2 で設定できる項目である。
162
第 16 章 PDF の利用を制限する
表 1 リビジョン 2 の標準セキュリティ・ハンドラで許可できること
ON の時許可
ビット位置
３
印刷を許可する
４
内容の変更を許可する
５
テキストや画像の抽出を許可する
６
テキスト注釈の追加・変更と対話式フォームフィールドを埋めることを許可
する。ビット 4 が ON ならば、新しい対話式フォームフィールドを作成した
り、変更することも許可する
次の表はリビジョン 3 と 4 で設定できる項目である。リビジョン 3・4 の標準セキュ
リティ・ハンドラの方が、リビジョン 2 よりも詳細な許可設定ができる。
表 2 リビジョン 3・4 の標準セキュリティ・ハンドラで制限できること
ビット位置
ON の時許可
３
印刷許可する—さらにビット 12 が ON なら高精度印刷を許可、OFF なら低
解像度印刷を許可 (*)
４
内容の修正を許可する
５
アクセシビリティ以外の目的でテキストや画像の抽出を許可する (*)
６
テキスト注釈の追加・変更と対話式フォームフィールドを埋めることを許可
する。ビット 4 が ON ならば、新しい対話式フォームフィールドを作成した
り、変更することも許可する
７
ビット６が不許可でも、署名を含め対話式フォームフィールドを埋めること
を許可する (*)
10
アクセシビリティの目的（スクリーン・リーダなど）でテキストや画像の抽
出を許可する (*)
11
ビット４（内容の修正）が不許可の時でも、文書の合成を許可する—ページ
挿入・ページ回転・ページの削除・しおりの作成・サムネイルの作成 (*)
12
高精度印刷を許可する
16.1.3 リビジョン 4 標準セキュリティ・ハンドラ
PDF 1.5 以降ではリビジョン４の標準セキュリティ・ハンドラを使うことができる。
この標準セキュリティ・ハンドラで追加になっている機能は次の点である。
1） PDF 1.5 の仕様で追加された、暗号フィルター辞書（CryptFilter）機能を使用で
きる
2） 暗号辞書の中で、PDF の中のストリング、ストリーム、添付ファイルに対して使
用する暗号フィルターを個別に指定できる。なお、添付ファイルについては
163
PDF1.6 から
3） 暗号辞書の中で、メタデータを暗号化するかどうかを指定できる。なにも指定し
ないと、メタデータも暗号化するが「メタデータは暗号化しない」ようにすること
も指定できる
レビジョン 4 で追加されたのは、PDF に関するパスワードによるアクセス管理ではな
く、むしろ PDF コンテンツへの暗号のかけ方をより細かく設定可能にする機能といえ
る。
暗号フィルター辞書
暗号フィルター辞書は、PDF 1.5 から追加された仕様で、暗号
フィルターを定義するもの。その役割は、主に使用する暗号アルゴリスムの指定、暗号
フィルターを適用するタイミングの指定などである。
PDF の暗号化では、これまで RC4 暗号アルゴリズムを使っていたが、PDF 1.6 から
新しい暗号アルゴリズム AES（Advanced Encryption Standard）も使えるようになっ
た。暗号フィルターで、使用するアルゴリズムを RC4 にするか AES にするか指定でき
る。また、暗号化しないでスルーする暗号フィルターを定義することもできる。
16.1.4 AES（Advanced Encryption Standard）
AES 暗号は、米国が 2001 年に標準として定めた新しい暗号アルゴリズムである。米
国でそれまで使っていた標準暗号方式が、技術進歩により脆弱になったため、世界中か
ら公募した 15 種類の暗号方式から選択されたもので、最終的にベルギーの研究者が考
案したものが採用された、とある（Institute of Standards and Technology（p. 242））。
従来、PDF で使われていた暗号アルゴリズム RC4 は、私企業のプライペートな暗号
アルゴリズムであったのに対して、AES は、政府が標準として定めた暗号アルゴリズム
であり、仕様書が一般に公開されているのが大きな特徴である。
16.2 公開鍵と秘密鍵でセキュリティ設定
PDF 仕様の 7.6 暗号化の項には、パスワード・ベースの標準セキュリティ・ハンドラ
の他に、7.6.4 公開鍵セキュリティ・ハンドラという、もうひとつのセキュリティハン
ド ラ が 規 定 さ れ て い る （ ISO 32000-1:2008. 7.6.4 Public-Key Security Handlers
（p. 240））。
公開鍵セキュリティ・ハンドラは、公開鍵暗号化技術を使って PDF にセキュリティを
かける方式である。
公開鍵暗号化技術とは、例えば、A と B の 2 者間で、次のような順序で暗号化通信を
164
第 16 章 PDF の利用を制限する
行なうものである。
1） B は、公開鍵と秘密鍵のペアを用意する。このふたつの鍵は、まったく異なる鍵
であるが、一方で暗号化したものは他方の鍵でしか、暗号解除することができない
2） B は、公開鍵の方をインターネットやメールなどを通じて、公開する。秘密鍵は、
外部に漏れないように保持する。
3） A は、B の公開鍵を使って文書を暗号化し、暗号化した文書を B に送信する。
4） B は、A から受け取った（暗号化された）文書を、秘密鍵を使って暗号を解除する。
この通信方式は、電子署名（デジタル署名）とは鍵の使い方が逆になっている。ちな
みに、電子署名は、秘密鍵で暗号化したものを相手に渡し、相手は、公開鍵で暗号を解
除するものである。
さて、PDF の公開鍵セキュリティ・ハンドラは次のようなことを行う。
1） PDF の文書コンテンツを暗号化するときに使用する暗号キーの元と、PDF を送信
する相手（複数人）の PDF の利用権限（相手によって変えることができる）設定デ
ータを用意する。
2） PDF を送信する相手の公開鍵を入手する。複数のときは、公開鍵は相手毎に異な
ったものになる。
3） １で用意したキーと相手の利用権限設定データを、相手毎に、各人の公開鍵を使
って暗号化する。それらの暗号化されたデータをまとめて、受信者データ表として
作成する
4） PDF の暗号化辞書に 3 で作成した受信者データ表を記録する
5） こうして作成した暗号化済 PDF を、相手に配信する
PDF を受け取った相手は、各人の秘密鍵を用いて、受信者データ表の中から暗号キー
の元と自分用の利用権限データとを取り出す。この暗号キーの元を使って、PDF の暗号
を解いて PDF を閲覧する。この時、自分用の利用権限データが有効になり、PDF の配
信元が設定した利用権限の範囲内でしか PDF を利用できないことになる。
パスワード方式の標準セキュリティ・ハンドラでは、PDF の受け手によって利用権限
を変更することができないが、公開鍵セキュリティ・ハンドラを使うと相手によって利
用権限を変えることができる。
16.3 PDF 配布物の著作権保護
PDF を企業内の電子文書として流通させたり取引先に提供する場合には、機密情報を
保護したい。一方、出版社などの場合、PDF として配布される情報自体は機密情報では
165
ないが、著作権などの権利保有者の立場として、正当な権利を逸脱した不正なコピーを
防ぎたい。
このようなとき、PDF を配布したときの権利保護はデジタルライツマネジメント
（DRM）の仕組みを使うことが多い。DRM は様々な方式の製品やサービスが提供され
ている。
デジタルデータ自体はいったん配布された後の複製を防ぐのは難しい。そこで PDF
入手した相手が閲読しようとするときにその相手が正当な権利をもっているかどうかを
確認し、正当な権利を持たない場合には開いてみることができないようにする方式が一
般的である。
166
第 17 章 印刷ワークフローにおける PDF
17.1 印刷と PDF
DTP ソフトの誕生した時期には、DTP で作成した出版物を PostScript ファイルとし
て保存し、PostScript ファイルを印刷会社に渡して、印刷会社では PostScript ファイル
を印刷の入稿データとしていた。印刷会社では PostScript インタープリタを搭載した
高機能なレーザプリンタで印刷用のフィルムを作るという生態系が誕生したのである。
こうして、アドビの PostScript はこの 20 年ほどの間に印刷業界の仕事をがらりと変え
てしまった。
PDF は PostScript をベースに生まれたものであるが、いまでは PostScript ファイル
の代わりに PDF ファイルを使って同じ生態系ができている。当初は PostScript を使っ
てワークフローを構築した印刷会社は、2000 年代初頭には PDF によるワークフローに
移行した。
17.2 PDF/X ファミリー
PDF/X ファミリーは ISO 15930 の番号がついている。印刷用データの交換を目的
とする PDF のプロファイル仕様である。印刷・出版産業のニーズは、地域と新聞・出
版・カタログ・商業印刷など応用領域によって変化する次のようなパターンがある。
●
送り手と受け手の間で技術的なコミュニケーションが最小ですむようなブラインド
交換と、事前に技術的な合意をした上で行う交換
●
一回の交換で必要な要素を入手するか、それとも、一部の要素は受け手のサイトに
存在したり、あるいは、別途交換するか（完全な交換、または、部分交換）
●
CMYK データの交換、または、他のカラー空間による符号化
●
送り手が期待する印刷の見栄えを指定するか、それとも、送り手が完全な全域デー
タを提供し、受け手が実際の印刷の条件設定に責任をもつか。
●
オブジェクトに対して外部の参照ファイルを使うか、すべてのオブジェクトが PDF
ファイルに中に符号化されるか。
こうした広範なニーズに答えるために、複数の部分から構成される ISO 標準を作るア
167
プローチを選んだ。PDF/X ファミリーはで規定されている。ISO 15930 は複数のパー
トからなるマルチドキュメントで、各パートが PDF/X ファミリーのメンバを定義して
いる。
表 1 ISO 15930 ファミリー
ISO 番号
PDF/X 番号
ベース PDF
ISO 15930-1:2001 PDF/X-1、PDF/X-1a
PDF 1.3
ISO 15930-3:2002 PDF/X-3
PDF 1.3
ISO 15930-4:2003 PDF/X-1a
PDF 1.4
ISO 15930-5:2003 PDF/X-2
PDF 1.4
ISO 15930-6:2003 PDF/X-3
PDF 1.4
ISO 15930-7:2008 PDF/X-4、PDF/X-4p
PDF 1.6
ISO 15930-8:2008 PDF/X-5g、PDF/X-5n、PDF/X-5pg PDF 1.6
PDF/X は PDF の仕様に定められる機能のそれぞれについて、①使用することを必須
とする、②使用することを禁止する、③なんらかの制限を加えて使用を許可する、とい
うことを定め、印刷用のデータ交換が確実に行えるようにするものである。わかりやす
い例を挙げれば、上記のファミリー全体を通じて、フォントは必ず PDF ファイル内に埋
め込み、受け取った側にそのフォントが存在しなくても、渡した側と同じ内容の印刷が
行われることを保証できるようにしている。
PDF/X の仕様内で完全な交換（あるいはブラインド交換）と呼ばれるものがある。こ
れはデータ交換において、1 回のファイル交換に、必要なすべての情報が含まれている
ことを意味する。たとえば、印刷データを PDF を渡し、その中のあるページの画像は別
途送る、というようなケースは完全な交換ではない。PDF/X は基本的には完全な交換を
要求するが、以下のものは、一部のデータを外部におくことを認めている。
●
PDF/X-2
●
PDF/X-4p
●
PDF/X-5g
●
PDF/X-5n
●
PDF/X-5pg
次に使用できるカラースペースの観点からの分類すると、PDF/X-1 および PDF/X-1a
で使用できるカラースペースは CMYK（およびグレースケール）であるが、その他の規
格は RGB、CMYK、グレースケールが使用可能である。
これに対して、PDF/X-3 では、RGB、ICC ベースカラーの使用を可能にし、カラー
168
第 17 章 印刷ワークフローにおける PDF
管理ワークフローを実現できる。
17.3 PDF/X-1、PDF/X-1a
PDF/X-1 は ISO 15930-1:2001 の別名であり、
「CMYK を中心とする完全交換」とい
う題がついている（ISO 15930-1:2001（p. 240））。基本は PDF/X-1a であるが、これは
PDF で使える機能に対して、主に次のような制限をつけたものである。
●
すべての印刷用の複合実体を PDF ファイル中に含むこと。
●
カラーは CMYK、グレースケール、セパレーションカラー (特色) とそれをベースと
するインデックスカラーなどに制限する
●
出力インテントを使ってカラー印刷特性を設定する
●
フォントは埋め込むこと
●
データ圧縮は LZW、JBIG2 を禁止
●
ハーフトーンの制限
●
PostScript のプログラム埋め込み禁止
●
暗号化禁止
●
透明（PDF1.4) の使用禁止
17.3.1 完全交換と部分交換
印刷された文書は、様々な場所で、様々な組織が作成した部分的なページを集合した
ものである。最終印刷物を作るために用意されたテキスト、グラフィックス、イメージ
などを伴う作業単位を複合実体（compound entity）と言うが、複合実体は、１ページ
であったり、ページの一部であったり、あるいは複数のページになる。
完全交換とは、１回の交換の中に複合実体のすべての要素があり、かつ、複合実体を
処理するための情報が複合実体の中に含まれるか、もしくは外部の標準で規定されてい
るものである。これに対する概念は、部分交換で、これは複合実体の一部の要素を意図
的に除外して交換し、別途入手するもの。
もうひとつ類似の概念として、ブラインド交換 （blind exchange） という言葉があ
る。ブラインド交換とは、受け手が、送り手から受け取ったページを、送り手の意図通
りにレンダリングするために、事前に技術的な情報の交換を必要としないものである。
ISO 15930 では、完全交換であれば、ブラインド交換になると考えている。
PDF/X-1 は PDF を使った完全交換を規定する。このために交換する PDF ファイル
には次のものを含まねばならない。
169
●
フォント、フォントメトリックス、フォントの符号化、カラー空間リソースなどを
含むすべての PDF のリソース
●
OPI で外部参照されるファイルはストリームとして PDF/X-1 ファイルに含む
●
すべての印刷用の要素が、意図されたひとつの印刷設定のために適切に準備されて
いる
OPI：Open Prepress Interface
OPI：Open Prepress Interface はもともと Aldus が規定したもの。印刷用の高解
像度の画像は非常に大きなサイズになるので、印刷用の DTP ファイルとは別に保存
し、DTP ファイルの中には、そのファイルが入る場所を確保し、プロキシとして代
わりの低解像度の画像を保存する方式。印刷時に OPI サーバと呼ぶフィルターを通
して、高解像度画像と入れ替える。PDF でも同じ仕組みがあり、PDF では、プロキ
シは画像または XObject として、OPI 辞書を伴って保存される。
PDF/X-1 にはコンフォーマンスレベル (準拠度) としては次の 3 つがある。
1） PDF/X-1:1999　PDF1.2 に準拠して作られた、ANSI CGATS.12/1-1999
2） PDF/X-1:2001　PDF1.3 に準拠し、ISO 15930-1:2001 規格で定める
3） PDF/X-1a:2001　PDF/X-1:2001 と比べて次の 3 点の違いがある
①
埋め込みファイルへの OPI 参照を禁止
②
PDF の Encrypt 辞書（プロテクト）を使用禁止
③
PDF の Info オ ブ ジ ェ ク ト に GTS_PDFXConformance キ ー の 値 と し て
PDF/X-1a:2001 をセットする。
さ ら に PDF 1.4 を ベ ー ス 規 格 と す る PDF/X-1a ： 2003 も で き て い る （ ISO
15930-4:2003（p. 241））。PDF/X-1a:2003 も CMYK を主とする完全交換を目的とする
規格であり、ISO 15930-1 との違いは次の通り。
●
PDF のバージョンが 1.3 から 1.4 にあがった。
●
OPI を使用しないようにした
●
ただひとつの準拠度すなわち PDF/X-1a:2003 のみ規定
●
PDF1.4 の追加機能である、JBIG2、透明、参照された PDF（Referenced PDF）
を不許可とする
PDF/X-1 は、廃止規格とされているという資料もあるが、ISO 15930-4:2003 には、
PDF/X-1 を明示的に廃止したとは書いていない。
次に PDF/X-1a:2001 と PDF/X-1a:2003 について、主な仕様を見る。
170
第 17 章 印刷ワークフローにおける PDF
17.3.2 PDF/X-1a ファイル構造
●
PDF/X-1a の構造は PDF Reference に従っていることが前提で、さらに、PDF/
X-1a の仕様で書かれた制限に従う。
●
事前に各ページを色分割して、一色毎に別々のページオブジェクトにしたような
PDF は、ブラインド交換にならないので許されない。
●
PDF/X-1a ファイルには、最終的に印刷される要素（印刷要素：print element）と
印刷向けでない要素（non-print element）を含むことができる。
●
すべての複合実体（compound entity）は、すべての PDF のリソースや印刷要素を
ひとつの PDF/X-1a ファイルに完全に含まなければならない。
17.3.3 カ
ラ
ー
カラーの規定は印刷要素のみに適用される。非印刷要素はどのようなカラーを用いて
も問題ない。
印刷要素は、CMYK データ、グレースケールデータ、またはセパレーション・カラー
データとして交換されなければならない。
PDF/X-1a ファイルの中の印刷要素は、DeviceCMYK、DeviceGray、Separation、
DeviceN、Index、Pattern カラー空間を、この仕様で規定する制限に沿って使うことが
できる。PDF/X-1a では DeviceRGB、CIE ベース・カラー空間を使うことができない。
PDF/X と Output Intent PDF/X の仕様の策定に伴い、ドキュメントを印刷する環境
や出力デバイスカラー特性と PDF 文書のカラー特性をマッチさせるために PDF のドキ
ュメント・カタログに Output Intent 辞書が追加された。Output Intent は、PDF1.3 で
は、PDF の仕様ではなくアドビのテクニカルノート#5413 として定義された。PDF1.4
から PDF の正式な仕様となっている。
PDF Reference の Output Intent の項目は次の表の通りである。PDF Reference の
説明と PDF/X の各パートでの制約には不一致の部分があり、その場合は、PDF/X の仕
様書を優先することになってる。
表 2 PDF/X 用の出力インテント辞書
キー
必須かどうか
値
Type
オプション
OutputIntent
S
必須
GTS_PDFX
OutputCondition
オプション
意図する出力環境を人間に分かる
171
ようにコンパクトに記述する
OutputConditionIdentifier 必須
意図する出力環境を人間に分かる
か、機械可読な形式で記述する。一
般には ICC Characterization Data
Registry のような業界標準を使用
する。業界標準でない場合、
Custom とするか、それともアプリ
ケーション独自でも良い。
RegistryName
オプション
OutputConditionIdentifier で定義
される条件の URI
Info
OutputConditionIdentifier
意図する環境を指定するための情
が標準の生産環境を指定して 報を人間に可読な形で記述
いないときのみ必須
DestOutputProfile
同上
PDF の文書を出力デバイスに変換
するための ICC プロファイルのス
トリーム
Output Intent は、現在、PDF/X のみが規定されているが、将来は、他の用途にも拡
張される予定である。PDF/X 以外では、参考情報としての意味しかもたないが、PDF/
X では重要な役割を負っている。
OutputIntent によるカラー印刷特性の識別
PDF/X-1a では Output Intent を使って
カラー印刷特性を識別する。次に OutputIntent に設定する内容について整理する。
OutputConditionIdentifier にはテキスト文字列が入る。これは RegistryName との
組み合わせで使う。
(1) RegistryName は意図する印刷特性を特性データ登録を使って定義するときに限
り使用できる。これを使うときは、OutputConditionIdentifier の値は、その登録にお
ける参照名（Reference name）に一致しなければならない。代表的なものは ICC 特性
データ登録（ICC Characterization Data Registry) である。
●
International Color Consortium. “ICC Characterization Data Registry.”（p. 240）
●
International Color Consortium. “CMYK Characterization data.”（p. 240）
この時、RegistryName キーの値は、(http://www.color.org) となる。
例えば、Japan Color 2001 Coated は、ICC Characterization Data Registry の参照
名が JC200103 となっている。すると Output intent 辞書の内容は次のようになる。
<< /Type /OutputIntent　% Output intent dictionary
/S /GTS_PDFX
172
第 17 章 印刷ワークフローにおける PDF
/OutputCondition (JC200103 (Japan Color 2001 Coated ))
/OutputConditionIdentifier (JC200103)
/RegistryName (http://www.color.org)
>>
(2) RegistryName キーがない時、OutputConditionIdentifier には特別な意味を持た
せることはできない。
(3) RegistryName キーが存在して、値が (http://www.color.org) ではないときは、
その値は、その登録について詳しい情報を入手可能な URL でなければならない。
(2) または (3) の場合は、DestOutputProfile が存在しなければならない。
OutputCondition キーは常に存在するべきで、その値は、印刷特性を人間のオペレー
タに分かりやすい形式で、コンパクトに伝える情報にする。
DeviceCMYK 、 Device Gray カ ラ ー 空 間
カ ラ ー 空 間 が DeviceCMYK ま た は
DeviceGray で指定されている PDF の印刷要素は、出力インテント・オブジェクトにあ
る印刷条件の通りに解釈する。
Separation 、 DeviceN カ ラ ー 空 間
CMYK カ ラ ー と ス ポ ッ ト カ ラ ー に 対 し て 、
Separation か DeviceN カラー空間を使うこともできる。
PDF の Separation カラー空間とは、対象となる出力デバイスの一種類の色素に対し
て名前をつけて指定する方式、DeviceN カラー空間とは、対象となる出力デバイスの多
種類の色素に対して名前をつけて指定する方式である。指定した色素がない他の出力デ
バイスのために代替カラー空間と、そのカラー空間で、指定の色素を合成するための色
調変換式を添えて出力する。
PDF/X-1a では、すべての Separation と DeviceN カラー空間のリソースは、代替カ
ラー空間としては、DeviceCMYK か DeviceGray を使わなければならない。
送り手と受け手が、別の約束をしていない限り、名前をつけた色素は、意図した出力
デバイスで使える独立した色素でなければならない。
Separation または DeviceN カラー空間で指定したスポットカラーをプロセスカラー
色素を使って印刷するときは、Separation または DeviceN カラー空間の代替カラー空
間と色調変換式を使う。
代替カラー空間が DeviceCMYK の場合は、PDF/X-1a 準拠のリーダは、PDF/X 出力
インテントで識別される CMYK を使う。また、DeviceGray の場合は、PDF/X 出力イ
ンテントで識別される CMYK の黒と同等に処理する。
Index、Pattern カラー空間 PDF の Index と Pattern カラー空間は、ベースとなるカ
173
ラー空間の上にカラーのテーブルを作ってインデックスでカラーを指定するもの。この
場合は、ベースとなるカラー空間に対して、上に述べた制約を適用する。
17.3.4 フ ォ ン ト
PDF/X-1a では、使われているすべての文字に対して、グリフ、メトリックス情報、
フォントの符号が埋め込まれていなければならない。受け手は、システムにインストー
ルされているフォントではなく、PDF ファイルに埋め込まれているフォントを使って、
描画したり表示したりしなければならない。
17.3.5 デ ー タ 圧 縮
PDF/X-1a:2003 では、LZW と JBIG2 圧縮を除いて使用可能となっている。これに対
し、PDF/X-1a:2001 は、ImageXObject 以外を圧縮するなら、Flate と RunLengh 圧縮
のみを許可。ImageXObject を圧縮するなら JPEG、Flate、RunLengh、白黒イメージ
であれば CCITT Fax 圧縮を許可している。
2 つのレベルの仕様書で書き方が違うため、PDF で扱えるすべての圧縮方式を調べて
みないと、この二つが同等かどうか分からない。そこで、念のために表を作ってみると
次のようになる1）。
表 3 PDF で扱える圧縮方法
PDF で使える圧縮方法
種類
PDF/X-1a で禁止
カラーとグレースケール
JPEG
白黒イメージ
CCITT (G3、 G4)、 RunLength, JBIG2 JBIG2
テキスト、線画、イメージ LZW、 Flate (ZLIB)
JPEG2000（PDF1.5～）
LZW
※PDF Reference Fifth Edition　2.2.2 Compression　p.15
JBIG2 は、Joint Bi-level Image experts Group（p. 241）が開発したモノクロイメー
ジの圧縮方式である。
PDF/X-1a:2001、PDF/X-1a:2003 で同等のように見えるが、問題は PDF/X-1a：
2001 では Image XObject とそうでないものに分けていること。PDF では、Image
XObject というのは画像ファイルを埋め込んだものに相当するが、それ以外にインライ
ン・イメージがあり、インライン・イメージについては、次の圧縮方式が使える
LZW, Flate (ZLIB), RunLengh, CCITT, JPEG
1） 「PDF の中のデータ圧縮」を別に整理する
174
第 17 章 印刷ワークフローにおける PDF
※PDF Reference Fifth Edition 4.8.6 Inline Images　pp 322- 325
結局、PDF/X-1a：2001 ではインライン・イメージの圧縮に CCITT, JPEG は使えな
いが、PDF/X-1a：2003 では、CCITT, JPEG も使えることになり、表現方法を変えた
ために仕様が変わっている。
17.3.6 トラッピング
多カラーの印刷工程では、色別の版の位置ずれが原因で、印刷対象の周囲にギャップ
ができたり帯ができたりする可能性がある。隣同士の色を重ねること、トラップ、によ
り版が多少ずれても問題が起こりにくくすることができる。
トラッピングは、PDF を作成するソフトで行ったり、中間的なアプリケーションで
PDF にトラップを追加したり、あるいは、最終段階の RIP（ラスター・イメージ・プロ
セサ）で追加することもある。PostScript にはトラッピングを設定することができる
が、PDF ファイルにはトラッピングは直接指定しないで、PDF に付随もしくは埋め込ま
れるジョブチケットで指定する。
トラッピングを最終工程よりも前に行ったときは、トラップは、トラップ・ネットワ
ーク注釈として PDF に保存する。
PDF/X-1a：2001、2003 ともこの部分は同じである。
まず、PDF の文書情報である Info 辞書の Trapped キーにトラッピングされたものか
どうかを記述する。Trapped キーは、通常の PDF ではオプションであるが、PDF/X-1a
では必須で、その値は、次のように True または False でなければならない。
●
PDF ファイル全体がトラッピングされているならば、キーの値は True
●
PDF ファイル全体がトラッピングされていないならば、キーの値は False
●
一部分だけトラッピングされているものは許可されない。またキーの値が
Unknown（PDF の規定値）は許可されない
PDF ファイルにトラップ・ネットワーク注釈を含んでいるなら、Trapped キーの値
は、True でなければならない。トラップ・ネットワーク注釈を作成した後で頁を修正し
たら、トラップ・ネットワーク注釈は無効となる。
トラップ・ネットワーク注釈の中で、トラップ・ネットワークの生成の際に代替フォ
ントで置換されたフォントを示す FontFauxing キーは存在しないか、存在しても空でな
ければならなう。トラップ・ネットワークを生成する際に想定するカラー空間を示す
PCM キーの値は、DeviceCMYK でなければならない。
175
17.3.7 PDF ファイルの識別
PDF/X-1a のファイルは次のように識別する。
●
PDF の Info 辞書に GTS_PDFXVersion キーを作成する
●
PDF/X-1a：2003 ではキーの値が、（PDF/X-1a:2003）となる
●
PDF/X-1a：2001 ではキーの値が、（PDF/X-1:2001）となる
○
PDF/X-1a：2001 ではさらに、Info 辞書に GTS_PDFXConformance キーを
作成し、このキーの値を（PDF/X-1a:2001）とする。
このほか、PDF/X-1a の場合は、Info 辞書に通常の PDF ではオプションのキーを設定
しなければならないものがある。
次に比較表を挙げる。
表 4 PDF/X-1a の文書情報辞書の一般項目の設定
キー
通常の PDF
Title
オプション 必須
Author
オプション
Subject
オプション
Keywords
オプション
Creator
オプション 勧告
Producer
オプション 勧告
PDF/X-1a
CreationDate オプション 必須
ModDate
オプション 必須
Trapped
オプション 必須（True, False)
必須の時、キーワードをゼロバイトにするのは許されない。
Trailer の ID キーは、通常はオプションであるが、PDF/X-1a では存在しなければな
らない。なお、PDF 生成ソフトは ID キーがユニークになるように作るべき（勧告）と
されている。
次の仕様は、PDF/X-1a：2001 には記述がなく、PDF/X-1a：2003 で追加になって
いる。
PDF ファイルを更新したときは、ModDate を更新しなければならず、Catalog 辞書
の Metadata ストリームも更新すべき (勧告）。
176
第 17 章 印刷ワークフローにおける PDF
17.3.8 境界ボックス
PDF は、紙と同じようにページの概念をもつ媒体である。PDF でのページはツリー構
造で管理され、ツリーの葉に相当する部分が１つのページであり、これをページオブジ
ェクトと言う。
ページオブジェクトには様々な属性を設定できる。これを設定したデータをページオ
ブジェクト辞書と言う。オブジェクト辞書の設定キーの中で PDF のページ境界に関す
るキーを次に示す。PDF/X-1a ではこれらのページの境界の設定について制限を課して
いる。
表 5 ページオブジェクト辞書のページ境界関連項目
キー
PDF
MediaBox 必須
CropBox
PDF/X1-a
継承可
オプション CropBox があるとき、BleedBox、ArtBox、TrimBox のいずれも
CripBox の境界を越えないこと
BleedBox オプション BleedBox があるときは、ArtBox、TrimBox は BleedBox の境界を越
えないこと
TrimBox
オプション TrimBox か ArtBox のどちらか、一方のみ、が設定されていなければな
らない。ArtBox よりも TrimBox の方が望ましい。
ArtBox
オプション
ページ境界の意味
通常の書類を PDF 化した場合のように、PDF を印刷した物が最終印刷物になる場
合、MediaBox、CropBox、TrimBox、BleedBox は一致する。しかし、PDF を印
刷用のフィルムに出力する場合は、MediaBox がフィルムの境界に相当し、TrimBox
が印刷して周囲を切り落としたページのサイズになる。
BleedBox は、TrimBox の外側に裁断や仕上げのために必要な幅を確保した領域
である。
CropBox は、ページの内容をクリップするための領域とされていて、他の境界線
との関連性はない。
ArtBox は DTP ソフトなどのアプリケーションが出力するもので、TrimBox の内
部でページの意味のある内容を囲む領域とされている。
※PDF Reference Fifth Edition 10.10.1 Page Boundaries pp. 890 - 893
DTP などの出力した EPS グラフィックスを PDF に変換したときなどに使うと、
177
ArtBox で切り取って他の PDF に埋め込むなどの用途で便利である。
17.3.9 PostScript XObject
PostScript XObject は、PostScript のプログラムを PDF の中に埋め込むものである
が、PDF/X-1a では使用禁止である。また PS オペレータは、PDF Reference Fifth
Edition でも、既に過去のものとして、使用しないことになっている。
PDF/X-1a:2003 では、form XObjects に、Subtype2 キーの値 PS を使用してはなら
ないことが追記されている。これは、PostScript XObject を、subtype キーを form と
し、Subtype2 キーを PS としても定義できますので、それを禁止したものである。
17.3.10 暗 号 化 辞 書
PDF/X-1a では暗号化辞書は使用禁止で、PDF のセキュリティ設定は利用できない。
17.3.11 代替イメージ
image XObject を指定するイメージ辞書には、ベースイメージに加えて複数の代替イ
メージを登録することができる。これは Alternates キーに image XObject の配列とし
て指定する。これらのすべての代替イメージは同じベースイメージの同じエリアのもの
でなければならない。さらに、各代替イメージには、その特性を指定するが、
DefaultForPrinting キーの値が True になるものは禁止されている。
17.3.12 注
釈
PDF/X-1a:2001 では、TrapNet 以外の注釈は、完全に BleedBox の外になければな
らない。BleedBox がないときは、TrimBox または ArtBox の外となる。
PDF1.4 で、注釈に PrinterMark が追加されたので、PDF/X-1a：2003 では次のよう
に変更されている。
TrapNet と PrinterMark 以外の注釈は、完全に BleedBox の外になければならない。
BleedBox がないときは、TrimBox または ArtBox の外となる。
PrinterMark 注釈は、TrimBox か ArtBox の外側になければならない。
いずれにせよ、PDF/X-1a を画面に表示したり、印刷するとき、注釈が実際のページ
の内容に重なってはならないことを規定している。
178
第 17 章 印刷ワークフローにおける PDF
17.3.13 アクションと JavaScript
PDF では、例えばしおりをクリックした時に、ビューアが新しいアプリケーションを
起動したり、音を鳴らしたり、注釈の外見を変更する、JavaScript を実行するなど、様
々なアクションを設定できる。
PDF/X-1a に準拠する PDF ファイルは、アクション、JavaScript を含むことができな
い。
17.3.14 BX/EX オペレータの使用
PDF では互換オペレータ BX/EX が定義されている。このオペレータで囲まれた部分
は、PDF の表示ソフトが理解できない場合、エラーにしないで無視するものである。
PDF/X-1a では、Contents ストリームの中に、PDF Reference にないオペレータを、
仮に BX/EX で囲ったとしても含むことができない。また、PDF/X-1a のリーダは、BX/
EX で囲まれた部分についても PDF Reference に従って解釈しなければならない。
PDFF/X-1a のライターは、BX/EX を使わないことが推奨されている。
17.3.15 透
明
PDF1．4 から透明が定義された。そこで、PDF/X-1a：2003 では、透明を使用しな
いように仕様が追加になっている。
具体的には、ExtGState オブジェクトまたは Image XObject に、SMask キーを使う
ときは、値を None にしなければならない。
ExtGState オブジェクトの BM キーは Normal または Compatible、CA キーと ca キ
ーの値は 1.0 でなければならない。
Group オ ブ ジ ェ ク ト の S キ ー に Transparency の 値 を も つ な ら ば 、 そ れ を form
XObject に含めてはならない。
17.4 PDF/X-3
PDF/X-1a の上位拡張仕様で、カラー管理ワークフロー用に適した完全交換という副
題が付いている。具体的には、カラー空間の使用可能範囲を広げて、RGB、ICC ベース
カラーの使用を可能とし、「カラー管理ワークフロー」を可能にしたものである。
デジタルカメラなどで撮影したカラーイメージ画像が印刷に使われることが増えてい
るので、PDF/X-1a よりもむしろ PDF/X-3 が重要になっている。
179
PDF/X-3 には 2002 年版と 2003 年版があり、それぞれ次の仕様書で規定される。
●
ISO 15930-3:2002（p. 241） PDF/X-3:2002　PDF Reference 1.3 ベース
●
ISO 15930-6:2003（p. 241） PDF/X-3:2003　PDF Reference 1.4 ベース
17.4.1 準拠ファイルとツール
PDF/X-3 の仕様に準拠するファイルとは PDF ファイルであって ISO の各仕様書に準
拠するもの。準拠ファイルには、印刷に関係ない PDF の他の機能を含むことが許され
る。
PDF/X-3 に準拠する書き手 (ライター) は ISO の各仕様に準拠するファイルを書くこ
とができなければならない。一方、読み手は、各仕様に準拠するすべての PDF/X-3 フ
ァイルを読むことができなければならない。さらに、PDF/X-1a:2001、PDF/X-1a:
2003 も処理できなければならない。
PDF/X-1a は、PDF/X-3 の下位規定になりますので、PDF/X-3 のリーダは、PDF/
X-1a も読めないといけないのである。
17.4.2 完 全 交 換
PDF/X-3 は、PDF/X-1a と同様完全交換の規定である。従って、複合実体のすべての
部品が PDF/X-3 のファイルに含まれていなければならない。
17.4.3 カ ラ ー 空 間
PDF/X-3：2002、PDF/X-3：2003 では、出力デバイスのコード値でカラーを交換
したり、測色計で定義したデータでカラーを交換できる。
いずれにせよ、印刷条件を事前に、名前付きの条件または ICC 出力プロファイルの形
で用意しておかねばならない。
測色計で定義したデータを記述するには、PDF の ICCBased カラー空間の ICC プロ
ファイルを使うか、または、CalGray、CalRBG、Lab カラー空間の同等の仕組みを使う。
出力デバイスのコード値は、PDF では、DeviceRGB、DeviceCMYK、DeviceGray、
Separation、DeviceN、Indexed、Pattern カラー空間を、次に述べる制約の元で使用
できる。
出力インテント
出力インテントについては、PDF/X-1a と次の点を除いてまったく
同じ。
印刷要素にデバイス独立のカラー空間を使用しているとき、DestOutputProfile キー
が存在しなければならない。
180
第 17 章 印刷ワークフローにおける PDF
PDF/X-1a については OutputIntent によるカラー印刷特性の識別（p. 172）を参照。
デバイス依存カラー
DeviceCMYK は、印刷条件が DeviceCMYK で指定されている
時は、PDF/X の出力インテントで識別される印刷条件で解釈しなければならない。
これに対して、PDF/X-3 のファイルに DeviceCMYK で定義されるカラーが含まれて
いるにも関わらず、指定印刷条件が CMYK でないならば、Resource 辞書の ColorSpace
下位辞書に DefaultCMYK カラー空間を含めなければならず、そこで測色計によるカラ
ー定義を提供しなければならない。
DeviceGray は、印刷条件が CMYK で指定されている場合、その黒色成分とみなす。
印刷条件がグレーで指定されるときは、PDF/X の出力インテントで識別される印刷条件
で解釈しなければならない。
DeviceGray で定義されるカラーデータを含んでいるにも関わらず、指定印刷条件が
CYMK で も グ レ ー で も な い 場 合 は 、 Resource 辞 書 の ColorSpace 下 位 辞 書 に
DefaultGray カラー空間を含めなければならず、そこで測色計によるカラー定義を提供
しなければならない。
DeviceRGB も、DeviceCMYK、DeviceGray と同様である。
ICCBased カラー空間
ICCBased カラー空間やその他の既定値の Stream 辞書で
は、Alternate（代替）カラー空間を含むことができない。
Separation, DeviceN カラー空間
CMYK カラー、スポットカラーには Searation ま
たは DeviceN カラー空間を使うことができる。
PDF/X-3 における Separation, DeviceN カラー空間の仕様は、PDF/X-1a における同
様の仕様を 3.2 項の記述に沿って拡張したものである。
すなわち、送り手と受け手が、別の約束をしていない限り、名前をつけた色素は、意
図した出力デバイスで使える独立した色素でなければならない。
Separation または DeviceN カラー空間で指定したスポットカラーをプロセスカラー
色素を使って印刷するときは、Separation または DeviceN カラー空間の代替カラー空
間と色調変換式を使う。
代替カラー空間が、PDF/X の出力インテントと同じデバイス依存カラーの場合、
PDF/X-3 準拠のリーダは、代替カラー空間をその印刷条件を参照するものとして扱う。
また、代替カラー空間が DeviceGray の場合は、PDF/X 出力インテントで識別される
CMYK の黒と同等に処理する。代替カラー空間が、印刷条件と対応しないデバイス依存
カラー空間を使っている場合は、3.2 項を適用する。
Indexed、Pattern カラー空間
Indexed、Pattern カラー空間の基底となるカラー空
間についても、上記の 3.2 項を適用する。
181
17.4.4 フ ォ ン ト
PDF/X-3 では、フォントのグリフ、メトリックス、符号化方法は、使用されているす
べての文字について埋め込まれていなければならない。
フォントは埋め込みを許可されたもののみを埋め込みできるので、埋め込みが許可さ
れていないフォントを PDF/X-3 で使うことはできない。
17.4.5 ファイル指定
PDF ではファイル指定機能によって、他のファイルの内容を参照することができる
が、PDF/X-3 ではファイル指定機能を使うことは禁止されている。
参考　PDF　Reference Fifth Edition　3.1　File Specifications　pp. 151 - 162
17.4.6 デ ー タ 圧 縮
PDF/X-3:2002 では、LZW 以外の PDF1.3 で使える圧縮を使用できる。
PDF/X-3:2003 では、LZW と JBIG2 以外の PDF1.4 で使える圧縮を使用できる。
17.4.7 トラッピング
PDF/X-3 のトラッピングについての仕様は、PDF/X-1a とカラー空間を示す PCM の
規定を除いてまったく同じ。
すなわち、PDF/X-1a では、PCM キーの値は、DeviceCMYK のみが許されている、
PDF/X-3 では、PCM キーの値は、PDF/X の出力インテントで指定した印刷条件に一致
していなければならないというように拡張されている。
17.4.8 PDF ファイルの識別
PDF/X-3 のファイルは、Info 辞書の GTS_PDF/XVersion キーで識別する。
●
PDF/X-3:2002 ではキーの値が、（PDF/X-3:2002）となる
●
PDF/X-3:2003 ではキーの値が、（PDF/X-3:2003）となる
PDF/X-1a の文書情報辞書の一般項目の設定は、PDF/X-1a と同じ。
17.4.9 境界ボックス
PDF/X-3 の境界ボックスに対する条件は、PDF/X-1a とまったく同じ。
182
第 17 章 印刷ワークフローにおける PDF
17.4.10 拡張グラフィックス状態
PDF/X-3 の拡張グラフィックス状態に関する制約も PDF/X-1a とまったく同じ。
17.4.11 PostScript XObject
PDF/X-3 では PostScript XObject を使うことはできない。この制約も PDF/X-1a と
まったく同じ。
17.4.12 暗 号 化 辞 書
PDF/X-3 では、暗号化辞書を使うことはできまない。PDF/X-1a と同じ。
17.4.13 代替イメージ
PDF/X-3 の代替イメージに関する制約も PDF/X-1a とまったく同じ。
17.4.14 注
釈
PDF/X-3 のトラッピング以外の注釈は、完全に BleedBox（もし、BleedBox が無い
時は、TrimBox または ArtBox）の外側になければならない。PDF/X-1a と同じ。
17.4.15 アクション、JAVAScript
PDF/X-3 では、アクションや JAVAScript を使うことができない。PDF/X-1a と同
じ。
17.4.16 BX/EX オペレータの使用
BX/EX オペレータの使用に関する制約は、PDF/X-1a と同じ。
17.4.17 デジタル署名
PDF/X-3 は、デジタル署名を含むことができ、PDF/X-3 のリーダはデジタル署名を
無視してもかまわない。
17.4.18 透
明
PDF 1.4 から追加された透明は、PDF/X-3：2003 で使用条件に制約が課されている。
この制約は、PDF/X-1a:2003 と同じ。
183
17.5 PDF/X-2
PDF/X-2 は ISO 15930-5:2003 の別名であり「PDF 1.4 を用いた印刷データの部分
交換」という副題がついている（ISO 15930-5:2003（p. 241））。
17.5.1 準拠ファイルとツール
PDF/X-2 に準拠しているかどうかの判断は PDF ファイルのバージョン番号ではな
く 、 PDF フ ァ イ ル に 含 ま れ て い る 印 刷 用 の 複 合 実 体 の 交 換 に 必 要 な 特 徴 が ISO
15930-5:2003 の仕様書に沿っているかどうかで判断しなければならない。なお、印刷
用複合実体の再現には関係ない情報が含まれていても差し支えない。
PDF/X-2 準拠のライター（作成ソフト）は、PDF/X-2 のファイルを生成することが
できれば良いが、PDF/X-2 準拠のリーダ（読むソフト）は PDF/X-2 だけではなく、
PDF/X-1a:2001、PDF/X-1a:2003、PDF/X-3:2002、PDF/X-3:2003 のすべてを適切
に処理できなければならない。
17.5.2 部 分 交 換
PDF/X-2 は部分交換という副題がついている。部分交換とは、一部の印刷要素、また
は要素の資源を、交換から意図的に除外しておき、別途入手可能とする方式である。デ
ータ交換で除外された要素をユニークに識別するための情報を提供することができるよ
うになっている。
PDF/X-2 の仕様は、部分交換を可能にすることで、他の仕様を補完するものである。
17.5.3 PDF/X-3 との関係
PDF/X-2 の仕様は、PDF/X-3:2003 の仕様のほぼすべての制約を満たさねばならな
い。PDF/X-3:2003 についての制約の中で、PDF/X-2 に適用されないのは、次の 4 項
目である。
1） PDF/X-3 ファイル構造
2） ファイル指定
3） トラッピング
4） PDF/X-3 ファイルの識別
PDF/X-3 が完全交換を目的としていて、一回の PDF ファイル交換ですべての情報を
交換しなければならないのに対し、PDF/X-2 は部分交換を目的とするため、複数回に分
184
第 17 章 印刷ワークフローにおける PDF
けて情報交換を行うことを認めていることから、制約条件が変わっていることになる。
次に PDF/X-3 と異なる箇所のみを取り上げる。
17.5.4 PDF/X-2 ファイル構造
PDF/X-2 では、複合実体のすべての要素がひとつの PDF/X-2 ファイルに含まれてい
るか、それとも、後述の外部参照要素の規定に準拠して識別できなければならない。
17.5.5 PDF/X-2 のファイル識別
Info 辞書の GTS_PDFXVersion キーの値を（PDF/X-2:2003）とする。Info 辞書のそ
の他のキーの使い方は PDF/X-3 と同様である。
17.5.6 外部参照要素
仕組み
PDF/X-2 のファイルでは、印刷要素を省略することができる。省略した印刷
要素については、Form XObject の機能を使って代理データを含めておく必要がある。
代理データはプレビュー画像などでも問題ない。
代理データは、Reference XObject の機構を使って、要素を置換するための対象デー
タを指し示さねばならず、この参照辞書には ID を含めなければならない。
PDF Reference の XObject というのは、一塊の完結したグラフィックス・オブジェ
クトのことである。これは、Image XObject、Form XObject、PostScript XObject の
3 種類が代表的なものだが、PDF 1.4 から Reference XObject、Group XObject が追加
されている。
この Reference XObject の機構を使うとある PDF ファイルの中に、別の PDF の内容
を持ち込むことができる。PDF/X-2 ではこの機構を使って別の PDF ファイル（ターゲ
ット PDF）を参照することで、部分交換を可能とする。
Reference XObject のターゲット PDF は、PDF/X-1a:2001、PDF/X-1a;2003、PDF/
X-3:2002、PDF/X-3:2003 または PDF/X-2:2003 のいずれかでなければならない。
Form XObject、Image XObject の OPI キーを使うことはできない。
ターゲット文書の識別
ターゲット PDF の Catalog 辞書には Metadata キーがなけ
ればならない。メタデータを構成するデータは、XMP 準拠（13.3 XMP 仕様について
（ p.
146 ） を 参 照 ） に な っ て い る こ と が 必 要 で 、 xapMM:DocumentID 、
xapMM:VersionID、xapMMRenditionClass プロパティを含まねばならない。多くの
場合、xapMMRenditionClass の値は、default となる。
外部 PDF を参照する元になる側の Form XObject（Reference XObject のための Ref
185
キーをもつもの）にも同じように Metadata キーをもつ必要がある。
こ の Metadata キ ー の 値 と な る メ タ デ ー タ ・ ス ト リ ー ム に は 、 XMP の
xapMM:RenditionOf 属性を含む必要があり、その値は、ResourceRef 要素となる。ま
た、xapMM:DocumentID、xapMM:VersionID、xapMM:RenditionClass 属性を含ま
ねばならない。
xapMM:DocumentID は、UUID のような 128 ビット数の ID とし、ユニークになる
ように生成する。参照元の PDF の FormXObject と、ターゲットの PDF を XMP のメタ
データを使って対応関係を付けて、ターゲットを識別する。
ターゲット PDF の選択
PDF/X-2 の仕様では、PDF/X-2 のリーダが候補となるター
ゲット PDF を探す方法の機構までは定めていない。但し、PDF/X-2 のファイルは、OS
や言語に依存しないように作るべきであり、PDF Reference の仕様で言われている過搬
性を満たすように注意するべき、とされている。
一旦、ターゲット候補となる PDF を認識できたならば、PDF の内部のオブジェクト
の ID と、参照元とターゲットのメタデータを比較して、ターゲットを識別することが
できる。
外部文書の描画
PDF/X-2 のすべての内容は、同じ印刷特性設定になるように準備さ
れねばならない。
また、すべてのターゲット文書にある外部データを使って描画する必要があり、ター
ゲット文書が欠落した状態で描画してはならない。
また、ひとつの PDF を描画する時は、その PDF に埋め込まれたフォントを使用しな
ければならず、他の PDF に埋め込まれたフォントを使用してはならない。
ターゲット文書を含む PDF とそれに含まれる PDF 間のオーバ・プリンティングは、
PDF Reference の定義に従って行う。
Form XObject の BB エントリの座標は、ターゲット PDF のメディアボックスの左下
隅に対して相対とする。
17.5.7 ファイル指定
前項で述べた Reference XObject 以外の方法により、PDF Reference 3.10 項に定め
るファイル指定機能を使うことは禁止されている。
17.5.8 トラッピング
ファイルを交換するにあたり、info 辞書の Trapped キーを使わなければならない。
Trapped キーでは、PDF/X-2 ファイルそれ自身のトラッピング状態を示すが、参照さ
186
第 17 章 印刷ワークフローにおける PDF
れるファイルや、PDF/X-2 ファイルと参照されるファイル間の組合せにの間でのトラッ
ピング状態を示すことはない。もし、PDF/X-2 ファイルの中のすべての印刷要素につい
てトラッピングされているなら、Trapped キーの値は True になる。それ以外のケース
ではキーの値は false である。部分的にトラッピングされたファイルは許可されない。
PDF/X-2 では Trapped キーの値に unknown は許されない。
Trappnet 注釈を含むなら、Trapped キーの値は True でなければならない。
FontFauxing キーの値についての条件は PDF/X-1a と同じ。また、PCM キーの値の
条件は、PDF/X-3 と同じ。
17.6 PDF/X-4
PDF/X-4 はベースとして PDF 1.6 を採用し、PDF 1.6 の機能内で使用可能な項目を
定義することで、印刷用データの交換形式を定めている。PDF/X-4 は 2008 年に国際標
準となったが、その後、2010 年に改訂が加えられた Second Edition に置き換えられて
いる（ISO 15930-7:2010（p. 241））。
PDF/X-4 は PDF/X-1a および PDF/X-3 で利用可能な特徴をすべて組み込み、さらに
ベースが PDF 1.6 となっているで、PDF/X-1a、PDF/X-3 のベースである PDF 1.3 や
PDF 1.4 以降に追加された機能が使用可能である。
PDF/X-4 は、フォントを埋め込まなければならない等の制限は PDF/X-3 と同様であ
るが、ベースが PDF 1.6 にあがることにより、以下の機能が使用できる。
●
JPXDecode フィルタの許可（JPEG2000 画像で使用される圧縮方法が使用可能で、
画質をさげずに圧縮率をあげることができる）。
●
Optional Content 使用の許可（これは Acrobat ではレイヤーと呼ばれている機能の
実装にも使われている）
次の項目はいずれも PDF 1.4 で追加された機能である、PDF 1.4 をベースとする ISO
15930-4(PDF/X-1a)、15930-5(PDF/X-2)、15930-6(PDF/X-3) では禁止とされてい
た。PDF/X-4 では、これらの使用が認められている。
●
JBIG2Decode フィルタの許可（モノクロ画像用の圧縮方法で、従来の圧縮方法よ
り、圧縮率をあげることができる）
●
透明使用の許可
この規格内には PDF/X-4 のほかに、PDF/X-4p と呼ばれる準拠レベルが定義されて
いる。PDF/X-4p は、使用するカラーに関する ICC プロファイルを PDF ファイル外に
置くことを許可したものである。このため完全交換ではない。
187
これは ICC プロファイルを埋め込むことによりサイズが増加することを回避する、と
いう理由のほかに、ICC プロファイルの埋め込みが禁止されていて、PDF/X-4 が採用で
きないケースへの対応である。この規格内では、特別な理由がない限り PDF/X-4p では
なく、PDF/X-4 を優先せよと述べられている。
17.7 PDF/X-5
PDF/X-5 は PDF/X-4 同 様 に 2008 年 に 国 際 標 準 ISO 15930-8 と な っ た （ ISO
15930-8:2010（p. 241））。他の PDF/X 同様、ベースとなる PDF の仕様に対して、その
機能内で使用可能な項目を定義することで、印刷用データの交換形式を定めるものであ
る。PDF/X-5 は、PDF/X-4 同様にベースとなる PDF の仕様は PDF 1.6。また、2010
年に改訂が加えられた Second Edition が発行され、現在はこちらに置き換えられてい
る（このあたりも PDF/X-4 と同様）。
では、PDF/X-4 とは何が異なるのかを簡単に紹介する。
PDF/X-5 には準拠レベルが 3 種類定義されている。
1） PDF/X-5g
2） PDF/X-5n
3） PDF/X-5gp
PDF には OPI(Open Prepress Interface) という、PDF の外部にあるグラフィックフ
ァイルを参照する機能がある。容量の大きなグラフィックを本文から切り離しておくこ
とにより、高解像度のグラフィックが使用される印刷用のデータの校正時に、修正とは
無関係な大きなデータのやりとりを行わなくてもすませることができる。
PDF/X は印刷データの交換を単一のデータのやりとりですませることを目的とした
ものであるが、上記の PDF/X-5g および PDF/X-5gp は、OPI とほぼ同様の手法を許可
することで、印刷データ自体は複数となってしまう、複数回のデータ交換の総量を抑え
たり、グラフィックデータは本文とは異なる部署から印刷業者へ渡す、といったことが
可能となる。
PDF/X-5g と PDF/X-5gp の 違 い は PDF/X-4 と PDF/X-4p の 違 い と 同 じ 。 PDF/
X-5gp は、PDF 外部にあるカラープロファイルの参照を許可したものである。PDF/
X-5n は若干、他と違ったものになっている。他の PDF/X 仕様は、ベースとする PDF
仕様に対して、使用可能な機能を制限するものであるが、PDF/X-5n は、ベースとする
PDF 仕様では禁止されている部分を許可する。PDF では 1 成分、3 成分、4 成分のカラ
ースペースに対するカラープロファイルの仕様が定義されているが、n 成分のカラース
188
第 17 章 印刷ワークフローにおける PDF
ペースのカラープロファイルについては定義されていない。PDF/X-5n はこれの仕様
が認められている。このプロファイルの仕様は ISO 15076-1:2005 で定められている
ものである。これ以外の部分については PDF/X-4p と同様の制限である。
このように、PDF/X-5 は、PDF/X-4 で制限されている内容を、使用するワークフロ
ーに応じて緩和したものと言える。PDF/X-5 の仕様内には、外部のグラフィックを使用
する必要がないのであれば、PDF/X-5g、PDF/X-5gp ではなく PDF/X-4、PDF/X-4p
仕様とするべきであるとされている。
189
第 18 章 電子政府と PDF
191
第 19 章 PDF と電子書籍
19.1 電 子 書 籍
電子書籍は、書籍をデジタルデータのまま配信し、パソコン、タブレット、スマート
フォン、携帯電話（ガラケー）または電子書籍専用の機器で閲読するものである。
1990 年代から開発・販売が始まったが、日本ではコミックや携帯電話向けのライト
ノベル（ラノベ）の配信が主流であった。2010 年はアップルの iPad が登場するなどで
電子書籍元年として注目が集まった。
電子書籍のデジタルデータの形式は日本では XMDF やドットブックなどの専用の形
式が普及してきた。2011 年に策定された EPUB3 の仕様で小説などの縦書きが表現が
で き る よ う に な っ た こ と （ IDPF “ EPUB 3 Becomes Final IDPF Specification. ”
（p. 240））、2012 年 10 月から Amazon の Kindle が日本でサービスを開始したことから
一気に EPUB3 への転換が始まっている。
19.2 PDF と EPUB の関係
PDF は紙に印刷するレイアウトイメージをそのままデジタル化したものである。
PDF をタブレットで読むとき、PDF リーダはタブレットの表示画面の大きさに合わせて
PDF を表示する。このため画面の小さなタブレットでは文字が小さくなってしまい読
みにくい。
リフロー型 EPUB は画面の大きさに合わせてテキストを折り返して表示するので画
面の小さなタブレットだからといって文字が小さくなることはない。
19.3 自
炊
19.3.1 自 炊 と は
2010 年は、電子書籍元年として電子書籍に関する話題が取り上げられない日がない
位関心を集めた。この一つの理由は iPad を初めとするタブレット型の端末が人気を集
めたことになる。書籍は重くて場所をとるので紙の書籍を電子化する動きが増えた。こ
193
れを「自炊」と呼んでいるが、2011 年にかけて「自炊」の代行業者が増えたことで著
作権者との間で争いとなり始めた。
自炊のマニュアルを公開している人もいる（ 「自分で作る電子書籍 PDF 本の作り方
（改訂版）－裁断機とドキュメントスキャナで作る電子書籍－」（p. 245））。
自炊には自動紙送り装置付きスキャナーと PDF が活躍している。
194
第 20 章 電子帳簿保存法と e 文書法
20.1 電子帳簿保存法
20.1.1 創 設 の 経 緯
IT 技術が進歩する中で、企業会計分野でコンピュータを利用した国税関係帳簿の作成
が普及し、経団連をはじめとする関係団体から、帳簿書類の電磁的記録（電子データ）
及びマイクロフィルムによる保存の容認について、強い要望が政府に対して寄せられて
いた。政府は、このような要望を受け、平成 9 年度末までに、帳簿書類の電磁的記録等
による保存を容認するための措置を講ずることを決定したのである。
国税庁「電子帳簿保存法“制度創設の背景”」によると、政府税制調査会の「平成 10
年度の税制改正に関する答申」で、次のような基本的な考え方が示されている。
（１）新しい時代の流れに対応し、納税者の帳簿書類の保存の負担軽減を図るため
に、記録段階からコンピュータ処理によっている帳簿書類については、電子データ
等により保存することを認めることが必要である。
（２）その際には、コンピュータ処理は、痕跡を残さず記録の遡及訂正をすることが
容易である、肉眼でみるためには出力装置が必要であるなどの特性を有することか
ら、適正公平な課税の確保に必要な条件整備を行うことが不可欠である。
（３）電子データ等による保存を容認するための環境整備として、EDI 取引（取引
情報のやり取りを電子データの交換により行う取引）に係る電子データの保存を義
務づけることが望ましいと考えます。
国税関係帳簿書類の電磁的記録等による保存制度等は、このような政府税制調査
会の答申における考え方を踏まえて創設されました。
20.2 e 文 書 法
既に紙になっている書類を電子化しようとしたら、一番手っ取り早いのはスキャナで
読み取ることである。e 文書法の施行に伴い、従来紙で保存が義務付けられていた書類
の電子保存が認められることになったのは、紙の書類を電子化への追い風である。
195
第 21 章 PDF の真性性・証拠性の確保
21.1 電子署名の仕組み
21.1.1 電子署名の実現方法
電子文書は対策を取らなければ、悪意のあるものがその文書を偽造したり、改竄した
しょうひょう
りすることが簡単であり、証憑として使用することが困難と考えられている。電子署名
の技術を利用することで電子文書の真正性を確保し、改竄を検出することができる。
電子署名は秘密鍵と公開鍵のペアを用いる暗号方式により実現している。電子文書の
作成者は秘密鍵で署名を行い、署名を施した電子文書とともにペアとなる公開鍵を相手
に渡す。相手はその公開鍵を用いて電子文書の改竄有無を検証するのである。公開鍵が
開示されるのに対し、秘密鍵は漏洩しないように厳格に秘密に管理しなければならない。
21.1.2 電 子 証 明 書
公開鍵を鍵の所有者を特定する情報などとともにファイルに保管したものが電子証明
書（公開鍵証明書）である。電子証明書の形式としては X.509 形式が普及している。
例えば、電子署名及び認証業務に関する法律施行規則（最終改正：平成二四年七
月五日総務省・法務省・経済産業省令第一号）の第六条では、二号で秘密鍵を「利
用者が電子署名を行うために用いる符号（以下「利用者署名符号」という。）」とし、
四号で「電子証明書の有効期間は、五年を超えないものであること。」五号では電子
証明書には、次の事項が記録されていることとする。
イ　当該電子証明書の発行者の名称及び発行番号
ロ　当該電子証明書の発行日及び有効期間の満了日
ハ　当該電子証明書の利用者の氏名
ニ　当該電子証明書に係る利用者署名検証符号及び当該利用者署名検証符号に係る
アルゴリズムの識別子
ここから施行規則では電子証明書として X.509 形式を想定していることが分かる。
一方で、電子証明書と秘密鍵の両方を含む PKCS#12 形式のファイルを電子証明書と
呼んだり、電子証明書と秘密鍵を収めた IC カードを電子証明書と呼ぶこともある。この
197
ように用語が混乱しているので混同しないように注意する必要がある。
例えば、法務省の「電子証明書取得のご案内」
（p. 245）ウェブページは、PKCS12
形式（拡張子.p12）のファイルを電子証明書としている。
図 1 法務省電子証明書取得ソフトウェア説明画面より
21.1.3 電子証明書の発行
署名の利用者自身が秘密鍵と電子証明書（公開鍵を含む）をパソコン等で生成し、電
子証明書を認証局に提出して認証してもらう。秘密鍵が漏洩したり、他人に利用された
場合は電子証明書を失効させなければならないので秘密鍵は登録しているコンピュータ
の外部に持ち出さないのが安全である。
自分自身で電子証明を作成すると発行元と発行先が同一となるが、これを自己署名証
明書という。認証局自身が作成するルート証明書も自己署名証明書である。ルート証明
書は証明書の信頼の基準になるものであり、厳格な運用管理規定に基づいて作成される。
一方、例えば、アンテナハウス「PDF 電子署名モジュール」（p. 244）でも「自己署名
証明書と対応する秘密鍵」を作成することができ、このような私的に発行する自己署名
証明書を署名の検証に用いることもできる。
私的に発行した証明書と認証局が認証した証明書との違いは、信頼できる証明書発行
198
第 21 章 PDF の真性性・証拠性の確保
機関が所有者の認証を行なっているかどうかである。従来の印鑑との類比で表現するな
らば、私的に発行した自己署名証明書を使うのは三文判の利用に相当するが、認証局が
発行した電子証明書は「印鑑登録証明書」を使うのに近いということができるだろう。
21.1.4 認証局の種類
認証局には次の表のようにいくつかのタイプがある。
表 1 認証局のタイプ
分類
プライベー
特長
企業あるいは企業グループが特定の目的のために運営するものである。
ト認証局
パブリック
一般の民間企業が電子証明書サービス事業として運営するものであり、さまざま
認証局
な種類の証明書が提供されている。
特定認証局
2001 年 4 月に施行された「電子署名及び認証業務に関する法律」（「電子署名
法」）に基づく認定を受けた民間企業が運営するものであり、一般には証明書に記
載される個人を証明する。
商業登記認
法務省が運営する商業登記に基づいて電子証明書を発行するもので、法人格の存
証局
在や代表者の代表権限などを証明する。
それぞれの認証局からは証明書ポリシー（CP）や運用規定（CPS）が公開されてお
り、相手側の電子証明書を発行した認証局の CP/CPS の内容を確認して、信頼の可否を
判断することが可能である。
特定認証局や商業登記認証局で電子証明書を発行する際には、その基礎に戸籍制度や
住民登録制度、印鑑証明制度を置き、それらに基づく証明方法を事前に確認しているた
め、本人のものとして厳格に確認が可能となっている。よって、証明書の信頼度が高い
が、その発行手続きは時間と手間を要する。
電子署名の用途に応じて、適格な認証局が発行した証明書を使用することが求められ
る。例えば、電子帳簿保存法では国税関係書類についてスキャナ保存をする場合は、特
定認証局または商業登記認証局の発行する証明書を使って電子署名を行なうこととされ
ている（電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する
法律施行規則（平成二一年三月三一日財務省令第二二号）第三条５二ロ）。
21.1.5 電子署名の検証
電子署名の検証時には電子文書が改竄されていないかということだけではなく、電子
199
証明書が署名時に有効であったことも確認することがある。例えば、電子帳簿保存法の
スキャナ保存には、国税関係書類の保存期間を通じて電子証明書が有効であり、かつ、
その時点で証明書の失効の届出がなかったことなどを確認できなければならないという
要件がある（電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関
する法律施行規則（平成二一年三月三一日財務省令第二二号）第三条５二ロ（3））。電
子文書が改竄されていないことの検証はプログラムによる計算なので単純であるが、証
明書の有効性を確認するには失効情報の保存あるいはそれに代わる方法が必要である。
21.2 タイムスタンプの仕組み
「タイムスタンプ」とは、信頼の置ける時刻に電子文書が存在していたことを証明する
情報を付与し、それ以降、内容や時刻に変更・改ざんがあったかどうかを証明するもの
である（タイムビジネス認定センター 「タイムスタンプのしくみ」（p. 244））。
一般の電子署名は、個人の PC のタイマーの時刻が刻印される。これは自由に時刻を
変更でき、信頼度が低いものである。対して、タイムスタンプ・サービスでは信頼でき
る時刻認証局がタイムスタンプを発行する。
図 2 タイムスタンプと電子署名の役割
電子帳簿保存法の施行規則では、国税関係書類をスキャナで読み取る際に、電子署名
に認定事業者のタイムスタンプを付し、さらにその書類の保存期間中記録事項が変更さ
れていないことを確認できることを要件としている（電子計算機を使用して作成する国
200
第 21 章 PDF の真性性・証拠性の確保
税関係帳簿書類の保存方法等の特例に関する法律施行規則（平成二一年三月三一日財務
省令第二二号）第三条５二ハ）。
21.3 PDF 電子署名（ISO 32000-1）
21.3.1 PDF 電子署名の概要
PDF 電子署名は PDF ファイルを対象として電子署名をするためのものである。通常
の電子署名と同じように秘密鍵を使って署名をして、署名した PDF に署名データと電子
証明書など一式を取り込んで新しい PDF を作成する。Adobe Reader には署名を検証
するための標準のハンドラが組み込まれているので、署名済みの PDF を Adobe Reader
を使って検証することができる。
21.3.2 PDF 電子署名の標準
PDF 電子署名は、PDF の国際標準 ISO 32000-1:2008（p. 240）の以下の項を中心に
規定されている。
●
ISO 32000-1 12.7 Interactive Forms, 主に 12.7.4.5 Signature Fields pp. 446～
451（署名フィールド）
●
ISO 32000-1 12.8 Digital Signatures pp. 466～478（電子署名）
21.3.3 PDF 独自機能
ISO 32000-1:2008 では、次のような PDF 独自の様々な追加機能も規定されている
（アンテナハウス「PDF 電子署名入門」（p. 244））。
●
署名後の PDF に対して変更制限を設定できる。
●
最初に署名した PDF の状態を保持した状態で、変更部分を PDF の増分更新で追加
して新しい PDF を作成することができる。
●
署名の外観により、署名した PDF の状態をビジュアルに表示ことができる。
署名後の変更許可の設定
最初に署名をつけるときに、署名後の PDF に対して次のよ
うな変更制限を設定することができる。
●
変更を許可しない
●
フォームフィールドの入力と署名フィールドに署名を許可
●
注釈の作成、フォームフィールドの入力と署名フィールドに署名を許可
署名の外観
電子署名のデータは、デジタルデータで眼に見えないものである。PDF
201
では署名に外観をつけることができる。この署名の外観は、署名フィールドに付随する
注釈機能として実現されている。図 3 署名の外観例（p. 202）の「アンテナハウス」の
スタンプが署名の外観の例である。
図 3 署名の外観例
外観を表示する領域をもたない署名（不可視署名）をすることもできる。
署名フィールドの作成
署名したい位置に未署名署名フィールドのある PDF を作成
して相手に渡し、指定位置に、相手の署名をつけて戻して貰うことができる。
21.3.4 PDF 電子署名の検証
PDF 電子署名を設定すると、署名データが PDF に埋め込まれる。この PDF 受領者は
Adobe Reader で署名の検証をすることができる。AdobeReaderX の署名パネルを開
いて検証すると図 4 署名の検証例（p. 202）のような検証結果を表示する。
図 4 署名の検証例
202
第 21 章 PDF の真性性・証拠性の確保
21.4 PDF タイムスタンプ
PDF 電子署名にタイムスタンプ・サービスが提供する時刻を埋め込むことで、PDF 文
書の存在時刻証明が可能となる。ISO 32000-1 ではタイムスタンプは PDF の電子署名
データに属性値としてつけることになっている。このため電子署名なしで、タイムスタ
ンプのみを付加することはできない。
図 5 タイムスタンプを AdobeReaderX の署名のプロパティで確認
203
第 22 章 PDF の長期保存
22.1 長期保存とは
22.1.1 長期保存の用途
従来は紙で保存していたものをほかの方法で保存する。マイクロフィルムのようなア
ナログ方式やデジタルデータで保存する方法がある。デジタル化することで保管のスペ
ースの縮小、また、保管場所に足を運ばなくても遠隔地から閲読することができるよう
になる、アナログ方式よりはメリットが大きい。
紙に変わるデジタルデータ形式としては PDF が最有力である。PDF の優位性はスマ
ートフォン、タブレット、パソコンなどの様々な環境にリーダが提供されていること、
またテキストデータを含むことでテキスト検索ができるなど。これに対して TIFF はリ
ーダが限られる、画像なので検索性が弱いなどの弱点がある。
法律の要請
長期保存を法律で定められている書類・図面など例。
●
会社法
●
建設業法・建築士法により保存が義務付けされた書類・図面。10 年～15 年間。
e 文書法、電子帳簿保存法などは紙に変えて、電子データによる保存を認めている。
その場合は一定の要件を満たす必要がある。
文化遺産
文化遺産として残す。国会図書館などがその役割を負う。法律で要請され
る期間よりはかなり長期間となる。
●
学位規則（昭和 28 年文部省令第 9 号）が改正され 2013 年 4 月から施行される。学
位論文は国会図書館で収集しているが、その形式は長期保存に向いた PDF/A を推
奨している（国立国会図書館 「国内博士論文の収集について」（p. 244））。
22.1.2 長期保存の要件
表示内容が変化しない デジタルデータである PDF 自体は劣化しない。しかし、時間
の経過により、周囲が変わる。
●
規格・仕様が変わる
●
ツールの動作環境が変わる
●
読み手が変わる
205
●
ツールが変わる
周りが変化しても、PDF を当初の意図通り閲読できるようにするように、作成時に配
慮しておく。
証憑性の確保
文書の保管目的が証憑性を確保するものであれば、長期署名などの対
策を施すことになる。
22.2 PDF/A ファミリー
PDF/A（ISO 19005 の同義語）ファミリーは PDF をベースとするプロファイル仕様
の 1 つであり、以下を目的とした規格である。
1） 使用するツールにかかわらず長期間に渡って、視覚的な外観を維持できる
2） 視覚的な外観だけでなく、意味や論理構造といった情報を格納できる
①
ドキュメント内で使用されている各文字に Unicode 値を対応付ける
②
タグ付 PDF の機能を使用して、ドキュメント内に論理構造を埋め込む
この規格は複数パートから構成されており、パート 1（PDF/A-1（ISO 19005-1））
が 2005 年、パート 2（PDF/A-2（ISO 19005-2））が 2011 年、パート 3（PDF/A-3
（ISO 19005-3））が 2012 年にそれぞれ策定された。
22.3 PDF/A-1
米国の AIIM (Association for Information and Image Management) 他の団体が中
心になって、2002 年から策定作業を開始、2005 年 9 月に ISO 標準となった。
PDF/A-1 は、PDF 1.4 の仕様をベースとし、PDF 1.4 の機能のうち、使ってはならな
い機能、指定しなくてはならない機能などを決めている（ISO 19005-1:2005（p. 241））。
PDF/A-1 には、2 種類の準拠レベルが定義されている。
●
PDF/A-1a（レベル A：ISO 19005-1 完全準拠）
●
PDF/A-1b（レベル B：ISO 19005-1 一部準拠）
レベル B は、PDF/A の第二の目的である論理構造などの表現を対象外とし、第一の
目的（長期にわたって表示環境によらず見た目がかわらないことを保証）だけに限定し
たものである。見た目を保証するために必要とされる主な事項としては「カラーの再現
性の保証」、
「フォントの埋め込み」があげられる。また、広範にわたる PDF の機能の中
で、長期間の保存・外観の維持を阻害する可能性のある機能は PDF/A では使用禁止と
なる。使用禁止される主な項目としては、
「暗号化」、
「ファイルの埋め込み (添付ファイ
206
第 22 章 PDF の長期保存
ル)」、「透明」の禁止が該当する。
PDF1.4 で幾つかの機能は必須（要求項目）である。また、一部の機能を禁止または
制限している。次に主な要求項目、禁止項目、制限項目を挙げる。但し、これ以外にも
細かな規定が数多くある。
22.3.1 要求項目（PDF/A-1b）
●
カラーの再現性を保証
○
デバイス独立カラーまたは PDF/A-1 OutputIntent 指定でカラー特性を指定
する
●
フォント埋め込み
○
基本 14 フォントを含む全てのフォントの埋め込み
○
使用している全グリフがあれば、部分埋め込みでも良い
○
埋め込むフォントは、表示用途で埋め込み許可があること（フォントの不正な
埋め込みを避ける）
○
リーダは、文字コードでなく、埋め込みフォントで表示する（文字コードで表
示するとフォント環境によって字形が変わるため）
●
XMP メタデータの埋め込み
22.3.2 要求項目（PDF/A-1a）
PDF/A-1b の要求項目に加えて次の項目を要求する。
●
タグ付き PDF で論理構造を埋め込む
●
ToUnicodeCMap で Unicode への対応（一部フォントを除く）
22.3.3 禁止事項（PDF/A-1a,1b 共通）
●
暗号化を禁止する。このため、パスワードによるアクセス許可はできない
●
LZW 圧縮
●
文書の代替可視化（印刷用と表示用のイメージを埋め込み使い分けすることなどは
禁止）
●
埋め込みファイル（ファイル添付操作）
●
PostScript コード
●
外部コンテンツへの参照など外部依存性
●
透明
207
22.3.4 制 限 事 項
注釈やアクションは全て禁止ではなく、一部の機能が禁止されている。
●
●
注釈の制限
○
隠し注釈、印刷不可の注釈
○
FileAttachment（添付ファイル注釈）
○
Sound、Movie（マルチメディア）
アクションの制限　○
Launch, Sound, Movie, ResetForm, ImportData, JavaScript アクションは禁
止。
○
NextPage, PrevPage, FirstPage, LastPage 以外の名前付きアクションは禁止。
○
対話フォームからアクションを実行禁止
22.3.5 微 細 な 要 求
ISO 19005-1 では、準拠すべき項目を非常に細かく指定している。例えば、フォント
データ構造のエントリの存在、TrueType フォントの符号化への要求などがある。こう
した微細な要求を満たしているかどうかは、ソフトウエアを使って適合性をチェックし
ないと保証できない。
22.4 PDF/A-2
PDF/A のパート 2（PDF/A-2:ISO 19005-2）とパート１との違いを記載する（ISO
19005-2:2011（p. 241））。
ベースとする PDF の仕様が PDF/A-1 は PDF 1.4、PDF/A-2 は PDF 1.7 である。
PDF 1.7 は ISO 32000-1 としても設定されている。PDF 1.4 から PDF 1.7 の間で、仕
様に追加された主なものをまとめる。
●
●
PDF 1.4 → PDF 1.5
○
JPEG2000 圧縮によるイメージ
○
オブジェクトストリーム、Xref ストリーム（圧縮率の向上）
○
オプショナルコンテント
○
XFA Form
PDF 1.5 → PDF 1.6
○
208
暗号化機能の強化（AES 暗号化の追加)
第 22 章 PDF の長期保存
○
●
カラースペース追加（DeviceN、NChannel）
PDF 1.6 → PDF 1.7(ISO 32000-1)
○
3D アートワーク
○
ポータブルコレクション
PDF/A-1 は PDF 1.4 をベースにして各種制限等を加えたものであるが、PDF/A-2 は
ほほ同じような制限を、ベースとなる PDF 1.7(ISO 32000-1) に課したものである。但
し、大きく異なる点として、PDF/A-1 では使用禁止となっていた PDF 1.4 の透明機能
が、PDF/A-2 では使用可能となっている。また、PDF 1.4 から PDF 1.7 で追加された
機能のなかでは、たとえば JPEG2000 圧縮によるイメージは使用可能であるが、XFA
Form は使用禁止である。
次に準拠レベルの定義は、PDF/A-1 ではレベル A およびレベル B の 2 種類を定義し
ているのに対して、PDF/A-2 では以下の 3 種類となっている。
●
PDF/A-2a（レベル A：ISO 19005-2 完全準拠)
●
PDF/A-2b（レベル B：ISO 19005-2 一部準拠）
●
PDF/A-2u（レベル U）
レベル A、レベル B の区分については PDF/A-1（ISO 19005-1）の場合と同等であ
る。レベル U は PDF/A-1 には無かった区分で、レベル A とレベル B の中間に位置する
ものであり、レベル A の論理構造などの情報は含まないが、レベル B の見た目の維持に
加えて、PDF 内のテキストの Unicode 値が取得できることを保証する。
PDF には Adobe Reader などで問題なく表示できても、文字コードが格納されていな
いため、たとえばコピー＆ペーストで他のアプリケーションに持ち込んだ場合に文字化
けしてしまう、というようなものが存在する。これはレベル B の見た目の保証という条
件は満たしているが、レベル U の Unicode 値の取得という条件は満たしていないとい
う状態に該当する。
レベル B を満たしていてもテキストのコピー&ペーストもできない、という可能性が
ある。このときデータの再利用という観点から見た場合不安が残る。レベル U を満た
すとテキストのコピー&ペーストができるので PDF を再利用しやすくなる。
22.5 PDF/A-3
PDF/A-3 の正式名称は「Use of ISO 32000-1 with support for embedded files
(PDF/A-3) 」 で あ り 、 2012 年 10 月 に ISO の 標 準 と な っ た （ ISO 19005-3:2012
（p. 241））。
209
PDF/A は PDF の特定のバージョンをベースとして、その機能に対して、使用範囲を
制限し、長期保存に適した形（視覚的な外観、およびドキュメントの論理構造、意味な
どを継続して維持すること）にするものである。PDF/A-1、PDF/A-2 がベースとする
PDF 仕様はそれぞれ、PDF 1.4、ISO 32000-1 となっている。PDF/A-3 はタイトルか
らもわかるように、PDF/A-2 同様に ISO 32000-1 をベースとしている。変更点は埋め
込みファイル関連である。
PDF/A-2 と PDF/A-3 の仕様書を比較すると、どちらにも、Embedded files という
項がある。この項の記載内容が変更され、PDF/A-3 では補遺部分に PDF/A-2 には無か
った Annex E (informative) Associate Files という項目が追加されている。この部分
を除くと、ISO 32000-1 をベースとし a、b、および u の 3 種類の準拠レベルを定めて
いる点など、PDF/A-3 は PDF/A-2 とほぼ同様である。
22.5.1 PDF の新しい目的
PDF/A-3 仕様の Introduction に、PDF を他のファイルフォーマットのコンテナとし
て機能できるようにすることが新しい目的である、との記載がある。
PDF フ ァ イ ル 内 に PDF や そ の 他 の フ ァ イ ル を 格 納 す る 埋 め 込 み フ ァ イ ル
（Embedded File）と呼ばれる機能がある。Acrobat 8 で「PDF パッケージ」、Acrobat
9 以降で「PDF ポートフォリオ」と呼ばれるようになった機能なども、これを用いて実
装されている。PDF/A-2 の仕様では、埋め込み可能なファイルを PDF/A-1 あるいは
PDF/A-2 形式のファイルに限定している。
PDF/A-3 では、この制限がなくなり、任意の形式のファイルを埋め込むことを認めて
いる。ただし、次のような要件が追加されている。
●
埋め込みファイルがどのようなものであるかを説明するテキストを記載する必要が
ある。
●
埋め込みファイルを記述するデータ内に AFRelationship という、新しいキーを追
加している（PDF/A-1、2 ではベースとなる PDF の仕様に対して使用可能なキーを
制限するような形で仕様を定めているが、PDF/A-3 では、ベースの PDF の仕様で
は定義されていないキーが使われるようになっている）。
●
AFRelationship は、埋め込みファイルと PDF 本文（全体であったり、PDF 内の一
部であったりする）との関係を指定するものである。
●
PDF/A-3 の仕様には、AFRelationship に設定する値の例がいくつか記載されてい
る。
○
210
ワープロファイルから PDF を作成し、元のワープロファイルを PDF 内に埋め
第 22 章 PDF の長期保存
込む場合は"Source"と記載し、PDF のオリジナルデータ（Source File）であ
ることを示す。
○
PDF 内に数式部分があり、この数式を補足するために MathML のデータを
PDF に埋め込む場合は"Supplement"と記載し、PDF 内のデータの補足データ
であることを示す。
○
PDF 内のチャートが存在し、このチャートのデータを CSV で埋め込んでおく
場合、"Data"と記載し、チャートの元データであることを示す。（"Source"、
"Data"、"Supplement"の他に、代替え表現用の"Alternative"それら以外の場合
の"Undefined"が定義されている）
●
このほかに、上記の説明で、埋め込みファイルが PDF ファイル全体に対するもので
あったり（上記のワープロの例）、PDF 内の一部に対するものであったり（上記の
数式の例）することを示すために、PDF 内の各種データに埋め込みデータと対応付
けをするためのキー（AF）が追加されている。
PDF/A-3 は、このような機能の追加により、PDF/A-2 を各種ファイルのコンテナと
して使用できるように拡張したものである。
22.6 PDF/A の作り方
22.6.1 PDF/A の準拠レベル
用途によって要件が異なるため、PDF/A にはいくつかの準拠レベルが定義される。
PDF/A-1 にはレベル A、B の 2 種類の準拠レベルが定義される。レベル A は目的 1
「長期に渡る外観の維持」と目的 2「意味と論理構造といった情報の保持」の双方を満た
すものであり、レベル B は目的 1 だけに限定したものである。
PDF/A-2 および 3 には、レベル A、B の中間となるレベル U が追加されている。これ
は目的 1 の外観の維持、および目的 2 の一部である「各文字と Unicode の対応付け」ま
でを満たすものである。
22.6.2 PDF/A の作成方法と準拠レベル
図 1 アプリケーションソフトから PDF を作る（p. 18）で、アプリケーションソフト
が作成した内容を PDF にする方法を以下のように分類した。
●
PostScript から PDF へ変換（①＋②＋③）
●
アプリケーションから直接 PDF 作成（④）
211
●
仮想プリンタドライバによる PDF 作成（⑤）
レベル A 準拠ファイルの作成には、PDF のコンテンツに論理構造を設定する必要があ
るが、印刷処理による PDF 作成では、仮想プリンタドライバがこの論理構造を取得する
ことができない。このため、仮想プリンタ方式による PDF/A ファイル作成はレベル B
（および U）準拠までとなる。PostScript から PDF 変換の方式も、同様の理由によりレ
ベル B（および U）準拠までとなる。
アプリケーションから直接 PDF を作成する方式では、アプリケーションのドキュメン
トが持つ論理構造を PDF のタグ付けに利用できるため、レベル A 準拠の PDF/A を作成
することが可能である。
次に、現在、一般的に入手可能なツールによる PDF/A 作成方法を記載する。
22.6.3 仮想プリンタ方式による PDF/A 作成
Adobe Acrobat XI の「Adobe PDF」、瞬間 PDF 作成 5 の「Antenna House PDF
Driver 5.0」といった仮想プリンタドライバは、PDF/A-1b ファイルを作成することが
できる。
Adobe PDF 印刷ダイアログのプリンタ選択で、Adobe PDF を選択し、詳細設定の
「PDF 設定」部で、「PDF/A-1b:2005(RGB)（または PDF/A-1b:2005(CMYK)）」を指
定することで、PDF/A-1b に準拠した PDF ファイルが作成される。
Antenna House PDF Driver 5.0
印刷ダイアログのプリンタの選択で、「Antenna
House PDF Driver 5.0」を選択し、詳細設定の「PDF バージョン」部で「PDF/A-1b:
図 1 Acrobat XI Adobe PDF
212
第 22 章 PDF の長期保存
図 2 Acrobat XI Adobe PDF 2
図 3 Antenna House PDF Driver 5.0
2005」を指定することで、PDF/A-1b 準拠の PDF ファイルが作成される。
Antenna House PDF Server V3 Antenna House PDF Driver を搭載したファイル
変換サーバーソリューションソフトウェア「Antenna House PDF Server V3」を利用
すれば、クライアント側に特別なソフトウェアをインストールすることなく、PDF/A-1b
213
ファイルを作成することができる。
22.6.4 PostScript から PDF へ変換
PostScript フ ァ イ ル か ら 、 PDF/A-1b フ ァ イ ル へ の 変 換 は Acrobat に 付 属 す る
Distiller を 使 用 す る こ と が で き る 。 ま た 、 フ リ ー ソ フ ト と し て 配 布 さ れ て い る
Ghostscript も PostScript から PDF への変換機能を持つが、オプション指定により
PDF/A-1b ファイルを作成することができる。
22.6.5 アプリケーションから直接 PDF/A 作成
Microsoft Office Microsoft Office 2010/2013 の Word などでは、直接 PDF を作成
することができるが、このダイアログ内の「ISO 19005-1 に準拠 (PDF/A)」指定により
PDF/A-1a ファイルが作成される。
Microsoft Office 用 PDFMaker Acrobat XI を イ ン ス ト ー ル す る と 、 Microsoft
Office の Word などにアドインプログラム (PDFMaker) が組み込まれる。これを使用
して PDF/A-1a を作成することができる（PDF/A-2、PDF/A-3 も指定可能である）。
図 4 Microsoft Office 用 PDFMaker
214
第 22 章 PDF の長期保存
22.7 PDF 長期署名（PAdES）
PAdES（PDF Advanced Electronic Signatures・PDF 長期署名）の仕様は ETSI
（European Telecommunications Standards Institute・欧州電気通信標準化機構）に
て ETSI TS 102 778「PDF Advanced Electronic Signature Profiles」として標準化さ
れている。ETSI では他にも長期署名仕様として、XAdES（XML Advanced Electronic
Signatures・XML 長期署名・ETSI TS 101 903 / ISO14533-Part2）や CAdES（CMS
Advanced Electronic Signatures・CMS 長期署名・ETSI TS 101 733 / ISO14533Part1）も標準化している。PAdES は XAdES・CAdES に続く ETSI としては 3 つ目の
長期署名フォーマット標準である。XAdES・CAdES が XML（eXtensible Markup
Language・拡張可能なマーク付け言語・W3C 勧告）
・CMS（Cryptographic Message
Syntax・暗号メッセージ構文・RFC3852）の電子署名のフォーマットであることに対
し、PAdES は PDF と言うドキュメントのフォーマットである点が異なる。
PAdES は PDF の標準仕様である ISO32000-2（PDF2.0）への採用に向けて現在作業
中であり、2013 年か遅くとも 2014 年には ISO32000-2 の電子署名部の仕様として採
用される予定になっている。なお ISO32000-1（PDF1.7）においても PDF 電子署名の
仕様が含まれているが、このレガシーな PDF 電子署名仕様は PAdES において PAdESBasic プロファイルとして整理された。この為に ISO32000-1 の PDF 電子署名の仕様
は ISO32000-2 になってもなお有効ではあるが、PAdES-Basic プロファイルの制限に従
う必要があるので注意すること。
PAdES の仕様は先に述べた PAdES-Basic を含む 6 つのパートで構成されている。
Part1 は PAdES 仕様全体の概要になっている。パート毎の仕様について簡単に解説す
る。
表 1 PAdES 仕様の構成
タイトル
概要
Part1: Overview -
PAdES 全体の説明、最初に読むべきパート
a framework document for PAdES (ETSI
Part6 を除く各パートの概要を説明
DTS/ESI-000085-1（p. 240）)
Part2: PAdES Basic -
署名データとして PKCS#7 形式を利用した仕様
Profile based on ISO 32000-1 (ETSI DTS/
ISO32000-1 の PDF 電子署名をベース
ESI-000072-2（p. 240）)
Part3: PAdES Enhanced -
署名データとして CAdES 形式を利用した仕様
215
PAdES-BES and PAdES-EPES Profiles
PAdES-Basic の替わりに利用できる新署名仕様
(ETSI RTS/ESI-000101-3（p. 240）)
Part4: PAdES Long Term -
長期保管をする為の追加仕様
PAdES-LTV Profile (ETSI RTS/
DSS/VRI 辞書と DocTimeStamp に分かれる
ESI-000082-4（p. 240）)
Part5: PAdES for XML Content -
署名データとして XAdES 形式を利用した仕様
Profiles for XAdES signatures (ETSI RTS/
XFA フォームや XML ファイル添付用の電子署名
ESI-000082-5（p. 240）)
Part6: Visual Representations of
署名外観や検証に関する仕様
Electronic Signatures (ETSI DTS/
ただし簡易説明であり詳細は別仕様を参照
ESI-000085-6（p. 240）)
22.7.1 Part1: Overview - a framework document for PAdES
PDF 電子署名では複数の電子署名をシリアル署名として増分更新により追加して行
く事ができる。各電子署名は署名フィールド（Signature Field）を持ち、署名フィール
から署名辞書（Signature Dictionary）や署名外観（Signature Appearance）を指定す
る形式になっている。
署名辞書は Type キーと SubFilter キーにより分類できる。また Filter キーには署名
ハンドラ（PDF Signature Handler）を指定する。Adobe の標準署名ハンドラは
Adobe.PPKLite である。Filter キーに指定された署名ハンドラが見つからない場合か
つ Type / SubFilter キーで指定された内容が扱えるのであれば、指定された署名ハンド
ラと異なる署名ハンドラで検証する事もできる。
表 2 署名辞書の種類
仕様
PAdES-Basic
Type キー値
Sig
PAdES-Enhanced Sig
PAdES-LTV
SubFilter キー値
adbe.pkcs7.detached 又は adbe.pkcs7.sha1
ETSI.CAdES.detached
DocTimeStamp ETSI.RFC3161
PKCS#7 や CAdES・RFC3161 等の署名データは Contents キーに Hex 文字列として
格納される。署名対象範囲を指定する ByteRange キーの範囲としては Contents の
Hex 文字列以外を指す事になる。パスワード等で暗号化された PDF ファイルであって
も Contents の中の Hex 文字列は例外として暗号化されないが、これは ISO32000-1 の
仕様に記述されていない。ISO32000-1 の仕様通りに実装すると署名辞書の Contents
の中の Hex 文字列を暗号化することになるが、Adobe 社の Acrobat / Reader ではエラ
216
第 22 章 PDF の長期保存
ーとなる。Acrobat / Reader との互換性を保つために、PDF 電子署名をサポートして
いるプロジェクトやプロダクトでは通常署名辞書 Contents 中の Hex 文字列は暗号化し
ない。
22.7.2 Part2: PAdES-Basic - Profile based on ISO 32000-1
PAdES-Basic は ISO32000-1:2008（PDF1.7）の PDF 電子署名仕様に対して新しい
要素を追加せず必須となる項目を定めたプロファイルとなっている。署名データとして
は PKCS#7（Public-Key Cryptography Standards #7・公開鍵標準#7・RFC2315）を
利用している。PAdES-Basic では署名辞書の SubFilter 名は adbe.pkcs7.detached ま
たは adbe.pkcs7.sha1 のいずれかとなる。adbe.pkcs7.detached では ByteRange で指
定された範囲自体が署名対象であり、adbe.pkcs7.sha1 では ByteRange で指定された
範囲のハッシュ値が署名対象である点が異なる。Adobe 製品において署名付与および
検証には ISO32000-1 の PDF 電子署名に対応したバージョンが必要となる。実質的に
Acrobat8 以降であればほとんど検証可能であろう。ハッシュ関数として SHA-2 を利用
している署名が使われている場合は Acrobat9 以降が必要である。過去環境との互換性
が PAdES-Basic 仕様を利用する場合の利点と言える。
PAdES-Basic で利用されている署名データ PKCS#7 は、署名証明書の保護が必須で
は無い等、厳密には長期署名には対応していない。その意味では PKCS#7 を利用する
PAdES-Basic 仕様を、PDF 長期署名である PAdES 仕様の一部とする事には懸念する声
もある。PAdES-Basic は長い歴史を持つ PDF 電子署名との互換性を維持する為に
PAdES 仕様に含まれていると言える。世の中には PAdES-Basic に適合した多くの署名
済み PDF ファイルが存在しているが、これらのファイルにも長期保管の道を残す為に採
用 さ れ た 仕 様 で あ る 。 PAdES-Basic は プ ロ フ ァ イ ル と し て ベ ー ス 仕 様 と し て の
ISO32000-1 に制限を付けている為に、過去の PDF 電子署名が全て PAdES-Basic 仕様
に適合している訳では無い点は注意する必要がある。ISO32000-1 には記述されている
が PAdES-Basic では認められていない SubFilter 名等の仕様が存在する。
署名と同時または直後に署名時刻を保証する為に付与するタイムスタンプを、署名タ
イムスタンプと呼ぶ。PAdES-Basic では PKCS#7 署名データに RFC3161 形式のタイ
ムスタンプトークンを埋め込むことで対応している。PAdES-Basic において署名タイ
ムスタンプは should となっているので埋め込むべきである。
22.7.3 Part3: PAdES-Enhanced - PAdES-BES and PAdES-EPES Profiles
PAdES-Enhanced は PAdES-Basic の署名データを CMS 長期署名である CAdES に
217
変更した新仕様である。CAdES は長期署名の仕様を全て満たしている為に、PAdESEnhanced は真の意味での PDF 長期署名の仕様と言える。PAdES-Enhanced では署
名辞書の SubFilter 名が ETSI.CAdES.detached となる。Adobe 製品において署名付与
および検証には Acrobat-X / Reader-X 以降のバージョンが必要となる。Acrobat-9 以
前のバージョンでは検証できないので注意が必要である。
PAdES-Enhanced で利用されている署名データ CAdES は、ベース仕様として CMS
を使っているが、CMS はそもそも PAdES-Basic で使われている署名データ PKCS#7 を
ベースに仕様策定された経緯がある。その意味では PAdES-Enhanced は PAdESBasic の上位互換仕様であると言える。CAdES の基本署名形式としてはまず CAdESBES が あ り 、 更 に ポ リ シ ー を 追 加 し た CAdES-EPES も 利 用 可 能 に な っ て い る 。
CAdES-BES を利用した場合を PAdES-BES プロファイルと呼び、CAdES-EPES を利用
した場合を PAdES-EPES プロファイルと呼ぶ。
CAdES の元仕様では、長期署名のアーカイブタイムスタンプ（CAdES 仕様では
CAdES-A 形式）をサポートしている。アーカイブタイムスタンプとは、アーカイブタ
イムスタンプ以前の署名やドキュメントの内容を保護する為に追加されるタイムスタン
プ の 名 称 で あ る 。 こ れ は CMS/PKCS#7 で は サ ポ ー ト さ れ て い な い 仕 様 で あ り 、
CAdES-A 形式が使えるのであれば実は後述する PAdES-LTV（Part4: Long Term PAdES-LTV Profile）仕様は不要である。しかしながらアーカイブタイムスタンプは有
効期間延長の度に追加して行く必要があり、署名データのサイズがだんだん大きくする
必要がある。一方 PDF 電子署名では署名時に ByteRange により署名データの最大サイ
ズが決まってしまい後からサイズ変更ができない。従ってアーカイブタイムスタンプを
使った CAdES-A 形式は結局 PAdES 仕様では仕組み的に採用できない。
基本的には PAdES-Enhanced 仕様では、署名に署名タイムスタンプ（署名時刻を保
証する為のタイムスタンプ）を加えた CAdES-T 形式までの署名データを使うとされて
いる。PAdES 仕様では長期保管する場合のアーカイブタイムスタンプとして後述する
ドキュメントタイムスタンプを利用する。PAdES-Enhanced においても署名タイムス
タンプは should となっているので埋め込むべきである。
22.7.4 Part4: Long Term - PAdES-LTV Profile
略して LTV（Long Term Validation）と呼ばれるプロファイルであり長期保管に必要
となる仕様がまとめられている。長期保管とは署名やタイムスタンプに使われる証明書
の有効期限が切れてもきちんと署名検証が出来る仕様を指す。長期保管を実現した電子
署名を長期署名と呼ぶ。長期署名には証明書の検証情報の保管とアーカイブタイムスタ
218
第 22 章 PDF の長期保存
ンプが必要となる。PAdES 仕様では、証明書の検証情報の保管に DSS/VRI 辞書を使
い、アーカイブタイムスタンプとしてドキュメントタイムスタンプ（DocTimeStamp）
を使う。
証明書の検証情報の保管（DSS/VRI 辞書） 証明書の検証情報には証明書（認証パス）
と失効情報の 2 種類が含まれる。これら検証情報は署名データに含むことが出来るが、
PDF のオブジェクトとして格納する為の仕様が DSS（Document Security Store）/VRI
（Validation Related Information）辞書である。
表 3 検証情報
検証情報の種類
説明
署名書群
署名証明書（タイムスタンプ証明書を含む）から信頼されたルート証明書（ト
ラストアンカー）までの証明書チェーン（認証パス）を構築する為に必要な
全証明書が必要。
失効情報群
失効情報には、CRL（証明書失効リスト）と OCSP（オンライン失効情報問
合せ）の 2 種類がある。CRL は失効している証明書の情報であり、OCSP は
指定された証明書の失効を含む各種状態を返す。失効情報として CRL と
OCSP のどちらを使っても良い。
検証情報の本体はバイナリのまま PDF のストリームオブジェクトとして追加される。
検証情報をオブジェクトのリファレンス（参照）として管理しているのが DSS/VRI 辞
書となる。DSS 辞書ではその PDF ファイルに含まれる全署名データに必要となる全て
の証明書・CRL・OCSP に対する参照を保持している。更に DSS 辞書では署名データハ
ッシュ値の HEX 文字列をキーとして、署名辞書単位で必要としている証明書・CRL・
OCSP の参照を保持している。検証者は VRI 辞書を見て署名データの検証に必要とな
る検証情報を取得する事になるが、他にも優先順位に従って外部保管した検証情報等を
利用しても良い。
表 4 検証情報の利用優先順位
優先順位
検証情報の格納場所
1
DSS の中の署名 VRI 要素から参照されている検証情報
2
DSS から参照されている検証情報
3
署名データ自身に埋め込まれている検証情報
4
ローカルなリポジトリに保管されている検証情報（外部から提供）
5
オンラインソースから取得された検証情報（ネットワークから取得）
219
ドキュメントタイムスタンプ（DocTimeStamp） ドキュメントタイムスタンプ
（DocTimeStamp）も広義では PDF 電子署名の 1 種と言える。他の電子署名と同様に署
名辞書を利用するが Type キーの値は Sig では無く DocTimeStamp を指定する。署名
データとして RFC3161 形式のタイムスタンプトークン（TimeStamp Token）を利用
する。タイムスタンプトークンのベース仕様は CMS である。ドキュメントタイムスタ
ンプでは署名辞書の SubFilter 名が ETSI.RFC3161 となる。Adobe 製品では署名付与
および検証には Acrobat-X / Reader-X 以降のバージョンが必要となる。
ドキュメントタイムスタンプの署名辞書では Cert・Reference・Changes・R・
Prop_AuthTime ・ Prop_AuthType キ ー は 禁 止 さ れ て い る 。 同 様 に Name ・ M ・
Location・Reason・ContactInfo キーの利用は非推奨になっており、非推奨のキーは存
在していても検証時には無視することになっている。
ドキュメントタイムスタンプをアーカイブタイムスタンプとしてでは無く、署名のか
わりに単独で付与することも許されている。署名では「誰が」と「真正性」を保証する
が、タイムスタンプでは「いつ」と「真正性」が保証される。知財保護等の用途では「い
つ」と「真正性」のみが必要である為にタイムスタンプのみの仕様も実際に使われている。
22.7.5 Part5: PAdES for XML Content - Profiles for XAdES signatures
Part5 では、PDF ファイルの中で XML を使う方法として、XML ファイルを添付ファ
イルとする方法と、入力フォームとして XFA Forms を利用する方法の 2 種類が説明さ
れている。どちらも XAdES 形式の署名データを XML 中に埋め込むことで長期署名が
可能となっている。
22.7.6 Part6: Visual Representations of Electronic Signatures
Part6 では署名外観について簡単に説明されている。署名外観は署名フィールドから
AP キーにより指定されるリソース（XObject）で実現される。しかしながら Part6 では
それ以上の署名外観に関する記述は無い。実際に利用されている署名外観は Adobe 社
が Acrobat SDK の為に公開しているドキュメント「Digital Signature Appearances」
(Adobe Systems “Adobe Acrobat 9 Digital Signature Appearances”
（p. 240）) を参照す
る事が事実上の標準になっている。他に RFC3709 の X.509 証明書に埋め込まれた証
明書イメージや、手書き署名イメージ（RFC3739 の 3.2.5 参照）も推奨されているが現
実的には使われているとは言えない。なお署名外観は「That the signature appearance
is not a source of trust.」と言うことで信頼の証では無い点は注意が必要である。
また Part6 では OASIS の DSS-X（OASIS DSS v1.0 Profile for Comprehensive
220
第 22 章 PDF の長期保存
Multi-Signature Verification Reports Version 1.0 OASIS DSS（p. 242））を参照した
長期署名の検証方法が説明されている。近年では長期署名の検証も標準化が検討されて
おり、将来的には標準化された検証手順を参照して更新されると思われる。
221
第 23 章 PDF を他の形式に変換する
23.1 PDF から HTML に変換する
23.2 PDF からオフィス形式へ
23.3 PDF を画像にする
223
第 24 章 PDF の代替形式
24.1 S
V
G
SVG（スケーラブル・ベクター・グラフィックス）は、ベクトル画像の標準として提
唱されているファイル形式である。XML で記述することになっており、Web との親和
性が高い。
現在は、WebKit などのブラウザ用可視化エンジンでのサポートも進んでいる。また、
オープンソースの SVG エディタ「Inkscape」のような優れた編集ソフトが普及してい
る（Inkscape（p. 240））。
EPUB3.0 が SVG を標準でサポートしている。
このように Web や電子書籍の分野を中心に SVG の利用環境の改善が着実に進んでい
る。
一方、印刷の専門領域でも EPS（Encapsulated PostScript) 問題の解決策（p. 39）で
述べたように、EPS の代わりに使うことが期待されている。Illustrator などのグラフィ
ックス・ソフトが完璧な SVG を作成できるようになれば、SVG を EPS の代わりにつか
うことが実用的になる。しかし、実際は理屈どおりに行かないもので、例えば、アドビ
の Illustrator の出力する SVG は、オリジナルのイラストを忠実に再現していない部分も
ある。これに関してはこれまでいくつか問題が報告されている。Corel の SVG の方が
むしろ品質が良いという意見も聞く。現状では、SVG を作成するソフトと SVG を解読
するソフトの間の互換性に注意して採用しなければならない1）。
24.2 X
P
S
24.2.1 Metro の発表
マイクロソフトが Windows XP の後継として開発した OS である Windows Vista に
は新しく Metro という印刷用の共通プラットフォームが用意された。Metro について
の概要は 2005 年 4 月に発表された。その発表以来、いろいろなメディアが Metro は
PDF キラーではないかと書き立てた。
1） これは 2005 年頃の事情なので要注意。最新状況を確認する必要がある。
225
日本語で読める Metro に関する記事には次のようなものがある。マイクロソフトの
発表に接した記者達は、Metro はアドビシステムズの PostScript や PDF と似ていると
いう印象をもったことがよく分かる。
2005/05/06 マイクロソフトの「Metro」は PDF キラーになるか— CNET Japan
●
（Fried, Ina（p. 243））
2005/04/27 Microsoft の新ファイル形式は『PDF』キラー？ — Japan Internet
●
Com（Kuchinskas, Susan（p. 243））
●
2005/04/26 MS、PDF 対抗の文書フォーマット「Metro」を披露— IT media（IDG
Japan（p. 243））
Metro は開発コードであり、その後 XPS（XML Paper Specification）という名称と
なった。この名前の付け方からしても、いかにも PDF 対抗という雰囲気が伺える。PDF
は紙に相当する電子媒体でなので、XPS が紙（Paper）の XML による名称は、まさに
PDF を XML 言語で表したということを意味する。
24.2.2 XPS に関する情報の経過
4 月 22 日付けの「Metro Specification and Reference Guide V0.7」は、9 月 11 日
付の「XML Paper Specification V0.75」と「Open Packaging Conventions V0.75」
に置き換わった。12 月末までに V0.8 をリリースする予定であった。2005 年 10 月に
はマイクロソフト関係者がブログで XPS について数多く発言した。PDC での発表をひ
とつの山場とし 10 月の発言が多く、11 月になると開発者のブログへの書き込みは減っ
た。
XPS 仕様書は 2006 年 10 月に V1.0 となり、XPS V1.0 の仕様書の配布も開始された。
●
Simonds. “XPS v1 is on-line.”（p. 242）
●
Microsoft. “XML Paper Specification.”（p. 242）
2013 年 2 月時点では、次の Web ページに XPS 情報が集約されている。
●
Microsoft. “XML Paper Specification: Overview.”（p. 242）
XPS プ ロ ジ ェ ク ト の ブ ロ グ ペ ー ジ
MSDN. “ XPS Team Blog - XML Paper
Specification and the Open Packaging Conventions.”（p. 242）
2005 年 11 月 16 日 に 開 設 さ れ た 。 開 設 の 目 的 は 、 XPS と Open Packaging
Conventions の仕様に関して、改訂情報の提供と、プログラム、アイデアなどについて
交換するためのブログ。18 日付けで XSP 0.8 に向けて仕様の改訂情報が公開されてい
る。 このブログがプロジェクトの公式ブログに相当しそうだ。
226
第 24 章 PDF の代替形式
マイクロソフト関係者のブログ
●
Simonds. Andy Simonds Blog（p. 242）
Andy Simonds は、Windows Digital Documents Team のグループ・プログラム・
マネージャ。このブログは、10 月 5 日から開始されている。
●
Yuan, Feng(袁峰) Blog（p. 243）
Feng Yuan は、マイクロソフトで GDI, GDI+, Avalon and printing に関する開発に
従事している。このブログではプログラム開発者の立場での説明が多い。
●
Jones, Brian. “Office Solutions.”（p. 241）
Brian Jones は、Office のファイル・フォーマットの普及活動の担当者。Office で XPS
保存する機能について発言している。
24.2.3 O P C 仕 様
0.75 版で仕様書を二つに分割した目的は、OPC の適用範囲を、XPS のみではなくマ
イクロソフト Office12 の XML 文書などにも広げるため、つまり、XPS というのは印刷
形式のファイルですが、それだけではなく Office12 のネイティブな XML ファイルまで
OPC を使うことになると見られる。
OPC の仕様書では、情報の生産者と情報の消費者の間で、情報の内容や情報源をどう
やってひとまとめに（パッケージ化）して受け渡すかを決めている。パッケージを作り
出す生産者は、インターネット上のサーバ、LAN 上のサーバ、デスクトップ PC などで
あり、パッケージを使う消費者は、デスクトップ PC 上のビューアや、LAN やデスクト
ップ PC に接続したプリンタにあたる。
パーツという基本構成要素をまとめてパッケージを作る。例えば、XML を使って外部
の画像を参照するテキスト文書を作成するとき、テキスト部分がひとつのパーツ、画像
がもうひとつのパーツになり、これを一まとめにしたものがパッケージである。
あるパーツからは、パッケージ内部のパーツのみでなく、外部のパーツも参照できる。
パッケージには参照関係をまとめて定義する関係部もある。パッケージ全体は ZIP で
圧縮されて受け渡される。
OPC 仕様の特徴
1） パッケージのパーツや関係部の記述などすべて XML 仕様に準拠している。
2） 消費者がパッケージを開けてみなくても内容がわかるようなサムネイルを付ける
ことができるようになっていること。
3） パッケージに対してデジタル署名を付けることができること。パッケージ全体は
227
XML で記述され、デジタル署名には XML シグネチャを使う。
XML でドキュメントを作成すると、外部参照している画像ファイルなど多数のファイ
ルに分かれてしまうため受け渡しの際の管理が面倒、という問題がある。OPC は XML
ドキュメントの受け渡しのためのパッケージ化にも使えるかもしれない。
24.2.4 X P S 仕 様
XML Paper Specification（XPS）とは、どのようなものか。まず XPS ドキュメント
の基本構成要素は FixedPage パーツである。FixedPage の概要は次のようなもので要
するに PDF または紙の 1 ページに相当する。
1） FixedPage にはページ上に可視化するすべての視覚的要素、すなわちグラフィッ
クスとテキストを含む。
2） 各ページは大きさと方向をもち、ページ上のレイアウトは決定済。
FixedPage をいくつかまとめると FixedDocument ができ、FixedDocument に順序
をつけて束ねたものが XPS のドキュメント本文パーツ（FixedDocumentSequence
Part）となります。要するに紙を束ねた書類がドキュメントの本文パーツということに
なる。
XSP ドキュメントのパッケージには、本文パーツ以外に、①サムネイル・パーツ、②
プリント・チケット・パーツ、③注釈パーツ、④フォント・パーツ、⑤イメージ・パー
ツがある。
たとえば、本文パーツが使用しているフォントは、フォント・パーツにその実体をも
つ。そして XPS ドキュメントの中にパッケージ化される。これにより、XPS ドキュメン
トを配布したとき、相手先の PC では、生産者が指定したフォントがなくても、XPS ド
キュメントを指定どおりのフォントを使って印刷できる。
イメージを本文とは別のパーツにしているのは、本文で同じイメージを何回も使うと
き、別のパーツとしてのイメージを参照することで、イメージの実体を一つだけもてば
良いからである。
現在までに、マイクロソフトと協力して Metro の開発を行ってきた会社の殆どはプリ
ンタ・メーカとプリンタ・メーカ向けに Windows 用のプリンタ・ドライバの開発を行
っているソフトウエア会社である。これは、Metro が従来の GDI ベースの印刷サブシス
テムがもつ弱点を乗り越える新しい印刷パスとしての位置づけで開発されてきたという
経緯があるからだろう。
しかし、XPS の仕様書をみると、XPS は単なる印刷システム用のスプールファイル形
式ではなく、紙に類似する用紙を定義し、その上にレイアウトされたドキュメントを配
228
第 24 章 PDF の代替形式
布するための機能を持っている。しかも、フォントの埋め込もでき、サムネイル、リン
ク、注釈などの機能ももち、限りなく PDF に近くなっている。少なくとも、XPS は PDF
に競合する使い方を意図して設計されているということはできる。
24.2.5 XPS の構造
次の図のような 4 ページものの XPS ファイルの内容を確認する。
図 1 XPS ファイル
これは ZIP 圧縮された XML 形式のファイルである。ZIP 圧縮ファイルの中には、
FixedDocumentSecuence.fdseq、[Content_Types].xml という二つのファイルのほか、
フォルダが三つある。
図 2 XPS ファイルのフォルダ構造
フォルダの中は次のような構造であり、マイクロソフト Office2007 の Office Open
XML 形式の文書保存形式と良く似ている。
4 ページのそれぞれが別のファイル（1.page～4.page の４つのファイル）になってい
る。この 1.page～4.page はそれぞれ XML ファイルになっていて、各ページのテキス
229
図 3 XPS ファイルのフォルダの中
ト・コンテンツが入っている。ちなみに 1 ページ目（1.page）を取り出して内容をブラ
ウザで表示すると次のようになる。
１ページ目の先頭の行は、「Cocoa & Chocolate」という見出であるが、これは、フ
ァイルの中では、1 ページ目の最後の方にある。 2 行目は、「The term “Cocoa,” a
図 4 XPS ファイルの 1 ページ目
230
第 24 章 PDF の代替形式
corruption of “Cacao,” is」という文字列で、上の画像では、この部分が、 Glyphs
OriginX="26.6666666666667" OriginY="98.2033333333333"
FontRenderingEmSize="16" FontUri="/Resources/a7b9593b-a0f7-4049-a7e6b8107ad481f9.ODTTF" UnicodeString="The term “Cocoa,” a corruption of
“Cacao,” is" Indices=";;;,38;;;;;,38;;;;;;;;;,38;;,38;;;;;;;;;;;,38;;;,38;;;;;;;;;,38"
Fill="#FF000000" となっているのが見える。
従って、文字列は（この例では）1 行単位に区切られていて、文字列の表示開始座標
とともに保存されている。また、ファイルの中では、文字列が表示の順序で現れるとは
限らない、ということが分かる。この特徴は、PDF ファイルと同じである。
それから、この文書には画像が二つあり、この画像は Resources というフォルダの中
に入っていることがわかる。また、上の図で Resources フォルダの中にはフォントらし
きものも入っている。このあたり、PDF と相当に似通っており、XPS は PDF をざっく
り XML で表現したものといっても大筋では間違っていないだろう。
24.2.6 XPS を作成する方法
XPS について知らないアプリケーションから XPS を自動的に出力する方法には次の
二通りある（Ford, Adrian（p. 240））。
●
Microsoft XPS Document Writer (MXDW) を使う
●
カスタム・ドライバを作る方法
MXSW を使う方法は.NET でも Win32API のアプリでも可能である。MXDW を起動
する方法は二つある。
1） ユーザが MXDW を印刷用のプリンタ・ドライバとして明示的に選択する。
MXDW は Save As ダイヤログを出すのでユーザがファイル名を入力する。
2） アプリケーションがプログラムで MXDW を選択する。GDI の DOCINFO 構造
体の lpszOutput にファイル名を設定するとファイル名が自動的につく。
カスタム・ドライバを作る方法はアプリケーションを改造できなくて、かつ、ファイ
ル名をユーザに指定させたくないとき、MXDW のコア・コンポーネントが MS の WDK
（Windows ドライバ・キット）として提供されているのでそれを使う。
1） WDK を使ってカスタムドライバ XPSDrv をつくる。
2） WDK には、フィルター・パイプライン・インターフェイスを使って、XPS の内
容をカスタマイズする方法などのサンプルもある。
この方法を使えば、カスタム・ワークフローへの印刷、のような機能をつくることが
できる。これだとまた、ワークフローに必要な独自の設定もできる。
231
24.3 F l a s h
232
謝
辞
2.4 PDF/E (ISO 24517)（p. 13）、2.5 PDF/UA (ISO 14289)（p. 14）、22.6 PDF/A の
作り方（p. 211）、17.2 PDF/X ファミリー（p. 167）ほか PDF/X 関連の記事はアンテナ
ハウスの松下明男の執筆した内容を利用しています。 第 21 章 PDF の真性性・証拠性の
確保（p. 197）はアンテナハウスの益田康夫の執筆した記事を利用しています。22.7
PDF 長期署名（PAdES）（p. 215）の節を有限会社ラング・エッジ代表取締役宮地 直人
氏に執筆していただきました。また、PDFInterest グループにて高木 和人氏、家田 文隆
氏にコメントをいただきました。別途、道広 勇司氏、アンテナハウスの石野 恵一郎に
もコメントをいただきました。心からお礼を申しあげます。
233
図 表 一 覧
図一覧
第 1 章 PDF ってどんなもの？
図 1 ポータブルの意味（p. 3）
図 2 HGP 創英角ポップ体（p. 5）
図 3 フォントの置換（p. 5）
図 4 Acrobat Distiller で PDF を作成（p. 8）
図 5 Acrobat2 のパッケージ（p. 9）
第 3 章 デスクトップで PDF を作成する
図 1 アプリケーションソフトから PDF を作る（p. 18）
図 2 PostScript ファイルを出力（p. 19）
図 3 Adobe PDF の印刷ダイヤログで、「ファイルに印刷」をチェック（p. 21）
図 4 Adobe PDF で作成したファイルの先頭（p. 22）
図 5 アドインボタンで PDF を作成（p. 29）
図 6 Word アドインの設定（p. 30）
図 7 Illustrator で作成した PDF のプロパティ（p. 33）
図 8 InDesign で作成した PDF のプロパティ（p. 34）
図 9 「瞬簡 PDF バインダー」のスキャナー連携メニュー（p. 35）
図 10 透明テキストを検索（p. 37）
第 4 章 PDF・Web・電子書籍
図 1 コンテンツ・レイアウトと成果物（p. 42）
図 2 fo:simple-page-master（p. 43）
図 3 用紙マスターに流し込むコンテンツを対応つける（p. 44）
図 4 レイアウト指定のないコンテンツから出版物を作る（p. 50）
第 5 章 PDF のナビゲーション機能
図 1 サムネイルウインドウを表示（p. 54）
図 2 しおり（p. 54）
図 3 しおりのある有価証券報告書（p. 55）
図 4 PDF ファイル構造（しおり関連）（p. 56）
図 5 宛先の設定（p. 57）
図 6 アクションの設定（p. 58）
第 7 章 文字コードと文字の表示形
図 1 IME のメニュー（p. 71）
図 2 Unicode では結合文字で表す文字（p. 73）
235
図 3 結合文字の仕組み（p. 74）
図 4 コードポイント・字体・字形（p. 82）
図 5 包摂基準の例（p. 83）
図 6 Adobe-Japan1 の CID とグリフの関係（p. 87）
図 7 Adobe-Japan1 のグリフ重複（p. 88）
図 8 Adobe-Japan1 のグリフ重複２（p. 88）
図 9 異なる CID と検索（p. 89）
図 10 CMap で文字コードから CID へ変換（p. 91）
図 11 Adobe-Japan1 の縦書き用グリフと横書き用グリフ（p. 92）
図 12 結合文字の例（p. 95）
図 13 アラビア文字の単独形と接続形（p. 96）
図 14 単語にカシーダを挿入してない状態（p. 98）
図 15 単語にカシーダを挿入した状態（p. 98）
図 16 Arabic Ligature Jallajalalouhou：U+FDFB（p. 99）
図 17 リガチャ（フォント別）（p. 100）
図 18 ラームとアリフのリガチャ（p. 102）
第 8 章 スクリプト処理
図 1 スクリプト処理の役割（p. 103）
図 2 字幅のない結合文字（p. 105）
第 10 章 PDF とフォント
図 1 ビットマップフォントの例示（p. 114）
図 2 文字から GID への対応（p. 126）
図 3 英数字混在文章の横書き（p. 127）
図 4 英数字混在文章の縦書き（p. 127）
図 5 PDF で文字を表示する方法（p. 129）
図 6 フォントを埋め込んだ PDF の「フォント」プロパティの例（p. 130）
図 7 フォント埋め込み PDF の表示（p. 131）
図 8 日本語文字を含む PDF の表示（p. 132）
図 9 WindowsXP のロケールを日本語に切り替え（p. 133）
図 10 フォントを埋め込まない中国語 PDF（p. 133）
図 11 アラビア文字は強制的に埋め込む（p. 134）
図 12 フォント・プロパティ（アラビア文字埋め込み）（p. 134）
図 13 フォントを埋め込まないラテン文字 PDF（p. 134）
図 14 フォント・プロパティ（ラテン文字非埋め込み）（p. 135）
図 15 プロポーショナルフォントの縦書き（p. 135）
図 16 プロポーショナルフォントの縦書き（フォント埋め込み）（p. 136）
図 17 埋め込みフォントの選択（p. 139）
236
図表一覧
第 14 章 PDF の配布と閲覧
図 1 PDF のプロパティ（p. 152）
第 15 章 PDF を編集・加工する
図 1 スタンプ注釈（Acrobat 9 Pro）（p. 159）
第 21 章 PDF の真性性・証拠性の確保
図 1 法務省電子証明書取得ソフトウェア説明画面より（p. 198）
図 2 タイムスタンプと電子署名の役割（p. 200）
図 3 署名の外観例（p. 202）
図 4 署名の検証例（p. 202）
図 5 タイムスタンプを AdobeReaderX の署名のプロパティで確認（p. 203）
第 22 章 PDF の長期保存
図 1 Acrobat XI Adobe PDF（p. 212）
図 2 Acrobat XI Adobe PDF 2（p. 213）
図 3 Antenna House PDF Driver 5.0（p. 213）
図 4 Microsoft Office 用 PDFMaker（p. 214）
第 24 章 PDF の代替形式
図 1 XPS ファイル（p. 229）
図 2 XPS ファイルのフォルダ構造（p. 229）
図 3 XPS ファイルのフォルダの中（p. 230）
図 4 XPS ファイルの 1 ページ目（p. 230）
表一覧
第 1 章 PDF ってどんなもの？
表 1 Acrobat のバージョンと PDF Reference の版番号（p. 10）
第 2 章 PDF の国際標準
表 1 PDF の使い方に関する仕様（p. 13）
第 3 章 デスクトップで PDF を作成する
表 1 Acrobat の仮想 PDF ドライバ名（p. 20）
第 7 章 文字コードと文字の表示形
表 1 地域別文字規格（p. 67）
表 2 Unicode の収録文字数（p. 79）
表 3 Adobe-Japan1 各版に追加されたグリフの概要（p. 85）
表 4 Adobe-GB1（p. 89）
表 5 Adobe-CNS1（p. 90）
表 6 Adobe-Korea1（p. 90）
237
表 7 Adobe-Japan1 用 CMap（p. 91）
表 8 アラビア語の句読点（p. 96）
表 9 アラビア文字の数字（p. 97）
第 8 章 スクリプト処理
表 1 結合文字（p. 105）
第 12 章 PDF のファイルサイズ
表 1 PDF で扱える圧縮方法（p. 143）
第 15 章 PDF を編集・加工する
表 1 主な注釈（p. 157）
第 16 章 PDF の利用を制限する
表 1 リビジョン 2 の標準セキュリティ・ハンドラで許可できること（p. 163）
表 2 リビジョン 3・4 の標準セキュリティ・ハンドラで制限できること（p. 163）
第 17 章 印刷ワークフローにおける PDF
表 1 ISO 15930 ファミリー（p. 168）
表 2 PDF/X 用の出力インテント辞書（p. 171）
表 3 PDF で扱える圧縮方法（p. 174）
表 4 PDF/X-1a の文書情報辞書の一般項目の設定（p. 176）
表 5 ページオブジェクト辞書のページ境界関連項目（p. 177）
第 21 章 PDF の真性性・証拠性の確保
表 1 認証局のタイプ（p. 199）
第 22 章 PDF の長期保存
表 1 PAdES 仕様の構成（p. 215）
表 2 署名辞書の種類（p. 216）
表 3 検証情報（p. 219）
表 4 検証情報の利用優先順位（p. 219）
238
参 考 資 料
AbFares, Huda Smitshujizen. Arabic Typography, a comprehensive sourcebook. Saqi Books, 2001
Adobe Systems Incorporated. PDF Reference, fifth edition:Adobe Portable Document Format Version
1.6 Adobe, 2004. Web. 2013 年 4 月 8 日
Adobe Systems Incorporated. “FAQ for Adobe PageMaker Users.” Adobe, n.d. Web. <http://
www.adobe.com/products/pagemaker/pdfs/pm_up_faq.pdf> 2013 年 4 月 8 日
Adobe Systems Incorporated. “PostScript Printer Drivers for Windows.” Downloads Web. <http://
www.adobe.com/support/downloads/product.jsp?product=pdrv&platform=win> 2013 年 4 月 8 日
Adobe Systems Incorporated. “PostScript Printer Drivers for Macintosh.” Downloads Web. <http://
www.adobe.com/support/downloads/product.jsp?product=pdrv&platform=mac> 2013 年 4 月 8 日
Adobe Systems Incorporated. “pdfmark Reference Manual.” Adobe Solutions Network. 2 Oct 2005.
Web. <http://partners.adobe.com/public/developer/en/acrobat/sdk/pdf/pdf_creation_apis_and_specs/
pdfmarkReference.pdf> 2013 年 4 月 11 日
Adobe Systems Incorporated. “Adobe-Japan1-6 Character Collections for CID Keyed Fonts.” Adobe
Technical Note #5078. 11 June 2004. Web. <http://www.adobe.com/content/dam/Adobe/en/devnet/font/
pdfs/5078.Adobe-Japan1-6.pdf> 2013 年 4 月 13 日
Adobe Systems Incorporated.“Adobe CMap and CIDFont Files Specification Ver.1.0.”Font Technical
Notes. 11 June 1993. Web. <http://partners.adobe.com/public/developer/en/font/5014.CIDFont_Spec.pdf>
2013 年 4 月 13 日
Adobe Systems Incorporated. “Adobe-GB1-4 Character Collection for CID-Keyed Fonts.” Adobe
Technical Note #5079. 30 Nov 2000. Web. <http://partners.adobe.com/public/developer/en/font/
5079.Adobe-GB1-4.pdf> 2013 年 4 月 13 日
Adobe Systems Incorporated. “Adobe-CNS1-4 Character Collection for CID-Keyed Fonts.” Adobe
Technical Note #5080. 27 May 2003. Web. <http://partners.adobe.com/public/developer/en/font/
5080.Adobe-CNS1-4.pdf> 2013 年 4 月 13 日
Adobe Systems Incorporated. “Adobe-Korea1-2 Character Collection for CID-Keyed Fonts.” Adobe
Technical Note #5093. 27 May 2003. Web. <http://partners.adobe.com/public/developer/en/font/
5093.Adobe-Korea1-2.pdf> 2013 年 4 月 13 日
Adobe Systems Incorporated. “CFF / Type 2 Q & A.” Web. <http://partners.adobe.com/public/developer/
opentype/index_cff2.html> 2013 年 4 月 14 日
Adobe Systems Incorporated. “Multiple Master Fonts.” Web. <http://partners.adobe.com/public/
developer/opentype/index_mult_master.html> 2013 年 4 月 14 日
Adobe Systems Incorporated. “CID-Keyed Font Technology Overview: Technical Note #5092.”12
September 1994. Web. <http://partners.adobe.com/public/developer/en/font/5092.CID_Overview.pdf>
2013 年 4 月 14 日
Adobe Systems Incorporated. “Adobe Far Eastern Fonts (1 seat) Japanese.”Font EULAs Web. <http://
www.adobe.com/products/type/font-licensing/end-user-licensing-agreements.html> 2013 年 4 月 14 日
Adobe Systems Incorporated. Adobe XMP Developer Center. Web. <http://www.adobe.com/jp/devnet/
239
xmp.html> 2013 年 4 月 14 日
Adobe Systems Incorporated. “Adobe Acrobat 9 Digital Signature Appearances.”5 May 2008. Web.
<http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/
acrobat_digital_signature_appearances_v9.pdf> 2013 年 5 月 19 日
ETSI DTS/ESI-000085-1. “PDF Advanced Electronic Signature Profiles; Part 1: PAdES Overview - a
framework document for PAdES.” European Telecommunications Standards Institute. Web. <http://
webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=31003> 2013 年 5 月 19 日
ETSI DTS/ESI-000072-2. “PDF Advanced Electronic Signature Profiles; Part 2: PAdES Basic - Profile
based on ISO 32000-1.” European Telecommunications Standards Institute. Web. <http://
webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=31004> 2013 年 5 月 19 日
ETSI RTS/ESI-000101-3. “PDF Advanced Electronic Signature Profiles; Part 3: PAdES Enhanced PAdES-BES and PAdES-EPES Profiles.” European Telecommunications Standards Institute. Web.
<http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=34235> 2013 年 5 月 19 日
ETSI RTS/ESI-000082-4. “PDF Advanced Electronic Signature Profiles; Part 4: PAdES Long Term PAdES LTV Profile.” European Telecommunications Standards Institute. Web. <http://
webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=31941> 2013 年 5 月 19 日
ETSI RTS/ESI-000082-5. “PDF Advanced Electronic Signature Profiles; Part 5: PAdES for XML
Content - Profiles for XAdES signatures.” European Telecommunications Standards Institute. Web.
<http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=31942> 2013 年 5 月 19 日
ETSI DTS/ESI-000085-6.“PDF Advanced Electronic Signature Profiles; Part 6: Visual Representations
of Electronic Signatures.” European Telecommunications Standards Institute. Web. <http://
webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=31986> 2013 年 5 月 19 日
Ford, Adrian.“Generating XPS Automagically.”Adrian Ford on XPS et cetera. 1 Feb 2008. Web. <http://
blogs.msdn.com/b/adrianford/archive/2008/02/02/generating-xps-automagically.aspx> 2013 年 4 月 20 日
Global Graphics Software Inc. Jaws PDF Creator 5.0. Acton: GGS, 2010. Web. <http://www.jawspdf.com/
pdfs/pdf_creator.pdf> 2013 年 4 月 9 日
International Color Consortium. “ICC Characterization Data Registry.”Web. <http://www.color.org/
registry2.html> 2013 年 4 月 20 日
International Color Consortium. “CMYK Characterization data.”Web. <http://www.color.org/
drsection1.html> 2013 年 4 月 20 日
IDPF.“EPUB 3 Becomes Final IDPF Specification.”News and Events. International Digital Publishing
Forum, 10 Oct 2010. Web. <http://idpf.org/news/epub-3-becomes-final-idpf-specification> 2013 年 6 月 5
日
Inkscape. Web. <http://inkscape.org/> 2013 年 4 月 15 日
ISO 32000-1:2008. “Document management -- Portable document format -- Part 1: PDF
1.7.”International Organization for Standardization. 2008.
ISO 14289-1:2012. “Document management applications — Electronic document file format
enhancement for accessibility — Part 1: Use of ISO 32000-1 (PDF/UA-1).” International
Organization for Standardization
ISO 15930-1:2001. “Graphic technology -- Prepress digital data exchange -- Use of PDF -- Part 1:
Complete exchange using CMYK data (PDF/X-1 and PDF/X-1a).” International Organization for
240
参考資料
Standardization
ISO 15930-3:2002. “Graphic technology -- Prepress digital data exchange -- Use of PDF -- Part 3:
Complete exchange suitable for colour-managed workflows (PDF/X-3).” International Organization
for Standardization
ISO 15930-4:2003. “Graphic technology -- Prepress digital data exchange using PDF -- Part 4:
Complete exchange of CMYK and spot colour printing data using PDF 1.4 (PDF/X-1a).”
International Organization for Standardization
ISO 15930-5:2003. “Graphic technology -- Prepress digital data exchange using PDF -- Part 5: Partial
exchange of printing data using PDF 1.4 (PDF/X-2).” International Organization for Standardization
ISO 15930-6:2003. “Graphic technology -- Prepress digital data exchange using PDF -- Part 6:
Complete exchange of printing data suitable for colour-managed workflows using PDF 1.4 (PDF/
X-3).” International Organization for Standardization
ISO 15930-7:2010. “Graphic technology -- Prepress digital data exchange using PDF -- Part 7:
Complete exchange of printing data (PDF/X-4) and partial exchange of printing data with external
profile reference (PDF/X-4p) using PDF 1.6.” International Organization for Standardization
ISO 15930-8:2010. “Graphic technology -- Prepress digital data exchange using PDF -- Part 8: Partial
exchange of printing data using PDF 1.6 (PDF/X-5).” International Organization for Standardization
ISO 19005-1:2005. “Document management -- Electronic document file format for long-term
preservation -- Part 1: Use of PDF 1.4 (PDF/A-1).” International Organization for Standardization
ISO 19005-2:2011. “Document management -- Electronic document file format for long-term
preservation -- Part 2: Use of ISO 32000-1 (PDF/A-2).” International Organization for
Standardization
ISO 19005-3:2012. “Document management -- Electronic document file format for long-term
preservation -- Part 3: Use of ISO 32000-1 with support for embedded files (PDF/A-3).”International
Organization for Standardization
ISO 24517-1:2008. “Document management -- Engineering document format using PDF -- Part 1: Use
of PDF 1.6 (PDF/E-1).” International Organization for Standardization
Joint Bi-level Image experts Group. JBIG Home Page. Web. <http://www.jpeg.org/jbig/index.html> 2013 年
4 月 20 日
Jones, Brian. “Follow up on questions around PDF support in Office ‘12’ (part 1 of many).” Brian
Jones: Office Solutions. MSDN Blogs, 4 Oct 2005. Web. <http://blogs.msdn.com/b/brian_jones/archive/
2005/10/04/476997.aspx> 2013 年 4 月 11 日
Jones, Brian. Brian Jones: Office Solutions. MSDN Blogs. Web. <http://blogs.msdn.com/b/brian_jones/>
2013 年 4 月 17 日
Leurs, Laurens.“The History of Fonts.”Prepressure.com. 2 Sep 2011 Web. <http://www.prepressure.com/
fonts/basics/history> 2013 年 4 月 14 日
Levantovsky, Vladimir. “Open Font Format.”The Moving Picture Experts Group. July 2008 Web.
<http://mpeg.chiariglione.org/standards/mpeg-4/open-font-format> 2013 年 4 月 14 日
“Tag: ‘jp90’.”Microsoft Typography. 29 Jan 2008. Web. <http://www.microsoft.com/typography/otspec/
features_fj.htm#jp90> 2013 年 4 月 11 日
Microsoft News Center. “Microsoft’s Steven Sinofsky Discusses Support for the PDF Format in Office
241
‘12’.” 02 October 2005. Web. <http://www.microsoft.com/en-us/news/features/2005/
oct05/10-02OfficePDF.aspx> 2013 年 4 月 10 日
Microsoft. “What is TrueType?” Microsoft Typography. 30 June 1997. Web. <http://www.microsoft.com/
typography/WhatIsTrueType.mspx> 2013 年 4 月 13 日
Microsoft. “OpenType specification.” Microsoft Typography. 21 September 2009. Web. <http://
www.microsoft.com/typography/otspec/> 2013 年 4 月 14 日
Microsoft. “cmap - Character To Glyph Index Mapping Table.” Microsoft Typography. 20 November
2008. Web. <http://www.microsoft.com/typography/otspec/cmap.htm> 2013 年 4 月 14 日
Microsoft. “OpenType Overview.” Microsoft Typography. 22 March 2001. Web. <http://
www.microsoft.com/typography/otspec/otover.htm> 2013 年 4 月 14 日
Microsoft. “XML Paper Specification.” Windows Dev Center. 24 Oct 2006. Web. <http://
msdn.microsoft.com/en-us/windows/hardware/gg463431.aspx> 2013 年 4 月 17 日
Microsoft. “XML Paper Specification: Overview.” Windows Dev Center. 30 June 2006. Web. <http://
msdn.microsoft.com/en-us/windows/hardware/gg463373.aspx> 2013 年 4 月 17 日
Microsoft. “Uniscribe.” msdn. 21 Nov 2012. Web. <http://msdn.microsoft.com/en-us/library/
dd374091%28v=vs.85%29.aspx> 2013 年 4 月 13 日
MSDN. “XPS Team Blog - XML Paper Specification and the Open Packaging Conventions.”Web.
<http://blogs.msdn.com/b/xps/> 2013 年 4 月 17 日
Institute of Standards and Technology. “Announcing the ADVANCED ENCRYPTION STANDARD
(AES).”26 Nov 2001. Web. <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf> 2013 年 4 月 20 日
OASIS. “OASIS DSS v1.0 Profile for Comprehensive Multi-Signature Verification Reports Version 1.0.”
12 Nov 2010. Web. <http://docs.oasis-open.org/dss-x/profiles/verificationreport/oasis-dssx-1.0-profiles-vrcs01.pdf> 2013 年 5 月 19 日
PDFlib GmbH. “Source Code of PDFlib Lite 7.” PDFlib PDFlib, n.d. Web. <http://www.pdflib.com/
download/free-software/pdflib-lite-7/> 2013 年 4 月 9 日
Phinney, Thomas W. “TrueType, PostScript Type 1, & OpenType: What’s the
Difference?”Typblography 26 Dec 2004. Web. <http://blogs.adobe.com/typblography/TT%20PS
%20OpenType.pdf> 2013 年 4 月 13 日
Phinney, Thomas W. “Phasing out ‘PostScript’ Type 1 fonts.”Typblography 6 Oct 2005. Web. <http://
blogs.adobe.com/typblography/2005/10/phasing_out_typ.html> 2013 年 4 月 13 日
Penney, Laurence. “A History of TrueType.”TrueType Typography. Web. <http://www.truetypetypography.com/tthist.htm> 2013 年 4 月 13 日
Simonds, Andy. “XPS v1 is on-line.”Andy Simonds Blog. 25 Oct 2006. Web. <http://blogs.msdn.com/b/
andy_simonds/archive/2006/10/25/xps-v1-is-on-line.aspx> 2013 年 4 月 17 日
Simonds, Andy. Andy Simonds Blog. <http://blogs.msdn.com/b/andy_simonds/archive/2006/10/25/xps-v1is-on-line.aspx> 2013 年 4 月 17 日
Unicode, Inc. “Chronology of Unicode Version 1.0.” History of Unicode. 13 Feb 2009. Web. <http://
www.unicode.org/history/earlyyears.html> 2013 年 4 月 12 日
Unicode, Inc. “Early Years of Unicode.” History of Unicode. 13 Feb 2009. Web. <http://
www.unicode.org/history/earlyyears.html> 2013 年 4 月 12 日
Unicode, Inc. “Linear B Syllabary.” Unicode 6.2 Character Code Charts. 3 Jan 2013. Web. <http://
242
参考資料
www.unicode.org/charts/PDF/U10000.pdf> 2013 年 4 月 13 日
Unicode, Inc. “Linear B Ideograms.” Unicode 6.2 Character Code Charts. 3 Jan 2013. Web. <http://
www.unicode.org/charts/PDF/U10080.pdf> 2013 年 4 月 13 日
Unicode, Inc. “Unicode and ISO 10646.” Frequently Asked Questions. 21 Dec 2012. Web. <http://
www.unicode.org/faq/unicode_iso.html> 2013 年 4 月 13 日
Unicode Consortium. “The Unicode Standard, Version 4.0.” Addison-Wesley, 2003.
Unicode Consortium. “The Unicode Standard, Version 5.0.” Addison-Wesley, 2007.
W3C. “Web Content Accessibility Guidelines (WCAG) 2.0, W3C Recommendation.” 11 Dec 2008.
Web. <http://www.w3.org/TR/2008/REC-WCAG20-20081211/> 2013 年 4 月 14 日
W3C. “Techniques for WCAG 2.0, Techniques and Failures for Web Content Accessibility Guidelines
2.0, W3C Working Group Note.” 3 January 2012. Web. <http://www.w3.org/TR/2012/NOTE-WCAG20TECHS-20120103/> 2013 年 4 月 14 日
W3C. “Extensible Stylesheet Language (XSL) Version 1.0, W3C Recommendation.” 15 October 2001.
Web. <http://www.w3.org/TR/2001/REC-xsl-20011015/> 2013 年 4 月 20 日
W3C. “Extensible Stylesheet Language (XSL) Version 1.1, W3C Recommendation.” 05 December
2006. Web. <http://www.w3.org/TR/xsl11/> 2013 年 4 月 20 日
Wesslings, Cyndy. “Save as PDF in Office ‘12’.” Cyndy Wessling. MSDN Blogs, 7 Oct 2005. Web.
<http://blogs.msdn.com/b/cyndy_wessling/archive/2005/10/08/478419.aspx 2013 年 4 月 11 日
Yuan, Feng(袁峰). MSDN Blogs> Feng Yuan (袁峰). Web. <http://blogs.msdn.com/b/fyuan/> 2013 年 4 月
17 日
Fried, Ina「マイクロソフトの‘Metro’は PDF キラーになるか」CNET Japan 2005 年 05 月 06 日 ウェブ
<http://japan.cnet.com/news/biz/20083315/> 2013 年 4 月 17 日
IDG Japan「MS、PDF 対抗の文書フォーマット‘Metro’を披露」IT Media ニュース 2005 年 05 月 06 日
ウェブ <http://www.itmedia.co.jp/news/articles/0504/26/news014.html> 2013 年 4 月 17 日
Impress Watch「PDF 日本語版」
『窓の杜』ウェブ <http://www.forest.impress.co.jp/library/software/primopdf/
> 2013 年 4 月 9 日
JIS X 0221『国際符号化文字集合（UCS）—第一部　体系及び基本多言語面』日本規格協会 1995
JIS X 0213『７ビット及び８ビットの２バイト情報交換用符号化拡張漢字集合』日本規格協会 2012
Kuchinskas, Susan「Microsoft の新ファイル形式は‘PDF’キラー？」 インターネットコム 2005 年 4 月 27
日 ウェブ <http://japan.internet.com/webtech/20050427/12.html> 2013 年 4 月 17 日
「Vista で化ける字，化けない字」『ITPro』2006 年 12 月 14 日 ウェブ<http://itpro.nikkeibp.co.jp/article/
COLUMN/20061211/256519/> 2013 年 4 月 12 日
「Vista で化ける字，化けない字（続報）」
『ITPro』2006 年 12 月 25 日 ウェブ<http://itpro.nikkeibp.co.jp/article/
COLUMN/20061221/257533/> 2013 年 4 月 12 日
「32 ドットビットマップフォントの無断複製について」ウェブ <http://wiki.fdiary.net/font/?stolenbitmap>
2013 年 4 月 14 日
「アウトラインフォントエディタ 概要」
『FontForge』ウェブ <http://fontforge.org/ja/overview.html#Overview>
2013 年 4 月 13 日
アドビシステムズ 『PDF リファレンス第 2 版―Adobe Portable Document Format Version 1.3 』ドキュメ
ントシステム訳 ピアソン・エデュケーション 2001 年
「アラビア系文字」『moji』ウェブ <http://moji.gr.jp/script/arabic/> 2013 年 4 月 11 日
243
アンテナハウス「PDF 出力ライブラリー」『アンテナハウス製品 OEM 販売のご相談』ウェブ <http://
www.antenna.co.jp/oem/PDFCreator/> 2013 年 4 月 9 日
アンテナハウス「PDF 電子署名モジュール」 ウェブ <http://www.antenna.co.jp/ml/back/> 2013 年 5 月 26 日
アンテナハウス「PDF 電子署名入門」2008 年 8 月 24 日 ウェブ <http://www.antenna.co.jp/PDF/reference/
PDFSingature.html> 2013 年 5 月 26 日
アンテナハウス「Unicode と XSL によるアラビア語の組版」
『多言語組版研究会（開催記録）』ウェブ <http://
www.antenna.co.jp/ml/back/> 2013 年 4 月 13 日
アンテナハウス「中国の文字規格 (メモ)」ウェブ <http://www.antenna.co.jp/ml/back/Chinese/
gb_charset_memo.htm> 2013 年 4 月 12 日
アンテナハウス「日刊経済情報誌（17 種類）の自動組版システム」『AH Formatter 導入事例紹介』ウェブ
<http://www.antenna.co.jp/AHF/ahf_jirei/casestudy_nna.html> 2013 年 4 月 11 日
タイムビジネス認定センター 「タイムスタンプのしくみ」『タイムスタンプとは』ウェブ <http://
www.dekyo.or.jp/tb/system/system_1.html> 2013 年 5 月 26 日
マイクロソフトサポート「最新の Word Viewer の入手方法」ウェブ <http://support.microsoft.com/kb/891090/
ja> 2013 年 4 月 8 日
マイクロソフト 「ファイルへ出力」
『Windows7』ウェブ <http://windows.microsoft.com/ja-jp/windows7/printto-file> 2013 年 4 月 8 日
マイクロソフト 「Windows の次期バージョン Windows Vista(TM) において日本語フォント環境を一新」
『PressPass』2005 年 7 月 29 日 マイクロソフト ウェブ <http://www.microsoft.com/japan/presspass/
detail.aspx?newsid=2353> 2013 年 4 月 12 日
「マルチプルマスターダイアログ 」
『FontForge』ウェブ <http://fontforge.org/ja/multiplemaster.html> 2013 年
4 月 14 日
リコー「ファイル形式とデータ量について」『スキャナーの小咄』ウェブ <http://www.ricoh.co.jp/scanner/
kobanashi/04.html> 2013 年 4 月 11 日
リコー「ビットマップフォント 」『フォント』ウェブ <http://www.ricoh.co.jp/font/built_in/bitmap/> 2013 年 4
月 13 日
リコー「エレメント方式フォント RT Font 」
『フォント』ウェブ <http://www.ricoh.co.jp/font/built_in/element/
> 2013 年 4 月 13 日
大熊 肇 「字体・字形・書体・字種」『TONAN's WEB 文字』ウェブ <http://www.tonan.jp/moji/11jitai/
index.html> 2013 年 4 月 13 日
大阪地裁 「海賊版フォント搭載ＰＣ販売事件」2004 年 5 月 13 日 ウェブ <http://www.translan.com/jucc/
precedent-2004-05-13b.html> 2013 年 4 月 14 日
加藤弘一 「小は大をかねるか？」
『ほら貝：文字コード』1997 年 11 月 16 日 ウェブ <http://www.horagai.com/
www/moji/show.htm#show02> 2013 年 6 月 22 日
国語審議会『表外漢字字体表』文部科学省 2000 年 12 月 8 日 ウェブ <http://www.mext.go.jp/b_menu/shingi/
old_bunka/kokugo_index/toushin/1325296.htm> 2013 年 4 月 13 日
国立国会図書館 「国内博士論文の収集について」2013 年 3 月 12 日 ウェブ<http://www.ndl.go.jp/jp/aboutus/
hakuron.html> 2013 年 6 月 5 日
小林 龍生ほか「言語の表記手段としての文字」
『bit 別冊 インターネット時代の文字コード』共立出版、2001
年 4 月号
「今昔文字鏡」紀伊国屋書店 2007 ウェブ <http://www.mojikyo.com/> 2013 年 4 月 13 日
244
参考資料
「自分で作る電子書籍 PDF 本の作り方（改訂版）－裁断機とドキュメントスキャナで作る電子書籍－」ウェブ
<http://bungakubu.kokushikan.ac.jp/chiri/Teacher/Hasegawa/PDF_BOOKS/newpage1.html> 2013 年 4 月
15 日
島根県立大学『eKanji』 2004 ウェブ <http://ekanji.u-shimane.ac.jp/> 2013 年 4 月 13 日
菅原 純「中国・新疆ウイグル自治区における文字と印刷・出版文化の歴史と現状」ウェブ <http://
www.aa.tufs.ac.jp/~tjun/data/gicas/xjcpp.pdf> 2013 年 4 月 11 日
染原 睦美「アドビ、PDF 作成ソフト廉価版 Acrobat Elements の販売終了へ」
『ITPro』2007 年 5 月 15 日 ウ
ェブ <http://itpro.nikkeibp.co.jp/article/NEWS/20070515/270990/> 2013 年 4 月 10 日
東京大学多国語処理研究会「ゆたかな文字文化を創りあげるために」 ウェブ <http://www.l.u-tokyo.ac.jp/
KanjiWEB/00_cover.html> 2013 年 4 月 13 日
日本タイポグラフィ協会「電子ドキュメントデータへのフォント埋込み機能に対する タイプフェイス／フォ
ントの権利保護に関する声明書」1998 年 11 月 28 日 ウェブ <http://www.typography.or.jp/act/morals/
moral4.html> 2013 年 4 月 14 日
「日本の文字コード」
『Cyber Librarian』ウェブ <http://www.asahi-net.or.jp/~ax2s-kmtn/character/japan.html>
2013 年 4 月 11 日
藤井 久美子『近現代中国における言語政策』 株式会社三元社発行 2003 年
文化庁『常用漢字表（平成 22 年 11 月 30 日内閣告示）』ウェブ <http://www.bunka.go.jp/kokugo_nihongo/pdf/
jouyoukanjihyou_h22.pdf> 2013 年 4 月 13 日
法務省「電子証明書取得のご案内」『商業登記に基づく電子認証制度』ウェブ <http://www.moj.go.jp/MINJI/
minji06_00028.html#042> 2013 年 5 月 26 日
三上 喜貴『文字符号の歴史 アジア編』共立出版 2002
道広 勇司『アラビア系文字の基礎知識』2005 年 ウェブ <http://moji.gr.jp/script/arabic/article01.html> 2013 年
4 月 11 日
峰岸 真琴 「タイ語，ラオス語，カンボジア語（クメール語）の文字処理と組版における課題」2003 年 6 月 9
日 ウェブ <http://www.aa.tufs.ac.jp/~mmine/lecture/lec03/TLKChar/TKL03menu.htm> 2013 年 4 月 20 日
峰岸 真琴 「東南アジア大陸部のインド系文字」2003 年 6 月 9 日 ウェブ<http://www.aa.tufs.ac.jp/~mmine/
SEAGrammatology/SEAGrammatologymenu.htm> 2013 年 4 月 20 日
安岡 孝一「Adobe-Japan1 の漢字 (部首画数順)」『漢字文化の全き繼承と發展のために』2006 年 11 月 29 日
ウェブ <http://coe21.zinbun.kyoto-u.ac.jp/results.html.ja> 2013 年 4 月 13 日
245
索
アルファベット
Adobe-CNS1 88
Adobe-GB1 88
Adobe-Japan1 87
Adobe-Korea1 88
AES（Advanced Encryption Standard） 164
Formatter AH Formatter 44
AH Formatter 38
ASCII コード 67
CAdES 218
CFF (Compact Font Format) 119
CID (Character ID) 86
CID-Keyed フォント 121
CJK 64
CJK 統合漢字 77
CSS 48
Distiller 8, 20
EPS 38
e-漢字データベース 84
GDI 型プリンタ・ドライバ 18
Ghostscript 22
GID 126
GT フォント 84
ISO 14289-1 15
ISO 10646 78
ISO 32000-1 11
JBIG2 143, 174
JIS X 0201 69
JIS X0208 70
JIS X0212 71
JIS X 0213 72
JIS X0221 78
JPEG 34
Laser Writer 7
metadata stream 145
on-the-fly 61
Open Office.org 32
OpenType 122, 126
OPI：Open Prepress Interface 170
PDF/X-4 187
PAdES 215
PAdES-Basic 217
PAdES-Enhanced 217
PageMaker 7
引
PDF/UA 14
PDF/X-1 169
PDF/X-1a：2003 170
PDF/X-2 184
PDF/X ファミリー 167
PDF/A 206
PDFLib 23
PDFMaker 28
PDFMark 38
PDF リーダ 1
PDF Reference 2
PDF 電子署名 201
PostScript 6, 38
PostScript プリンタ・ドライバ 17, 19
TIFF 34
TrueType フォント 115, 118
Type0 フォント 120
Type1 フォント 115, 116
Type3 フォント 120
Unicode 77
Uniscribe 75, 104
WCAG 2.0 153
Web 表示用に最適化 151, 152
XMP メタデータ 146
XSL-FO 組版エンジン 44
XSL-FO 42
あ
アウトラインフォント 115
アクセシビリティ 153
アラビア文字 95
アーカイブタイムスタンプ 218
異体字 81
一括 PDF 作成 26
埋め込みファイル 210
か
仮想 PDF ドライバ 20, 28
グリフ 85
グリフセット 85
グリフデータ 126
結合文字 95, 104
高圧縮 PDF 37
公開鍵暗号化 164
合成済み文字 105
247
今昔文字鏡 84
コードポイント 78
さ
サムネイル
53
しおり 54
字形 81
字体 80
字体中心主義 80
字幅のある記号 105
字幅のない記号 105
シフト JIS コード 70
商業登記認証局 199
証明書の検証情報 219
常用漢字表 80
書体 81
署名外観 220
署名タイムスタンプ 217
真正性 220
スクリプト処理エンジン 104
ストリーム・オブジェクト 145
正字 81
全角文字 70
互換分解マップ 101
俗字 81
た
ダイアクリティカルマーク 94
大文字セット 84
タグ付き PDF 31, 110
ターンドデジタル 17
注釈 157
長期署名 218
テキスト 67
デジュール標準 2
デファクト標準 2
電子化文書 17
電子証明書 197
電子書籍 193
電子署名の検証 199
電子文書 17
透明テキスト付き PDF 35, 36
248
ドキュメント情報辞書 145
ドキュメント・スキャナー 34
ドキュメントタイムスタンプ 220
特定認証局 199
な
認証局
199
は
半角文字 70
ハングル 92
ビットマップフォント 114
フォント 113
フォントファイル形式 116
符号化文字 66, 80
符号化文字集合 66
プレーンテキスト 67, 103
プロファイル仕様 12
ページ記述言語 6
ページプリンタ 6
包摂 82
ポータブル 3
ポートフォリオ 210
ボーンデジタル 17
ま
マルチプルマスター・フォント
マークアップ注釈 158
メイリオ 74
メタデータ 145
面区点位置 82
文字 66
文字コード 66
文字集合 66
ら
ライブラリー 23
リガチャ 99
リニアライズド PDF
リンク 57
ルート証明書 198
連綿体 95
151
119
PDF インフラストラクチャ解説
2013 年 3 月 11 日
2013 年 7 月 21 日
0.25
0.34
PDF のアクセシビリティにタグ付 PDF を記述
PDF の注釈の種類の項を詳しくした
編 著 者 小林　徳滋
発 行 所 アンテナハウス株式会社 CAS 電子出版
住 所 東京都中央区東日本橋 2 丁目 1 番 6 号
電話番号 03-5829-9021
Ｗ Ｅ Ｂ http://www.cas-ub.com
Copyright © 2012-2013 Antenna House, Inc.

パンフレット - 日本ビジュアルコミュニケーション協会

特許図面作成のワークショップ - 日本ビジュアルコミュニケーション協会

北日本看護学会研究奨励委員会 平成 27 年度奨励研究募集要項

平成 26 年度 公社保有地の売却に係る一般競争入札の結果について

NEOソレタンシュ工法【PDF0.9MB】

情報セキュリティ: 2005年7月8日

ケミクリートプライマーNS

詳細 - JEMIC 日本電気計器検定所

学校全体で取り組む環境保全活動 - リデュース・リユース・リサイクル推進