RubyのPDF生成、Prawnを使って簡単かつきれいに

作者 Sebastien Auvray , 翻訳者 編集部 投稿日 2008年8月31日

セクション

デベロップメント,

プロセス/プラクティス

トピック

コミュニティ ,

RubyGems ,

Ruby on Rails ,

Ruby

タグ

PDF ,

Reporting ,

Community

Ruby（とRails）でPDFを生成する方法は(リンク)現在、数種類存在する。既存のソリューションに不満のあるGregory Brownは、DSLアプローチを使って独自のライブラリを設計することに決めた。Prawnは(リンク)また他のRuby用PDFライブラリより、速度でも上を行くはずである。

インストールを完了すると、DSL風のアプローチを使って簡単にPDFを生成できる（Prawnのサンプルから例を引用）。

Prawn::Document.generate("image.pdf", :page_layout => :landscape) do

  text 'Welcome in Prawn!', :at => [50,525]

  pigs = "data/images/dice.png"
  image pigs, :at => [50,450], :scale => 0.5

  ruport = "data/images/ruport_transparent.png" 
  image ruport, :at => [50,525]

end

このクィックサンプルから、下のようなPDFが出力される。

PrawnはRails／Ruport(リンク)の世界で確実に面白い存在になるであろうし、Edge Ruportでは間もなくPrawnがPDF::Writerに取って代わる。


PrawnのリリースはBrownと情報交換するにはぴったりの機会であった。というのも、コミュニティが資金提供する開発ベンチャーの「Ruby Mendicant(リンク)」をBrownが設立したからである。半年前Brownは、自分がこれから先の半年間、専念する予定のオープンソース・プロジェクトへの参加を募った。１万ドル以上を集めた後、Brownは取り組むプロジェクトとしてPrawnを選んだ。


InfoQ:  Prawnもまた、PDFライブラリなのですか。
Gregory Brown：Prawnは他のRuby PDFソリューションとはまったく異なります。なぜなら、別言語からのライブラリのポートではありませんし、低レベルのライブラリにラップをかけたものでもないからです。具体的な特徴の検討が必要なとき以外は、出回っているソリューションを広範囲にわたって調査しているわけではないので、巷にある任意のPDFライブラリにそっくりのものが出来上がるようなことはないと思います。これが望ましいことであり、最終的には環境下で自然と感じられるようなソリューションに行き着けば、と願っています。


開発するきっかけは何だったのでしょうか。
Ruby Mendicantプロジェクトのおかげで自由に使える時間があったので、難題に取り組めると思ったのです。PDF の仕様は1,300ページ超という量に上り、生成サイド向けになっているのはそのほんの一部ですが、手強い仕事であり、片手間に簡単に仕上げられるようなものではありません。使い勝手の良いPDFライブラリに対する自分のニーズが非常に高いので、その方向へ進むモチベーションはとても高いのです。それをさらに高めてくれたのがJames Grayからの投稿で、Grayの提案により、PDF::Writerを長い間維持するよりは、新しいライブラリを書くことにより、全体的な労力を減らすことができました。それについては、ここで(リンク)チェックできます。


なぜPDF::Writerを断念したのでしょうか。
断念していません。厳密に言えば、私はまだ現役の保守管理者であり、重大なバグは直しますし、Prawnが広く採用されるようになるまで、メンテナンスリリースを出すつもりです。現時点で唯一決定しているのは、少なくとも私の手からPDF::Writer 1.2を出すことはないということです。私はMichael Milnerと数ヵ月前にAustin Zieglerから PDF::Writerを引き継ぎましたが、それは他の誰もこの仕事を引き受けなかったからで、数年間手つかず状態になっていて、処理しなければならないバグ・フィックスがたくさんあったのです。メンテナンスリリースを2、3出したので、PDF::Writerは良くなっています。


しかし、PDF::Writerに保守管理者が見つからなかったのには理由があり、それは主にコードが維持管理不可能だからです。当時このライブラリは優れていたのですが、大きな障害なしに拡張や修復は不可能です。Prawnこそが前進するための道筋と考える理由がここにあり、Prawnには、初めてPDF::Writerを開発した時には検知が困難だった落とし穴を回避するチャンスがあります。

Prawnの方が高性能とされているようですが。
表のレンダリングはずっと高速です。主にアルゴリズムの違いによるもので、ライブラリ自体はまだ細々したことの最適化がまったく完了していません。しかし、こうしたアルゴリズムの相違が積み重なり、速度が一桁増しになる可能性もあり、そうなれば誰も文句ないでしょう。 ;）


ベンチマークはありますか。
2列の表、1833件のレコードを使ったほぼ同一の出力をPrawnとPDF::Writerで比較したものを、ソース付きで配布しています。私のマシン上では、Prawnで3.5秒ほど、PDF::Writerで90〜100秒ほどかかりました。データのサイズが増えるほど、両者には開きが出ます。


James Healyが同じことを、CairoバインディングをラップするライブラリのPDF::Wrapperでベンチマークしています。驚いたことに、Prawnの方がわずかばかり速かったのですが、それはHealyがRubyで前処理を施していて、さらにPrawnの方が多少効率的だったからです。新機能が追加され、現在の両ライブラリはパフォーマンス的に変わりなくなっていると思いますが、私自身ではこの2つでベンチマークをしたことはありません。

FPDFというPHPライブラリ（こちらもFPDFという名称）のポートと比較するとPrawnの方がずっと高速、という報告も聞きましたが、ベンチマークは行っていません。あるユーザが、それまでインボイス生成コードに3分以上を要していたのに、Prawnでは約37秒だったと述べています。


他のさらに低レベルのライブラリと競合できますか。
Cライブラリやその同類と比較するベンチマークはまったく行っていません。目標はPrawnを「Rubyで高速に」、「十分高速にして役に立つ」ようにすることと思っています。Prawnを純粋なRubyに留めておくという目標、そしてコードを可能な限り読みやすくするという目標が念頭にあるので、パフォーマンスのみを追求して、こうした目標を犠牲にすることはありません。しかし、パフォーマンスには注意を払い続けるので、PDFをRuby外でコードしなければならなくなるようなボトルネックにはしません。ですから、ユーザの皆さんには安心していただきたいと思います。


その他の言語のライブラリとは競合できますか。
Prawn向けの調査を行ったとき、私にとって最も快適な2言語、PerlとPythonについて調べました。正直言って、いずれの言語にも、感激するようなソリューションはありませんでした。Prawnでは単純性とコア機能を中心に据えることを心がけていますが、PrawnはPerlとPythonで目にしたライブラリと比較して、ずっと優れたインタフェースを備えていると感じます。


もちろん、最近はPerlやPythonよりずっとRubyに時間を割いていたので、普通では気がつくことを見落としたかもしれません。もしそうなら、できる限りたくさんの良いアイデアを採り入れたいので、ぜひ教えてください。

半年前に始まった(リンク)Ruby Mendicant事業について、もっと教えていただけませんか。
元々は思いつきでした。ストレスがあり、契約の仕事にイライラしていた時にO'Reillyのブログに投稿しました。基本的には、少し休みをとって、オープンソースのハックに専念したいと示唆したのです。私の言うことをまじめに受けとった方々もいて、十分な支持が集まってから、寄付を募るためにPledgieキャンペーンを張りました。1カ月後には、22週間分の資金が集まり、こうしてRuby Mendicantプロジェクトが始まったわけです。


最初のプロジェクトとしてPDF生成を選んだ理由をお聞かせください。
アイデアはいくつかあったのですが、PDF生成はその１つです。コミュニティで次に人気が高かったのが、献身的にドキュメンテーションに取り組むことで、この分野ならライブラリの一群に熱中して、rdocをきれいに整理したり、ことによるとチュートリアルを書いたりもしていたでしょう。PDFにはもっとサポートがあることが分かりましたし、ひとつの統一された目標だったので、皆に好まれたのです。私が本当に必要としているものなので、モチベーションの維持は比較的簡単でしたし、ですから、いいものを選んだと思っています。


近い将来の計画はどうなっていますか。
近い将来、Prawnでは基本的なインラインのスタイリングができるようになるでしょう。アスペクト比を維持しながら、ボックス内にフィットするようにイメージの大きさを調整可能にする機能もイメージサポートに追加するつもりです。Prawnの表生成における柔軟性を拡大する一大計画もあります。

間もなく、基本的な図形描画やイメージ、その他希望のもので構成されるコンポーネントを作成できるようになりますし、その後はテキストで行うように、こうしたコンポーネントをセルに貼り付けられるようになるでしょう。さらに、PDF文書自体への直接レンダリングも、おそらくは複数の場所で可能になるでしょう。私たちのやり方が適切であれば、コアへのプラグインとして配布できるようなカスタムウィジェットをユーザが書けるようになる可能性もあり、そうなればとてもすてきですね。

長期的にはどうでしょう。
PDF::Writerユーザと一緒に取り組んで必要な機能をPrawnへ入れ、PDF::Writerユーザがマイグレートできるようにしたいと熱望しています。ここでの大きなハードルは、何もAPI互換を企てようというのではなく、願わくは機能と安定性を十分魅力的なものとして、皆をこちらに引き寄せたい、ということです。その後の夢はPDF::Writerを引退させ、Prawnのネーム空間をPDFへ変更し、PDF::Documentとすることです。

これがすんだら、PDF::Reader（現在James Healyが保守管理）とより緊密に統合したいと思っています。両プロジェクトが別個のgemであり続ける可能性は高いですが、単一の包括的なRuby PDFプロジェクトの下に一体化したいのです。その後は、その中に他のPDF関連パッケージを入れれば、Ruby向けの真に統一されたPDFソリューションが出来上がります。

しかし、すべては、物事がどれほど速く進行してくれるか、またコミュニティが私のアイデアをどれほど受け入れてくれるかにかかっています。時間が経てばわかるでしょう。

最近の状況はRubyのハッカーに厳しいのでしょうか。
なぜ厳しいのでしょうか？私たちは有用で需要があり、私たちがクライアントを必要とするより、クライアントが私たちを必要としているのです。Railsにはますます酷い苦労をさせられていますが、私たちのコミュニティは最高です。しかし、信頼している者に喜んで現金を支払い、プロジェクトにハックさせるコミュニティについて不平を言うことはできません。商業的な成功が続いていても、草の根の努力を支援している人が多数いることの証明であり、非常に勇気づけられます。

私が見るところの主要問題は、インターネットが誇大宣伝マシンと化して劇的な状況を作りだし、RubyプログラマはRubyだけでプログラミングして、他はすべて非難する狂信者、というふうに世間の認識を歪めてしまったことです。一般に、この認識は真実とあまりにもかけ離れています。多数の優れたRubyistsは実際に、部外者よりもこの問題に頭を悩ませているので、この件で私は他人の痛みを感じています。;）

なぜO'reillyのブログをやめてしまったのですか。
O'Reilly Newsでブログする予定です。O'Reillyはブログの内部ネットワーク構造を変更していて、私の知っている限り、公にはまだまったく論じられていない大きな変更があります。けれども私はこれからもO'ReillyでRubyについて話をする予定で、単にURLが変わるだけです。O'Reilly News上ではコンテンツの標準が多少変わりますが、その方向性は気に入っています。

非公式の技術的な掲載については、個人的なブログとは別のブログ始めていて、もう少し焦点を絞ることができるようにしています。そういったことに興味をお持ちの方々は、現在私が構築中のカスタマイズしたブログ用ソフトウェアが完成したら、私の追跡(リンク)ができるようになります。

全体としてみれば、この2つのブログでRuby以外の言語や概念にちょっと手を出すことができるでしょう。自分が使っている様々な*nixツールについて書きたいと思うことが度々あり、アーランにももう少し手を出したいので、ブログの幅が広がって面白くなると思います。

原文はこちらです：http://www.infoq.com/news/2008/08/ruby-pdf-generation-prawn

• 次へ >