Возможно, Word просто отображает увеличенное изображение и отправляет его таким образом, как принтер (я предполагаю, что Distiller работает как принтер). Если так, то это хорошо для обычных принтеров, но неэффективно для поддельных принтеров, производящих файлы PDF.
Например, pdfLaTeX правильно встраивает изображение в выходной файл. Проверьте мой PDF, загруженный в галерею min.us: Вставка изображения в документ LaTeX
Важно то, какой PDF-файл вы используете. Если попытка использовать другой принтер PDF, например отличный и бесплатный PDFCreator, не решит проблему, то вам следует попробовать использовать специальный экспорт PDF, т.е. не работать в качестве принтера. AFAIK последние версии Word имеют встроенный экспорт PDF, поэтому, если он будет правильно реализован, вы получите небольшой файл, благодаря встраиванию изображений, используемых в документе.
ОГРОМНОЕ РЕДАКТИРОВАНИЕ
Галерея была переименована для встраивания изображения PNG в LaTeX vs Word
Я более внимательно посмотрел на мой mytest.pdf сгенерированный pdfLaTeX, и ваш test2.pdf сгенерированный Word.
mytest.pdf test2.pdf
Начнем с распаковки. Если вы посмотрите в несжатый файл, вы легко заметите начало потока изображения (<<...>>stream строка потока с параметрами Width и Height, такая же, как в 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 предоставляет JPEG вместо PNG на своем внутреннем выходе для дальнейшей обработки 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
Вы видите это сейчас? Поток изображения (в формате PNG) из PDF, созданный pdfLaTeX, возможно, является простым необработанным форматом (176 * 295 * 3 = 155760, 1 происходит из-за лишнего перевода строки). Давайте проверим это:
$ convert -depth 8 -size 176x295 rgb:myteststream myteststream.png
И мы вернули наше оригинальное изображение! Нет, подождите. Похоже, что распаковка pdftk 1.41 глючит, и изображение было почти таким же, с некоторыми недостатками. Я обновил до pdftk 1.44, но эта версия не распаковывает поток изображений вообще. Более того, pdftk не выводит потоковый словарь в одну строку, поэтому вышеизложенное извлечение с использованием sed больше не работает, но исправлять его сейчас нет смысла.
Так что мы можем сделать с Word? Не много метинкс. По крайней мере, вы можете перенести встроенное изображение из одного PDF в другой. Я повторил распаковку обоих PDF-файлов, используя последние pdftk, открыл их в vim, заменил в test2uc.pdf <<...>>stream...endstream на аналог из mytestuc.pdf , сохранил как test2fixuc.pdf и сжал в test2fix.pdf ,
test2fix.pdf
test.pdf
Было бы грехом не проверять ваш большой PDF в конце концов. Хорошо, я подготовил еще один oneliner для воспроизведения с несжатыми PDF-файлами pdftk 1.44, чтобы перечислить потоки изображений и их начальные строки в файлах. Поэтому я начну с распаковки 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-принтер, и мое предыдущее предположение также было верным.
Уф. Это расследование заняло некоторое время. Слово это кусок мусора.
Обходные?
Тем временем были даны некоторые предложения. Позвольте мне прокомментировать их.
Использование Writer с приличной поддержкой PDF, такой как LibreOffice (забудьте об OpenOffice, теперь он устарел) - хорошее решение, если только некоторые несовместимости не делают вас неспособными работать с ним.
Использование большего изображения в том же окне на странице также не является плохой идеей, потому что даже после JPEG-изображения артефакты будут менее заметны.
Мой другой гросс, хотя использует 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 по умолчанию хорош для апскейлинга, но если вы действительно хотите такое пиксельное изображение, тогда используйте Box, как предложено @ceving. Конечно, первые 2 файла полезны, только если вы (по какой-то причине) должны использовать поддельные принтеры PDF.
Я загрузил все три файла.
test-300dpi-mitchell.jpg (426 КБ)test-300dpi-box.jpg (581 КБ)test.jpg (74 КБ)
Если моя гипотеза верна и Word не будет повторно сжимать изображение JPEG, тогда просто используйте последнее, не масштабированное, и используйте встроенный вывод PDF, потому что у него меньше недостатков (по крайней мере, он избегает ненужного увеличения).
