100 ページ以上の PDF ドキュメントを生成する必要があります。このプロセスでは処理に大量のデータが必要であり、一度に生成すると、より多くの時間とメモリが必要になります。
私は自分のやり方をハックするためにいくつかの異なる方法を試しました:
- HTML の生成と変換を行う xhtml2pdf
- いくつかのページを生成するrportlabと
- マージ用のpyPdf
さまざまな結果で動作しましたが、遅く、必要以上に多くのメモリを必要とします (インスタンスのソフトメモリ制限に達することがあります)。現在、ブロブストアにそれぞれを格納するさまざまなタスクでいくつかのセクションを生成し、それらを pyPdf とマージしますが、大きなドキュメントではチョークします。
私が生成しているドキュメントはそれほど複雑ではなく、ほとんどが表とテキストであり、内部参照も TOC も、ドキュメントの残りの部分を認識する必要のあるものも何もありません。私はレイアウトのためにカモノハシと一緒に暮らすことができ、派手なドキュメントの外観や HTML2PDF 変換は必要ありません。
目標は、データストアが許す限り速くドキュメントを生成することです。並列ページ生成は便利ですが、必須ではありません。
各タスクが単一のページを生成し、最後のタスクがブロブストアファイルをファイナライズして読み取り可能にする、blobstore files apiを使用したページごとの生成を考えていました。しかし、生成を一時停止し、部分的なPDFをストリームに保存し、そのストリームで生成を再開して、別のタスクで次のページを生成する方法を見つけることができないようです。
だから私の質問は:
GAE では、数ページよりも大きな PDF ドキュメントを生成し、生成をタスク リクエスト間で分割し、結果のドキュメントをブロブストアに保存する方法を教えてください。
reportlab で世代分割ができない場合、GAE タスク要求によって設定された制限に適合するように、異なる PDF ドキュメントをマージするフットプリントを最小限に抑えるにはどうすればよいですか?
更新: Conversion API の代替案は大歓迎です。
2nd UPDATE 変換 API は廃止されているため、現在それはオプションではありません。
3 回目 の更新 Pileline または MapReduce API はここで役立ちますか?