PDF変換画像のオープンソースツールをいくつか紹介します
3300 ワード
最近のプロジェクトでは、PDFを1枚の図に変換する必要があります.調査の結果、この機能は比較的流行しているJavaオープンソースソフトウェアが3つあります.しかし、使用中、それらの違いはまだ大きい.この3つのソフトウェアPdf-renderer,PDF Box,JPedalについて簡単に紹介します.
まず、この3つのツールの位置は異なります.
PDF-Rendererは、ユーザーがPDFドキュメントを簡単に表示できるようにするためのオープンソースプロジェクトです.PDFドキュメントを解析することで、ユーザーは自分のアプリケーションでPNGを表示、プレビュー、描画し、3 Dのシーンにマージすることができます.
PDF BoxはJavaで実装されたPDFドキュメントコラボレーションクラスライブラリであり、PDFドキュメントの作成、処理、ドキュメントコンテンツ抽出機能を提供します.また、PDFの処理を容易にするための多くのコマンドも含まれています.その強力な機能は、解析PDFドキュメントを処理することです.また、業界では広く安定して使用されています.
JPedalはIDRsolutions社の製品です.この製品はPDF解析とPDF展示において比較的専門的な表現を持っている.JPedalは、その一部の機能のみをオープンソースします.このうちPDF転送画像の機能はLGPLの下にあります.
上の位置から見ると、PDF-Rendererは私たちの要求に合っているはずです.次に、画像の品質、効率の面から簡単に比較します.
以下に、PDFから3つのツールを変換した画像を示します.
[size=large] [b]PDF-renderer[/b][/size]
[img]http://dl.iteye.com/upload/attachment/551828/ee546739-d2ee-3737-b90b-bda5a26c06e8.png[/img]
[size=large][b] PDFbox[/b][/size]
[img]http://dl.iteye.com/upload/attachment/551830/ee4d67f3-15cf-39de-80f4-5112cd01fcd8.png[/img]
[size=large][b] Jpedal[/b][/size]
[img]http://dl.iteye.com/upload/attachment/551832/b25c7c01-8e56-3e19-93c9-816ce5305f30.png[/img]
画像の質から見ると、PDBboxの線がうまく描けなかった後、ほとんど差がない(もちろん、画素上ではPDF boxが最も高い).しかし、彼らの間の変換効率はやはり大きな差がある.変換効率では、テストによってうまくいかなかったのはPDF Boxで、次いでJpedal.である.最も良いのはPDF_renderer.が私のテストでPDF-rendererの変換効率はJpedalの約2、3倍である.Jpedalの変換効率はPDF boxの約3倍である.
しかし,一定量の文書のテストを経て,多くのPDF文書がPDF-rendererで処理できないことが分かった.1つの主な原因はPDF-rendererのフォントが不完全である.PDF boxには独自のフォントパッケージがあり、変換できない場合はデフォルトのフォント処理に変換されます.現在のテストでは、PDF boxとJpedalで処理できないドキュメントはまだ見つかっていません.PDF boxでは、表の線を正確に捉えられないことがあるので、今回のプロジェクトではJpedalを使用することにしました.Jpedalが商業会社の製品である以外に、使わない理由はないようです.
プロジェクトの使用中は、マルチスレッドバッチ変換を使用するためです.メモリオーバーフローの問題が発生.特にPDF boxを使用する場合は、より多くのメモリが必要になります.ここでは、メモリオーバーフローの問題をどのように追跡して解決するかについて簡単に説明します.皆さんはもっと良い方法があるかもしれませんが、皆さんの意見を熱烈に歓迎します.
まず、jvisualvmを利用して、プラグインを装着すればメモリの使用状況を動的に観察できることを自然に考えているかもしれません.スレッドスタック、CPU、メモリスナップショットをいつでも出すことができます.しかし、大きなアプリケーションシステムでは、メモリがもともときついので、jvisualvmを開くと基本的にそこで死んでしまいます.ここで考えられるのは,gc logとメモリオーバーフロー後のスタック情報を用いて処理することである.
JVM起動では、次の構成パラメータを追加します.
gcの詳細logを開き、個別のファイルに書き込みます.ここで、HeapDumpOnOutOfMemoryErrorの構成は、メモリオーバーフロー時にjava_を書きます.pidXXXX.hprofのファイルはjvmが起動した場所にあります.Eclipse Memory Analysisプラグインを使用して、このファイルを開くと、メモリオーバーフロー時のメモリスタック情報を取得できます.中にはLeak Suspects機能があり、メモリオーバーフローの可能性が最も高いと考えられるobjeeを分析しています.次の図を示します.
[img]http://dl.iteye.com/upload/attachment/551857/2ba9e916-0d9c-373d-894b-f92a14716416.png[/img]
図から、不審な点が2つあることがわかります.2つ目は私たちが写真を回して使ったものです.コードを改善することができます
gcログファイルにも言及しました.gcログを分析することで、JVMスタックのメモリ使用状況がわかります.ここではtaobao人が開発したgcログを表示するツールを紹介します.小さくて使いやすいです.[url]http://code.google.com/p/gclogviewer/[/url]現在のバージョンでは絵を描くしかありませんが、次のバージョンでは絵の性能が向上するほか、チューニングのアドバイスも追加されます.次は私がコードを変更する前後の2つのgc図です.
[img]http://dl.iteye.com/upload/attachment/551862/bb2502e4-eaf7-35a3-8ec6-fcad87ad9967.png[/img]
この図から、メモリがクラッシュするまで上昇していることがわかります.
これはコードを変更した図です.
[img]http://dl.iteye.com/upload/attachment/551868/1b291528-55e9-307e-adbc-221f688ef54c.png[/img]
この図では、メモリが安定しています.しかし、転化過程ではFull GCにいた.アプリケーションの一時停止は深刻です.幸いなことに、これはバックグラウンドのデータ訂正プログラムです.パフォーマンスの最適化にはまだ多くのことができます.
まず、この3つのツールの位置は異なります.
PDF-Rendererは、ユーザーがPDFドキュメントを簡単に表示できるようにするためのオープンソースプロジェクトです.PDFドキュメントを解析することで、ユーザーは自分のアプリケーションでPNGを表示、プレビュー、描画し、3 Dのシーンにマージすることができます.
PDF BoxはJavaで実装されたPDFドキュメントコラボレーションクラスライブラリであり、PDFドキュメントの作成、処理、ドキュメントコンテンツ抽出機能を提供します.また、PDFの処理を容易にするための多くのコマンドも含まれています.その強力な機能は、解析PDFドキュメントを処理することです.また、業界では広く安定して使用されています.
JPedalはIDRsolutions社の製品です.この製品はPDF解析とPDF展示において比較的専門的な表現を持っている.JPedalは、その一部の機能のみをオープンソースします.このうちPDF転送画像の機能はLGPLの下にあります.
上の位置から見ると、PDF-Rendererは私たちの要求に合っているはずです.次に、画像の品質、効率の面から簡単に比較します.
以下に、PDFから3つのツールを変換した画像を示します.
[size=large] [b]PDF-renderer[/b][/size]
[img]http://dl.iteye.com/upload/attachment/551828/ee546739-d2ee-3737-b90b-bda5a26c06e8.png[/img]
[size=large][b] PDFbox[/b][/size]
[img]http://dl.iteye.com/upload/attachment/551830/ee4d67f3-15cf-39de-80f4-5112cd01fcd8.png[/img]
[size=large][b] Jpedal[/b][/size]
[img]http://dl.iteye.com/upload/attachment/551832/b25c7c01-8e56-3e19-93c9-816ce5305f30.png[/img]
画像の質から見ると、PDBboxの線がうまく描けなかった後、ほとんど差がない(もちろん、画素上ではPDF boxが最も高い).しかし、彼らの間の変換効率はやはり大きな差がある.変換効率では、テストによってうまくいかなかったのはPDF Boxで、次いでJpedal.である.最も良いのはPDF_renderer.が私のテストでPDF-rendererの変換効率はJpedalの約2、3倍である.Jpedalの変換効率はPDF boxの約3倍である.
しかし,一定量の文書のテストを経て,多くのPDF文書がPDF-rendererで処理できないことが分かった.1つの主な原因はPDF-rendererのフォントが不完全である.PDF boxには独自のフォントパッケージがあり、変換できない場合はデフォルトのフォント処理に変換されます.現在のテストでは、PDF boxとJpedalで処理できないドキュメントはまだ見つかっていません.PDF boxでは、表の線を正確に捉えられないことがあるので、今回のプロジェクトではJpedalを使用することにしました.Jpedalが商業会社の製品である以外に、使わない理由はないようです.
プロジェクトの使用中は、マルチスレッドバッチ変換を使用するためです.メモリオーバーフローの問題が発生.特にPDF boxを使用する場合は、より多くのメモリが必要になります.ここでは、メモリオーバーフローの問題をどのように追跡して解決するかについて簡単に説明します.皆さんはもっと良い方法があるかもしれませんが、皆さんの意見を熱烈に歓迎します.
まず、jvisualvmを利用して、プラグインを装着すればメモリの使用状況を動的に観察できることを自然に考えているかもしれません.スレッドスタック、CPU、メモリスナップショットをいつでも出すことができます.しかし、大きなアプリケーションシステムでは、メモリがもともときついので、jvisualvmを開くと基本的にそこで死んでしまいます.ここで考えられるのは,gc logとメモリオーバーフロー後のスタック情報を用いて処理することである.
JVM起動では、次の構成パラメータを追加します.
-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:D:/java/gc/gc.log -XX:+HeapDumpOnOutOfMemoryError
gcの詳細logを開き、個別のファイルに書き込みます.ここで、HeapDumpOnOutOfMemoryErrorの構成は、メモリオーバーフロー時にjava_を書きます.pidXXXX.hprofのファイルはjvmが起動した場所にあります.Eclipse Memory Analysisプラグインを使用して、このファイルを開くと、メモリオーバーフロー時のメモリスタック情報を取得できます.中にはLeak Suspects機能があり、メモリオーバーフローの可能性が最も高いと考えられるobjeeを分析しています.次の図を示します.
[img]http://dl.iteye.com/upload/attachment/551857/2ba9e916-0d9c-373d-894b-f92a14716416.png[/img]
図から、不審な点が2つあることがわかります.2つ目は私たちが写真を回して使ったものです.コードを改善することができます
gcログファイルにも言及しました.gcログを分析することで、JVMスタックのメモリ使用状況がわかります.ここではtaobao人が開発したgcログを表示するツールを紹介します.小さくて使いやすいです.[url]http://code.google.com/p/gclogviewer/[/url]現在のバージョンでは絵を描くしかありませんが、次のバージョンでは絵の性能が向上するほか、チューニングのアドバイスも追加されます.次は私がコードを変更する前後の2つのgc図です.
[img]http://dl.iteye.com/upload/attachment/551862/bb2502e4-eaf7-35a3-8ec6-fcad87ad9967.png[/img]
この図から、メモリがクラッシュするまで上昇していることがわかります.
これはコードを変更した図です.
[img]http://dl.iteye.com/upload/attachment/551868/1b291528-55e9-307e-adbc-221f688ef54c.png[/img]
この図では、メモリが安定しています.しかし、転化過程ではFull GCにいた.アプリケーションの一時停止は深刻です.幸いなことに、これはバックグラウンドのデータ訂正プログラムです.パフォーマンスの最適化にはまだ多くのことができます.