阻止 Microsoft Word 2010 平滑屏幕截图？

Question

当我将 JPEG 屏幕截图插入 Microsoft Word 时，它会平滑它们而不是保留位图中的原始像素。当我打印到 PDF（使用 Acrobat Distiller）时，根据我的下采样设置，我要么得到模糊的屏幕截图，要么得到非常臃肿的文件大小。

我想要的是：

我希望 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（在选项中的图像下选择“无损压缩”），图像完好无损。

• 测试_OO.pdf

不幸的是，OpenOffice 破坏了我创建的更复杂的 Word 文档的格式；所以我不能只在 Word 中创建文档并使用 OO 来呈现 PDF；我必须完全切换到 OO，这比我现在准备采取的步骤要大得多。

Answer 1

Word 可能只是呈现放大的图像并将其作为打印机输入发送（我假设 Distiller 用作打印机）。如果是这样，那么它对普通打印机有好处，但对于生成 PDF 文件的假打印机效率低下。

例如 pdfLaTeX 在输出文件中正确嵌入图像。检查我上传到 min.us 画廊的 PDF：在 LaTeX 文档中嵌入图像

重要的是您正在使用的 PDF 生成堆栈。如果尝试其他 PDF 打印机，如免费的PDFCreator，不能解决问题，那么您应该尝试使用专用的 PDF 导出，即不作为打印机工作。AFAIK 最近的 Word 版本内置了 PDF 导出，因此如果正确实施，那么由于在文档中使用了嵌入图像，您将获得小文件。

大编辑

图库已重命名为在 LaTeX 与 Word 中嵌入 PNG 图像

我已经更彻底地查看了mytest.pdf由 pdfLaTeX 生成的和test2.pdf由 Word 生成的。

mytest.pdf test2.pdf

让我们从解压缩开始。如果您查看未压缩的文件，您会很容易发现图像流的开头（<<...>>stream具有 Width 和 Height 参数的行，与 中的相同test.png，即 176x295），以endstream标记结尾。偷看时间。

（此时警告 pdftk 假定为 1.41 版）

测试2.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 在其内部输出中提供 JPEG 而不是 PNG，以进行进一步的 PDF 处理。哇！将输出发送到打印机时可能会发生同样的事情。

测试流.jpg

我的测试.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 不会在一行中输出流字典，因此上面使用 sed 的提取不再有效，但现在修复它没有意义。

那么我们可以对 Word 做些什么呢？没有太多的想法。至少您可以将嵌入的图像从一个 PDF 移植到另一个。我重复使用的pdftk最近两个PDF文件的解压缩，在vim打开他们，代替test2uc.pdf <<...>>stream...endstream来自对口mytestuc.pdf，保存test2fixuc.pdf和压缩test2fix.pdf。

test2fix.pdf

测试.pdf

毕竟不检查你的大 PDF 是一种罪过。好的，我准备了另一个 oneliner 来使用 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

在这两种情况下，只有一个图像流。为什么会有更多的人？！

$ 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 引入的（也许它可以关闭）？我怀疑 PDFCreator 会吐出同样的东西，除非是 Word 执行了这种令人难以置信的疯狂……

testuc-stream1.png 等（使用右箭头导航）

结论

重要的事情是：

• 你可以清楚地看到，那个被切割成碎片的巨大图像实际上是放大的JPEG，所以我的假设是正确的，
• 因为在 PDFCreator 中，您还会在输出中获得巨大的文件，是 Word 为假 PDF 打印机提供了非常大的图像，我之前的假设也是正确的。

呼。这项调查花了一些时间。词是一块垃圾。

解决方法？

同时也提出了一些建议。让我评论他们。

使用像LibreOffice这样的具有良好 PDF 支持的 writer （忘记 OpenOffice，它现在已经过时）是一个很好的解决方案，除非某些不兼容使您无法使用它。

在页面上的同一个框中使用更大的图像也不是什么坏主意，因为即使在 JPEG 化之后，伪像也不会那么明显。

我的另一个 grosz 从一开始就使用 JPEG。这样 Word 不应该重新压缩它（你永远不知道......）并且你可以提供最高质量的 JPEG。还有无损JPEG压缩。Redmond 的开发人员大概认为不需要它，所以如果 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 shell 中可用的这种算术扩展）

我认为默认的 Mitchell 很适合放大，但如果你真的想要这样的像素图像，那么按照@ceving 的建议使用 Box。当然，只有在您必须（出于某种原因）使用假 PDF 打印机时，前 2 个文件才有用。

我已经上传了所有三个文件。

测试-300dpi的-mitchell.jpg（426 KB） 测试-300dpi的-box.jpg（581 KB） test.jpg放在（74 KB）

如果我的假设是正确的并且 Word 不会重新压缩 JPEG 图像，那么只需使用最后一个未放大的图像并使用内置的 PDF 输出，因为它的缺点较少（至少避免了不必要的放大）。

Answer 2

打开File > Settings > Advanced，然后在Image size and quality部分，选中Do not compress image in files（请参阅屏幕截图以定位此选项的位置）

下图是在激活该选项之前和之后插入的相同 JPG 图像（文档捕获放大 400% 以显示抗锯齿差异）：