Word có thể chỉ hiển thị hình ảnh được nâng cấp và gửi nó theo cách đó như là đầu vào máy in (tôi cho rằng Distiller hoạt động như một máy in). Nếu vậy, nó tốt cho máy in bình thường, nhưng không hiệu quả đối với máy in giả tạo tệp PDF.
Ví dụ pdfLaTeX nhúng hình ảnh đúng vào tệp đầu ra. Kiểm tra tệp PDF của tôi được tải lên thư viện min.us: Nhúng hình ảnh vào tài liệu LaTeX
Điều quan trọng là những gì PDF sản xuất ngăn xếp bạn đang sử dụng. Nếu thử máy in PDF khác, như PDFCreator tuyệt vời và miễn phí , không khắc phục được sự cố, thì bạn nên thử sử dụng xuất PDF chuyên dụng, tức là không hoạt động như một máy in. Các phiên bản Word gần đây của AFAIK có tích hợp xuất PDF, vì vậy nếu nó được triển khai đúng cách, thì bạn sẽ có được tệp nhỏ, nhờ nhúng hình ảnh được sử dụng trong tài liệu.
EDIT LỚN
Thư viện đã được đổi tên thành Nhúng hình ảnh PNG trong LaTeX vs Word
Tôi đã xem xét kỹ hơn về phần mytest.pdfđược tạo bởi pdfLaTeX và phần test2.pdfđược tạo bởi Word.
mytest.pdf
test2.pdf
Hãy bắt đầu với việc giải nén. Nếu bạn xem tập tin không nén, bạn sẽ dễ dàng phát hiện bắt đầu luồng hình ảnh ( <<...>>streamdòng có tham số Chiều rộng và Chiều cao, giống như trong test.png, tức là 176x295), kết thúc bằng endstreamthẻ. Thời gian trôi qua.
(CẢNH BÁO tại thời điểm này pdftk được giả sử là trong phiên bản 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
Vì vậy, Word đang cung cấp JPEG thay vì PNG trên đầu ra bên trong của nó để xử lý PDF tiếp theo. Chỉ là WOW! Điều tương tự có thể xảy ra khi gửi đầu ra cho máy in.
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)
Nó không phải là tệp COM, nhưng nó cũng không phải là PNG.
$ du -b test.png test2stream myteststream
57727 test.png
20004 test2stream
155761 myteststream
Bạn thấy nó bây giờ? Luồng hình ảnh (của PNG) từ PDF được tạo bởi pdfLaTeX có thể là định dạng thô đơn giản (176 * 295 * 3 = 155760, 1 đến từ dòng mới không cần thiết). Hãy kiểm tra xem:
$ convert -depth 8 -size 176x295 rgb:myteststream myteststream.png
Và chúng tôi có hình ảnh ban đầu của chúng tôi trở lại! Không chờ đợi. Có vẻ như pdftk 1.41 giải nén là lỗi và hình ảnh gần như giống nhau với một vài sai sót. Tôi đã nâng cấp lên pdftk 1.44, nhưng phiên bản này hoàn toàn không giải nén luồng hình ảnh. Hơn nữa, pdftk không xuất từ điển luồng trong một dòng, do đó, trích xuất trên sử dụng sed không còn hoạt động nữa, nhưng không có điểm nào để sửa nó ngay bây giờ.
Vậy chúng ta có thể làm gì về Word? Không nhiều methinks. Ít nhất bạn có thể ghép hình ảnh nhúng từ PDF này sang PDF khác. Tôi đã lặp lại việc giải nén cả hai tệp PDF bằng pdftk gần đây, mở chúng trong vim, thay thế test2uc.pdf <<...>>stream...endstreambằng bản sao từ mytestuc.pdf, lưu dưới dạng test2fixuc.pdfvà nén vào test2fix.pdf.
test2fix.pdf
test.pdf
Rốt cuộc sẽ là một tội lỗi nếu không kiểm tra PDF lớn của bạn. Ok, tôi đã chuẩn bị một oneliner khác để chơi với pdftk 1,44 tệp PDF không nén để liệt kê các luồng hình ảnh và dòng bắt đầu của chúng trong các tệp. Vì vậy, tôi sẽ bắt đầu với việc giải nén test.pdf.
(CẢNH BÁO tại thời điểm này pdftk được giả sử là trong phiên bản 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
Một cái gì đó thực sự điên rồ ở đây! 6 hình ảnh thô (rõ ràng lần này pdftk không có bất kỳ vấn đề nào trong việc giải nén chúng) kết hợp lại 43444452 byte! Hãy kiểm tra lại test2uc.pdfvà 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
Trong cả hai trường hợp chỉ có một luồng hình ảnh. Tại sao cái quái đó có thể có nhiều hơn trong số họ?!
$ 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
Hình ảnh bị cắt thành nhiều mảnh ... Có vẻ như một loại bảo vệ hoàn toàn ngu ngốc, có thể được giới thiệu bởi Distiller (và có thể nó có thể bị tắt)? Tôi nghi ngờ điều tương tự sẽ được PDFCreator nhổ ra, trừ khi đó là Word, người thực hiện sự điên rồ khó tin này ...
testuc-stream1.png và những người khác (sử dụng mũi tên phải để điều hướng)
Phần kết luận
Những điều quan trọng là:
- bạn có thể thấy rõ, hình ảnh khổng lồ bị cắt thành từng mảnh thực sự được nâng cấp JPEG, vì vậy giả thuyết của tôi là chính xác,
- bởi vì trong PDFCreator bạn cũng nhận được tệp khổng lồ trong đầu ra, đó là Word cung cấp hình ảnh cực kỳ lớn cho máy in PDF giả và giả định trước đây của tôi cũng đúng.
Phù. Cuộc điều tra này mất một thời gian. Lời là một mảnh rác.
Cách giải quyết?
Trong khi đó, một số gợi ý đã được đưa ra. Hãy để tôi nhận xét họ.
Sử dụng trình soạn thảo với sự hỗ trợ PDF tốt như LibreOffice (quên đi OpenOffice, giờ nó đã lỗi thời) là giải pháp tốt, trừ khi một số điều không thể làm cho bạn không thể làm việc với nó.
Sử dụng hình ảnh lớn hơn trong cùng một hộp trên trang cũng không phải là ý tưởng tồi, bởi vì ngay cả sau khi JPEG-izing, các tạo tác sẽ ít nhìn thấy hơn.
Một grosz khác của tôi mặc dù đang sử dụng JPEG từ đầu. Bằng cách đó, Word không nên giải nén nó (bạn không bao giờ biết ...) và bạn có thể cung cấp chất lượng JPEG cao nhất có thể. Ngoài ra còn có nén JPEG lossless. Các nhà phát triển từ Redmond có lẽ nghĩ rằng nó không cần thiết, vì vậy tôi sẽ không ngạc nhiên nếu Word không xử lý các JPEG như vậy. Chà, TBH nó không được hỗ trợ rộng rãi (ngay cả trong thế giới nguồn mở), giống như mã hóa số học (hoặc tình huống thậm chí còn tồi tệ hơn trong trường hợp mã hóa số học).
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
(Trong Windows, sử dụng 416 thay vì $(())mở rộng số học này có sẵn trong hệ vỏ POSIX)
Tôi nghĩ rằng mặc định Mitchell là một công cụ tốt để nâng cấp, nhưng nếu bạn thực sự muốn hình ảnh pixel như vậy, thì hãy đi với Box như @ceving đề xuất. Tất nhiên 2 tệp đầu tiên chỉ hữu ích nếu bạn phải (vì một số lý do) sử dụng máy in PDF giả.
Tôi đã tải lên cả ba tập tin.
test-300dpi-mitchell.jpg (426 KB)
test-300dpi-box.jpg (581 KB)
test.jpg (74 KB)
Nếu giả thuyết của tôi là đúng và Word sẽ không giải nén hình ảnh JPEG, thì chỉ cần sử dụng cái cuối cùng không được nâng cấp và đi với đầu ra PDF tích hợp, vì nó ít bị thiếu (ít nhất là nó tránh được việc nâng cấp không cần thiết).
