Lightweight Language Lovers

火事場のCPAN 〜偉大なるLLの"オカン"Perl 〜

最近、1つのPDFファイルを切り分けて複数のファイルに分割する必要に迫られました。
Windows用のフリーソフトがいくつかあるようですが、自動化を考えるとLLで処理したいものです。
ただ、今回は急で時間がほとんどありません。こんな時、火事場の○○力になってくれるのがPerlのCPANです。
PDF::API2というモジュールを使うと、本当に簡単に実現できてしまいました。
CPANについてはあちこちで説明されていると思いますので、ここではポイントだけ書いておきます。
まず、CPANを使うための準備ですが、
```
# perl -MCPAN -e shell
```
として、基本的にはデフォルトですすめていくのですが、proxy の設定でちょっとつまずいてしまいました。あわてていたので、そのページに出ていたとおり、
```
Your ftp_proxy? [http://proxy:8000/]
```
と[]まで入れて答えてしまいました。（愚か・・・）今、冷静に考えるとこれはデフォルト値が表示されている例だったのですね・・・普通にURLだけ入れれば良かったのです。アドレスだけ入れたり、IPアドレスで入れてみたりしてもつながらなかった訳です。
小一時間ほど損をしてしまいましたが、設定さえ出来ればモジュールのインストールそのものは
```
install PDF::API2
```
で一発です。他に必要となるモジュールは自動的にインストールしてくれました。
PDF-API2-0.59.002.tar.gzの中には、サンプルと思われるプログラムがいくつか入っています。この中のpdf-merge.plが雛型として使えそうです。
CPANシェルから install コマンドでインストールした場合、どこに入ったのかがわかりませんでしたが、
今探してみると、.cpan/build/PDF-API2-0.59.002/contribにありました。
このプログラムは複数のPDFファイルをマージして1つのPDFファイルにする例です。今したいのは、逆のことですが、プログラムを見ると、ページ毎に取り込んでいるようです。ということは、ここでページを指定すれば欲しいページだけに限定できそうです。

まず、変数の値を変数名として評価し、値を展開するには、evalを使うのが簡単だと思います。

#!perl (-)
use PDF::API2;

if(2 > scalar @ARGV) {
    print <<"EOT";
Usage: $0 <outfile> <infile1,from,to> ... <infileN>

merges serveral pdf files into on ;-)

cheers, 
fredo
EOT
}

my $outfile=shift @ARGV;

my $pdf=PDF::API2->new;

foreach my $in (@ARGV) {
    (my $infile, my $page_from, my $page_to) = split /,/, $in;
    print STDERR 'loading file $in .';
    my $inpdf=PDF::API2->open($infile);
    my $pages=scalar @{$inpdf->{pagestack}};
    foreach my $page ($page_from..$page_to) {
        print STDERR "$page.";
        $pdf->importpage($inpdf,$page);
    }
    $inpdf->end();
    print STDERR " done.\n";
}

$pdf->saveas($outfile);

__END__

ただ、これだと代入文の左辺では使えません。多少乱暴ですが、
```
   1 arg = 'nenrei'
   2 exec('dict_' + arg + ' = {}')
   3 print dict_nenrei
   4 {}
```
とすれば、目的とする名前の辞書が作られたことが分かります。
でも良く考えてみると本当に必要なのは、「ある名前に対応するオブジェクトを作成」することです。これは辞書そのものです。
```
   1 counter = {}
   2 arg = 'nenrei'
   3 counter[arg] = {}
   4 print counter['nenrei']
   5 {}
```
確かに一番最初の書き方は簡潔で洗練されているように感じます。しかし、簡潔な分、$が一つ無くなっただけで全然意味が違ってきてバグの元ですし、「これは便利」と説明性を考えずに安易に使ってしまいがちです。後の書き方は稚拙なのかも知れませんが、とても「堅牢」な感じがします。
- この「堅牢である」という感覚、COBOL+メインフレームで育った人間特有の感覚かも知れません。(それとも私だけか・・・)命令文の書ける桁等も決まっていて、特にIF文では最後のピリオド1つで意味が大きく違ってしまうような言語を使っていると、すべて大文字で厳格なコーディング規約に従った図形的に整然としたソースを見ると安心するのです。英小文字や{}が多い最近のコードを「軟弱」と感じてしまうのです。悲しき職業病ですね・・・
私達は、ある言語で使える機能が他の言語に無いと、その言語は劣っていると感じてしまいがちですが、大切なのは、「可変変数がある」ことではなく、「実現したいことが出来る」ことです。
私は今回の例を通じて、言語のデザインとして、「何が出来ないか」も、とても大切な要素だと感じました。次世代Python (Python 3000)の計画では、組み込み関数から除外される関数もあるそうです。Pythonは使っていて、あっと驚くことが無く、感覚として「理にかなっている」と感じることが多いのは、こんな風に慎重にデザインされていることに理由があるのかも知れません。

CategoryPython

Lightweight Language Lovers

火事場のCPAN 〜 偉大なるLLの"オカン"Perl 〜

火事場のCPAN 〜偉大なるLLの"オカン"Perl 〜