Word อาจจะแสดงภาพที่อัปสเกลแล้วส่งแบบนั้นเมื่ออินพุตของเครื่องพิมพ์ (ฉันคิดว่า Distiller จะทำงานเป็นเครื่องพิมพ์) ถ้าเป็นเช่นนั้นก็ดีสำหรับเครื่องพิมพ์ปกติ แต่ไม่มีประสิทธิภาพสำหรับเครื่องพิมพ์ปลอมที่สร้างไฟล์ PDF
ตัวอย่างเช่น pdfLaTeX ฝังรูปภาพในไฟล์เอาต์พุตอย่างถูกต้อง ตรวจสอบ PDF ของฉันที่อัปโหลดไปยังแกลเลอรี่ min.us: การฝังภาพในเอกสาร LaTeX
สิ่งสำคัญคือ PDF ที่สร้างสแต็กที่คุณใช้อยู่ หากลองใช้เครื่องพิมพ์ PDF อื่น ๆ เช่นดีและฟรี PDFCreatorไม่สามารถแก้ไขปัญหาได้คุณควรลองใช้การส่งออก PDF เฉพาะนั่นคือไม่ได้ทำงานเป็นเครื่องพิมพ์ AFAIK เวอร์ชัน Word ล่าสุดมีการส่งออก PDF ในตัวดังนั้นหากมีการใช้งานอย่างถูกต้องคุณจะได้รับไฟล์ขนาดเล็กด้วยการฝังภาพที่ใช้ในเอกสาร
แก้ไขอย่างมาก
แกลเลอรีถูกเปลี่ยนชื่อเป็น รูปภาพ PNG ใน LaTeX เทียบกับ Word
ฉันดูรายละเอียดทั้งหมดที่mytest.pdfสร้างขึ้นโดย pdfLaTeX และของคุณtest2.pdfสร้างขึ้นโดย Word
mytest.pdf
test2.pdf
เริ่มจากการคลายการบีบอัดกันเถอะ หากคุณดูเป็นไฟล์ที่ไม่มีการบีบอัดคุณจะเห็นจุดเริ่มต้นของสตรีมรูปภาพได้อย่างง่ายดาย ( <<...>>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 เพิ่มเติม แค่ว้าว! สิ่งเดียวกันอาจเกิดขึ้นเมื่อส่งออกไปยังเครื่องพิมพ์
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 หนึ่งไปยังอีกภาพหนึ่งได้ ฉันซ้ำ uncompression ของไฟล์ PDF ทั้งใช้ pdftk ล่าสุดเปิดพวกเขาในการเป็นกลุ่มแทนที่ในtest2uc.pdf <<...>>stream...endstreamกับคู่จากmytestuc.pdfบันทึกเป็นและบีบอัดให้test2fixuc.pdftest2fix.pdf
test2fix.pdf
Test.pdf
มันจะเป็นบาปที่ไม่ได้ตรวจสอบ PDF ขนาดใหญ่ของคุณหลังจากทั้งหมด ตกลงฉันได้เตรียม oneliner อื่นเพื่อเล่นกับ pdftk 1.44 PDF ที่ไม่บีบอัดเพื่อแสดงรายการสตรีมรูปภาพและบรรทัดเริ่มต้นในไฟล์ ดังนั้นผมจะเริ่มต้นด้วย test.pdfuncompressing
(คำเตือน ณ จุดนี้ 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 ไบต์! ทำการตรวจสอบ Let 's และtest2uc.pdfmytestuc.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 (และอาจปิดได้) ฉันสงสัยว่าสิ่งเดียวกันจะถูก spitted โดย PDFCreator ยกเว้นว่าเป็น Word ที่ใช้ความวิกลจริตอย่างเหลือเชื่อ ...
testuc-stream1.png และอื่น ๆ (ใช้ลูกศรขวาเพื่อเลื่อนดู)
ข้อสรุป
สิ่งสำคัญคือ:
- คุณสามารถเห็นได้อย่างชัดเจนว่าภาพขนาดใหญ่ที่ถูกตัดเป็นชิ้น ๆ จริง ๆ แล้วลดขนาด JPEG ดังนั้นสมมติฐานของฉันจึงถูกต้อง
- เพราะใน PDFCreator คุณจะได้รับไฟล์ขนาดใหญ่ในผลลัพธ์มันเป็น Word ที่ให้ภาพขนาดใหญ่สุดยอดไปยังเครื่องพิมพ์ PDF ปลอมและการคาดคะเนก่อนหน้าของฉันก็ถูกต้องเช่นกัน
วุ้ย. การสอบสวนนี้ใช้เวลาพอสมควร Word เป็นชิ้นส่วนขยะ
วิธีการแก้ปัญหา?
ในระหว่างนี้มีข้อเสนอแนะให้ ให้ฉันแสดงความคิดเห็นพวกเขา
การใช้ตัวเขียนที่มีการรองรับ PDF ที่ดีเช่นLibreOffice (ลืมเกี่ยวกับ OpenOffice ตอนนี้ล้าสมัยแล้ว) เป็นทางออกที่ดีเว้นแต่ว่าความผิดพลาดบางอย่างทำให้คุณไม่สามารถทำงานกับมันได้
การใช้รูปภาพที่ใหญ่กว่าในกล่องเดียวกันบนหน้ากระดาษก็ไม่ใช่ความคิดที่ไม่ดีเช่นกันเพราะแม้หลังจาก JPEG-izing แล้วสิ่งประดิษฐ์ก็จะมองเห็นได้น้อยลง
grosz อีกอันของฉันกำลังใช้ JPEG ตั้งแต่ต้น ด้วยวิธีนี้ Word ไม่ควรบีบอัดใหม่ (คุณไม่มีทางรู้ว่า ... ) และคุณสามารถให้คุณภาพ JPEG ที่มีคุณภาพสูงสุด นอกจากนี้ยังมีการบีบอัด JPEG แบบ lossless นักพัฒนาจาก 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)
ฉันคิดว่าค่าเริ่มต้นของ Mitchell นั้นดีสำหรับการลดอัตราการสุ่ม แต่ถ้าคุณต้องการภาพพิกเซลเช่นนั้นให้ไปที่ Box ตามที่ @ceving แนะนำ แน่นอนว่าไฟล์ 2 ไฟล์แรกมีประโยชน์เฉพาะในกรณีที่คุณต้องใช้เครื่องพิมพ์ PDF ปลอม (ด้วยเหตุผลบางประการ)
ฉันอัพโหลดทั้งสามไฟล์แล้ว
test-300dpi-mitchell.jpg (426 KB)
test-300dpi-box.jpg (581 KB)
test.jpg (74 KB)
หากสมมติฐานของฉันถูกต้องและ Word จะไม่บีบอัดรูปภาพ JPEG ใหม่ให้ใช้อันสุดท้ายที่ไม่ลดขนาดและไปกับเอาต์พุต PDF ในตัวเนื่องจากมีข้อผิดพลาดน้อยกว่า (อย่างน้อยก็หลีกเลี่ยงการอัปเกรดที่ไม่มีความจำเป็น)
