Słowo może po prostu renderuje przeskalowany obraz i wysyła go w ten sposób jako dane wejściowe drukarki (zakładam, że Distiller działa jak drukarka). Jeśli tak, to jest dobre dla normalnych drukarek, ale nieefektywne dla fałszywych drukarek produkujących pliki PDF.
Na przykład pdfLaTeX poprawnie osadza obraz w pliku wyjściowym. Sprawdź mój plik PDF przesłany do galerii min.us: Osadzanie obrazu w dokumencie LaTeX
Ważne jest to, jakiego stosu plików PDF używasz. Jeśli wypróbowanie innej drukarki PDF, takiej jak świetny i darmowy PDFCreator , nie rozwiąże problemu, powinieneś spróbować użyć dedykowanego eksportu PDF, tj. Nie działając jako drukarka. Najnowsze wersje programu AFAIK mają wbudowany eksport PDF, więc jeśli zostanie poprawnie zaimplementowany, otrzymasz mały plik, dzięki osadzeniu obrazów używanych w dokumencie.
OGROMNA EDYCJA
Nazwa galerii została zmieniona na Osadzanie obrazu PNG w LaTeX vs. Word
Dokładniej przyjrzałem się mojej mytest.pdfwygenerowanej przez pdfLaTeX i twojej test2.pdfwygenerowanej przez Word.
mytest.pdf
test2.pdf
Zacznijmy od rozpakowywania. Jeśli spojrzysz na nieskompresowany plik, z łatwością zauważysz początek strumienia obrazu ( <<...>>streamlinia z parametrami Szerokość i Wysokość, tak samo jak w test.png, tj. 176x295), który kończy się endstreamtagiem. Czas na podgląd
(OSTRZEŻENIE w tym momencie zakłada się, że pdftk jest w wersji 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
Tak więc program Word podaje JPEG zamiast PNG na wewnętrznym wyjściu w celu dalszego przetwarzania PDF. Po prostu WOW! To samo może się zdarzyć podczas wysyłania wydruku do drukarki.
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)
To nie jest plik COM, ale nie jest to również PNG.
$ du -b test.png test2stream myteststream
57727 test.png
20004 test2stream
155761 myteststream
Widzisz to teraz? Strumień obrazu (PNG) z pliku PDF utworzonego przez pdfLaTeX jest prawdopodobnie prostym formatem raw (176 * 295 * 3 = 155760, 1 pochodzi ze zbędnej nowej linii). Sprawdźmy to:
$ convert -depth 8 -size 176x295 rgb:myteststream myteststream.png
I mamy nasz oryginalny obraz z powrotem! Nie, czekaj. Wygląda na to, że dekompresja pdftk 1.41 jest błędna, a obraz był prawie taki sam z kilkoma wadami. Uaktualniłem do wersji pdftk 1.44, ale ta wersja w ogóle nie dekompresuje strumienia obrazu. Co więcej, pdftk nie wyświetla słownika strumieniowego w jednym wierszu, więc powyższa ekstrakcja za pomocą sed już nie działa, ale teraz nie ma sensu go poprawiać.
Co możemy zrobić z programem Word? Niewiele myśli. Przynajmniej możesz przesadzić osadzony obraz z jednego pliku PDF do drugiego. Powtórzyłem dekompresję obu plików PDF przy użyciu ostatniego pdftk, otworzyłem je w vimie, zastąpiłem test2uc.pdf <<...>>stream...endstreamodpowiednikiem z mytestuc.pdf, zapisałem jako test2fixuc.pdfi skompresowałem do test2fix.pdf.
test2fix.pdf
test.pdf
Grzechem byłoby jednak nie sprawdzanie dużego pliku PDF. Ok, przygotowałem kolejny oneliner do gry z nieskompresowanymi plikami PDF pdftk 1.44, aby wyświetlić strumienie obrazów i ich początkowe linie w plikach. Zacznę od rozpakowywania test.pdf.
(OSTRZEŻENIE w tym momencie zakłada się, że pdftk jest w wersji 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
Coś tutaj jest naprawdę szalone! 6 nieprzetworzonych zdjęć (najwyraźniej tym razem pdftk nie miało żadnych problemów z ich rozpakowaniem) razem 43444452 bajtów! Sprawdźmy ponownie test2uc.pdfi 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
W obu przypadkach tylko jeden strumień obrazu. Dlaczego do cholery może być ich więcej ?!
$ 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
Obraz został pocięty na wiele kawałków ... Wygląda to na jakąś głupią ochronę, może wprowadzoną przez Distillera (a może można go wyłączyć)? Wątpię, by to samo wypluł PDFCreator, chyba że to Słowo wykona to niewiarygodne szaleństwo ...
testuc-stream1.png i inne ( nawiguj za pomocą prawej strzałki)
Wniosek
Ważne rzeczy to:
- wyraźnie widać, że ogromny obraz, który został pocięty na kawałki, jest w rzeczywistości powiększony do formatu JPEG, więc moja hipoteza była poprawna,
- ponieważ w PDFCreator otrzymujesz również ogromny plik wyjściowy, to Word zapewnia strasznie duży obraz fałszywej drukarce PDF, a moje wcześniejsze przypuszczenie również było prawidłowe.
Uff Dochodzenie zajęło trochę czasu. Słowo to śmieci.
Obejścia?
W międzyczasie podano kilka sugestii. Pozwól mi je skomentować.
Używanie programu piszącego z przyzwoitą obsługą plików PDF, takiego jak LibreOffice (zapomnij o OpenOffice, jest już przestarzałe) jest dobrym rozwiązaniem, chyba że niektóre niezgodności uniemożliwiają pracę z nim.
Używanie większego obrazu w tym samym polu na stronie również nie jest złym pomysłem, ponieważ nawet po JPEG, artefakty będą mniej widoczne.
Mój kolejny grosz korzysta z JPEG od samego początku. W ten sposób Word nie powinien go ponownie kompresować (nigdy nie wiesz ...) i możesz zapewnić najwyższą możliwą jakość JPEG. Istnieje również bezstratna kompresja JPEG. Programiści z Redmond prawdopodobnie uważali, że to nie jest potrzebne, więc nie będę zaskoczony, jeśli Word nie będzie obsługiwał takich plików JPEG. Cóż, TBH nie jest powszechnie obsługiwany (nawet w świecie open source), podobnie jak kodowanie arytmetyczne (lub jest to nawet gorsza sytuacja w przypadku kodowania arytmetycznego).
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
(W systemie Windows użyj 416 zamiast tego $(())rozszerzenia arytmetycznego dostępnego w powłokach POSIX)
Myślę, że domyślny Mitchell nadaje się do skalowania w górę, ale jeśli naprawdę chcesz takiego pikselicznego obrazu, wybierz Box, jak sugeruje @ceving. Oczywiście pierwsze 2 pliki są przydatne tylko wtedy, gdy musisz (z jakiegoś powodu) używać fałszywych drukarek PDF.
Przesłałem wszystkie trzy pliki.
testowy-mitchell.jpg 300 dpi (426 MB)
testowy-box.jpg 300 dpi (581 MB)
test.jpg (74 KB)
Jeśli moja hipoteza jest słuszna, a program Word nie skompresuje ponownie obrazu JPEG, skorzystaj z ostatniej nieskalowanej i skorzystaj z wbudowanego pliku wyjściowego PDF, ponieważ ma on mniej niedociągnięć (przynajmniej pozwala uniknąć niepotrzebnej aktualizacji).
