namazu-ml(ring)

[Rei FURUKAWA <furukawa@xxxxxxxxxxxx>]

古川です。

>> On Mon, 22 Mar 1999 01:27:07 +0900 (JST), sugiura@xxxxxxxxxxxx (Sugiura Shiro) said: 
  > <199903211525.AAA10712@xxxxxxxxxxxxxx>の記事において
  > yokoi@xxxxxxxxxxxxxxxさんは書きました。
  > >> 　　生成される*.txtファイルが空、またはバイナリになってしまう
  > >> 　　なお、試したpdfファイルにテキスト情報が含まれていることは確認済み
  > 私もいくつか試してみましたが、うまくいくものと上記のような症状に
  > なるのがありました。覚えている限りでは、日本語が入っているPDFでは

私もさっそく試してみましたが、確かに空のファイルになったり、日本語文書
が意味不明のバイナリになってしまったりしました。

そこで、データとスクリプトを見ながら、いろいろいじっていたのですが、若
干ゴミ混じりながら、なんとか日本語も抽出できるようになりました。namazu
の素材くらいには、使えるのではないかと思います。

本来ならば、pdf のフォーマットを調べたり、ghostscript のソースを読むと
かするべきだとは思うのですが、面倒だったので、「目の前のデータを変換す
る」だけの、「いきあたりばったりパッチ」になっています。そのため、変換
できないものが続出、という可能性もあります。現時点で気になっている点は…

(1) 一連の処理を、どういう条件で実行したらよいのか分からなかったので、
    '-j' というオプションをつけたときのみ実行するようになっています。
    英語 PDF で '-j' をつけると、逆に文字化けするかもしれません(不明)。

(2) 記号は変換していません。そのため、日本語の文書中に 8bit 文字が不用
    意に現れたりします。これは文字化けの原因になるので、'-o' オプション
    を強く推奨します。

(3) その他、こちらで分かった範囲外のコードについては、'-o' オプションを
    つけると、空白に変換し、つけないと、ゲタ ('〓') に変換してエラーを
    出力します(終了はしません)。

(4) 手もとのデータの中に、FlateDecode というオプションがついているらし
    いものがあるのですが、これはなぜか inflate() が Z_DATA_ERROR を返し
    てきて変換できない、という問題が残っています。

    これはデータとニラめっこして分かるようなものではないので、放ってあ
    ります。
    (ちなみに、そのデータは、ghostscript でも読めなませんでした)


(5) *.txt が空になってしまうのは、PDF ファイルの先頭に 128 バイトのヘッ
    ダ (MacBinary というやつでしょうか) のようなものがあるためみたいな
    ので、その場合は、単純に先頭 128 バイトを無視するようにしてしまいま
    した。

(6) 私の遭遇した問題と、横井さんやすぎうらさんが遭遇した問題は、似て非
    なるものかもしれません。そうするとお役に立てませんが、あしからず。


http://www01.tcp-ip.or.jp/~furukawa/patch/

に置いてみました。

-- 
Rei FURUKAWA 
furukawa@xxxxxxxxxxxx