Microsoft Word 2010がスクリーンショットをスムージングしないようにしますか？

Question

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

私が欲しいもの：

WordとAcrobatでビットマップをそのままにして、ピクセルをそのままにしてプロセスを完了するようにしたい。ズームインすると、元の画像は次のようになります。

What I want

私が得るもの：

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

What I get

サンプルファイル：

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

編集：これはWord2010の場合です-それを反映するようにタグを更新しました。

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

Test_OO.pdf

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

przemoc · Accepted Answer

Wordは、アップスケールされた画像をレンダリングし、それをプリンター入力として送信するだけかもしれません（Distillerはプリンターとして機能すると思います）。もしそうなら、それは通常のプリンターには良いですが、PDFファイルを生成する偽のプリンターには非効率的です。

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

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

巨大な編集

ギャラリーの名前が LaTeX vs WordにPNG画像を埋め込むに変更されました

私はpdfLaTeXによって生成された私のmytest.pdfとWordによって生成されたあなたのtest2.pdfをより徹底的に調べました。

mytest.pdf test2.pdf

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

（この時点での警告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はさらにPDF処理するために、内部出力でPNGではなくJPEGを提供しています。すごい！プリンタに出力を送信するときにも同じことが起こる可能性があります。

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の）画像ストリームは、おそらく単純なraw形式です（176 * 295 * 3 = 155760、1は余分な改行から来ています）。それを確認しましょう：

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

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

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

test2fix.pdf

test.pdf

結局のところ、あなたの大きなPDFをチェックしないのは罪でしょう。さて、私はpdftk 1.44非圧縮PDFで再生してファイル内の画像ストリームとその先頭行を一覧表示する別のワンライナーを用意しました。それで、私は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

何かが本当に狂ってる！ 6つの生の画像（今回はpdftkで圧縮解除に問題がなかったようです）で43444452バイトを取りました！ 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化した後でも、アーティファクトが目立たなくなるためです。

私のもう1つのグロスは、最初から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では、この$(())の代わりに416を使用してください。POSIXシェルで使用できる算術展開）

デフォルトの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出力を使用してください。。

Francisco Alvarado · Answer

ファイル> 設定> 詳細を開き、画像のサイズと品質セクションで、オプションをチェックします実行ファイル内の画像を圧縮しない（このオプションがどこにあるかを示すためにスクリーンキャプチャを参照してください）
Word settings

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

trough · Answer

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

ceving · Answer

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

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

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

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

harrymc · Answer

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

Insert/Pictureを使用すると、画像が滑らかになります。
しかし、画像エディタに入ってコピーしてからWordに貼り付けると、画像は滑らかになりません。

その他の考えられる回避策は次のとおりです。

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