Paperium Design, Rough Ideas

こういう感じの方針で作ってくべしという指標

  • API はなるべく PDFium をベタに map していく。Intelligent なことはアプリがやる。
  • 自分が使わなそうな API は入れない。当たり前だけど。メタデータとか際限なく色々ありそうなので。そこはがんばらない。
  • Finalizer は実装しない。自分でちゃんと close() してねということにする。finalizer がらみの複雑な色々とかと付き合う気になれん。
  • Checked exception はナシ。例外階層は一定程度真面目にやる。といっても PDFium のレイヤで起こりうるのは IO とそれ以外、くらいな気がするが・・・。
  • 主要な native backed オブジェクトはインターフェイスにしておく。ネイティブが絡むとさすがにテストとかが辛かろう。
  • Java の IO は使わず mmap でバリっと読むの限定とする。ダウンロードしながら表示とかやらない。どう考えても圧倒的にメモリ効率が違う。

実装

  • システムコール類は単一のクラスに押し込める。Android 方式。任意のオブジェクトのメソッドを ad-hoc に native にしていくのは色々つらそうなため。
  • 悩ましいのは PDFium の API だが・・・。これも native との境界はぜんぶ static にしておく方が見通しはいいかもしれないなあ。もとの API が C なわけだし。その方がネイティブの切り口に悩まなくて済みそう。
  • JNI 境界のオブジェクト受け渡しはあんまりがんばらない。配列とか文字列でがんばり type-safety は追求しない。
  • 自分が使いそうな API は、即座に必要なくても一応足していく。開発しながらライブラリとアプリを往復するの大変そうなので。

実装すべき(API を生やすべき)機能

ヘッダを眺めると・・・

  • public/fpdf_attachment.h 不要。 PDF に埋め込んだファイルを取り出すとか、そんな機能あったんか・・・。
  • public/fpdf_annot.h 不要。 注釈(ハイライトとか?) PDF を編集するとか考えてないので。ハイライトはやるとしてもアプリのレイヤで実装することになるでしょう。
  • public/fpdf_catalog.h 不要。なんなのかすらわからん。
  • public/fpdf_dataavail.h 不要。 プログレッシブローディングの仕組み。ファイルはダウンロードしおわってから開くに限る。
  • public/fpdf_doc.h 色々はいってる
    • Bookmark: XXX 要調査。
    • Action: XXX 要調査
    • Link: XXX 要調査。このへんは埋め込まれたリンクとかぽい。たぶん。必要。
    • そのほか: まあ実装していいかな、という程度。
  • public/fpdf_edit.h 名前みただけで見るからに不要。てか PDFium ふつうにページとか作れるのすごいね。
  • public/fpdf_ext.h 不要。サポートしてない機能があったときに通知をうけとれる。
  • public/fpdf_flatten.h 不要。annotation や form を描画データとして焼き込めるらしい。印刷とかに使うのかな。
  • public/fpdf_formfill.h 名前からして不要。
  • public/fpdf_fwlevent.h 不要。マウスイベントとかを定義している・・・。
  • public/fpdf_ppo.h 不要。ドキュメント間でページをコピーしたりとか。
  • public/fpdf_progressive.h 不要。 プログレッシブレンダリングサポート!まあ PDF の仕様書とか論文とか、時々遅い子いるよね。シングルスレッドで progressive rendering とか時代を感じるわ。
  • public/fpdf_save.h 不要。変更した PDF をファイルに書き戻せる。
  • public/fpdf_searchex.h 必要。ページ内テキスト検索。こういうのスレッドセーフだと並列化できるのだけれど、ダメだろうなあ。
  • public/fpdf_structtree.h たぶん不要。ツリーのデータ。ページ単位でついてるので目次ではない。なんなのだろうね・・・
  • public/fpdf_sysfontinfo.h 不要、というか多分実装できない。システムにインストールされているフォントを伝えるためのインターフェイス。これないと読めない PDF とかありそうなので、最終的にはなんらかの頑張りを求められるのかもしれないが。
  • public/fpdf_text.h 必要。ページの中のテキストや、その描画場所にアクセスする。
  • public/fpdf_transformpage.h たぶん不要。ページ単位でもっている bouding box のメタデータが取れる。印刷用ではないかと想像。
  • public/fpdfview.h 必要。これがメインの API だけれど、どこまでカバーすべきかは要調査。
    • レンダリングの仕方とかは考えないとねえ。

それなりに C++ のヘルパとか書かないと厳しそうだな・・・。