サーバーで情報を「フォーム」にマージし、最終出力として PDF を生成する最適な方法 [終了]

Question

背景:

サポートされていない Acrobat Reader OCX 統合を使用してユーザーがレビューできる PDF を生成する、「継承」した VB6 アプリケーションがあります。プログラムはデータを含む FDF ファイルを生成し、FDF が PDF とマージされるときにマージされた結果をレンダリングします。Acrobat Reader 4 でのみ正しく動作します :-(。新しいバージョンの Acrobat Reader をインストールすると、このアプリケーションが機能しなくなるため、ユーザーは非常に不快になります。

結合するデータを PDF 出力生成サーバーに送信できるように、このアプリを再設計したいと考えています。このサーバーは、渡されたデータをフォームにマージし、その PDF イメージを生成して保存します。これにより、最終結果を表示したいユーザーは簡単に PDF を取得できます (生成されるのは 1 回だけです)。基礎となるデータが変更された場合、PDF は削除され、次回リクエストされたときに再生成されます。クライアント プログラムは、（本来の目的どおり）PDF ファイルの表示専用に使用されるため、任意のバージョンの Acrobat Reader を使用できます。サーバーは、おそらく Web サービスとして、Visual Studio 2005 を使用して .NET (C#) で作成される可能性が高くなります。

質問:

他の人は私にこれについてどのように勧めますか?これを行うには、サーバーで Adob​​e の Acrobat 9 を使用し、データを FDF または Adob​​e の XML 形式に入れて、Acrobat にマージを実行させる必要がありますか?「データをフォームに結合して PDF を出力」の分野に強力な競合他社はありますか?他の人はどうやってこれをやっているのでしょうか？もちろん、API ベースである必要があり、サーバーには GUI はありません...

一部の出力は FDF/PDF 経由で生成されますが、アプリケーションの別の部分では、実際には線、グラフィックス、およびテキストが一度に 1 ページずつプリンター (またはプレビュー目的のフォーム) に送信され、適切な X/Y 座標、フォント、サイズなどそれぞれについて、それがページの最後にいつ来るかを知るなど。このコードは現在、ユーザーが確認できるように表示するプログラム内にあり、最終フォームをプリンタに印刷するプログラム内にもあります。レビュー担当者とプリンターの間の一貫性を保つために、優れた PDF 生成 API ツールを使用するか、コードをそのまま使用して PDF プリンターで PDF を生成することで、この出力生成ロジックもサーバーに移動したいと考えています...そしてクライアントが表示できるようにこの PDF を保存します。

「フォーム ソフトウェア」や「入力フォーム ソフトウェア」、または同様の検索をグーグルで検索すると、ほとんどがユーザーがフォームに入力するための UI に関連した無関係な内容が非常に多く返されます。検索を適切に絞り込む方法がわかりません。他のプログラマも同様の出力を生成する必要があり、いくつかの優れたツールを試しているはずなので、このサイトはそのような質問をするのに最適な場所であると思われます。

編集：

PDFタグとPDF生成を追加しました。また、現在の顧客は PDF 出力を主張していますが、代替案を提供していただき感謝しています。

Answer 1

VB6 ソリューションでは役に立ちませんが、サーバー上の .net または Java ソリューションでは役立ちます。
iText または iTextSharp を取得する http://www.lowagie.com/iText/.
PDF と FDF の FDFReader/FDFWriter クラスをマージして FDF ファイルを生成したり、PDF ファイルからフィールド名を取得したりできる PdfStamper クラスがあります。

Answer 2

私の忠告を聞きたまえ。PDF を捨てて XPS にしましょう。私は 2 つのアプリに取り組んでおり、どちらもサーバーベースです。1 つは、画像ベースのドキュメントを PDF としてブラウザーに表示します。2 つ目は、FixedPage テンプレートを使用して、データ ソースにバインドされた XPS ドキュメントを構築します。

両方のプロジェクトに取り組んだ後の私の結論は、PDF は最悪だということです。XPS ドキュメントではそれほど重要ではありません。まともな PDF ライブラリを購入するには現金を支払う必要がありますが、XPS にはフレームワークが付属しています。PDF ドキュメントの生成はメモリを大量に消費し、穴がたくさんあり、サーバーにあまり適していません。XPS ドキュメントは設置面積がはるかに小さいため、足を撃たれる可能性が低くなります。

Answer 3

私は Microsoft Word を使用して大きな成功を収めました。フォームは Word でデザインされ、XML データと合成されます。ドキュメントは PDF コンバーター (この場合は Neevia ですが、もっと優れたものもあります) を介して実行され、PDF が生成されます。

これらはすべて C# で行われます。

Answer 4

同じボートです。現在、次の方法で PDF を作成しています。vb6 アプリは、レコード (ファイル名、作成日、ユーザー、最終的な宛先を含む) を SQL にドロップし、xls (またはドキュメント) はサーバー ディレクトリ (共有) に移動され、サーバーにはファイルウォッチャーを監視する vb.net サービスがあります。そのディレクトリ。ファイルが表示され、サービスは Excel (Word) を起動して Adob​​e 経由でファイルを PDF にし、SQL を参照して PDF 作成時に PDF をどう処理するかを判断し、終了時間を記録します。

これは安価なソリューションでした。コードの作成に約 1 日、両端のデバッグとビルドのロールアウトにさらに 1 日しかかかりませんでした。

これは方法ではありません。 PDF を作成しようとすると、Adobe が不定期にクラッシュします。2 週間はまったく問題なく動作しますが、その後は (今日のように) 5 分ごとにクラッシュします。または1時間おきに。または、11:07、2:43、3:05、および 6:11。

次のリビジョンでは、Excel と Word からデータを変換し、PDFTron を使用してデータを直接 PDF にドロップする予定です。はい、PDFTron には費用がかかります (プロセッサあたり 1 キロバックのライセンスを購入しました) が、うまく機能します。XPSは ニース しかし私もあなたと同じように PDF を提供する必要があります。それが物事のやり方です。

pdfTron (グーグルで検索) をチェックして、希望どおりの動作をするかどうかを確認してください。次に、必要なライセンスとその支払い方法を決定するだけです。誰かがもっと良いものを思いついたなら、投票してリストの一番上に入れてくれる事を願っています!!!