名前: ZR 日時: 2007-05-03 17:42:35 IPアドレス: 59.140.98.*
>>47864 以上を踏まえて、以下の発言に対する私の認識を述べます。 >（1）Takashimaさん >>47784 >> otftotfmを使って、otf（たとえばLinuxLibertine）を使うようにすると >> どのようなencodingであっても、encファイルにunicode番号が書かれ >> dvipdfmxがpdfに対応表を埋め込んでくれるので、クリップボードに >> unicodeでコピーされます。 > >（2）anonymouseさん >>47785 >> dvipdfmx の場合ならば、CMap を作れば良いのでは？ > >（a）khmのような「合成文字」を使っていない場合は（1）ないし（2）の > 方法が可能 >（b）「合成文字」を使っている場合はフォントを新規に作成する まず、前に言ったことの裏返しとして、 - 正しくないフォントを .enc や VF を用いて reencode しても正しく ならない。 がいえます。これより (1) について私は次のように考えます。 - otftotfn については詳しくは知らないが、結局 .enc と .tfm を生成 してそれに基づいて dvipdfmx に処理させているので、これは reencode しているだけであり、私が問題としている「正しくないものを正しく する」の解決にはならない。少なくとも、ttf2tfm や afm2tfm では これはできないはずである。 - しかし、最初から Unicode エンコーディングの OpenType フォントを 用いるのだから、それはほぼ確実に正しい Unicode 値を持っていること が期待できる。 - 従って、OpenType (または TrueType) フォントを用いることにすれば、 「問題」は最初から起こらず、テキスト抽出が成功する。 # OTF/TTf の場合も、.enc を用いているならば、グリフ名でグリフを呼び # 出しているはず。この場合の Unicode 値への変換はどう行われるか? # グリフに付随する Unicode 値になる…のではないのかな? (2) については、次のように考えます。 - CMap を自前で用意することで、dvipdfmx が Type1 を処理する際に、 フォントの符号位置(グリフ名)から Unicode 値への変換を、規約に 従うものでなく好きなものに変えることができるので、「正しくない ものを正しくする」ことができる。 - ただし、Type1 フォントのグリフ名を変更するのは難しくないから、 いちいちフォント毎に CMap を書くことになるのなら、フォントの グリフ名を変えた方がよいかも? (ライセンス上の問題がない場合)
この書き込みへの返事：