Word belki sadece görüntüyü büyütür ve yazıcı girişi olarak gönderir (Distiller'ın bir yazıcı olarak çalıştığını varsayıyorum). Öyleyse normal yazıcılar için iyi, ancak PDF dosyaları üreten sahte yazıcılar için verimsiz.
Örneğin pdfLaTeX görüntüyü çıktı dosyasına düzgün bir şekilde yerleştirir. Min.us galerisine yüklenen PDF'mi kontrol et: Resmi LaTeX belgesine gömme
Önemli olan, hangi PDF üreten yığını kullanıyorsunuzdur. Harika ve ücretsiz bir PDFCreator gibi başka bir PDF yazıcıyı denemek sorunu çözmüyorsa, özel bir PDF dışa aktarma kullanmayı denemelisiniz, yani bir yazıcı olarak çalışmıyor. AFAIK'in son zamanlardaki Word sürümlerinde yerleşik PDF dışa aktarma özelliği vardır, bu nedenle düzgün bir şekilde uygulanırsa, belgede kullanılan görüntüleri gömdüğünüz için küçük bir dosya elde edersiniz.
BÜYÜK EDİT
Galeri, LaTeX'e ve Word'e PNG resmi yerleştirme olarak yeniden adlandırıldı
mytest.pdfPdfLaTeX test2.pdftarafından oluşturulan ve Word tarafından oluşturulan benim daha iyice baktım .
mytest.pdf
test2.pdf
Sıkıştırmadan başlayalım. Sıkıştırılmamış bir dosyaya bakarsanız , etiketle biten resim akışının ( <<...>>streamGenişlik ve Yükseklik parametreleriyle aynı test.pngçizgide, yani 176x295 ile aynı satır) başlamasını kolayca görürsünüz endstream. Gözetleme zamanı.
(Bu noktada UYARI pdftk 1.41 sürümünde kabul edilmiştir)
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
Böylece Word, daha fazla PDF işlemesi için PNG yerine JPEG formatında çıktı veriyor. Sadece VAY! Yazıcıya çıktı gönderirken aynı şey olabilir.
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 dosyası değil, ama PNG de değil.
$ du -b test.png test2stream myteststream
57727 test.png
20004 test2stream
155761 myteststream
Şimdi gördün mü? PdfLaTeX tarafından üretilen PDF'den gelen görüntü akışı (PNG) muhtemelen basit bir ham formattır (176 * 295 * 3 = 155760, 1 gereksiz yeni satırdan gelir). Kontrol edelim:
$ convert -depth 8 -size 176x295 rgb:myteststream myteststream.png
Ve orijinal imajımızı geri aldık! Hayır bekle. Görünüşe göre pdftk 1.41 uncompression sorunu var ve imaj birkaç kusur ile aynıydı. Pdftk 1.44'e yükselttim, ancak bu sürüm görüntü akışını hiç açmıyor. Üstelik pdftk, tek satırda stream sözlüğü çıkarmaz, bu yüzden sed kullanarak yapılan ekstraksiyon artık çalışmaz, ancak şimdi düzeltmenin bir anlamı yoktur.
Peki, Word hakkında ne yapabiliriz? Fazla bir şey düşünmüyor. En azından gömülü resmi bir PDF'den diğerine aktarabilirsiniz. Son iki pdftk kullanarak her iki PDF'nin sıkıştırılmamasını da tekrarladım, bunları vim içinde açtım, yerine gelen test2uc.pdf <<...>>stream...endstreamile eşleştirdim mytestuc.pdf, olarak kaydedildi test2fixuc.pdfve sıkıştırıldım test2fix.pdf.
test2fix.pdf
test.pdf
Sonuçta büyük PDF'inizi kontrol etmemek günah olurdu. Tamam, görüntü akışlarını ve başlangıç satırlarını dosyalarda listelemek için pdftk 1.44 sıkıştırılmamış PDF'lerle oynamak için başka bir çevrimiçi hazırladım. Bu yüzden sıkıştırmadan başlayacağım test.pdf.
(Bu noktada UYARI pdftk 1.44 sürümünde kabul edilmiştir)
$ 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
Burada bir şeyler gerçekten delilik! 6 ham resim (görünüşe göre bu sefer pdftk 43444452 byte'ı bir araya getirerek) Hadi yeniden kontrol test2uc.pdfve 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
Her iki durumda da yalnızca bir görüntü akışı. Neden halt onlardan daha fazla olabilir ?!
$ 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
Görüntü birçok parçaya bölündü ... Belki de Distiller tarafından tanıtılan bir tür tamamen aptalca korumaya benziyor (ve belki de kapatılabilir)? Bu inanılmaz deliliğin peşinde koşan Kelime olmadığı sürece, PDFCreator tarafından da aynı şeyin tükeneceğinden şüpheliyim ...
testuc-stream1.png ve diğerleri (gezinmek için sağ oku kullanın)
Sonuç
Önemli şeyler:
- açıkça görebiliyorsunuz, parçalara bölünmüş devasa fotoğrafın aslında üst düzey JPEG olduğu, bu yüzden hipotezim doğruydu.
- çünkü PDFCreator'da çıktıda çok büyük bir dosya elde edersiniz, sahte PDF yazıcısına çok büyük bir görüntü sağlayan Word'dür ve önceki varsayımım da doğruydu.
Uf. Bu soruşturma biraz zaman aldı. Kelime bir hurda parçası.
Geçici Çözümler?
Bu arada bazı önerilerde bulunuldu. Onları yorumlayayım.
LibreOffice gibi iyi bir PDF desteğiyle yazar kullanmak (OpenOffice'i unutun, artık kullanılmıyor), bazı uygunsuzluklar çalışmanıza engel olamıyorsa iyi bir çözümdür.
Sayfadaki aynı kutuda daha büyük görüntü kullanmak da kötü bir fikir değil çünkü JPEG izlemeden sonra bile eserler daha az görülüyor.
Başka bir grosz olsa baştan JPEG kullanıyor. Bu şekilde, Word bunu tekrar sıkıştırmamalı (asla bilemezsiniz ...) ve mümkün olan en yüksek kalitede JPEG sağlayabilirsiniz. Kayıpsız JPEG sıkıştırma da var. Redmond'lı geliştiriciler muhtemelen gerekli olmadığını düşünüyorlardı, bu yüzden Word bu tür JPEG'leri kullanmazsa şaşırmam. Eh, TBH, yaygın olarak desteklenmiyor (açık kaynak dünyasında bile), tıpkı aritmetik kodlama gibi (ya da aritmetik kodlama durumunda daha da kötü bir durum).
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'ta $(())POSIX kabuklarında bu aritmetik genişlemenin yerine 416 kullanın )
Sanırım varsayılan Mitchell, yükseltme için iyi bir seçim, ancak gerçekten böyle pikselli bir görüntü istiyorsanız, o zaman ceving'in önerdiği gibi Box ile gidin. Elbette ilk 2 dosya sadece (bir nedenden dolayı) sahte PDF yazıcılar kullanmanız gerekiyorsa kullanışlıdır.
Üç dosyayı da yükledim.
test-300dpi-mitchell.jpg (426 KB)
test-300dpi-box.jpg (581 KB)
test.jpg (74 KB)
Eğer hipotezim doğruysa ve Word JPEG görüntüsünü yeniden sıkıştırmayacaksa, yalnızca sonuncusunu yükseltilmemiş olanı kullanın ve yerleşik PDF çıktısı ile devam edin, çünkü daha az eksikliğe sahiptir (en azından gereksiz yükseltmeyi önler).
