名前: ZR 日時: 2007-05-03 16:13:29 IPアドレス: 59.140.98.*
>>47849 どうも、人によって問題意識が違っているようなので ;-) 私が想定していたのは、Type 1 フォントにおいて、グリフが「正しい」 名前を持っていないときに、PDF からのテキスト抽出が失敗することです。 ここで、「正しい」名前とは、Adobe の次の規約に従った名前のことです。 Unicode and Glyph Names 例えば、 a. 「A」に見えるグリフの名前が B である。この場合、当然この文字は B (U+0042) と見做される。 b. T1 エンコーディングのフォントの位置 "A9 のグリフ「l'」 の名前が lcommaaccent(U+013C) になっている。正しくは lcaron(U+013E)。 c. ギリシャ文字のフォントの「Ω」のグリフ名が Omega である。これは U+2126 OHM SIGN に変換され正しくない。uni2126 であるべき。 d. T1 エンコーディングの位置 "20 のグリフ(空白文字の記号)は従来 visiblespace と名付けられていたが、これは AGL にないので変換 できない。uni2423 であるべき。 e. a(U+0061) と dieresis(U+00A8) から TeX の \accent 命令または VF の 機構により a-umlaut を合成した。この場合、最善でもテキスト文字列 として <00A8,0061> が得られるだけで、これは a-umlaut を表す正しい Unicode 列でない。正しいのは <00E4>(NFC) または <0061,0308>(NFD)。 のようなことです。以後、「正しい」グリフ名をもつフォントのことを 「正しいフォント」と呼ぶことにします。 # dvipdfmx も AGL (glyphlist.txt) を用いて規約に従い PDF に埋め込む # CMap を自動生成している。ただし、W32TeX の dvipdfmx ではさらに独自 # の変換表 texglyphlist.txt も用いていて c や d の問題は解決される。 まず、以下のことに注意してください。 - 正しいフォントについて、それを .enc ファイルで reencode しても、 また単純な VF (DVI 命令は SELECTFONT と SETCHAR のみ)を通して reencode しても、結果のフォントは正しい。単純な VF の参照元の フォント(MAPFONT)が複数あっても構わない。 - 現在 TeX で広く用いられている Type1 フォントのほとんどは細かい 点(上の c, d の類)を除いて正しい。 * Adobe, URW++ 等による「TeX 用でない」Type1 フォント * BlueSky の OT1 Type1 フォント (OT2 や数式用は違う) * sm-cuper, LM Type1 フォント, CB Type1 フォント * TeX-gyre Type1 フォント さらに、以下のことも留意しておくべきでしょう。 - PDF からのテキスト抽出に必要以上に拘るべきでない。抽出を完全 にしようとすると、TeX や VF のもつ文字合成の機能がほとんど 使えなくなる。最近では、フォントやそのレンダリングの技術が進歩し、 結合文字などを含む Unicode 列を「正しい表示」に変えることが できるが、非常に単純なレンダリング技術だけを仮定した TeX に それを望むべきでない。(XeTeX では新しい技術が使われている。) もちろん、テキスト抽出ができることは、Web 上で文書が検索可能 であるために大事であるが、そこは「成功する部分が多ければ多い ほどよい」位の心構えを持つのがよいと思う。 (続く)
この書き込みへの返事：