PDF 内部構造 テキスト 新しいページはコチラ

提供: yonewiki
移動: 案内, 検索
(→‎/Encoding)
(→‎　　/DescendantFonts :/FontDescriptor : /CharSet)
 
158行: 158行:
 
</table>
 
</table>
  
 +
 +
　<span style = "background:linear-gradient(transparent 75%, #ff9393 75%); font-weight:bold; ">注意したいのはTJとTjの違いです。Tj は 文字列を指定しているので、PDFtkを動かす環境の文字コードSJISやテキストの文字コードを利用して、そのまま出力する。TJは文字コード番号を指定している。間違うと、文字コード番号が見つからないというような意味のエラーがでる可能性が高い。</span>
 +
 +
　
  
 
=== '''日本語を扱う''' ===
 
=== '''日本語を扱う''' ===
177行: 181行:
  
 
　少し長いサンプルソースなので、全部載せて、説明はしません。日本語を表示するために、使われているフォントやコード関連のオペレータの意味については解読して、日本語文書ファイルを作れるようにしていきます。
 
　少し長いサンプルソースなので、全部載せて、説明はしません。日本語を表示するために、使われているフォントやコード関連のオペレータの意味については解読して、日本語文書ファイルを作れるようにしていきます。
 +
 +
 +
　<span style = "background:linear-gradient(transparent 75%, #ff9393 75%); font-weight:bold; ">文字出力のオペレータは両方大文字のTJになっています。そのまま英文を出力するときはTjでした。間違えないでください。</span>
  
 
==== '''日本語PDF仕組み''' ====
 
==== '''日本語PDF仕組み''' ====
236行: 243行:
 
</syntaxhighlight2>
 
</syntaxhighlight2>
  
−
　という具合にリソースの定義部で、/Fontフォントが定義され、その中で/DescendantFonts。そしてさらにその中で/FontDescriptorについての定義がされる。コメントの％KozMinは、Macのフォントの小塚明朝の場合はこんな感じの記述という例で、完全に動作するとは保証できないのであしからず。この3段論法みたいなフォント情報はひとつにまとめて書くことが出来る。まとめて記述するには、以下のような感じ。
+
　という具合にリソースの定義部で、/Fontフォントが定義され、その中で/DescendantFonts。そしてさらにその中で/FontDescriptorについての定義がされる。コメントの％KozMinは、Macのフォントの小塚明朝の場合はこんな感じの記述という例で、完全に動作するとは保証できないのであしからず。この3段論法みたいなフォント情報はひとつにまとめて書くことが出来る。まとめて記述するには、以下のような感じ。Adobe Acrobat Readerには小塚明朝が表示できる様に組み込まれていてWindowsでも使えるはずですが、自分は上手くやれませんでした。なんかもうちょっとコツがあるのかも知れない。ちな、この小塚フォントをWindowsの汎用フォントフォルダに移動して普通に使って文書に埋め込んだりして配布して使うのは規約違反らしいです。Acrobatで見るためだけに使いなさいと言う事らしい。
  
 
<syntaxhighlight2 lang="text">
 
<syntaxhighlight2 lang="text">
292行: 299行:
 
</syntaxhighlight2>
 
</syntaxhighlight2>
  
−
　三つを一つに纏めれましたが、この三つは意味が違うので注意が必要です。/F1という名前のフォントはType0という扱いをします。という意味合いで、このファイルでの扱いを、決めるための定義なのでこのPDFファイルのための独自情報です。ここでType0になっているのは、複数のフォントを、まとめれるという特徴があるのでよく使われるフォントタイプです。その中にある/DescendantFontsにはこういうフォントを組み合わせて使いますという具合です。Descendantは日本語で子孫という意味です。実際に利用するフォントの構造を指定しています。ＭＳゴシックがTrueTypeのCIDフォントだということを意味しています。
+
　三つを一つに纏めれましたが、この三つは意味が違うので注意が必要です。/F1という名前のフォントはType0という扱いをします。という意味合いで、このファイルでの扱いを、決めるための定義なのでこのPDFファイルのための独自情報です。ここでType0になっているのは、複数のフォントを、まとめれるという特徴があるのでよく使われるフォントタイプです。その中にある/DescendantFontsにはこういうフォントを組み合わせて使いますという具合です。Descendantは日本語で子孫という意味です。実際に利用するフォントの構造を指定しています。ＭＳゴシックがTrueTypeのCIDキー付きフォントだということを意味しています。実際はOpen Typeの構造に準拠していますが、TrueTypeとしても動作する様になっている形式です。OpenTypeは使えないと言うアプリケーションは多いWindowsの世界では良く取られる対処法です。
  
  
−
　そして、/FontDescriptorはストリームで対応する文字コードについてのフォント情報が無かったときはどのフォントは情報に従うのかという意味を持っています。Descriptorとは説明する者という意味です。
+
　そして、/FontDescriptorはストリームで対応する文字コードについてのフォント情報が無かったとき、この例ではType0フォントのMSゴシックが無い場合、どのフォントの情報に従うのかという意味を持っています。そしてどの様なフォントなのかを説明しなければなりません。Descriptorとは説明する者という意味です。
  
 
==== '''日本語PDFフォント情報のオペレータ個別の意味''' ====
 
==== '''日本語PDFフォント情報のオペレータ個別の意味''' ====
348行: 355行:
  
  
−
　簡単にフォントファイル形式の現状を説明するならば、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もわりとあたらしい技術ですが、近く非対応になることがきまっています。
+
　簡単にフォントファイル形式の現状を説明するならば、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もわりとあたらしい技術ですが、近く非対応になることがきまっています。あたらしくないか？自分の体内時計がおかしいのかな。
  
  
435行: 442行:
  
  
−
　いっぱいある。ほんとうに切り分けされて表示される動作が違うのか気になるけど、ある。実在する。その中からVer1.3までには以下のようなCMapが使えることになっている。CMapは何かの文字コードと同じになっている場合があり、その場合はCMap名に文字コード体系名が入れ込まれていることがあります。でも近年のフォントはUnicodeになっていることが多い。
 
  
−
中国語<span>(</span>簡体字<span>)</span>
+
　いっぱいある。ほんとうに切り分けされて表示される動作が違うのか気になるけど、ある。実在する。その中からVer1.3までには以下のようなCMapが使えることになっている。CMapは何かの文字コードと同じになっている場合があり、その場合は関連した文字コード名のCMap名に同じGlyph値を横流しするような文字コード体系名が入れ込まれていることがあります。近年のフォントはUnicodeになっていることが多い。
 +
 
 +
'''中国語<span>(</span>簡体字<span>)</span>'''
 
<table style="width: 100%; text-align: left; border-collapse: collapse; border-spacing: 0;">
 
<table style="width: 100%; text-align: left; border-collapse: collapse; border-spacing: 0;">
 
  <tr style=" background: #778ca3; border-right: solid 1px #778ca3; color: #ffffff;">
 
  <tr style=" background: #778ca3; border-right: solid 1px #778ca3; color: #ffffff;">
476行: 484行:
 
  </tr>
 
  </tr>
 
</table>
 
</table>
−
中国語<span>(</span>繁体字<span>)</span>
+
 
 +
 
 +
'''中国語<span>(</span>繁体字<span>)</span>'''
 
<table style="width: 100%; text-align: left; border-collapse: collapse; border-spacing: 0;">
 
<table style="width: 100%; text-align: left; border-collapse: collapse; border-spacing: 0;">
 
  <tr style=" background: #778ca3; border-right: solid 1px #778ca3; color: #ffffff;">
 
  <tr style=" background: #778ca3; border-right: solid 1px #778ca3; color: #ffffff;">
512行: 522行:
 
  <tr style=" background: #eeeeee;">
 
  <tr style=" background: #eeeeee;">
 
   <td>CNS-EUC-V</td>
 
   <td>CNS-EUC-V</td>
 +
  <td>上記の縦書き版</td>
 +
</tr>
 +
<tr>
 +
  <td>UniCNS-UCS2-H</td>
 +
  <td>Adobe-CNS1文字コレクション用Unicode(UCS-2)エンコーディング</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>UniCNS-UCS2-V</td>
 
   <td>上記の縦書き版</td>
 
   <td>上記の縦書き版</td>
 
  </tr>
 
  </tr>
 
</table>
 
</table>
 +
 +
 +
 +
'''日本語'''
 +
<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>説明</th>
 +
  </tr>
 +
<tr>
 +
  <td>83pv-RKSJ-H</td>
 +
  <td>Macintosh JIS X 0208文字セット KanjiTalk6 拡張 Shift-JISエンコーディング Script Manager code 1</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>83pv-RKSJ--V</td>
 +
  <td>上記の縦書き版</td>
 +
</tr>
 +
<tr>
 +
  <td>90ms-RKSJ-H</td>
 +
  <td>Microsoft Code Page 932 lfCharSet 0x80 JIS X 0208文字セット+NECおよびIBM拡張</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>90ms-RKSJ-V</td>
 +
  <td>上記の縦書き版</td>
 +
</tr>
 +
<tr>
 +
  <td>90msp-RKSJ-H</td>
 +
  <td>上記と同じで半角ラテン文字をプロポーショナル形式で置換</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>90msp-RKSJ-V</td>
 +
  <td>上記の縦書き版</td>
 +
</tr>
 +
<tr>
 +
  <td>90pv-RKSJ-H</td>
 +
  <td>Macintosh JIS X 0208文字セット KanjiTalk7 拡張 Shift-JISエンコーディング Script Manager code 1</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>90pv-RKSJ-V</td>
 +
  <td>上記の縦書き版</td>
 +
</tr>
 +
<tr>
 +
  <td>Add-RKSJ-H</td>
 +
  <td>JIS X 0208文字セット＋富士通FMR拡張 Shift-JISエンコーディング</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>Add-RKSJ-V</td>
 +
  <td>上記の縦書き版</td>
 +
</tr>
 +
<tr>
 +
  <td>EUC-H</td>
 +
  <td>JIS X 0208文字セット EUC-JPエンコーディング</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>EUC-V</td>
 +
  <td>上記の縦書き版</td>
 +
</tr>
 +
<tr>
 +
  <td>Ext-RKSJ-H</td>
 +
  <td>JIS C 6226(JIS78)文字セット＋NEC拡張 Shift-JISエンコーディング</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>Ext-RKSJ-V</td>
 +
  <td>上記の縦書き版</td>
 +
</tr>
 +
<tr>
 +
  <td>H</td>
 +
  <td>JIS X 0208文字セット ISO-2022-JPエンコーディング</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>V</td>
 +
  <td>上記の縦書き版</td>
 +
</tr>
 +
<tr>
 +
  <td>UniJIS-UCS2-H</td>
 +
  <td>Adobe-Japan1文字コレクション用Unicode<span>(</span>UCS-2<span>)</span>エンコーディング</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>UniJIS-UCS2-V</td>
 +
  <td>上記の縦書き版</td>
 +
</tr>
 +
<tr>
 +
  <td>UniJIS-UCS2-HW-H</td>
 +
  <td>上記と同じで半角ラテン文字をプロポーショナル形式で置換</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>UniJIS-UCS2-HW-V</td>
 +
  <td>上記の縦書き版</td>
 +
</tr>
 +
</table>
 +
 +
 +
'''韓国語'''
 +
<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>説明</th>
 +
  </tr>
 +
<tr>
 +
  <td>KSC-EUC-H</td>
 +
  <td>KS X 1001:1992文字セット EUC-KRエンコーディング</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>KSC-EUC-V</td>
 +
  <td>上記の縦書き版</td>
 +
</tr>
 +
<tr>
 +
  <td>KSCms-UHC-H</td>
 +
  <td>Microsoft Code Page 949 lfCharSet 0x81KS X 1001:1992文字セット8822追加ハングル UHC Unified Hangul Codeエンコーディング</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>KSCms-UHC-V</td>
 +
  <td>上記の縦書き版</td>
 +
</tr>
 +
<tr>
 +
  <td>KSCpc-EUC-H</td>
 +
  <td>Macintosh KS X 1001:1992文字セット＋Mac OS KH拡張 Script Manager Code 3</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>KSCpc-EUC-V</td>
 +
  <td>上記の縦書き版</td>
 +
</tr>
 +
<tr>
 +
  <td>UniKS-UCS2-H</td>
 +
  <td>Adobe-Korea1文字コレクション用Unicode<span>(</span>UCS-2<span>)</span>エンコーディング</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>KSCpc-EUC-V</td>
 +
  <td>上記の縦書き版</td>
 +
</tr>
 +
</table>
 +
 +
 +
　CMapはフォントファイルにあるものなので、自分でPDFファイル生成する場合は対になるべきCMapを見つけるコツがいるってことになりますね。あるいは自分で全部の文字に対するCMapを記述するという手もありますが、いずれにしてもグリフIDと文字コードの関係は知らないと対応できません。
 +
 +
 +
例えば、今回の場合は、以下のようなストリームを作ると対応するCMapを自作したことになるようです。ToUnicodeのオブジェクトとして、割り当てると、PDFでの文字選択のコピー&ペースト処理がうまく動作するようになります。
 +
 +
 +
<Syntaxhighlight2 lang="text">
 +
  /CIDInit /ProcSet findresource begin
 +
      12 dict begin
 +
        begincmap
 +
        /CIDSystemInfo
 +
            <<
 +
              /Registry (Adobe)
 +
              /Ordering (UCS)
 +
              /Supplement 0
 +
            >> def
 +
            /CMapName /Adobe-Identity-UCS def
 +
            /CMapType 2 def
 +
            1 begincodespacerange
 +
              <0000> <FFFF>
 +
            endcodespacerange
 +
            17 beginbfchar
 +
              <0003> <0020> %
 +
              <0030> <004D> %M
 +
              <0036> <0053> %S
 +
              <0838> <3044> %い
 +
              <084B> <3057> %し
 +
              <0862> <306E> %の
 +
              <089B> <30A9> %ォ
 +
              <08A1> <30AF> %ク
 +
              <08A6> <30B4> %ゴ
 +
              <08A9> <30B7> %シ
 +
              <08B5> <30C3> %ッ
 +
              <08BA> <30C8> %ト
 +
              <08C7> <30D5> %フ
 +
              <08E5> <30F3> %ン
 +
              <0B61> <4E16> %世
 +
              <23FA> <754C> %界
 +
              <2A3E> <7F8E> %美
 +
            endbfchar
 +
        endcmap
 +
        CMapName currentdict /CMap defineresource pop
 +
      end
 +
  end
 +
</Syntaxhighlight2>
 +
 +
 +
　CMapは文字コードと縦書き、横書き、異体字etcによる図柄の変更のような情報から1つのグリフに置き換えるもので、近年のWindowsやMacにあるような既存のデータはフォント内にCMap情報が内蔵されています。つまりCIDFontType0<span>(</span>Type1方式<span>)</span>やCIDFontType2<span>(</span>TrueType<span>)</span>のようなもので、OpenType<span>(</span>*.otf *.otc<span>)</span>やTrueType<span>(</span>*.ttf *.ttc<span>)</span>となっています。突き合わせの詳細を見るにはフォントから抜き出さないと見れない場合がほとんどです。CMapファイルが外だしになっているCIDFontが使える昔ながらのアプリもあります。この場合CMap情報が書かれたファイルが一つのフォルダにまとめられていることが多いです。CIDFontと平たく言ってしまうとTrueTypeフォントやOpenTypeフォントのことでもあるので誤解を招きやすいですが、もっと古いCIDFontというのがありました。有名どころのアプリではTex関連のツール。同じことですがgs<span>(</span>GhostScript<span>)</span>なんかがCMapフォルダを保持しているツールです。Acrobat Readerも保持していたような。あまりCMapを個人で編集することはないので、誰かが作ってくれていて、しらずしらずに使っているのではないでしょうか。
 +
 +
 +
　さきほど列挙したような有名どころのCMapファイルが入っていると思います。TrueTypeやOpenTypeが流行ってからの新しいCMapファイルは単独として存在していない可能性もあります。どちらにしてもCMapファイルを作るのは大変です。個人的に作り始めたら1か月くらいかかるんじゃないかな。既存のモノをちょこっといじってあたらしく作るというのなら個人でできると思います。特定の文字を置き換えて表示させることもできるはずです。ToUnicodeのような仕組みがあれば、変更された文字をコピーした時の動きも変更できます。
 +
 +
 +
 +
　まずは、既存のフォントからCMapを抜き出して、どういうものに対応しているか見てみることができます。全文字の対応をひとつひとつ見比べるのはできないので、縦書き？横書き？文字コードは何を受け入れて、どのように変換する？絵文字は？とかそういうざっくりした特徴毎にはまとめられています。全部を見なくても、どれを使えばCMapがうまく表示したいグリフに案内してくれるか、予想はつきます。そういうことができる力量は必要です。
 +
 +
 +
　では、抜き出してみましょう。抜き出すには、有名どころの専用アプリケーションを使うのがよいと思います。Windowsなら3種類が有力です。
 +
 +
 +
・Adobe製の[https://github.com/adobe-type-tools/afdko afdko]というツール。Python環境の構築が必須です。
 +
 +
・RT's free softさんの[https://rtfreesoft.blogspot.com/search?q=winttx WINTTX]というツール。コマンドプロンプトを使って実行ができるexeがついてます。ダウンロードしてきてPathをとおして使います。
 +
 +
・イギリスのバベルストーンという会社が作った[https://www.babelstone.co.uk/Software/BabelMap.html BabelMap]というツール。ちょっとやれることが多いUI付きのツールです。やりたいことを的確にやれる方法を覚えないと使えないかも
 +
 +
:*グリフ番号の対応表を見る
 +
::メニュー[Fonts]-[Overview of All Font]でひらくWindowで所望のフォントを選択してInfomationボタンを押す。ウィンドウを開いて、下の方にCMAPがplatfomIDとかの分類ごとに表示されるので、その中から希望のモノを選択してCmap copy subtableを選択して、Excelとかの表計算アプリに貼りつけると見やすい。
 +
 +
 +
:　この他、含まれているフォントを見るのも便利。昔Microfostから無償提供されていたFont Toolの代わりにはなります。便利。
 +
 +
 +
　いずれのツールをつかっても、同じような結果が得られて、拡張子が ttx のファイルが生成できますがより正しいものが得られるのはttxコマンドが使えるようになるツールですね。手っ取り早く確認するだけならバベル。
 +
 +
 +
　以下のようなコマンドで実行できます。フォントファイルのあるフォルダで実行して、同じディレクトリに置けばよいでしょう。C:¥$Env:windir¥Fontsフォントフォルダで dir コマンドを使えばファイル名も見れます。
 +
 +
ttx -t cmap -y 0 msgothic.ttc
 +
 +
 +
　-t cmap はcmapをフォントファイルから取り出すためのオプションで -y 0 で ttc や otcのようなフォントコレクションにおいて何番目のフォントの情報を抜き出すかという意味になります。標準フォントはたいてい0に入ってると思う。1がプロポーショナル形式 とかですね。日本語が含まれるようなモノならば、わりかしい大きいサイズのテキストは出力されます。
 +
 +
 +
　出力されたCMapには、規格化されたプラットフォームやフォーマットに基づいたCMap向けの番号が使われています。これが何を意味しているのかを調べれば全体が把握できるようになると思います。
 +
 +
 +
　[https://docs.microsoft.com/en-us/typography/opentype/spec/cmap マイクロソフトが公開しているCMap番号の情報]を見るのがいいです。簡単に説明を抜き出すと
 +
 +
<Syntaxhighlight2 lang="text">
 +
  <cmap>
 +
    <tableVersion version="0"/>
 +
    <cmap_format_14 platformID="0" platEncID="5" format="14" length="680" numVarSelectorRecords="4">
 +
    <!-- platformID 0=Unicode -->
 +
    <!--                platEncID=0 Unicode1.0 semantics 非推奨-->
 +
    <!--                platEncID=1 Unicode1.1 semantics 非推奨-->
 +
    <!--                platEncID=2 ISO/IEC 10646 semantics 非推奨-->
 +
    <!--                platEncID=3 Unicode2.0 and onwards semantics,Unicode BMP 副表4or6必要-->
 +
    <!--                platEncID=4 Unicode2.0 and onwards semantics,Unicode full repertorie 副表10or12必要-->
 +
    <!--                ★platencID=5 Unicode Variation Sequences for use with subtable format 14 副表14必要-->
 +
    <!--                platEncID=6 Unicode full repertorie for use with subtable format 13  副表13必要-->
 +
   
 +
    <!-- platformID 1=Macintosh 非推奨-->
 +
    <!-- platformID 2=ISO 非推奨-->
 +
    <!--                platEncID=0 7bit ASCII 非推奨-->
 +
    <!--                platEncID=1 ISO10646  非推奨-->
 +
    <!--                platEncID=2 ISO8859-1  非推奨-->
 +
    <!-- platformID 3=Windows -->
 +
    <!--                platEncID=0 記号-->
 +
    <!--                platEncID=1 Unicode BMP Format4を使用。U+100000～U+10FFFF がある場合Format=12 platEncID=10-->
 +
    <!--                platEncID=2 Shift-JIS-->
 +
    <!--                platEncID=3 PRC-->
 +
    <!--                platEncID=4 BIG Five-->
 +
    <!--                platEncID=5 Wansung-->
 +
    <!--                platEncID=6 Johab-->
 +
    <!--                platEncID=7 予約済-->
 +
    <!--                platEncID=8 予約済-->
 +
    <!--                platEncID=9 予約済-->
 +
    <!--                platEncID=10 Unicode Full repertoire-->
 +
    <!-- platformID 4=Custom -->
 +
    <!--                platEncID=0～255 OTF(OpenTypeFont) Windows NT 互換 マッピング-->   
 +
    <!-- Format=0 Byte Encode Table -->
 +
    <!-- Format=2 上位Byte透過Table -->
 +
    <!-- Format=4 差分への領域マッピング -->
 +
    <!-- Format=6 トリミングされたTable Mapping -->
 +
    <!-- Format=8 16bit 32bit 混合カバレッジ(網羅率) -->
 +
    <!-- Format=10 トリミング配列 -->
 +
    <!-- Format=12 領域化されたカバレッジ網羅率 -->
 +
    <!-- Format=13 多対一の範囲マッピング -->
 +
    <!-- Format=14 ユニコードバリエーションシーケンス -->
 +
      <map uvs="0xe0100" uv="0x5026" name="glyph22091"/>
 +
 +
</Syntaxhighlight2>
 +
 +
　CMapストリームの書き方は以下に Adobe Technical Notes
 +
 +
　１．#5014, Adobe CMap and ClDFont Files Specification
 +
 +
　２．#5092, CID-Keyed Font Technology Overview
 +
 +
　３．#5099 Developing CMap Resources for CID-Keyed Fonts
 +
 +
　の資料があります。
 +
 +
　[https://adobe-type-tools.github.io/font-tech-notes/pdfs/5014.CIDFont_Spec.pdf https://adobe-type-tools.github.io/font-tech-notes/pdfs/5014.CIDFont_Spec.pdf]
 +
 +
　[https://adobe-type-tools.github.io/font-tech-notes/pdfs/5092.CID_Overview.pdf https://adobe-type-tools.github.io/font-tech-notes/pdfs/5092.CID_Overview.pdf]
 +
 +
　[https://adobe-type-tools.github.io/font-tech-notes/pdfs/5099.CMapResources.pdf https://adobe-type-tools.github.io/font-tech-notes/pdfs/5099.CMapResources.pdf]
 +
 +
 +
　え？すごくないか、この資料。読み込むにはパワーいるわぁ。CMapをうまく操作したくなったら読もうかな。
 +
 +
 +
　簡単にMSゴシックフォントのCMapを見てみる。
 +
 +
 +
１．最初にPlatformID 0 platEncID 5 Format14が記載されている。これはUnicodeのU+FFFFより大きい値のグリフの対応表があります。Glyph22000番あたりに122個が割り当てられている。PlatformID 0 はUnicode で platEncID5はUnicode Variation Sequences for use with subtable format なので、当然正しい内容が記載されている。こちらはグリフ番号がついてるので対応は見やすい。
 +
 +
２．次に platformID 3 platEncID 1 Format 4 でplatformID 3 はWindows platEncID 1 は Unicodeですね。ここでがっつりとUnicode Mapを使ってGlyph番号の指定がされています。uni0000 からuniFFEE で 15760個のグリフが対応を指定されています。こちらはグリフ番号が含まれない情報です。上からグリフ番号が1から始まる連番です。行番号のついてるテキストエディタで開いて引き算しながら眺めるもよろし、エクセルにはりつけて、横にオートフィルとかで連番を振りなおすもよろしです。
 +
 +
３．次は platformID 3はWindows、platEncID10 はUnicode Full repertoire のformat 12 領域化されたカバレッジ網羅率による記述があります。16126個あります。差分情報が入り込んでいます。異体文字セレクタとかで呼び出されるグリフUnicode番号も保持しています。
 +
 +
 +
　Wordが出力したPDFではすべてが元のグリフ番号を保持していて、そのまま、謎の番号で対応する文字を出力し、ToUnicodeで謎の番号に対するUnicodeにおける元の文字番号を指定しています。これは、メイリオフォントを設定しても同じでした。マイクロソフトが作ったわけではないフォントでポストスクリプト名が無いものについては、フォントをベジェ曲線として書き出してしまいます。ここまで、わかった状態でPDF出力の試験をすることで、更にわかってくることもあるものです。謎の順番で登録されている。このような謎の順番が何種類あるか知るにはどうしたらいいのか。ひとつひとつフォントの中身を見るしかないのか。MSゴシックはUnicode Fontで32008書体分がCMapで定義されているになっていると言える。
 +
 +
 +
　元の番号と、グリフ体系がわかっていないとPDFを作るのはわりかし大変だなぁ。プログラムからどの対応するUnicode番号のグリフ番号が何番かを探せるようにしないと無理があるな。メイリオも違う番号になっているし。
 +
 +
 +
　文字コードから、どのフォント内のどのグリフ番号を使うかというのを決める作業の自動化を文字列ベースでおこなえるような仕組みが無いと、任意のフォントで日本語を入力することはできないということを頭にいれておきましょう。プログラムで使うフォントが選択できるテキストエディタなんかの機能を盛り込んだときには、この細かい手続きを比較的意識することなくできているということですね。
 +
 +
 +
　テキストエディタを保有するプログラムを制作する場合、CMapには何らかの文字コードに対応したグリフ番号の対応が記載されているので、文字コードから一意に決まるわけではなくても、状況に応じたデフォルトのグリフ番号が決まり、それが表示されている感じですね。プリンタへの印刷機能を盛り込んでいる場合でも、印刷処理をシステムにまかせているおかげで細かいことを考えずに印刷する機能も盛り込めているはずです。PDFへの印刷処理をするときは、このグリフ番号を取得する必要があるので、ここまで意識したプログラムをやったことがあるかというのが、この仕組みを利用できる重要な要素になると思います。
 +
 +
 +
　ここでは、これ以上、Encodingで何を指定するべきかを考えても、なにも解決しないので、全体の機能を見渡したうえで、対処法を見つけた方が良いので、次に進みましょう。
 +
 +
===== '''/ToUnicode''' =====
 +
　GIDに対応するUnicode番号が書かれた埋め込みCMapストリームへの参照を指定することで、GIDだけを使って書かれた、テキストについてコピー&ペーストにような文字コードとしての仕組みが必要な機能を支援します。GIDはグリフ番号で、CIDは文字の番号なので、文字コードの意味を持つ番号です。
 +
 +
 +
　CMapのストリームに関しては[[PDF 内部構造 CMap|コチラ]]の記事で記述します。
 +
 +
　
 +
 +
===== '''/DescendantFonts''' =====
 +
　Descendantは子孫とかって意味の英語。PDF内で扱うFontオブジェクトにぶら下がる実際のフォントを1つだけ明記する配列を指定することになっています。FontオブジェクトがこのPDFでのフォントの扱い方に関する情報であるのに対して、実際のフォント情報の内容を指定します。DecendantsFontの対応する配列内の /Type には必ず /Font という辞書名文字列を指定します。
 +
 +
 +
====== '''　/DescendantFonts :/BaseFont''' ======
 +
　必須。通常は親ノードの/BaseFont と同じフォント名 辞書名文字列になります。フォント名に半角スペースが含まれる場合は、対応する文字コード番号#20に置き換えます。コンソールの取り扱い文字コード、テキストの文字コードがSJISでもUTF-8でも同じ値です。
 +
 +
　
 +
 +
====== '''　/DescendantFonts :/CIDToGIDMap''' ======
 +
　CID<span>(</span>文字コード<span>)</span>からGID(グリフ番号)への対応を指定。辞書名文字列を設定する場合、指定できるのは /Identity のみです。省略した場合も/Identityが指定されたものとして扱われます。この辞書はストリームを指定するオプションで Type 2 の CIDFont を使う場合のみ有効となるものです。使っている実例をみたことがないので、Glyph値ｃが1 なら1=<02><03>がインデックスのバイト番号です。0=<00><01> 1=<02><03>で、CIDはグリフ値3がMSゴシックフォントのように half space " "を表すCID 0x20=GID<span>(</span>グリフ値<span>)</span>=3なら
 +
 +
xx_cid1_Hi1 xx_cid1_Hi2  xx_cid1_Lo1 xx_cid1_Lo2
 +
xx_cid2_Hi1 xx_cid2_Hi2  xx_cid2_Lo1 xx_cid2_Lo2
 +
<00> <00> <00> <20>
 +
 +
のような、グリフ番号0から順にCID値が8バイトで連続するストリームになるということでしょう。みたことないけど。知らんけど。使うことないだろうけど、認証をとるようなPDFエディタを作ったらここもきっちり網羅しておかないと駄目なんだろう。わからないことの方が莫大にあるので、認証なんて一生取れないだろうけど。
 +
obj x 0
 +
<<
 +
 +
>>
 +
stream
 +
<00> <00> <00> <00> %グリフ値 0 0は未定義文字のデフォルト表示文字だったような。CMapならば1から始まる。
 +
<00> <00> <00> <00> %グリフ値 1
 +
<00> <00> <00> <00> %グリフ値 2
 +
<00> <00> <00> <20> %グリフ値 3
 +
…
 +
…
 +
endstram
 +
　
 +
 +
====== '''　/DescendantFonts :/DW''' ======
 +
　1グリフ毎の横幅のデフォルト値。全グリフに適用される整数値。規定値は0
 +
　font内部の指定値に左右されますが、等幅半角文字なら1024emあるいは、1000、等幅全角文字なら2048emあるいは2000emとなっているものが多いでしょう。なので最大の2048を適用しておいて、それでは、他の文字が具合が悪いので、半角文字の一文字毎に次の/Wを使って指定することになります。範囲指定できるので、それほど大変ではありません。
 +
 +
/DW 2048
 +
 +
====== '''　/DescendantFonts :/W''' ======
 +
　指定グリフ毎の横幅の値。全グリフに適用される配列整数値。規定値はなし。但しDW値は適用される。以下のような形式をとる。単位はem
 +
 +
<Syntaxhighlight2 lang="text" line=1>
 +
/W
 +
[
 +
  100 [ 1024 1000 1024]
 +
  103 128 1024
 +
  160 223 1024
 +
  33088 40956 2048
 +
  57408 64508 2048
 +
]
 +
</syntaxhighlight2>
 +
 +
3行目は100 が そのあとの配列の1番目、配列が残り二つあるので、101から連番で101=1000、102=1024のように割り当てられる。個別指定が楽。
 +
 +
4行目は数字が3つ続く形式で1番目の数字から2番目の数値が文字番号の範囲で、3つめがグリフ幅の値を指定している。したがって103～128番の文字番号がグリフ横幅1024となる。範囲指定が楽。他の行も同じく。
 +
 +
 +
====== '''　/DescendantFonts :/DW''' ======
 +
　1グリフ毎の縦幅に関するデフォルト値。全グリフに適用される2つの整数値を持つ配列。規定値は[880 -1000]。横書きの設定も生かしつつ、縦書きをするための仕組みとして、v というベクトルを考える。ｖは横書き原点<span>(</span>ベースラインの右端<span>)</span>を縦書き原点<span>(</span>文字の水平の真ん中の上の頂点<span>)</span>に移すベクトルとして、そのベクトルのｘ成分は文字幅の半分。つまり、/Ｗ あるいは /ＤＷで設定した値の半分。例えば文字幅が2024なら半分の1024。ｙ成分を指定する値の一つとして表現する。そして、ｖによって移った原点を真下に送る値をもう一つの指定値で表現する。以下のように座標値を数式で表現できる。ベクトルのyは上方向がプラス、ｘは右方向がプラスとすると
 +
 +
 +
　v= <span>(</span>x座標量 = 文字幅/2, y座標量 = vのyの大きさ<span>)
 +
 +
 +
　縦書きのy方向への移動量をベクトルw1で表現するとx座標量は常に0で
 +
 +
　w1 = (x座標量 = 0, y座標量 = w1のyの大きさ)
 +
 +
　と書ける。このときのvのyの大きさとw1のyの大きさを指定すると縦書きに必要な移動量が決まるため、/DW2では、この2つの値の整数値を設定した配列をオペランドで指定する。規定値の
 +
 +
 +
　/DW2 [880 -1000]
 +
 +
　は、上方向に880em移動したところを原点に下方向に1000em移動することを意味する。あたらしく決まった原点にたいして、次の文字を縦書きになるように新しい文字の幅の真ん中を中心にして、文字の縦幅の上の頂点が重なるように配置していく。ということを意味している。
 +
 +
　
 +
　配列の最初の値が大きいほど上の文字との近づく。その次の値が大きいと文字幅が小さくなり次の文字が詰まってくる。そういうイメージだ。
 +
 +
 +
　/W2では、ベクトルｖのxの大きさも指定するので、/Wと/DWのように同じ意味の引数になっていない関係に注意したいところ。
 +
 +
　
 +
 +
====== '''　/DescendantFonts :/W2''' ======
 +
　指定グリフ毎の縦幅の値。全グリフに適用される配列整数値。規定値はなし。但しDW2の値は適用される。以下のような形式をとる。単位はem
 +
 +
<Syntaxhighlight2 lang="text" line=1>
 +
/W2
 +
[
 +
  100 [ -1000 500 880 -1024 512 884 -1000 500 880]
 +
  103 128 -1024 512 884
 +
  160 223 -1024 512 884
 +
  33088 40956 -2048 1028 2048
 +
  57408 64508 -2048 1028 2048
 +
]
 +
</syntaxhighlight2>
 +
 +
 +
　3行目は100 が そのあとの配列の1･2･3番目で縦文字幅を調整、配列が残り二つあるので、101から連番で101が4･5･6番目で、102が7･8･9番目のように割り当てられる。個別指定が楽。DW2とW2とで引数の数が異なりW2の方が3つで一つ多い、DW2の2番目の値がW2の例の一番最初の値と同じ。DW2の最初の値がW2の例の3番目と同じ。2番目は v ベクトルのxの座標量も指定している。文字の中心をこの辞書で個別に設定していけることを意味している。
 +
 +
 +
　4行目は数字が5つ続く形式で1番目の数字から2番目の数値が文字番号の範囲で、のこりの3つがグリフ幅の値を指定している。したがって103～128番の文字番号がグリフ縦幅上に884em移動して中心は512emとなり、文字幅として-1024を移動するような動作をするグリフ群となる。この方法は範囲指定が楽。他の行も同じ動きで記述されていく。
 +
 +
　
 +
 +
====== '''　/DescendantFonts :/Subtype''' ======
 +
　ここでは実際に使うフォントファイルの形式を指定します。このCIDFont辞書のエントリでは/CIDFontTye0か/CIDFontTye0のどちらかを指定します。TrueType系なら/CIDFontType2。OpenType系なら/Subtype /CIDFontType0と指定します。間違えても細かいことをしない限りか？現段階の大雑把な操作ではあまり問題はおこらないようです。いやOpen TypeのようでTrueTypeとして動くようなフォントが多いWindowsのおかげか、
 +
 +
====== '''　/DescendantFonts :/FontDescriptor''' ======
 +
　Descriptor=説明するもの。という英訳ができるわけです。この辞書の中で呼び出したフォントファイルの詳細な扱い方を設定します。呼び出したフォントが Type0<span>(</span>複合型フォント<span>)</span> あるいは Type3<span>(</span>内部で定義するフォントプログラム<span>)</span>の場合。このフォントデスクリプタは設定しません。フォントのことをよく知っていないと設定できないような値が続きます。
 +
 +
<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: 100px;">オペランド型</th>
 +
  <th>説明</th>
 +
  </tr>
 +
<tr>
 +
  <td>Type</td>
 +
  <td>辞書名</td>
 +
  <td>/FontDescriptor　と記述しなければなりません。</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>Ascent</td>
 +
  <td>数値</td>
 +
  <td>アクセント記号を除いたグリフの最大高さベースラインが 0 基準となる大きさ</td>
 +
</tr>
 +
<tr>
 +
  <td>CapHeight</td>
 +
  <td>数値</td>
 +
  <td>アクセント記号を除いたアルファベット大文字の最大高さ。</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>Descent</td>
 +
  <td>数値</td>
 +
  <td>グリフの最大低さ深さベースラインが 0 基準となる大きさ</td>
 +
</tr>
 +
<tr>
 +
  <td>Flags</td>
 +
  <td>整数値</td>
 +
  <td>等幅フォントであるかなど、特性を示す番号</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>FontBBox</td>
 +
  <td>矩形</td>
 +
  <td>グリフのem単位座標系でフォントを囲むような値。文字を選択したときに強調される矩形だと思います。</td>
 +
</tr>
 +
<tr>
 +
  <td>FontName</td>
 +
  <td>辞書名</td>
 +
  <td>フォントのPostScript名。日本語名でも英語名でもいい。</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>ItalicAngle</td>
 +
  <td>数値</td>
 +
  <td>左に傾く度数をプラスとした斜体文字向けの角度指定。値が0以外の場合は通常マイナスの値になるはず。</td>
 +
</tr>
 +
<tr>
 +
  <td>StemV</td>
 +
  <td>数値</td>
 +
  <td>文字の軸の幅。全体の最大付近の幅みたいな値になります。</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>AvgWidth</td>
 +
  <td>数値</td>
 +
  <td>規定値0。0なら指定されていないとみなす。フォントの平均幅。</td>
 +
</tr>
 +
<tr>
 +
  <td>FontFile</td>
 +
  <td>ストリーム</td>
 +
  <td>Type1形式のフォントプログラム埋め込みストリーム</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>FontFile2</td>
 +
  <td>ストリーム</td>
 +
  <td>TrueType形式のフォントプログラム埋め込みストリーム</td>
 +
</tr>
 +
<tr>
 +
  <td>FontFile3</td>
 +
  <td>ストリーム</td>
 +
  <td>Type1、TrueType形式以外のフォントプログラム埋め込みストリーム。形式名はストリーム内辞書のSubTypeで指定。</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>Leading</td>
 +
  <td>数値</td>
 +
  <td>テキスト行間のベースライン同士の空き縦幅。規定値 0。0は指定なしの扱い。</td>
 +
</tr>
 +
<tr>
 +
  <td>MaxWidth</td>
 +
  <td>数値</td>
 +
  <td>フォントのグリフ最大幅</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>MissingWidth</td>
 +
  <td>数値</td>
 +
  <td>フォント辞書Widths配列で幅が指定されていない場合に使われる幅。規定値は 0。</td>
 +
</tr>
 +
<tr>
 +
  <td>StemH</td>
 +
  <td>数値</td>
 +
  <td>StemVに対応する。垂直方向の幅の値</td>
 +
</tr>
 +
<tr style=" background: #eeeeee;">
 +
  <td>XHieght</td>
 +
  <td>数値</td>
 +
  <td>アルファベット小文字向けのHeightに対応する値。</td>
 +
</tr>
 +
<tr>
 +
  <td>CharSet</td>
 +
  <td>文字列</td>
 +
  <td>Type1フォントのみで有効な値。サブセット化するために特定の文字を指定する/から始まる名前をリスト化した文字列。この情報が無い場合はサブセットであることを示すものはFontNameにタグがつけられているかどうかになります。</td>
 +
</tr>
 +
</table>
 +
 +
 +
CharSetで指定する各文字名の正式な名称は PDFリファレンスの最後の付録のあたりに記述があります。
 +
 +
　
 +
 +
====== '''　　/DescendantFonts :/FontDescriptor : /Flags''' ======
 +
　フラグ番号毎の意味。数字はビット位置です。2進数の桁数の位置です。フラグは複数を一括で指定することもできます。
 +
 +
１．FixedPitch
 +
:等幅フォントです。日本語の等幅は半角と全角で幅が違うので、該当しません。等幅だけど正式にはプロポーショナル扱いです。
 +
 +
 +
２．Serif
 +
:明朝フォントのようなウロコのついた文字です。
 +
 +
 +
３．Symbolic
 +
:記号の集まりのようなフォント
 +
 +
 +
４．Script
 +
:手書きフォント、英字の場合は筆写体。
 +
 +
 +
６．NonSymbolic
 +
:ラテン文字またはそのサブセット
 +
 +
 +
７．Italic
 +
:斜体文字
 +
 +
 +
１７．AllCap
 +
:小文字が含まれないフォント
 +
 +
 +
１８．SmallCap
 +
:大文字と小文字の字形は分かれて登録されているものの、文字サイズが同じ大きさになっている。
 +
 +
 +
１９．ForceBold
 +
:小さな文字になっても、最小の細さは保持されて太字指定がくずれない。
 +
 +
 +
　2と6と19が複合した場合は 100 <span></span> 0000 <span></span>0000 <span></span> 0010 <span></span> 0010 = 10進数で262178となります。したがって
 +
 +
/flags 262178
 +
 +
　と設定します。
 +
 +
　
 +
 +
====== '''　　/DescendantFonts :/FontDescriptor : /CharSet''' ======
 +
　サブセットっていうのは、Fontファイルに含まれる文字の一部をだけを抜き出して保持するようなフォントです。特に埋め込みする場合は全部の文字を保持することは意味がありません。このサブセットというフォントを再構成して任意の6文字を先頭につけたものを作ります。例えば
 +
 +
 +
　EOODIA+Poetica
 +
 +
 +
　というようなフォント名はサブセット化されているフォント名の代表です。その中に含まれている文字を文字列で指定することでサブセット化されていて、どの文字が含まれているかを指定するものになっています。
 +
 +
　
 +
 +
====== '''　/DescendantFonts :/CIDSystemInfo''' ======
 +
　ここにCIDFontの情報を記述します。必須の情報です。説明の要素が強い情報です。PDFのビューワーから、この情報にアクセスして、どんなCIDFontが使われているのかを知る術になっているようです。
 +
 +
 +
この中に3つの辞書を設定します。
 +
 +
 +
*/Registry
 +
:　このCID情報の登録者文字列を設定します。個人でフォントを登録することは少ないので会社名であることが多いようです。よく使われるのが (Adobe) です。文字列です。
 +
 +
*/Ordering
 +
:　文字のエンコーディング方式名を設定します。Identityならそのまま、UCSはユニコードシーケンス。といった具合です。(Japan1) ならAdobeJapan1です。
 +
 +
*/Supplement
 +
:　補足です。ここには文字のエンコーディング方式の世代番号のようなものを登録します。整数です。0～65535くらいまで設定できます。AdobeJapan1の場合は登録文字数によって 0～7 に分けられています。7はUnicode文字セットのほとんどを収録しているようなフォントになります。
 +
 +
　
 +
 +
==== '''SubType Type3の利用によるテキスト出力''' ====
 +
　Type3 は PDFのフォントストリーム部分にPDFでのグラフィック描画処理を流用してフォントプログラムを構成する方法。試しにやってみたけど、今のところ、エラーになりまくりです。
 +
 +
　自分が作ったType3フォント2文字は以下のように生成したものの、Font リソース部で名前をつけて参照先をしていして実体化させようとしたところで、PDFオープン時にエラーになる。悲しい。
 +
 +
 +
　途中経過としては以下のようなスクリプトだ。インターネットに出回っているType3のPDFはうまくFontの定義は出来ているみたい。でもマネしてもダメだな。もう少し理解しないと駄目だな。
 +
 +
 +
　ページの処理中にエラーが発生しました。文書を読み取り中に問題が発生しました(18)となるType3指定例。解決編までは、しばし待たれよ。それっていつだよ。だな。
 +
 +
<Syntaxhighlight2 lang="text">
 +
…
 +
 +
…
 +
4 0 obj
 +
<<
 +
  /Font
 +
  <<
 +
      /F0 15 0 R
 +
      /F1 6 0 R
 +
      /F2 14 0 R
 +
      %/Type3Font 16 0 R %Type3
 +
  >>
 +
>>
 +
endobj
 +
…
 +
 +
…
 +
stream
 +
…
 +
%/Type3Font 10.0 Tf
 +
%(abababab) Tj T*
 +
…
 +
endstream
 +
…
 +
 +
…
 +
 +
16 0 obj
 +
<<
 +
  /Name/Type3Font
 +
  /Type /Font
 +
%  /Resources
 +
%  <<
 +
%      /ProcSet [/PDF /ImageB]
 +
%  >>
 +
  /SubType /Type3
 +
  /FontBBox [0 0 750 750]
 +
  /FontMatrix [0.001 0 0 0.001 0 0]
 +
  /FirstChar 97
 +
  /LastChar 98
 +
  /Widths [1000 1000]
 +
  /Encoding 17 0 R
 +
  /CharProcs 18 0 R
 +
>>
 +
endobj
 +
 +
17 0 obj
 +
<<
 +
  /Type /Encoding
 +
  /Differences [97 /square /triangle]
 +
>>
 +
endobj
 +
 +
18 0 obj
 +
<<
 +
  /square 19 0 R
 +
  /triangle 20 0 R
 +
>>
 +
endobj
 +
 +
19 0 obj
 +
<<
 +
 +
>>
 +
stream
 +
  1000 0 0 0 750 750 d1
 +
  0 0 750 750 re
 +
  f
 +
endstream
 +
endobj
 +
 +
20 0 obj
 +
<<
 +
 +
>>
 +
stream
 +
  1000 0 0 0 750 750 d1
 +
  0 0 m
 +
  375 750 l
 +
  750 0 l
 +
  f
 +
endstream
 +
endobj
 +
 +
xref
 +
0 21
 +
…
 +
 +
…
 +
</Syntaxhighlight2>
 +
　上の方にある行
 +
 +
%/Type3Font 16 0 R %Type3
 +
 +
　のコメントを外すとエラーでコメント化したままなら問題ないです。惜しいところまで来ている。凡ミスしてるんだろうなぁ。わからん。落ち着け俺。うまくいっているインターネット上から入手したType3フォントを使っているPDFあるんだから、うまくいくはず。
 +
 +
==== '''フォントプログラムの埋め込み''' ====
 +
　ここまでフォントの原理を理解することに焦点を合わせて、プログラムを埋め込まない使い方をしましたが、埋め込まない日本語PDFはISOの意に沿わない形式と言えるそうです。なので埋め込まないといけないのですが、フォントファイルから埋め込みフォントの記述方法については詳しく述べられた文献がみつからないため、続編記事には時間がかかりそうです。
 +
 +
 +
　なんやかんやで今まで、色々なわからないことを潰してきましたので、なんとかしていくでしょう。
 +
2022年8月上旬現在。
 +
 +
　やってみたんですけど。Wordとかで埋め込まれたフォントストリームをバイナリ―エディタで切り出して、元と同じファイル名の拡張子を付けると、抽出された文字だけのサブセットフォントになっています。バイナリーエディタで編集するときは stream 0x0a…0x0a endstream という具合に改行コード 0a があると思うので、0aも切り取ります。フォントファイルのバイナリーは…の部分そのものということ。
 +
 +
 +
　なのでフォントファイルの編集方法がわかれば、埋め込み用のフォントプログラムは作れそうです。でも編集方法がわかるくらいなら、フォントエディタでも作れるくらいのスキルがあるわけで、なかなかの壁だな。PDFで使った文字コードすべてを検出して、フォントファイルから、使った文字コードに対応するグリフだけを残して、あとは消したフォントサブセットをつくる。これができればPDF文書の内製化および発展的使い方も見えてくる。あるいは、印刷機能を理解する方面からPDFConverterとストリームのやり取りをするという方法に戻るか。それでは、なんだか面白くない。せっかくPDFの構造を理解することに積極的になったのだから、やりこみたいような気もする。
 +
 +
 +
　素人はフォントファイルを編集するFontForgeとかの先人達が築き上げた立派なフォントエディタでいじったものを張り付けて埋め込むという作業でもしてないさいって感じになるのかな。フォントファイルの構造解析しないとだめだな。また勉強だ。意外と根本の原理がわかっていないでコンピュータつかってるんだなぁって思わされる。フォントひとつすら理解できていないだもんな。恥ずかしい限り。
 +
 +
 +
再び、2022年8月上旬現在。あまり時間かからず確かめれてる。
 +
 +
　
  
 
[[PDF 内部構造#説明|PDF 内部構造]]に戻る。
 
[[PDF 内部構造#説明|PDF 内部構造]]に戻る。

2022年8月10日 (水) 00:00時点における最新版

「https://www.yo-net.jp/yonewiki/index.php?title=PDF_%E5%86%85%E9%83%A8%E6%A7%8B%E9%80%A0_%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88&oldid=11700」から取得

個人用ツール
名前空間

変種
操作
案内
ツールボックス