Field Reportsの特徴 (4) テンプレート方式の帳票ツール

帳票ツールの分類

世の中には色々な方式の帳票ツールがあり，その処理方式も様々です。

Field Reportsでは，あらかじめ準備しておいたテンプレートにテキストや画像を流しこむ方式を採用しています。
そのような方式にした理由を説明するために，まず既存の帳票ツールを処理方式により分類するところから始めたいと思います。

私の主観で帳票ツールを大まかに分類すると，以下の３通りに分けられると思います。

(1)API方式

用紙上にテキスト・画像・罫線などの要素を配置するプリミティブなI/Fが一式用意されている。
要素を配置する場所を用紙上の座標で指定する。
特定の言語のライブラリとして機能が提供されることが多い。

利点

APIが用意されている言語からは，簡単に利用できる。
要素のスタイル（フォントサイズ・表示色など）・配置する座標などの属性をプログラムから完全に制御することができる。

欠点

帳票レイアウトをすべてハードコーディングする必要があるので，コーディング量が多くなりがち。
帳票デザインの変更により，プログラムの修正が必要になる。
禁則処理・ハイフネーション処理などは困難（手作りで実装する必要が生じる）。

(2)組版方式

テキスト・画像・罫線などの要素を先頭から順次配置することで紙面を構成する。
要素を配置する位置は，基本的には自動的に決められる。
既存の文書出作成ソフトの出力をPDF等に変換することで実装された例が多い。

実装例

TeX
XML+XSLT

利点

各要素の大きさ（文書量）に応じて配置を調整するので，余分は空白領域ができない。
禁則処理・ハイフネーション処理などを行うため，仕上がりが美しい。
文書が多い帳票に向いている。

欠点

「入力ファイル作成 → 組版処理 → PDF変換」の様に複雑な工程をたどるので，処理が遅くなりがち。
要素の位置は基本的にツール任せになるので，プログラムからきめ細かく制御することは困難（または煩雑）。

(3)テンプレート方式

用紙上にテキスト・画像などの要素を配置する枠（フォーム）や固定のテキスト・画像・罫線を配置して，帳票テンプレートをあらかじめ準備しておく。
帳票作成時には，フォームに動的なテキストの値を流し込むことで，帳票を完成させる。

利点

コーディング量は少なくて済む。
デザインの変更に強い。

欠点

枠の位置が固定になるので，文書量に応じて要素の位置を調整するのが難しい。
テキストのスタイルは基本的にテンプレート作成時に決定されるので，実行時に変更することは困難（または煩雑）。
禁則処理・ハイフネーション処理などは困難。

まとめ

各方式の利点・欠点をまとめると次のようになります。

	開発効率	耐変更	定形フォーム	複数行	動的要素	処理速度
API方式	×	×	○	×	○	○
組版方式	○	○	×	○	△	△
テンプレート	○	○	○	△	×	○

「耐変更」とは，帳票デザインに変更が発生した際の対応の容易さを示します。

「複数行」とは，複数行にわたるテキストを配置したい場合の行分割処理の容易さを示します。
組版方式では，単に行を分割するだけでなく和文の禁則処理・英文のハイフネーション処理などが行えることが一般的なので，◯としています。

Field Reportsがテンプレート方式を採用した理由

日本的な帳票では，あらかじめ定められた枠の中にテキストをピタリとはめ込むことがしばしば要求されますので，まず組版方式は難しいだろうと考えました。

残ったAPI方式とテンプレート方式では，自由度を取るか開発効率を取るかという選択になりますが，開発効率を優先事項と考え，テンプレート方式を採用しました。
何十枚・何百枚と帳票を作成する場合には，開発効率の僅かな差が全体の開発工数に大きく影響してくるからです。

テンプレート方式の欠点をいかにカバーしたのか？

動的なスタイル変更

実際の帳票では，テキストの表示色・フォントサイズの様なスタイルを動的に変更したい場合が出てきます。
APIを一式用意すればプログラムから制御することが可能になりますが，プログラミングが煩雑になるのは避けたいと考えました。

そこで Field Reports では，XML+XSLTによる組版ツールで用いられる「スタイルシート」の考え方を導入しました。
XMLの各要素をPDFのフォーム（フィールド）に対応付けることにより，スタイルシートによるスタイル指定を可能にしました。
Field Reportsのスタイル指定については，後日詳しく説明させていただきます。