Word는 업 스케일 된 이미지를 렌더링하여 프린터 입력으로 전송합니다 (Distiller가 프린터로 작동한다고 가정합니다). 그렇다면 일반 프린터에는 좋지만 PDF 파일을 생성하는 가짜 프린터에는 비효율적입니다.
예를 들어 pdfLaTeX는 출력 파일에 이미지를 올바르게 포함시킵니다. Minus 갤러리에 업로드 한 PDF 확인 : LaTeX 문서에 이미지 임베드
중요한 것은 사용중인 PDF 생성 스택입니다. 훌륭하고 무료 인 PDFCreator 와 같은 다른 PDF 프린터 를 사용해도 문제가 해결되지 않으면 전용 PDF 내보내기를 사용하십시오 (예 : 프린터로 작동하지 않음). AFAIK 최신 Word 버전에는 PDF 내보내기 기능이 내장되어 있으므로 올바르게 구현하면 문서에 사용 된 이미지가 포함되어있어 작은 파일을 얻게됩니다.
거대한 편집
갤러리가 LaTeX vs Word에서 PNG 이미지 포함 으로 이름이 변경되었습니다.
나는 mytest.pdfpdfLaTeX에 의해 생성 된 것과 test2.pdfWord에 의해 생성 된 것을 더 자세히 살펴 보았습니다 .
mytest.pdf
test2.pdf
압축 해제부터 시작하겠습니다. 압축되지 않은 파일을 살펴보면 이미지 스트림의 시작 부분 ( 예 : 176x295 <<...>>stream와 같은 너비 및 높이 매개 변수가있는 줄)을 쉽게 찾아 태그로 test.png끝납니다 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 대신 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)은 단순한 원시 형식 일 수 있습니다 (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를 사용하여 두 PDF의 압축 해제를 반복하고 vim에서 열어서 test2uc.pdf <<...>>stream...endstream으로 대응하고 mytestuc.pdf로 저장 test2fixuc.pdf하고에 압축했습니다 test2fix.pdf.
test2fix.pdf
test.pdf
결국 큰 PDF를 확인하지 않으면 죄가 될 것입니다. 좋아, 이미지 스트림과 파일의 시작 줄을 나열하기 위해 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
뭔가 정말 미쳤어! 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가 도입 한 완전히 어리석은 보호처럼 보입니까 (아마도 끌 수 있음)? 이 믿을 수없는 광기를 수행하는 Word가 아니라면 PDFCreator도 같은 일을 할 것입니다.
testuc-stream1.png 및 기타 (오른쪽 화살표를 사용하여 탐색)
결론
중요한 것은 :
- 조각으로 자른 거대한 이미지는 실제로 JPEG 크기가 높아져서 내 가설이 정확하다는 것을 분명히 알 수 있습니다.
- PDFCreator에서 출력물에 큰 파일을 가져 오기 때문에 가짜 PDF 프린터에 굉장히 큰 이미지를 제공하는 것이 Word이며 이전의 가정도 정확했습니다.
휴 이 조사에는 시간이 걸렸습니다. 단어는 쓰레기입니다.
해결 방법?
그동안 몇 가지 제안이있었습니다. 댓글을 달겠습니다.
일부 비 호환성으로 인해 작업 할 수없는 경우를 제외하고 LibreOffice 와 같은 적절한 PDF 지원 기능을 갖춘 라이터 (OpenOffice를 잊어 버렸습니다)는 사용하는 것이 좋습니다.
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 프린터를 사용해야하는 경우에만 유용합니다.
세 파일을 모두 업로드했습니다.
test-300dpi-mitchell.jpg (426 KB)
test-300dpi-box.jpg (581 KB)
test.jpg (74 KB)
내 가설이 옳고 Word에서 JPEG 이미지를 다시 압축하지 않으면 마지막으로 업 스케일되지 않은 이미지를 사용하고 단점이 적기 때문에 내장 된 PDF 출력을 사용하십시오 (적어도 불필요한 업 스케일을 피함).
