pdfimages
and mupdf
/を使用した画像抽出は、mutool
これまでのところ正常に機能します。
FreePDF で生成された PDF の画像は常にスライスされるため、1 つの画像が複数の画像ファイルになります。
これを回避するトリックはありますか?の結果をどのように使用できpdfshow
ますか? PDFをPNGまたはJPEGに変換した後、画像をカット/トリミングするための位置と高さと幅を知るための座標はありますか?
pdfimages
and mupdf
/を使用した画像抽出は、mutool
これまでのところ正常に機能します。
FreePDF で生成された PDF の画像は常にスライスされるため、1 つの画像が複数の画像ファイルになります。
これを回避するトリックはありますか?の結果をどのように使用できpdfshow
ますか? PDFをPNGまたはJPEGに変換した後、画像をカット/トリミングするための位置と高さと幅を知るための座標はありますか?
抽出後に画像が「スライス」される理由として最も可能性が高いのは、PDF ファイル内での生き方として、抽出前に既に「スライス」されていることです。
一部の PDF 生成ソフトウェアがこれを行う理由を聞かないでください。
MS Powerpoint はこれで悪名高いです。グラデーションを示す背景画像は、PDF 内で何万ものピクセルや同様のサイズのミニ画像にスライスされることがよく1x1
あり1x2
ます1x8
。
サンプル PDF の画像フラグメントは、次のコマンドで識別できます(これには、Poppler フォークではなく、Poppler フォークに基づくpdfimages -list
の最新バージョンが必要です!):pdfimages
xpdf
pdfimages -list so-28023312-test1.pdf
page num type width height color comp bpc enc interp objectID x-ppi y-ppi size ratio
------------------------------------------------------------------------------------------
1 0 image 271 271 rgb 3 8 jpeg no 18 0 163 163 26.7K 12%
1 1 image 271 271 rgb 3 8 jpeg no 19 0 163 163 21.7K 10%
1 2 image 271 271 rgb 3 8 jpeg no 30 0 163 163 22.9K 11%
1 3 image 271 271 rgb 3 8 jpeg no 31 0 163 163 21.8K 10%
1 4 image 132 271 rgb 3 8 jpeg no 32 0 162 163 9895B 9.2%
1 5 image 271 271 rgb 3 8 jpeg no 33 0 163 163 22.5K 10%
1 6 image 271 271 rgb 3 8 jpeg no 34 0 163 163 16.5K 7.7%
1 7 image 271 271 rgb 3 8 jpeg no 35 0 163 163 16.9K 7.9%
1 8 image 271 271 rgb 3 8 jpeg no 36 0 163 163 20.3K 9.4%
1 9 image 132 271 rgb 3 8 jpeg no 37 0 162 163 14.5K 14%
1 10 image 271 271 rgb 3 8 jpeg no 20 0 163 163 17.1K 8.0%
1 11 image 271 271 rgb 3 8 image no 21 0 163 163 107K 50%
1 12 image 271 271 rgb 3 8 image no 22 0 163 163 96.7K 45%
1 13 image 271 271 rgb 3 8 image no 23 0 163 163 119K 56%
1 14 image 132 271 rgb 3 8 jpeg no 24 0 162 163 10.7K 10%
1 15 image 271 99 rgb 3 8 jpeg no 25 0 163 161 7789B 9.7%
1 16 image 271 99 rgb 3 8 jpeg no 26 0 163 161 6456B 8.0%
1 17 image 271 99 rgb 3 8 jpeg no 27 0 163 161 7202B 8.9%
1 18 image 271 99 rgb 3 8 jpeg no 28 0 163 161 8241B 10%
1 19 image 132 99 rgb 3 8 jpeg no 29 0 162 161 5905B 15%
1 ページに 20 の異なるフラグメントしかないため、簡単に...
-j
次のコマンドは、フラグメントを抽出し、JPEG ( ) 28023312として保存しようとします。
pdfimages so-28023312-test1.pdf 28023312
PPMとして出てきた3枚の画像があります。ImageMagick を使用convert
して、それらから JPEG を作成します (厳密には必須ではありませんが、「ステッチング」コマンド ラインが簡素化されます。
for i in 11 12 13; do
convert 28023312-0${i}.ppm 28023312-0${i}.jpg
done
最初の 3 つのフラグメント、280233312-000.jpg、280233312-001.jpg、および 280233312-002.jpg を次に示します。
ImageMagick は、20 枚の画像を再びつなぎ合わせることができます。PDF ページと 20 個の JPEG を見ると、それらをまとめる必要がある順序を簡単に判断できます。
convert \
\( 28023312-0{00,01,02,03,04}.jpg +append \) \
\( 28023312-0{05,06,07,08,09}.jpg +append \) \
\( 28023312-0{10,11,12,13,14}.jpg +append \) \
\( 28023312-0{15,16,17,18,19}.jpg +append \) \
-append \
complete.jpg
コマンドの分析:
+append
イメージ オペレータは、リストされたすべてのイメージを水平方向に追加します。
\( ... \)
行は、画像スタックの対応する部分の「脇」処理を示します (エスケープされた括弧で区切る必要があります)。この水平追加操作の結果は、現在の画像スタック内の個々のフラグメントを置き換えます。
最終-append
イメージ オペレータは、現在のイメージを垂直方向に追加します。
これは、完全につなぎ合わされた JPEG の結果です。
理論的には、このプロセスを自動化できます。このためには、PDF ソース コードを分析する必要があります。ただし、コンテンツ ストリームが圧縮されている可能性があるため、これはかなり困難です。
コンテンツ ストリームのすべてまたはほとんどを解凍し、PDF ファイル構造をより適切に表現するにはmutool clean -d
、 、podofouncompress
またはqpdf --qdf
.
私は、「構造的でコンテンツを保持する PDF ファイル トランスフォーマー」であるqpdfを好みます。コマンドは次のとおりです。
qpdf --qdf --object-streams=disable so-28023312-test1.pdf qdf.pdf
結果の PDF ファイルは、以前のバイナリ セクションのほとんど(すべてqdf.pdf
ではない) が ASCII になっているため、分析がより簡単になります。このファイル内の出現箇所を検索すると、画像が挿入されている場所が表示されます (ただし、ここで完全な PDF 分析チュートリアルを提供することはできません。申し訳ありません...)。Do
次のコマンドは、Do
発生するすべての行と、その前の行 ( -B 1
) を出力します。
grep -a -B 1 " Do" qdf.pdf
1002 0 0 1002 236 5776.67 cm
/Im0 Do
--
1001 0 0 1002 1237 5776.67 cm
/Im1 Do
--
120.12 0 0 120.24 268.44 693.2004 cm
/Im2 Do
--
[...skipping 15 other output segments...]
--
1002 0 0 369 3237 3406.67 cm
/Im18 Do
--
490 0 0 369 4238 3406.67 cm
/Im19 Do
--
1 0 0 1 204.9037018 508.5130005 cm
/Fm0 Do
すべての/ImNN Do
行は画像を挿入します (/Fm0 Do
行は画像ではなくフォーム オブジェクトを参照します)。
たとえば、前の行は現在の変換行列490 0 0 369 4238 3406.67 cm
を設定します。この線だけで、画像の位置とサイズを推測できる場合があります。このファイルの場合、それだけでは十分ではありません。現在の「描画位置」を決定するには、さらに前の行の内容が必要になります。
FreePDF は Ghostscript を使用して「仮想プリンター」を作成します。「PDF に印刷」すると、実際にはアプリケーションが Windows 印刷パイプラインに印刷され、Windows 印刷パイプラインがグラフィック プリミティブを Windows PostScript プリンター ドライバーに送信し、Windows PostScript プリンター ドライバーが PostScript をポート モニターに送信します。FreePDF Port Monitor は、この PostScript プログラムをディスクに保存します。出力が完了すると、PostScript を解釈して PDF ファイルを生成する Ghostscript が起動します。
ここで、Ghostscript の非常に古いバージョンを使用していない限り (可能な場合はチェックする必要があります!)、これは入力に含まれていたものをすべて受け取り、それを出力に入れます。画像をスライスしません。
つまり、Kurt と David が上で述べたように、この問題の本当の理由は、Ghostscript が認識する前に、PostScript プログラムがその中の画像をスライスしたことにあるということです。
一般的にはそうではないことはわかっていますが、インストールした PostScript プリンター ドライバー、その構成、使用している Windows のバージョン、およびプリンターを駆動するアプリケーションによって大きく異なります。
David が正しく言っているように、Microsoft Office アプリケーションには、特定の種類のパターンをこのように描画するという悪い習慣があります (「半透明効果」を得るために、セルがイメージマスクであるパターンを使用し、「白い」ピクセルは透明です)。
また、(たとえば) 大きな写真があり、PostScript プリンターが最小限のメモリで構成されている場合、ドライバーはプリンターのメモリを使い果たさないように画像を分割することがあります。デスクトップ PC では Ghostscript を圧倒するためにモンスター イメージを使用する必要があるため、これは明らかに構成上の問題です。
したがって、基本的には、これに完全に回答するには、さらに多くの情報が必要ですが、原則として、FreePDF に到達する前に損害が発生したということです。PDF ファイルの作成に使用された Ghostscript のバージョンは、FreePDF が消去/上書きを選択しない限り、PDF ファイルのメタデータに含まれます。
最後に、Kurt が指摘したように、PDF ファイルへのリンクを投稿する必要があります。理想的には、PDF の作成に使用されたアプリケーション ファイルと中間 PostScript ファイルです。