PDF 内部構造 テキスト 新しいページはコチラ
提供: yonewiki
(→日本語PDFファイルサンプル) |
(→/BaseFont) |
||
| 360行: | 360行: | ||
===== '''/BaseFont''' ===== | ===== '''/BaseFont''' ===== | ||
| + | |||
/FontNameでもフォントの名前を指定しますが、通常は同じ値になります。この値はPDFを更に紙や仮想プリンタでPDFや他の形式へ印刷するときにPostスクリプトが使われるときのフォント名の指定として使われます。そこで改めてフォントが参照されて、フォントの輪郭・形状を印刷機にわたりグリフ情報が活用されます。Fontの孫情報であるDescendantFont情報で指定するFontNameと同じでないと印刷するときに違うフォントが使われてしまいチグハグなことになってしまいます。ここで注目してほしいのは値の指定方法が少し特殊なことになっていることです。PDFのソースファイルの形式がSJISであれば、普通に | /FontNameでもフォントの名前を指定しますが、通常は同じ値になります。この値はPDFを更に紙や仮想プリンタでPDFや他の形式へ印刷するときにPostスクリプトが使われるときのフォント名の指定として使われます。そこで改めてフォントが参照されて、フォントの輪郭・形状を印刷機にわたりグリフ情報が活用されます。Fontの孫情報であるDescendantFont情報で指定するFontNameと同じでないと印刷するときに違うフォントが使われてしまいチグハグなことになってしまいます。ここで注目してほしいのは値の指定方法が少し特殊なことになっていることです。PDFのソースファイルの形式がSJISであれば、普通に | ||
| 387行: | 388行: | ||
| + | ここまで、理解した場合にやってみたくなるのは違うフォント名をあてがうとどうなるかです。ちなみにAdobeJapan1配列のフォント。例えば、ヒラギノフォントとかに差し替えるて、PDFを生成すると、文字化けが起こります。「美しいMSゴシックの…」のローマ字部分は半角にはなったもの化けませんでした。ヒラギノといっても大日本スクリーンのTrueTypeヒラギノフォントです。これはフォントごとにグリフIDが異なるために起こる問題です。同じ動作になるものもあります。例えば、MS-PGothicに変更しても大丈夫です。MS-PGothicはＭＳPゴシックというフォントのPostScriptNameなので、シフトJISコードに変換する必要はないです。PostScriptNameを調べるのは簡単ではないです。特定のフォント管理アプリNexusFontのようなものを導入していれば確認できます。フォント編集を行うFontForgeでも良いです。Meiryoなんかに変更してもうまく行くかと思ったのですが、これはダメでした。いやはや、これは大変そうですね。 | ||
| + | |||
| + | |||
| + | ワードが生成したＭＳゴシックフォントのエンコード方式がIdentity-Hと指定されていることが大きな要因となっています。 | ||
| + | |||
| + | ===== '''/Encoding''' ===== | ||
| + | エンコード方式を設定する部分です。フォントには、何種類かのエンコード方式があります。 | ||
[[PDF 内部構造#説明|PDF 内部構造]]に戻る。 | [[PDF 内部構造#説明|PDF 内部構造]]に戻る。 | ||
