PDF 内部構造 テキスト 新しいページはコチラ
提供: yonewiki
(→/Encoding) |
(→/Encoding) |
||
815行: | 815行: | ||
− | Wordが出力したPDFではすべてが元のグリフ番号を保持していて、そのまま、謎の番号で対応する文字を出力し、ToUnicodeで謎の番号に対するUnicodeにおける元の文字番号を指定しています。これは、メイリオフォントを設定しても同じでした。マイクロソフトが作ったわけではないフォントでポストスクリプト名が無いものについては、フォントをベジェ曲線として書き出してしまいます。ここまで、わかった状態でPDF出力の試験をすることで、更にわかってくることもあるものです。謎の順番で登録されている。このような謎の順番が何種類あるか知るにはどうしたらいいのか。ひとつひとつフォントの中身を見るしかないのか。MSゴシックはUnicode | + | Wordが出力したPDFではすべてが元のグリフ番号を保持していて、そのまま、謎の番号で対応する文字を出力し、ToUnicodeで謎の番号に対するUnicodeにおける元の文字番号を指定しています。これは、メイリオフォントを設定しても同じでした。マイクロソフトが作ったわけではないフォントでポストスクリプト名が無いものについては、フォントをベジェ曲線として書き出してしまいます。ここまで、わかった状態でPDF出力の試験をすることで、更にわかってくることもあるものです。謎の順番で登録されている。このような謎の順番が何種類あるか知るにはどうしたらいいのか。ひとつひとつフォントの中身を見るしかないのか。MSゴシックはUnicode Fontで32008書体分がCMapで定義されているになっていると言える。 |
− | + | 元の番号と、グリフ体系がわかっていないとPDFを作るのはわりかし大変だなぁ。プログラムからどの対応するUnicode番号のグリフ番号が何番かを探せるようにしないと無理があるな。メイリオも違う番号になっているし。 | |
+ | |||
+ | |||
+ | 文字コードから、どのフォント内のどのグリフ番号を使うかというのを決める作業の自動化を文字列ベースでおこなえるような仕組みが無いと、任意のフォントで日本語を入力することはできないということを頭にいれておきましょう。プログラムで使うフォントが選択できるテキストエディタなんかの機能を盛り込んだときには、この細かい手続きを比較的意識することなくできているということですね。 | ||
+ | |||
+ | |||
+ | テキストエディタを保有するプログラムを制作する場合、CMapには何らかの文字コードに対応したグリフ番号の対応が記載されているので、文字コードから一意に決まるわけではなくても、状況に応じたデフォルトのグリフ番号が決まり、それが表示されている感じですね。プリンタへの印刷機能を盛り込んでいる場合でも、印刷処理をシステムにまかせているおかげで細かいことを考えずに印刷する機能も盛り込めているはずです。PDFへの印刷処理をするときは、このグリフ番号を取得する必要があるので、ここまで意識したプログラムをやったことがあるかというのが、この仕組みを利用できる重要な要素になると思います。 | ||
+ | |||
+ | |||
+ | ここでは、これ以上、Encordingで何を指定するべきかを考えても、なにも解決しないので、全体の機能を見渡したうえで、対処法を見つけた方が良いので、次に進みましょう。 | ||
+ | |||
[[PDF 内部構造#説明|PDF 内部構造]]に戻る。 | [[PDF 内部構造#説明|PDF 内部構造]]に戻る。 |