1

最近、ITextSharp がHTML コンテンツ ( CKEditor、TinyMCE などの HTML エディターから渡される) をレンダリングするのに非常に長い時間 (多くの場合 30 秒以上) かかるというパフォーマンスの問題に遭遇しました。

以前は、HTMLWorker を使用してコンテンツを解析していましたが、うまく機能していました。高速でかなり正確でしたが、より複雑な HTML (テーブル、順序付きリスト、順序なしリストなど) が渡されるようになると、機能が低下し始めました。

//The HTML Worker was quick, however it's weaknesses began to show with more 
//complex HTML
List<IElement> objects = HTMLWorker.ParseToList(sr, ss);

この状況では複雑なマークアップが必要であり、これらの問題を解決するために正規表現操作やその他の厄介なことを実行しようとするのではなく、XMLWorker を使用して解析を処理することにしました。

//This outputs everything perfectly and retains all of the proper styling that is
//needed. However, when things get complex it gets sluggish
XMLWorkerHelper.GetInstance().ParseXHtml(writer,document,stringReader);

XMLWorker の結果は驚くべきもので、すべて必要なとおりに出力されましたが、そのパフォーマンスにより、ほとんど使用できなくなりました。(追加のテーブル、スタイル、およびリストによって)コンテンツの複雑さが増すにつれて、読み込み時間も増加しました。

上記の行はパフォーマンスのボトルネックのようであり、それを使用していくつかの異なる代替手段を試してもまったく役に立ちませんでした (基本的なカスタム XmlHandler の作成など)。

考えられる原因とアイデア

  • 渡されたコンテンツから無関係で無効なマークアップを取り除いてみましたが、ほとんど効果がありませんでした。

  • 問題は iTextSharp 自体にあり、XMLWorkerHelper がどのように機能しているか? ここで iText XML Helper Demo内で SAME 入力を使用しようとしましたが、驚くほど高速でした。パフォーマンスは少なくとも同等になると考えました。

  • 現在の考慮事項は、保存方法を使用してレンダリングされた PDF を実際に保存し、動的に生成するのではなく、オンデマンドで取得することです。私はこれを避けたいと思っていますが、それはテーブルにあります。

  • コンテンツは Microsoft Word ( cringe ) から貼り付けられており、可能な限りクリーンアップしようとしましたが、上記の iText デモには同じコンテンツで大きな問題はなかったので、大きな問題ではないと思います。

  • iTextSharp を使用する代替案はありますか?

追加の詳細とコードを提供できることを嬉しく思います。

4

1 に答える 1

1

この号は数年前のものですが、 TuesPechkin プロジェクト経由で最終的にwkhtmltopdfライブラリを使用することを選択したことを将来の読者に知らせたいと思いました。

パフォーマンスは iTextSharp よりも大幅に改善されており、既存のプロジェクトに適したさまざまなシナリオの実装例を含む優れたドキュメントがあります。

于 2015-08-10T14:32:33.407 に答える