Мешать Microsoft Word 2010 сглаживать снимки экрана?
Когда я вставляю снимки экрана JPEG в Microsoft Word, он приглаживает их вместо того, чтобы сохранить исходные пиксели от битового массива. Когда я затем печатаю к PDF (использующий Acrobat Distiller), в зависимости от моего субдискретизировать настройки, я или получаю расплывчатые снимки экрана или чрезвычайно чрезмерно увеличенные в размере размеры файла.
Что я хочу:
Я хотел бы, чтобы Word и Acrobat оставили битовые массивы в покое так, чтобы они сделали его посредством процесса с их пикселями неповрежденным. Это - то, на что похоже исходное изображение, когда Вы увеличиваете масштаб:
Что я получаю:
Это - то, на что похож документ Word, когда Вы вставляете то же изображение и увеличиваете масштаб. Когда это печатается к PDF, все те дополнительные пиксели результат в намного большем файле.
Файлы примера:
- Test.png (56K) демонстрационный файл изображения снимка экрана
- Test.docx (69K) файл Word, содержащий только это изображение
- Test.PDF (9.4 МБ) файл PDF, распечатанный от Производителя алкогольной продукции использования файла Word, со всей выключенной субдискретизацией
- Test2.PDF (98K) файл PDF, сгенерированный с помощью инструмента "Save as PDF" 2010-х Word (отмечают очень низкое качество сжатого изображения),
Править: Это с Word 2010 - я обновил теги для отражения этого.
Править: Я подтвердил, что OpenOffice не имеет этой проблемы. Я открыл Test.docx (ссылаемый выше) и экспортировал его как PDF от OO (выбирающий "сжатие без потерь" под Изображениями в опциях), и изображение проникает целый.
К сожалению, OpenOffice искажает форматирование на документах более составного слова, которые я создал; таким образом, я не могу только создать документы в Word и использовать OO для рендеринга PDFs; я должен был бы переключиться на OO в целом, которое является большим шагом, чем я готов взять прямо сейчас.
1 ответ
Word, возможно, просто представляет увеличенное масштаб изображение и отправляет ему тот путь как вход принтера (я предполагаю, что Производитель алкогольной продукции работает принтером). Если так, затем это хорошо для нормальных принтеров, но неэффективно для поддельных принтеров, производящих файлы PDF.
Например, pdfLaTeX правильно встраивает изображение в выходной файл. Проверьте мой PDF, загруженный на min.us галерею: Встраивание изображения в ЛАТЕКСНОМ документе
Важная вещь - то, какую стопку создания PDF Вы используете. Если попытка другого принтера PDF, как большой и свободный PDFCreator, не решает проблему, затем необходимо попытаться использовать, выделил экспорт PDF, т.е. не работать принтером. AFAIK недавние версии Word имеют встроенный экспорт PDF, поэтому если он правильно реализован, затем Вы получите маленький файл благодаря встраиванию изображений, используемых в документе.
ОГРОМНОЕ РЕДАКТИРОВАНИЕ
Галерея была переименована к Встраиванию изображения PNG в ЛАТЕКСЕ по сравнению с Word
Я посмотрел более тщательно на мой mytest.pdf сгенерированный pdfLaTeX и Вашим test2.pdf сгенерированный Word.
Давайте запустимся с распаковки. При изучении несжатого файла Вы легко определите начало потока изображения (<<...>>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 дает JPEG вместо PNG на его внутреннем выводе для дальнейшей обработки PDF. Просто WOW! То же самое может произойти когда вывод отправки с принтером.
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, является возможно простым форматом .raw (176*295*3=155760, 1 прибывает из лишней новой строки). Давайте проверим его:
$ convert -depth 8 -size 176x295 rgb:myteststream myteststream.png
И у нас есть наше исходное изображение назад! Нет, ожидайте. Выглядит, что несжатие pdftk 1.41 является багги, и изображение было почти тем же с несколькими дефектами. Я обновил до pdftk 1.44, но эта версия не распаковывает поток изображения вообще. Кроме того, pdftk не производит потоковый словарь в одной строке, таким образом, выше извлечения с помощью sed больше не работает, но нет никакого смысла в фиксации его теперь.
Таким образом, что мы можем сделать о Word? Не очень, мне кажется. По крайней мере, можно пересадить встроенное изображение от одного PDF до другого. Я повторил несжатие обоих PDFs использование недавнего pdftk, открыл их в энергии, замененной в test2uc.pdf <<...>>stream...endstream с дубликатом от mytestuc.pdf, сохраненный как test2fixuc.pdf и сжатый до test2fix.pdf.
test.pdf
Это был бы грех, не проверяющий Ваш большой PDF, в конце концов. Хорошо, я подготовился, другая острота для проигрывания с pdftk 1.44 распаковала PDFs для списка потоков изображения и их строк начала в файлах. Таким образом, я запущу с распаковки 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 не имел никаких проблем в распаковке их), берущий вместе 43 444 452 байта! Давайте перепроверим 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
В обоих случаях только один поток изображения. Почему heck там мог быть больше из них?!
$ 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
Изображение было сокращено ко многим частям... Это похоже на некоторую совершенно глупую защиту, возможно, представленную Производителем алкогольной продукции (и возможно это может быть выключено)? Я сомневаюсь, что тому же самому досадил бы PDFCreator, если это не Word, кто выполняет это невероятное безумие...
testuc-stream1.png и другие (используют стрелку вправо для навигации),
Заключение
Важные вещи:
- можно ясно видеть, что огромным изображением, которое было разрезано на куски, является на самом деле увеличенный масштаб JPEG, таким образом, моя гипотеза была корректна,
- потому что в PDFCreator Вы получаете также огромный файл в выводе, это - Word, кто предоставляет ужасно большое изображение поддельному принтеру PDF, и моя более ранняя гипотеза была также корректна.
Уф. Это расследование заняло время. Word является частью спама.
Обходные решения?
Тем временем некоторые предложения были даны. Позвольте мне прокомментировать их.
Используя устройство записи с достойной поддержкой PDF как LibreOffice (забывают о OpenOffice, это - obsoleted теперь), хорошее решение, если некоторые incompabilities не делают Вас не могущими работать с ним.
Используя большее изображение в том же поле на странице также не, что плохая идея, потому что даже после JPEG-izing, артефакты будут менее видимы.
Мой другой грош, хотя использует JPEG с начала. Тем путем Word не должен повторно сжимать его (Вы никогда не знаете...), и можно обеспечить максимально возможное качество JPEG. Существует также сжатие JPEG без потерь. Разработчики из Редмонда, по-видимому, думали, что это не нужно, таким образом, я не буду удивлен, не обрабатывает ли Word такой JPEGs. Ну, 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 является хорошим для увелечения масштаба, но если Вы действительно хотите такое изображение pixelatic, затем идет с Полем как @ceving предложенный. Конечно, сначала 2 файла полезны, только если необходимо (по некоторым причинам) использовать поддельные принтеры PDF.
Я загрузил все три файла.
test-300dpi-mitchell.jpg (426 КБ) test-300dpi-box.jpg (581 КБ) test.jpg (74 КБ)
Если моя гипотеза является правильной, и Word не повторно сожмет изображение JPEG, то просто используют последний, не увеличенный масштаб, и идут со встроенным выводом PDF, потому что это имеет меньше недостатков (по крайней мере, это избегает бесполезный высококлассный).
Откройте File> Settings> Advanced, затем в разделе Размера изображения и качества, проверьте, что опция Do не сжимает изображения в файлах (См. снимок экрана для ориентирования, где эта опция расположена),
Следующее изображение является тем же изображением JPG (получение документа 400%, увеличенных, чтобы показать сглаживающееся различие) вставленный прежде и после активации что опция:
Похоже, что функция масштабирования Microsoft Word использует билинейную фильтрацию. Это не должно изменять само изображение, но только как оно отображено при увеличениях кроме 100%. То, что Вы хотите, является ближайшим соседним масштабированием, но я сомневаюсь, что MS Word имеет опцию для этого.
Я повторил управление вставкой Test.png в документ в Word 2007 и нашел к моему удивлению, что результат зависит от механизма, который каждый использует.
Если Вы используете, Вставляют / Изображение затем, изображение сглаживается.
Но если Вы вводите редактор изображений и действительно копируете, то вставляете в Word, то изображение не сглаживается.
Другие возможные обходные решения:
- Попытайтесь использовать Вставку, Особенную в качестве Растрового или Независимого от устройств битового массива.
- Не вставляйте изображения. Используйте вкладку Inset / группа Иллюстраций / команда Picture и измените "Вставку" выпадающая кнопка для "Соединения с файлом". Файл изображения может быть оптимизирован, чтобы сеть заняла меньше места.
Это - вероятно, самое самое легкое решение масштабировать исходные изображения к 300 точкам на дюйм или безотносительно разрешения, которое Вы используете во время своего экспорта PDF. Программа преобразования ImageMagick может сделать это, например.
Исходное изображение имеет ширину 176 пикселей. Если Вы хотите масштабировать его к 4 дюймам на уровне 300 точек на дюйм, целевая ширина составляет 1 200 пикселей. Это сделает это:
convert test.png -filter Box -resize 1200 test_300dpi.png
Я испытал это, всегда лучше препятствовать тому, чтобы продукты Microsoft пытались думать, что могло бы быть хорошо для Вас. Всегда лучше решить это самостоятельно.