Djangoからの美しいPDF印刷

なぜなら この記事は数年の実験の結果であり、多くの手紙があります。 しかし-おそらく-それは説明されているように、誰かがレーキで何ヶ月もサイクリングすることを節約します。

一般的なケースでは、これはDjangoでさえもではなく、テンプレートエンジンを使用してPythonから規制されたドキュメントを印刷することです。

さらに怠を読むために-私はすぐに言います-問題は完全に解決されていません。 しかし、多かれ少なかれ機能するバージョンが登場しました。

1.課題

• ユーザーがデータをWebフォームに入力します
• サーバーはこのデータを印刷可能なテンプレートに挿入します。
• そして、印刷可能な形式でユーザーを提供します

2.制限

• フォームは「ソフト」（精度がそれほど重要ではない場合-契約やアカウントなど）および「ハード」（精度-スキャナーの場合は最大-移民通知またはSTSへの申請（フォーム26.2-1））にすることができます。
• さらに、「ソフト」フォームでさえ、作成者の計画にできるだけ近い場所で印刷する必要があり（境界が1 cmであると言った場合、ユーザーは正確に1 cmの境界を持つドキュメントを取得する必要があります）、特に改ページを考慮します（フォーム11001、21001などを参照してください） .d。）。
• 必須-ソース素材を変換するための最小限の動き（原則として-.xlsまたは.doc、「Consultant」または「Guarantor」からシームレス）。
• なぜなら Webアプリケーションについて話している-ソリューションの応答性と信頼性が非常に望ましい=>ネイティブのPythonライブラリを使用することが非常に望ましい。
• このファーム全体をレンタルホスティング（理想的にはGAE）に配置することが望ましいです。
• テンプレートを視覚的に編集できることが望ましいです。
• テンプレートのクイックプレビュー（およびさらに良い結果）が望ましいです。

最初の段階は、最終形式の選択です。 さまざまなt.zでの熟考の後。 （クロスプラットフォーム、保証された結果、変換可能性c）選択はPDFで決まりました。

今-入力形式とその変換方法。

3.ソフトフォーム

ODF

私たちは、Open Document Format-ODS、ODTなどについて話している。

ここではすべてが非常に簡単です。

• LibreOfficeでテンプレートを編集します（データ用のスペースを残します）。
• どういうわけか、Djangoのフィールドに入力します。
• どういうわけかPDFを取得

データの場所：ユーザー定義フィールドをドキュメントに追加するか、{{django tags}}をテキストに直接挿入します。 最初のケースでは、これらのフィールドに後でpythonから入力することはおそらく可能ですが、どのように想像することもできません（より正確には、表示されるものはすべて非常に紛らわしいようです） したがって、タグはテキスト形式で配置するだけです。

この場合、フィールドの入力は基本です-テンプレートをDjangoテンプレートエンジンにフィードするだけです（gentushkiのテンプレート内で選択するためにPythonライブラリを残します:-)。 そして、キックごとにドキュメントを解凍/圧縮しないために、ドキュメントは* .fodX（フラットX）に保存されます-唯一の解凍されたxml。 テンプレートはxmlとして供給されます。

PDFの取得-オプションなし-LibreOfficeの使用：LibreOfficeデーモン（libreofficed（ubuntudersのどこかにあります））またはunoconvをフィードするか、デーモンモードでLOランチャーを手動で実行します。 これらのオプションはすべてほぼ同じです。

長所

• インターネットで掘られたドキュメントをすぐに使用できます（通常はMicrosoft Office形式の「コンサルタント」から）。
• 編集テンプレートで-問題ありません。
• プレビューと同様。
• おそらく-Googleドキュメントに関するPDFを取得しています-まだ試していません。 しかし、それがリアクティブになることは疑いません（間違っていることは疑いません。googledoxのコンサルタントから同じフォーム21001をダウンロードしてみてください（税務Webサイトにあります））。

欠点

• テンプレートを記述するときに、LibreOfficeが自発的にタグを破壊し、あらゆる種類のspan lang = "en-GB"などを{{..}}内に挿入します。 次に、すべてを手動で戻す必要があります。
• サーバーの素晴らしいリソース消費-100％CPU（数に関係なく1つのみ）、数百メートルのRAM、PDFを受信-最大1分後（フォーム21001-P4-3.0で50秒）。 Javaも同じです。
• 多くのパッケージ（Fedora、CentOS）をプルします。
• 少なくともいくつかのXサーバー（たとえば、Xvfb）の存在。
• おそらく、彼らはいくつかのホスティングでLibreOfficeを展開することを許可されるでしょう-しかし、私は例えばnic.ruを強く疑います。 GAEについても話していません。
• 結果のプレビューはありません。

まとめ

極端なフォールバックオプションとして-適切。 しかし、同じくらい極端です。

HTML

ここでは、テンプレートの編集（手作業）とテンプレートエンジン（スパーク）により、すべてが明確になります。 小さいですが、主な質問が1つあります-PDFを取得する方法ですか？ 必要に応じて改ページを使用して、すばやく効率的に。 そして、これが最も実験的でした。

純粋なpython htmlレンダリング（PISAや祖先/相続人/フォークなど）を使用した多数の実験により、重要な（IMHO）結論が導き出されました。結果を保証するには、既製のhtmlエンジンを使用する必要があります。 そのうち、私たち皆が知っているように、最大​​4（通常から）。 これらのうち、Linuxではgeckoとwebkitの2つまで使用できます。 Pythonからgeckoを呼び出すことはほとんど可能ですが、a）Xを実行する必要があります（LibreOfficeの場合のように）b）既製のレシピが見つかりませんでした。

残りのWebkit：

• PyQt4> Qt> WebKit> QPrinter（このような）。 ネイティブ（多くの機能を備えていますが）賢く-しかし、改ページはキャッチしません。 さらに、DPIとZoomFactorを使用した特別なダンスが必要です。
• GTK> WebKit> GTKプリンター（このような）。 ネイティブで、賢く-しかし、改ページもキャッチしません。
• 特別に変更されたwebkit- wkhtmltopdf-を外部バイナリの形式（現在はこのオプションも使用）で使用するか、ネイティブのPythonバインディング （処理中ですが、小さな問題があります）を使用します。 ネイティブ（バインディングの場合）、スマートに改ページをキャッチし、結果が保証されます。

長所

• 理論的には 、視覚的な編集が可能です。
• インスタントプレビュー（同じHTML形式）-テンプレートとして-結果
• PDFへのリアクティブ変換。
• PDFに変換する純粋なpython API（「進行中」）。

欠点

• それでも、高品質のHTMLは手作りです。
• 複雑なフォーム（21001など）は、独自に作成または描画する必要があります。これは、インターネット上では怖い.xlsであるためです。
• なぜなら Linux用に構築されたlib /バイナリを使用する-同じnic.ru（FreeBSD）では、何も機能しません（松葉杖なし）。 GAEはまだ問題外です。

まとめ

「ソフト」ドキュメントの主なオプション。 しかし、 高品質の純粋なpython htmlレンダー（フラッシュ、JS、その他の漫画なし）を探す必要がありますが、高品質のCSS処理が必要です。

たぶん

将来的には、TeX、LaTeX、Lyx、docbook形式が考慮されますが、これまでのところ利点はありません（特に「ほぼソフトな」形式の場合-同じ21001など）。

4.ハードフォーム

ここではすべてが悲しい。 特に、ここでは既にビジュアルエディタが非常に望ましいという事実に照らして。

さらに、ロシア連邦の「ハード」フォームの大部分（すべてではないにしても）では、テキストが文字に分割されるときに「正方形」が使用され、それぞれが独自の正方形に収まります（ 例 ）。

最初のもの（「tiffのプルテキスト」など）を削除し、ファイナリストに直行します。

RML

Reportlabの開発（はい、python-reportlabは彼らのものです）は通常のXMLであり、PDFで不思議な仕事をすることができます。 なぜなら よく知られているpython-trml2pdfはすでにRIPです（開発者が正直に私に書いたように）-このtrml2pdfを取り、少し仕上げなければなりませんでした。 RMLの多くの興味深い機能をサポートしておらず、 宗教により商用のrml2pdfを購入することは禁じられています（さらに壊れています）。

長所

• ネイティブ
• 賢く
• 柔軟に
• ホスティングに問題はないはずです（理論的に）-GAEでも（試したことはありません）。

欠点

• 厳密に手作り
• 非常にトリッキーな構文は、正確な配置（「グラフィック」）と「ソフト」テキスト（「フローラブル」）を混在させる必要がある場合です（したがって、ビジュアルエディターがないようです）。
• プレビューなし-テンプレートも結果もありません。

まとめ

正確な形式（特に単純な形式）のフォールバック。

PDFフォーム

ここではすべてが非常に簡単です。PDFのソース-PDFの最終結果です。

1. 左手に元のPDFを取ります
2. 組み込みのDjangoテンプレートエンジンによって処理されたXFDF（気取らないxml）-右側
3. それらを新しいPDFにマージ（取り込み）（「ロールアウト」-フラット化）
4. それをユーザーに渡します

問題は1つだけです-項目3。

これまで、PDFフォームを操作するためのネイティブで正しく機能するpython APIは見つかりませんでした（ただし、popplerは既に何かを実行できますが、明らかに、さらに多くの機能があります）。したがって、 iTextが唯一の許容可能なオプションです。 pdftkまたは自転車を使用することは、すでにあなたの好みに合っています。

長所

• 何でもPDFフォームに変換できます（別の問題として）。
• （同様に）編集することもできます。
• 絶対に保証された結果。
• 組み込みのPDF形式「正方形」（コンボ）。
• ほとんどの場合-ホスティングに問題はありません（おそらく-およびGAEに）-私は試していません。

欠点

• Python APIの代わりに外部アプリケーションを呼び出します。
• Javaも同じです。

まとめ

正確な印刷フォームの主なオプション。

5.概要

今日形成された合計：

• 「ソフト」フォーム-html | webkit-しかし、かなり重く、冗長で、あまりポータブルではないwebkittoxライブラリを使用します（そして見続けます）。
• 「ハード」フォームはPDFフォームですが、 松葉杖を介して外部JAVAライブラリを使用します（ポプラをレイプし続けます）。
• ODFおよびRML-それぞれフォールバックオプションとして。

PS。 これがどのように機能するか- ここで見ることができます-ODFとRMLなしで、後者が提供されます。