PDF 内部構造 テキストのソースを表示
新しいページはコチラ
移動:
案内
,
検索
[[PDF 内部構造#説明|PDF 内部構造]]に戻る。 == '''概要''' == PDFの最も重要な機能であるテキスト機能を使ったPDFファイルの作り方について触れていきます。いままでの知識も必要になります。自分で作れるようになると楽しさがアップです。WordみたいなことがPDFだけで出来るようになっていきます。しかも、かなり柔軟に設定もできるので、作りたいと思った文書ファイルが思うがままです。こういうのを理解すると自分でPDFファイルを超柔軟な設定が扱えるようなプログラムを作りたくなってきます。 === '''テキスト状態''' === テキスト状態についての設定をするオペレータを紹介していきます。まずは、以下のようなソースで基本的な文書が作れることを示します。 <syntaxhighlight2 lang="text"> %PDF-1.7 %粤ﾏﾓ 1 0 obj << /Kids [2 0 R] /Type /Pages /Count 1 >> endobj 2 0 obj << /Rotate 0 /Parent 1 0 R /MediaBox [0 0 1033 1462] /Resources 3 0 R /Type /Page /Contents [4 0 R] >> endobj 3 0 obj << /Font << /F0 << /BaseFont /Times-Italic /Subtype /Type1 /Type /Font >> >> >> endobj 4 0 obj << >> stream %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %ここからが方眼紙作成のグラフィックストリーム。 % .....(省略)..... % %ここまでが方眼紙作成のグラフィックストリーム。 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %テキスト文字列部分ストリーム開始 BT %BT(=Begin Text) /F0 36 Tf % F0=Times-Italicで 36 Tfのフォントサイズ 1 0 0 1 100 800 Tm %Tmは現在のテキストマトリクスを移動(平行移動/回転/拡大縮小) 50 TL % TLはテキストレディング垂直(上下)余白 50 ポイントになる。テキストの左下が50ポイント間隔 (Create a PDF file. How the text works.) Tj T* %Tjはオペランドの配列()の中を現在のグリフ設定で描画。 %T*は次の行へ移動 3 Tc % Tcは文字の間隔 (Create a PDF file. How the text works.) Tj T* 10 Tw % Twは単語の間隔 (Create a PDF file. How the text works.) Tj ET % ET(=End Text) %テキスト文字列部分ストリーム終了 endstream endobj 5 0 obj << /Pages 1 0 R /Type /Catalog >> endobj xref 0 6 trailer << /Root 5 0 R /Size 6 >> startxref 0 %%EOF </syntaxhighlight2> このような設定でPDF生成すると以下のようなPDF表示を得ることができます。 [[ファイル:PDF Text Condition.png|400px|thumb|none|テキストの例]] 方眼紙になっているので、文字列が50ポイント置きに配置されていることがわかります。ポイント単位で細かく文字を配置できる気配がします。そしてテキスト状態を変えるオペレータを記述すると最初は文字列の間隔が変わり、次に単語単位の間隔も帰れました。英語の斜体文字のグリフの扱いは複雑なので、どこがどれくらい広がったのか、論理的な説明は難しいので、ここでは、だいたい変化させれるということにとどめておきます。おいおい、検証することにしましょう。 Createの最後のeの文字に注目すると文字間隔を3ポイントにした後の真ん中の行と一番最初の行で比較すると、Createの文字の間は5つで、3 ポイント× 5 つ で15 ポイントです。eの左端が15ポイントくらいずれた場所に配置されている感じなので文字間隔が数値どおり広がっていると考えて問題ないでしょう。それにくわえて単語間となる部分の文字間隔は2つ分と単語間隔1つ分16ポイントくらい移動しているようにも見えます。 <table style="width: 100%; text-align: left; border-collapse: collapse; border-spacing: 0;"> <tr style=" background: #778ca3; border-right: solid 1px #778ca3; color: #ffffff;"> <th style="width: 175px;">オペランド</th> <th style="width: 175px;">オペレータ</th> <th>簡単な説明</th> </tr> <tr> <td>文字列</td> <td>Tj</td> <td>オペランド配列で指定されてた文字列の描画をする</td> </tr> <tr style=" background: #eeeeee;"> <td>数値</td> <td>TL</td> <td>垂直文字間隔の設定。規定値は100</td> </tr> <tr> <td>数値</td> <td>T*</td> <td>次の行に移動</td> </tr> <tr style=" background: #eeeeee;"> <td>数値</td> <td>Tc</td> <td>文字間隔のポイント値をオペランドに指定</td> </tr> <tr> <td>数値</td> <td>Tw</td> <td>単語間隔のポイント値をオペランドに指定</td> </tr> <tr style=" background: #eeeeee;"> <td>数値</td> <td>Tf</td> <td>フォントサイズ</td> </tr> <tr> <td>数値</td> <td>Tz</td> <td>水平間隔。指定した値/100の値。規定値が100で1を意味する</td> </tr> <tr style=" background: #eeeeee;"> <td>数値,数値,文字列</td> <td>"</td> <td>オペランドに文字間隔,単語間隔,文字列を一括で指定するオペレータ</td> </tr> <tr> <td>文字列</td> <td>'</td> <td>T* 文字列 Tj という構造の動作を文字列 ' だけで指定できる</td> </tr> <tr style=" background: #eeeeee;"> <td>文字列に数値を含む</td> <td>TJ</td> <td>オペランドに文字間隔と文字列を一括で指定するオペレータ</td> </tr> <tr> <td>数値6個</td> <td>Tm</td> <td>最初の数値はcmで指定する値と同じ意味だが、テキストがグラフィックス座標系を基準とした上に配置される点では同じオペレータではない。</td> </tr> <tr style=" background: #eeeeee;"> <td>数値</td> <td>Tr</td> <td>整数値1指定でモード切替。</td> </tr> <tr> <td>数値</td> <td>Ts</td> <td>ベースラインモードを整数値で切り替え。</td> </tr> </table> === '''日本語を扱う''' === ==== '''日本語PDFファイルサンプル''' ==== 残念ながら上記のような設定ではテキストで文字列配列の部分に日本語を入力しただけでは日本語は扱えません。簡単ではないってことですね。フォント設定にコツがいります。文字列配列の指定もエスケープシーケンスを意識した設定が必要です。で、実際に手作業で組んでいくのはかなり難しいので、ここでは既に日本語への変換方法を知っているアプリケーションにPDFを作成してもらって、そこから解析していくという、手法をとります。わかってる人たちはスゴイよ。自分は信頼できるアプリケーションとして、Windows10でMicrosoftWordを使います。やっぱね。この組み合わせは安定しているよ。完璧なアプリケーションとは言えないかもしれなけれど、PDFを出力する基本部分くらいなら、100%大丈夫だよね。さすがは世に出てきているだけのことはある。そんな感じです。個別のフォントでどういう設定にするべきかを調べようと思うと、また別のフォント解析アプリを使ったり、作ったりして立ち向かう必要がありますが、そういう基本的なことをWordとWindows10の組み合わせではやってくれます。 ありがたい。で、さっそく出力しました。それだけだと埋め込みフォントっていう、もう一歩先進的なことをやってしまいますので、これを埋め込まないフォントとして扱うように、ちょろっとイカサマ的な操作をします。そうして出来上がるのが以下のような文書です。文書の内容は「美しいMS ゴシックフォントの世界」としました。あんまり長文にすると、わけわからなくなってくるので、16文字ね。 サンプルソース：[[メディア:JpTextPoweredByWord-text.pdf|JpTextPoweredByWord-text.pdf]]<br /> サンプルPDF ：[[メディア:JpTextPoweredByWord.pdf|JpTextPoweredByWord.pdf]] ※WindowsとかのMSゴシックフォントが存在する環境でのみ表示される日本語テキスト表示PDFです。通常PDFではフォント情報を埋め込む方式を使うので、環境によって表示されない、このような環境依存方式を採用することはありません。これは簡単に表示させるための作戦でしかないです。埋め込まないPDFは表示が環境依存ですが、そのかわりファイルサイズが軽くなります。Webページと同じだね。 [[ファイル:PDF Text_JpString.png|400px|thumb|none|日本語テキスト表示の例]] 少し長いサンプルソースなので、全部載せて、説明はしません。日本語を表示するために、使われているフォントやコード関連のオペレータの意味については解読して、日本語文書ファイルを作れるようにしていきます。 ==== '''日本語PDF仕組み''' ==== Windowsでのコマンドラインは、自分はSJISで動かしています。PDFtkはファイルをSJISで書かれている認識して処理しています。そうするとファイル中で日本語を使うときは、2種類の方法になります。ひとつはSJISの文字コードの数値あるいはテキストそのままを入れて文字を表現する。テキストをそのまま入れる場合は文字コードのレベルで数値化したレベルのPDFファイルとして認識してSJISとして処理されるという概念を常に意識します。もう一つは、SJIS以外の文字コードを使うとして、オペレータで文字コードはこういうものを使っていますと指定して、文字コードの数値で入力するという方法です。そのまま日本語の文字列をPDFファイル内に配置する訳にはいかないことが面倒なところです。ということは、テキストエディタだけでPDFを構成するのは簡単ではないと想像できると思います。この他、イメージなんかも全部テキストで表現するとしたら同じような理由でテキストエディタだけで操作するのは、困難を極めます。自分でPDF編集アプリをつくらないと楽にはならないでしょう。でも、理解するということは、そういうことをやっていくきっかけにはなるはずです。 簡単じゃないのはいやだな。 ==== '''日本語PDFフォント情報''' ==== では、日本語を入力することを考えていきましょう。 要(かなめ)は、フォント情報をページ構成の一部として取り込む部分です。英字でもやった。リソースオブジェクトとして設定した辞書のなかに設定する /Font オペレータですね。一般にはフォント設定は3個のオブジェクトに分けて書くことが多いようです。以下のような構成です。 <syntaxhighlight2 lang="text"> 2 0 obj << /Resources << /Font << /F0 3 0 R >> >> >> 3 0 obj %Resourceで定義されたフォントに関する辞書 << /Type Font /Name /F0 /Subtype /Type0 /BaseFont /#82l#82r#83S#83V#83b#83N %KozMin /KozMinPr6N-Regular /DescendantFonts[4 0 R] >> 4 0 obj %Fontで定義されたDescendantFontに関する情報 << /Type /Font /SubType /CIDFontType2 %KozMin /CIDFontType0 /BaseFont #82l#82r#83S#83V#83b#83N %KozMin /KozMinPr6N-Regular /CIDSystemInfo << /Registry (Adobe) /Ordering (Identity) %KozMin (Japan1) /Supplement 0 % KozMin 6 >> /FontDescriptor 5 0 R >> 5 0 obj ％DescendantFontで定義されたFontDescriptor情報 << /Type /FontDescriptor /FontName #82l#82r#83S#83V#83b#83N %KozMin /KozMinPr6N-Regular /Flags 6 /StemV 6 0 R /Ascent 859 /Descent -140 /ItalicAngle 0 /FontBBox 7 0 R /CapHeight 679 >> … </syntaxhighlight2> という具合にリソースの定義部で、/Fontフォントが定義され、その中で/DescendantFonts。そしてさらにその中で/FontDescriptorについての定義がされる。コメントの％KozMinは、Macのフォントの小塚明朝の場合はこんな感じの記述という例で、完全に動作するとは保証できないのであしからず。この3段論法みたいなフォント情報はひとつにまとめて書くことが出来る。まとめて記述するには、以下のような感じ。 <syntaxhighlight2 lang="text"> 2 0 obj << /Resources << /Font << /F0 3 0 R >> >> >> 3 0 obj %Resourceで定義されたフォントに関する辞書 << /Type /Font /Subtype /Type0 /BaseFont /#82l#82r#83S#83V#83b#83N /ToUnicode 4 0 R /Encoding /Identity-H /DescendantFonts [ << /Type /Font /BaseFont /#82l#82r#83S#83V#83b#83N /W 11 0 R /CIDToGIDMap /Identity /CIDSystemInfo << /Supplement 0 /Ordering (Identity) /Registry (Adobe) >> /Subtype /CIDFontType2 /FontDescriptor << /FontName /#82l#82r#83S#83V#83b#83N /StemV 1000 /Ascent 859 /Flags 6 /Descent -140 /ItalicAngle 0 /FontBBox [-1000 -140 1000 859] /Type /FontDescriptor /CapHeight 679 >> >> ] >> endobj 4 0 obj << >> stream endstream endobj … </syntaxhighlight2> 三つを一つに纏めれましたが、この三つは意味が違うので注意が必要です。/F1という名前のフォントはType0という扱いをします。という意味合いで、このファイルでの扱いを、決めるための定義なのでこのPDFファイルのための独自情報です。ここでType0になっているのは、複数のフォントを、まとめれるという特徴があるのでよく使われるフォントタイプです。その中にある/DescendantFontsにはこういうフォントを組み合わせて使いますという具合です。Descendantは日本語で子孫という意味です。実際に利用するフォントの構造を指定しています。ＭＳゴシックがTrueTypeのCIDフォントだということを意味しています。 そして、/FontDescriptorはストリームで対応する文字コードについてのフォント情報が無かったときはどのフォントは情報に従うのかという意味を持っています。Descriptorとは説明する者という意味です。 ==== '''日本語PDFフォント情報のオペレータ個別の意味''' ==== ===== '''/SubType''' ===== 今回たまたまWordから生成されたPDFが使っただけ部分で順番にみていくと/SubTypeが定義されていて、サブタイプの意味は以下の通りになっています。 <table style="width: 100%; text-align: left; border-collapse: collapse; border-spacing: 0;"> <tr style=" background: #778ca3; border-right: solid 1px #778ca3; color: #ffffff;"> <th style="width: 175px;">サブタイプ名</th> <th style="width: 175px;">タイプ</th> <th>簡単な説明</th> </tr> <tr> <td>Type0</td> <td>Type0</td> <td>コンポジットフォント。複合型、階層構造をもつフォント。</td> </tr> <tr style=" background: #eeeeee;"> <td>Type1</td> <td>Type1</td> <td>エンコード形式を持つグリフ定義。</td> </tr> <tr> <td>MMType1</td> <td>Type1</td> <td>マルチプルマスタフォント。</td> </tr> <tr style=" background: #eeeeee;"> <td>Type3</td> <td>Type3</td> <td>PDFグラフィックスオペレータストリームで定義するフォント</td> </tr> <tr> <td>TrueType</td> <td>TrueType</td> <td>TrueTypeフォント形式に基づくフォント</td> </tr> <tr style=" background: #eeeeee;"> <td>CIDFontType0</td> <td>CIDFont</td> <td>グリフ形式がType1に基づくCIDフォント</td> </tr> <tr> <td>CIDFontType2</td> <td>CIDFont</td> <td>グリフ形式がTrueTypeに基づくCIDフォント</td> </tr> </table> 専門用語のオンパレードですね。上記の設定のようにSubtypeが記述される箇所によって、CIDFontType2って言うたり、Type0フォントって言ったりしてる。この点がややこしく感じますが少し前に記述したように、このファイルで扱うフォント形式としての宣言と参照するフォントの形式の定義になっています。 簡単にフォントファイル形式の現状を説明するならば、TrueTypeやCIDFontType TrueType系はマイクロソフト牽引しているフォントファイルの形式です。TrueTypeそのものはAppleが開発したものですが、マイクロソフトが先にWindowsというOSを流行らせたため、この形式を採用したマイクロソフトが先導する形になってファイル形式の定義自体もマイクロソフトの都合のいいように扱われていった感じです。あるフォントの属性値の意味がマイクロソフトによって捻じ曲げられたりした可能性もあります。Adobeが牽引したのがType0やType1という形式のフォントです。Apple Computerは主にデザイナーに愛されたコンピュータでAdobe製品との親和性が高かったため、こちらを使うことになります。TrueTypeとType1ともにCIDFontという形式を採用します。フォントファイルは文字コード体系毎に存在していましたが、CIDFontはCMapという文字コードとフォントファイル内のグリフIDの対応表みたいなものをセットにするという概念をもっています。そして現在は両陣営ともにOpenTypeというものに統合しようと決めたというのが現在の状態です。フォントの仕組みの標準化という動きもあって、現状よりももっともっとOpenTypeに代わっていくはずです。置き換わる途中でまた新しい仕組みが生まれる可能性もあります。OpenTypeはビットマップフォントにも対応しているし絵文字やマルチバイト・国際化そういうものの全てに対応できるようになっています。フォントを制作している大きな会社もこの動きに追随するべく、置き換えが進んでいます。しかし、過去の遺産も多く、古いフォントファイルじゃないと動作しないアプリが使われている業界もあったりと、移行は簡単ではないという感じですね。なんやかんやで、結局はお金かかります。誰かが頑張ってフォント作っている以上はね。対価がないと移行できない。そんなこんなで、Type1やCIDFontTypeというものは使われなくなってきているのが現状です。新しいAdobe製品ではType1フォントは読み込めないようになっていったりしています。CIDFontもわりとあたらしい技術ですが、近く非対応になることがきまっています。 困ってる人いるんだろう。Microsoftは慌てず騒がずやっていくようです。現在のWindowsフォントシステムとTrueTypeが優れているという自負でしょうね。 上記のサンプル例では出来る限りシンプルな形式にするため、CMapをUnicodeに変換するストリームの内容も消したため、文字列を選択してコピーしてテキストにペーストした場合、文字化けします。ふむー。いろいろ気を使わないとだめだな。PDF手ごわい。CMapはフォントの文字番号を意味しています。PDFではこの情報を、Unicodeとの対応を示すことで、コピーした時にテキストとして有用な文字コード番号に関する情報を得て、テキスト編集がしやすいような工夫がされています。PDFでは文字選択によるコピーをさせないようなモードもありますし、文字の形状をフォントファイルの中から得て、テキスト描画時に指定された文字情報はフォントから抜き出すための番号であり、その番号が対応するテキストは何かというのを個別のものとして管理しています。/ToUnicode 4 0 R という部分がその部分で、この参照先のオブジェクトに本来であれば、文字コードに対応する部分の情報をつけておくのが普通です。 ここまでやって日本語は使える状態になったといえるでしょう。 ここではひとまず、表示に関わる設定のみにしぼって説明してから、発展させていくものとして話を進めます。 ===== '''/BaseFont''' ===== /FontNameでもフォントの名前を指定しますが、通常は同じ値になります。この値はPDFを更に紙や仮想プリンタでPDFや他の形式へ印刷するときにPostスクリプトが使われるときのフォント名の指定として使われます。そこで改めてフォントが参照されて、フォントの輪郭・形状を印刷機にわたりグリフ情報が活用されます。Fontの孫情報であるDescendantFont情報で指定するFontNameと同じでないと印刷するときに違うフォントが使われてしまいチグハグなことになってしまいます。ここで注目してほしいのは値の指定方法が少し特殊なことになっていることです。PDFのソースファイルの形式がSJISであれば、普通に /BaseFont ＭＳゴシック のように日本語フォント名を使っていも良いですが、SJISではない場合はコマンドラインの文字コードに合わせる必要があります。自分の場合はSJISなのでSJISのコードを使いました。指定方法が少し特殊で、2バイト目に文字を使っています。これはアルファベットの1バイトコードに割り当てられた数字で、1文字の値になっています。 /FontName /#82l#82r#83S#83V#83b#83N % 82(l=0x6C) : Ｍ % 82(r=0x72) : Ｓ % 83(S=0x53) : ゴ % 83(V=0x56) : シ % 83(b=0x62) : ッ % 83(N=0x4E) : ク という具合です。気になる人はSJISの2バイト文字一覧表を確認してみると良いでしょう。こんな面倒なこと本当にやるのっていう感じですが、テキストエディタによっては楽々に変換できます。サクラエディタだと、特に簡単でSJIS形式でファイルを保存して、文字コードを知りたい一文字毎に、カーソルを合わせると値を見ることができます。後ろの一文字だけをアルファベットに置き換えるには、置き換えたい文字を範囲選択して、メニューの[変換]-[文字コード]の UTF-8→SJIS を選択するとよいでしょう。pdftkコマンドにかけるテキストをSJISにするなら、普通に日本語を打ち込むだけで良いです。#82#6Cのように番号に変換しなくても良いです。間違えてUTF8形式で保存してしまうと。文字化けの原因になるので、最初からSJISコードの数字にしておいた方が、テキストが何形式でもSJIS文字番号として解釈するため、文字化けの原因にもならず、フォントがおかしな設定になって、見つかりません的なことにはなりません。複雑やね。コマンドが解釈する文字コードとテキストが保有する文字コード。テキストの表示処理に使われてる文字コードいろいろあります。そうなんですよ。テキストがSJISで保存してるんだけど、表示処理自体はUTF-8になってたりすることもあります。UTF-8の文字コードでプログラムは処理していて、保存するときにSJISとかの形式にして保存するという意味です。サクラエディタはそのような仕組みになっています。PDFtkをSJIS環境のコマンドで動かすと、#82l#82r#83S#83V#83b#83Nのように日本語文字のフォント名を置き換えます。また次もSJISで処理されてもうまくうごくように工夫されているのかもしれないし。自分の考えすぎかもしれない。こんな方式あるんだ。的なことって、この界隈には沢山あります。知らないことだらけですからね。うちらは後塵を拝しています。 文字コードの仕組みを細かく追っていける冷静な人になれるといいね。それくらいまで理解できていないと文書ファイルを自由自在に操るには壁になるよ。おちついて考えれば理解できるはずだし、わかっている方が、間違いの起こりにくい世界の全体が見渡せる。あー。こういう仕組みをつけておけば使う人は困らないのかー。みたいなことの創造力につながる。大事だよね。わかんなくても生きていけるけどね。どうなんだろうね。 ここまで、理解した場合にやってみたくなるのは違うフォント名をあてがうとどうなるかです。ちなみにAdobeJapan1配列のフォント。例えば、ヒラギノフォントとかに差し替えるて、PDFを生成すると、文字化けが起こります。「美しいMSゴシックの…」のローマ字部分は半角にはなったもの化けませんでした。ヒラギノといっても大日本スクリーンのTrueTypeヒラギノフォントです。これはフォントごとにグリフIDが異なるために起こる問題です。同じ動作になるものもあります。例えば、MS-PGothicに変更しても大丈夫です。MS-PGothicはＭＳPゴシックというフォントのPostScriptNameなので、シフトJISコードに変換する必要はないです。PostScriptNameを調べるのは簡単ではないです。特定のフォント管理アプリNexusFontのようなものを導入していれば確認できます。フォント編集を行うFontForgeでも良いです。Meiryoなんかに変更してもうまく行くかと思ったのですが、これはダメでした。いやはや、これは大変そうですね。 フォントによっては、それこそ既存のフォントを勝手に編集して自作した個人的なモノが使われてPDFファイルが広く世に出回っているパターンもあります。CMap情報が無い場合はテキストとしての情報を構築するのをあきらめるPDF出力アプリがあります。ワードでさえ、そのように判断します。この場合、文字のように見えて、すべてがグリフ情報からベジェ曲線グラフィックに置き換えられます。まだまだ先の発想になりますが、すべてを理解したのち、PDF原稿から文字を抜き出す的な完全な自動化はテキストという考え方だけでは無理です。さらにOCRのような処理まで含めて考えることで、PDFから文字が抜き出せるということになります。簡単には、抜き出せる部分もあるので、特定のPDFに対しては文字が抽出できるようなものは作れると思います。 とにもかくにも、置き換えがうまくいかないのは、ワードが生成したＭＳゴシックフォントのエンコード方式がIdentity-Hと指定されていることが、他のフォントファイルとは、一致しない場合がある要因となっています。このあたりの理解を深めないと勘違いする。逆引きのようなことは難しいことなので、まずは、作るという方向から構造を知りましょう。本来のPDFの役割ですから。逆引きは便利だけど応用とか裏技とか秘儀的なことです。テキストを画面に美しく表示するのがPDFのあるべき姿だったのでした。 埋め込みすることがほとんどなので、あまり役に立たない情報ですが、フォントを埋め込まない場合でCID<span>(</span>Character "ID"entity<span>)</span>FontのCIDFontType0<span>(</span>OpenType CFF<span>(</span>CollectionFontFileコレクションフォントファイル<span>)</span><span>)</span>を子孫<span>(</span>DescendantFonts<span>)に持つ場合はBaseFont名の後ろに"-"を足したうえでCMap名を付けておくことが一般的です。 ===== '''/Encoding''' ===== エンコード方式を設定する部分です。PDFファイルから文字を選択してコピーすることがうまくいくということは、保証されていません。PDFファイルを作る側の都合になります。それもこれも、このエンコードが絡みます。フォントには、何種類かのエンコード方式があります。既存のCMap名がある場合はその名前がエンコード方式にあたりますので、その名前に対応する /で始まる文字列 を記述します。CMapの構造をPDFの中で直接記述することもできます。別の参照にCMapストリームとして記述することになります。 CMAPの存在の大きな理由としては、文字コードだけでフォントファイルに収められた文字絵柄の番号のグリフ<span>(</span>Glyph ID <span>)</span>がきまるということではないです。 ×：文字コード → Glyph番号 CMapは縦書き横書きだけでも分かれています。ほとんどのCMAPがなんらかの形で縦書き横書き用にわかれています。縦横だけに限りません。同じ文字コードでも特殊な用途では、CMapを切り替えるだけで表示してほしいグリフがあったりします。まず、代表的なCMap名として3つ /Identity /Identity-H /Identity-V があります。アイデンティティ。固有の。というとかっこいいですが、CMapの名前としては、そのまんま。っていう意味合い強い。-Hとついているのは、水平のH<span>(</span>Horizontal<span>)</span>。水平方向のためのCMapつまり横書き。Vは垂直<span>(</span>Vertical<span>)</span>で縦書きですね。ちゃんと準備されているフォントならば水平と垂直ではフォントが保持している文字間情報の数値が異なっていて、字詰めの美しさが違います。記号の向きとか、「」とかはあきらかに違う表示がされるように工夫されています。" " とか。いいだしたらきりがないと思える数々についてすべて対応している。フォントって凄絶<span>(</span>せいぜつ<span>)</span>ね。 他にも見たことある名前をあげるとしたら 78-EUC-H 78-EUC-V 78-H 78ms-RKSJ-H 78ms-RKSJ-V 78-RKSJ-H 78-RKSJ-V 78-V 83pv-RKSJ-H 90msp-RKSJ-H 90msp-RKSJ-V 90ms-RKSJ-H 90ms-RKSJ-V 90pv-RKSJ-H 90pv-RKSJ-V Add-H Add-RKSJ-H Add-RKSJ-V Add-V Adobe-Japan1-0 Adobe-Japan1-1 Adobe-Japan1-2 Adobe-Japan1-3 Adobe-Japan1-4 Adobe-Japan1-5 Adobe-Japan1-6 EUC-H EUC-V Ext-H Ext-RKSJ-H Ext-RKSJ-V Ext-V H Hankaku Hiragana Identity-H Identity-V Katakana NWP-H NWP-V RKSJ-H RKSJ-V Roman UniJIS2004-UTF16-H UniJIS2004-UTF16-V UniJIS2004-UTF32-H UniJIS2004-UTF32-V UniJIS2004-UTF8-H UniJIS2004-UTF8-V UniJISPro-UCS2-HW-V UniJISPro-UCS2-V UniJISPro-UTF8-V UniJIS-UCS2-H UniJIS-UCS2-HW-H UniJIS-UCS2-HW-V UniJIS-UCS2-V UniJIS-UTF16-H UniJIS-UTF16-V UniJIS-UTF32-H UniJIS-UTF32-V UniJIS-UTF8-H UniJIS-UTF8-V UniJISX02132004-UTF32-H UniJISX02132004-UTF32-V UniJISX0213-UTF32-H UniJISX0213-UTF32-V V WP-Symbol) [[PDF 内部構造#説明|PDF 内部構造]]に戻る。
PDF 内部構造 テキスト
に戻る。
個人用ツール
ログイン
名前空間
ページ
議論
変種
表示
閲覧
ソースを表示
履歴表示
操作
検索
案内
メインページ
コミュニティ・ポータル
最近の出来事
最近の更新
おまかせ表示
ヘルプ
ツールボックス
リンク元
関連ページの更新状況
特別ページ
