Microsoft Word 2010によるスクリーンショットの平滑化を停止しますか？

JPEGスクリーンショットをMicrosoft Wordに挿入すると、ビットマップの元のピクセルを保持する代わりに、それらを滑らかにします。次に、Acrobat Distillerを使用してPDFに印刷すると、ダウンサンプル設定に応じて、スクリーンショットがぼやけたり、ファイルサイズが非常に大きくなります。

私が欲しいもの：

WordとAcrobatにビットマップをそのままにしておき、ピクセルがそのままの状態でプロセスを実行できるようにしたいと思います。これは、ズームインすると元の画像のように見えます。

私が得るもの：

これは、同じ画像を挿入してズームインしたときのWord文書の外観です。これをPDFに印刷すると、これらの余分なピクセルはすべて非常に大きなファイルになります。

サンプルファイル：

• Test.png（56K）サンプルのスクリーンショット画像ファイル
• Test.docx（69K）この画像のみを含むWordファイル
• Test.PDF（9.4MB）Distillerを使用してWordファイルから印刷されたPDFファイル。すべてのダウンサンプリングがオフになっています。
• Test2.PDF（98K）Word 2010の「PDFとして保存」ツールを使用して生成されたPDFファイル（非常に低品質の圧縮画像に注意してください）

編集：これはWord 2010で使用されます-それを反映するようにタグを更新しました。

編集： OpenOfficeにはこの問題がないことを確認しました。Test.docx（上記参照）を開いて、それをOOからPDFとしてエクスポートし（オプションの[画像]で[ロスレス圧縮]を選択）、画像は無傷で表示されます。

• Test_OO.pdf

残念ながら、OpenOfficeは私が作成したより複雑なWord文書のフォーマットを変更します。そのため、Wordでドキュメントを作成し、OOを使用してPDFをレンダリングすることはできません。OOに完全に切り替える必要があります。これは、今すぐに準備するよりも大きなステップです。

Wordは、単にアップスケールされたイメージをレンダリングし、プリンター入力としてそのまま送信します（Distillerはプリンターとして機能していると思います）。その場合、通常のプリンターには適していますが、PDFファイルを生成する偽のプリンターには非効率的です。

たとえば、pdfLaTeXは出力ファイルに画像を適切に埋め込みます。min.usギャラリーにアップロードしたPDFを確認してください：LaTeX文書に画像を埋め込む

重要なのは、使用しているPDF生成スタックです。優れた無料のPDFCreatorのような他のPDFプリンターを試しても問題が解決しない場合は、専用のPDFエクスポートを使用する、つまりプリンターとして機能しないようにしてください。AFAIKの最近のWordバージョンにはPDFエクスポートが組み込まれているため、適切に実装されている場合、ドキュメントで使用されている画像を埋め込むことで小さなファイルを取得できます。

巨大な編集

ギャラリーは、LaTeX対WordでのPNG画像の埋め込みに名前が変更されました

私はmytest.pdfpdfLaTeXによって生成されたものと、test2.pdfWordによって生成されたものをより徹底的に調べました。

mytest.pdf test2.pdf

圧縮解除から始めましょう。圧縮されていないファイルを調べると、タグで終わる画像ストリームの先頭（、たとえば176x295 <<...>>streamと同じ、幅と高さのパラメータを持つ行）を簡単に見つけることができます。ピークタイム。test.pngendstream

（この時点での警告pdftkはバージョン1.41であると想定されています）

test2.pdf

$ pdftk test2.pdf output test2uc.pdf uncompress
$ sed '\,^<</Width 176[^>]*/Height 295[^>]*>>stream$,!d' test2uc.pdf
<</Width 176/BitsPerComponent 8/Interpolate true/Height 295/Filter[/DCTDecode]/Subtype/Image/Length 20003/ColorSpace/DeviceRGB/Type/XObject>>stream
$ sed '1,\,^<</Width 176[^>]*/Height 295[^>]*>>stream$,d;/^endstream$/,$d' test2uc.pdf > test2stream
$ xxd test2stream | head -10
0000000: ffd8 ffe0 0010 4a46 4946 0001 0101 0048  ......JFIF.....H
0000010: 0048 0000 ffe1 005c 4578 6966 0000 4d4d  .H.....\Exif..MM
0000020: 002a 0000 0008 0004 0302 0002 0000 0016  .*..............
0000030: 0000 003e 5110 0001 0000 0001 0100 0000  ...>Q...........
0000040: 5111 0004 0000 0001 0000 0b13 5112 0004  Q...........Q...
0000050: 0000 0001 0000 0b13 0000 0000 5068 6f74  ............Phot
0000060: 6f73 686f 7020 4943 4320 7072 6f66 696c  oshop ICC profil
0000070: 6500 ffe2 0c58 4943 435f 5052 4f46 494c  e....XICC_PROFIL
0000080: 4500 0101 0000 0c48 4c69 6e6f 0210 0000  E......HLino....
0000090: 6d6e 7472 5247 4220 5859 5a20 07ce 0002  mntrRGB XYZ ....
$ file test2stream 
test2stream: JPEG image data, JFIF standard 1.01

そのため、Wordは内部出力でPNGの代わりにJPEGを提供し、さらにPDFを処理しています。すごい！プリンターに出力を送信するときにも同じことが起こります。

test2stream.jpg

mytest.pdf

$ pdftk mytest.pdf output mytestuc.pdf uncompress
$ sed '\,^<</Width 176[^>]*/Height 295[^>]*>>stream$,!d' mytestuc.pdf
<</Width 176/BitsPerComponent 8/Height 295/Subtype/Image/Length 155760/ColorSpace/DeviceRGB/Type/XObject>>stream
$ sed '1,\,^<</Width 176[^>]*/Height 295[^>]*>>stream$,d;/^endstream$/,$d' mytestuc.pdf > myteststream
$ xxd myteststream | head -10
0000000: ebeb ebea eaea ecec eceb ebeb ebeb ebeb  ................
0000010: ebeb ebeb ebec ecec ebeb ebeb ebeb ebeb  ................
0000020: ebeb ebeb ebeb ebeb ebeb ebeb ebeb ebeb  ................
0000030: ebeb ebea eaea eaea eaec ecec eaea eaec  ................
0000040: ecec ebeb ebec ecec ebeb ebeb ebeb ebeb  ................
0000050: ebeb ebeb ebeb ebeb ebeb ebeb ebeb ebeb  ................
0000060: ebeb ebeb ebeb ebeb ebeb ebeb ebeb ebeb  ................
0000070: ebeb ebeb ebeb ebeb ebeb ebeb ebeb ebeb  ................
0000080: ebea eaea ecec eceb ebeb ebeb ebea eaea  ................
0000090: ebeb ebeb ebeb ebeb ebeb ebeb ebeb ebeb  ................
$ file myteststream 
myteststream: DOS executable (COM)

COMフ​​ァイルではありませんが、PNGでもありません。

$ du -b test.png test2stream myteststream 
57727   test.png
20004   test2stream
155761  myteststream

今見えますか？pdfLaTeXによって生成されたPDFからの（PNGの）画像ストリームは、おそらく単純な生の形式です（176 * 295 * 3 = 155760、1は余分な改行から来ています）。確認しましょう：

$ convert -depth 8 -size 176x295 rgb:myteststream myteststream.png

元の画像が戻ってきました！いいえ、待ってください。pdftk 1.41の圧縮解除にはバグがあり、画像にはいくつかの欠陥がほとんどありました。pdftk 1.44にアップグレードしましたが、このバージョンは画像ストリームをまったく解凍しません。さらに、pdftkはストリーム辞書を1行で出力しないため、上記のsedを使用した抽出は機能しませんが、修正する意味はありません。

では、Wordについてできることは何でしょうか。あまり気にしない。少なくとも、1つのPDFから別のPDFに埋め込み画像を移植できます。最近のpdftkを使用して両方のPDFの圧縮解除を繰り返し、それらをvimで開きtest2uc.pdf <<...>>stream...endstream、対応するものに置き換え、mytestuc.pdfとして保存しtest2fixuc.pdf、に圧縮しましたtest2fix.pdf。

test2fix.pdf

test.pdf

結局のところ、大きなPDFをチェックしないのは罪です。OK、pdftk 1.44の非圧縮PDFで再生する別のonelinerを用意し、ファイル内の画像ストリームとその開始行をリストしました。だから私は圧縮解除から始めますtest.pdf。

（この時点での警告pdftkはバージョン1.44であると想定されています）

$ pdftk test.pdf output testuc.pdf uncompress
$ awk '{if(i)h=h$0} /^[0-9]+ [0-9]+ obj $/{i=1;h=""}/^stream$/{i=0;if(h!~/\/Image/)next;print h,":"NR+1}' testuc.pdf 
<</ColorSpace /DeviceRGB/Subtype /Image/Length 10443804/Width 707/Type /XObject/BitsPerComponent 8/Height 4924>>stream :619
<</ColorSpace /DeviceRGB/Subtype /Image/Length 11264460/Width 953/Type /XObject/BitsPerComponent 8/Height 3940>>stream :12106
<</ColorSpace /DeviceRGB/Subtype /Image/Length 2813256/Width 953/Type /XObject/BitsPerComponent 8/Height 984>>stream :12910
<</ColorSpace /DeviceRGB/Subtype /Image/Length 11264460/Width 953/Type /XObject/BitsPerComponent 8/Height 3940>>stream :18547
<</ColorSpace /DeviceRGB/Subtype /Image/Length 2813256/Width 953/Type /XObject/BitsPerComponent 8/Height 984>>stream :19312
<</ColorSpace /DeviceRGB/Subtype /Image/Length 4845216/Width 328/Type /XObject/BitsPerComponent 8/Height 4924>>stream :19326

ここで何かが本当に異常です！43444452バイトを合わせた6つの未加工画像（明らかに今回はpdftkの解凍に問題はありませんでした）！test2uc.pdfとを再確認してみましょうmytestuc.pdf。

$ awk '{if(i)h=h$0} /^[0-9]+ [0-9]+ obj $/{i=1;h=""}/^stream$/{i=0;if(h!~/\/Image/)next;print h,":"NR+1}' test2uc.pdf 
<</Width 176/BitsPerComponent 8/Interpolate true/Height 295/Filter /DCTDecode/Subtype /Image/Length 20003/ColorSpace /DeviceRGB/Type /XObject>>stream :113
przemoc@debian:~/latex/test/img/mod$ awk '{if(i)h=h$0} /^[0-9]+ [0-9]+ obj $/{i=1;h=""}/^stream$/{i=0;if(h!~/\/Image/)next;print h,":"NR+1}' mytestuc.pdf 
<</DecodeParms <</Colors 3/Columns 176/Predictor 10/BitsPerComponent 8>>/Width 176/BitsPerComponent 8/Height 295/Filter /FlateDecode/Subtype /Image/Length 54954/ColorSpace /DeviceRGB/Type /XObject>>stream :22

どちらの場合も、画像ストリームは1つだけです。どうしてもっとたくさんあるのでしょうか？！

$ sed '1,618d;/^endstream $/q' testuc.pdf | convert -depth 8 -size 707x4924 rgb:- testuc-stream1.png
$ sed '1,12105d;/^endstream $/q' testuc.pdf | convert -depth 8 -size 953x3940 rgb:- testuc-stream2.png
$ sed '1,12909d;/^endstream $/q' testuc.pdf | convert -depth 8 -size 953x984 rgb:- testuc-stream3.png
$ sed '1,18546d;/^endstream $/q' testuc.pdf | convert -depth 8 -size 953x3940 rgb:- testuc-stream4.png
$ sed '1,19311d;/^endstream $/q' testuc.pdf | convert -depth 8 -size 953x984 rgb:- testuc-stream5.png
$ sed '1,19325d;/^endstream $/q' testuc.pdf | convert -depth 8 -size 328x4924 rgb:- testuc-stream6.png

画像は多くの部分にカットされました... Distillerによって導入された可能性のある、まったく馬鹿げた保護のように見えます（オフにすることもできます）。この信じられないほどの狂気を実行するのがWordでない限り、PDFCreatorによって同じことが吐き出されるとは思わない...

testuc-stream1.pngおよびその他（右矢印を使用してナビゲートします）

結論

重要なことは次のとおりです。

• はっきりとわかるように、断片に切り取られた巨大な画像は実際にはJPEGにアップスケールされているので、私の仮説は正しかったです。
• PDFCreatorでは出力で巨大なファイルも取得するため、偽のPDFプリンターに非常に大きな画像を提供するのはWordであり、私の以前の仮定も正しかったためです。

ふう。この調査には時間がかかりました。言葉はがらくたです。

回避策は？

その間、いくつかの提案が行われました。コメントさせてください。

LibreOffice（OpenOfficeを忘れて、今では廃止されています）のようなまともなPDFをサポートするライターを使用することは、いくつかの非互換性によって操作できない場合を除いて、優れたソリューションです。

ページ上の同じボックスに大きな画像を使用することも悪い考えではありません。JPEG化した後でも、アーティファクトが目立たなくなります。

私の別のgroszは、最初からJPEGを使用しています。そうすれば、Wordはそれを再圧縮すべきではなく（あなたは決して知らない...）、JPEGの最高品質を提供できます。ロスレスJPEG圧縮もあります。レドモンドの開発者はおそらく必要ないと考えていたので、WordがそのようなJPEGを処理しなくても驚かないでしょう。TBHは、算術コーディングと同様に（オープンソースの世界でさえ）広くサポートされていません（または算術コーディングの場合はさらに悪い状況です）。

convert test.png -quality 100 -resize $((100*300/72))% test-300dpi-mitchell.jpg
convert test.png -quality 100 -filter box -resize $((100*300/72))% test-300dpi-box.jpg
convert test.png -quality 100 test.jpg

（Windowsでは$(())、POSIXシェルで利用可能なこの算術展開の代わりに416を使用します）

デフォルトのMitchellはアップスケーリングに適していると思いますが、そのようなピクセル画像が本当に必要な場合は、@ cevingが示唆するようにBoxを使用してください。もちろん、最初の2つのファイルは、（何らかの理由で）偽のPDFプリンターを使用する必要がある場合にのみ役立ちます。

3つのファイルをすべてアップロードしました。

test-300dpi-mitchell.jpg（426 KB） test-300dpi-box.jpg（581 KB） test.jpg（74 KB）

私の仮説が正しく、WordがJPEG画像を再圧縮しない場合は、アップスケールされていない最後の画像を使用し、組み込みのPDF出力を使用します。

オープンファイル ]> [ 設定 ]> [ 高度その後で、画像サイズと画質のセクション、チェックオプションファイルでない圧縮画像（このオプションが配置されているでorientateに画面キャプチャを参照してください）

次の画像は、そのオプションをアクティブにする前と後に挿入された同じJPG画像（アンチエイリアスの違いを示すために400％に拡大されたドキュメントキャプチャ）です。

Microsoft Wordのズーム機能は双線形フィルタリングを使用しているようです。これは画像自体を変更するのではなく、100％以外の倍率での表示方法のみを変更する必要があります。必要なのは最近傍スケーリングですが、MS Wordにはそのためのオプションがあるとは思いません。

Test.pngをWord 2007のドキュメントに挿入する操作を繰り返しましたが、驚いたことに、結果は使用するメカニズムに依存していることがわかりました。

挿入/画像を使用する場合、画像は滑らかになります。
ただし、イメージエディタを入力してコピーしてからWordに貼り付けると、画像は滑らかになりません。

他の可能な回避策は次のとおりです。

1. ビットマップまたはデバイスに依存しないビットマップとして形式を選択して貼り付けてみてください。
2. 画像を貼り付けないでください。[挿入]タブ/ [イラスト]グループ/ [画像]コマンドを使用し、[挿入]ドロップダウンボタンを[ファイルへのリンク]に変更します。画像ファイルをWeb用に最適化して、スペースを節約できます。

元の画像を300dpiまたはPDFエクスポート中に使用する解像度にスケーリングするのがおそらく最も簡単なソリューションです。たとえば、ImageMagickの変換プログラムで実行できます。

元の画像の幅は176ピクセルです。300dpiで4インチにスケーリングする場合、ターゲットの幅は1200ピクセルです。これはそれを行います：

convert test.png -filter Box -resize 1200 test_300dpi.png

私は、マイクロソフト製品があなたにとって何が良いかを考えようとするのを防ぐことが常に良いことを経験しました。独自に決定することをお勧めします。

この質問はこれに似ています

これは、ラッピングスタイルに関係します...上下のみに設定します。こちらをご覧ください。

このコメントが明白すぎる、または関連性がない場合は修正してください：

たとえば、テキストのページ（.bmpおよび.pngをテストしました）の鮮明な画像をWord 2010文書（.docx）に貼り付けると、元の画像がぼやけて表示されます。これは、「オプション」の関連設定に関係なく、自動サイズ変更とWordによる画像処理によるものです。しかし、私がその後

1. 画像を選択
2. リボンのヘッダー「フォーマット」に移動します
3. 「元に戻す」矢印の付いた小さな画像のように見えるリボンの左端の領域にある小さなアイコンを選択します
4. 関連するメニューをプルダウンします
5. 「画像とサイズを元に戻す」という下の項目を選択します（これはドイツ語からの緩やかな翻訳でした）。

その後、ぼかした画像の代わりに、貼り付けた鮮明な画像が再び表示されます。

注：Acrobat Readerの組み込みの写真ツールを使用して、直接Wordに貼り付けると、上記は機能しません。画面全体のスクリーンショットを撮るか、IrfanViewを使用する必要があります。