Microsoft Word 2010 daran hindern, Screenshots zu glätten?

Wenn ich JPEG-Screenshots in Microsoft Word einfüge, werden diese geglättet, anstatt die ursprünglichen Pixel aus der Bitmap beizubehalten. Wenn ich dann (mit Acrobat Distiller) in PDF drucke, erhalte ich abhängig von meinen Downsample-Einstellungen entweder verschwommene Screenshots oder übergroße Dateigrößen.

Was ich will:

Ich möchte, dass Word und Acrobat die Bitmaps in Ruhe lassen, damit sie den Prozess mit intakten Pixeln durchlaufen. So sieht das Originalbild beim Einzoomen aus:

Was ich bekomme:

So sieht das Word-Dokument aus, wenn Sie dasselbe Bild einfügen und vergrößern. Wenn dies als PDF gedruckt wird, führen all diese zusätzlichen Pixel zu einer viel größeren Datei.

Beispieldateien:

• Test.png (56K) Eine Beispiel-Screenshot-Bilddatei
• Test.docx ( 69 KB ) Eine Word-Datei, die nur dieses Bild enthält
• Test.PDF (9,4 MB) Eine mit Distiller aus der Word-Datei gedruckte PDF-Datei, bei der das Downsampling deaktiviert ist
• Test2.PDF (98 KB) Eine PDF-Datei, die mit dem Tool "Als PDF speichern" von Word 2010 erstellt wurde (beachten Sie die sehr geringe Qualität des komprimierten Bildes).

Bearbeiten: Dies ist mit Word 2010 - Ich habe die Tags aktualisiert, um dies widerzuspiegeln.

Bearbeiten: Ich habe bestätigt, dass OpenOffice dieses Problem nicht hat. Ich habe Test.docx (siehe oben) geöffnet und es als PDF von OO exportiert (in den Optionen unter "Bilder" die Option "verlustfreie Komprimierung" ausgewählt), und das Bild ist unversehrt.

• Test_OO.pdf

Leider zersetzt OpenOffice die Formatierung komplexerer Word-Dokumente, die ich erstellt habe. Ich kann also nicht einfach die Dokumente in Word erstellen und OO zum Rendern der PDFs verwenden. Ich müsste ganz auf OO umsteigen, was ein größerer Schritt ist, als ich jetzt zu tun bereit bin.

Word rendert möglicherweise nur ein vergrößertes Bild und sendet es auf diese Weise als Druckereingabe (ich gehe davon aus, dass Distiller als Drucker arbeitet). Wenn ja, dann ist es gut für normale Drucker, aber ineffizient für gefälschte Drucker, die PDF-Dateien erstellen.

Zum Beispiel bettet pdfLaTeX das Bild korrekt in die Ausgabedatei ein. Überprüfen Sie mein PDF, das in die min.us-Galerie hochgeladen wurde: Bild in LaTeX-Dokument einbetten

Wichtig ist, welchen PDF-Stapel Sie verwenden. Wenn Sie andere PDF-Drucker wie den großartigen und kostenlosen PDFCreator ausprobieren, um das Problem zu beheben, sollten Sie versuchen, einen dedizierten PDF-Export zu verwenden, dh nicht als Drucker zu arbeiten. In neueren Word-Versionen von AFAIK ist der PDF-Export integriert. Wenn er ordnungsgemäß implementiert ist, erhalten Sie dank der Einbettung der im Dokument verwendeten Bilder eine kleine Datei.

RIESIGE BEARBEITUNG

Die Galerie wurde in Einbetten von PNG-Bildern in LaTeX vs Word umbenannt

Ich habe mir meine mytest.pdfvon pdfLaTeX und Ihre test2.pdfvon Word generierten genauer angesehen .

mytest.pdf test2.pdf

Beginnen wir mit dem Dekomprimieren. Wenn Sie in eine unkomprimierte Datei schauen, erkennen Sie leicht den Anfang des Bildstroms ( <<...>>streamZeile mit den Parametern Breite und Höhe, wie in test.png, dh 176 x 295), der mit dem endstreamTag endet . Spähen Sie Zeit.

(WARNUNG An dieser Stelle wird angenommen, dass pdftk in Version 1.41 ist.)

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

Daher gibt Word JPEG anstelle von PNG für die weitere PDF-Verarbeitung in die interne Ausgabe ein. Einfach wow! Das Gleiche kann passieren, wenn eine Ausgabe an den Drucker gesendet wird.

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)

Es ist keine COM-Datei, aber auch keine PNG-Datei.

$ du -b test.png test2stream myteststream 
57727   test.png
20004   test2stream
155761  myteststream

Siehst du es jetzt? Der von pdfLaTeX erzeugte Bildstrom (von PNG) aus PDF ist möglicherweise ein einfaches Rohformat (176 * 295 * 3 = 155760, 1 stammt aus überflüssigen Zeilenumbrüchen). Lass es uns überprüfen:

$ convert -depth 8 -size 176x295 rgb:myteststream myteststream.png

Und wir haben unser ursprüngliches Bild zurück! Nein, warte. Es sieht so aus, als ob die Dekomprimierung von pdftk 1.41 fehlerhaft ist und das Bild mit ein paar Fehlern fast dasselbe war. Ich habe ein Upgrade auf pdftk 1.44 durchgeführt, aber diese Version dekomprimiert den Image-Stream überhaupt nicht. Darüber hinaus gibt pdftk das Stream-Wörterbuch nicht in einer Zeile aus. Daher funktioniert das Extrahieren mit sed nicht mehr, aber es macht keinen Sinn, es jetzt zu reparieren.

Was können wir also mit Word tun? Nicht viel überlegt. Zumindest können Sie eingebettetes Bild von einer PDF in eine andere übertragen. Ich habe das Dekomprimieren beider PDFs mit dem neuesten pdftk wiederholt, sie in vim geöffnet, durch das test2uc.pdf <<...>>stream...endstreamGegenstück von ersetzt mytestuc.pdf, gespeichert test2fixuc.pdfund komprimiert test2fix.pdf.

test2fix.pdf

test.pdf

Es wäre eine Sünde, wenn Sie Ihr großes PDF nicht prüfen würden. Ok, ich habe einen weiteren Oneliner vorbereitet, um mit unkomprimierten PDFs von pdftk 1.44 zu spielen und Bildströme und ihre Anfangszeilen in Dateien aufzulisten. Also werde ich mit dem Dekomprimieren beginnen test.pdf.

(ACHTUNG an dieser Stelle wird angenommen, dass pdftk in Version 1.44 ist.)

$ 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

Irgendwas ist hier wirklich verrückt! 6 rohe Bilder (anscheinend hatte pdftk dieses Mal keine Probleme, sie zu dekomprimieren), 43444452 Bytes zusammen! Lassen Sie uns noch einmal überprüfen test2uc.pdfund 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

In beiden Fällen nur ein Bildstrom. Warum zum Teufel könnte es mehr von ihnen geben ?!

$ 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

Bild wurde in viele Teile zerschnitten ... Es sieht aus wie eine Art völlig dummer Schutz, der vielleicht von Distiller eingeführt wurde (und vielleicht kann er ausgeschaltet werden)? Ich bezweifle, dass PDFCreator dasselbe ausspuckt, es sei denn, es ist Word, das diesen unglaublichen Wahnsinn vollbringt ...

testuc-stream1.png und andere (mit dem Rechtspfeil navigieren)

Fazit

Wichtige Dinge sind:

• Sie können deutlich sehen, dass das riesige Bild, das in Stücke geschnitten wurde, tatsächlich eine hochskalierte JPEG-Datei ist. Meine Hypothese war also richtig.
• Da in PDFCreator auch große Dateien ausgegeben werden, liefert Word dem gefälschten PDF-Drucker ein furchtbar großes Bild, und meine frühere Annahme war auch richtig.

Puh. Diese Untersuchung dauerte einige Zeit. Das Wort ist ein Stück Müll.

Problemumgehungen?

In der Zwischenzeit wurden einige Vorschläge gemacht. Lassen Sie mich sie kommentieren.

Die Verwendung von Writer mit angemessener PDF-Unterstützung wie LibreOffice (vergessen Sie OpenOffice, es ist inzwischen veraltet) ist eine gute Lösung, es sei denn, einige Inkompatibilitäten machen es Ihnen unmöglich, damit zu arbeiten.

Die Verwendung eines größeren Bilds in demselben Feld auf der Seite ist auch keine schlechte Idee, da Artefakte auch nach dem JPEG-Format weniger sichtbar sind.

Mein anderes Grosz verwendet jedoch von Anfang an JPEG. Auf diese Weise sollte Word es nicht erneut komprimieren (Sie wissen es nie ...) und Sie können die höchstmögliche Qualität von JPEG liefern. Es gibt auch verlustfreie JPEG-Komprimierung. Vermutlich dachten Entwickler aus Redmond, dass dies nicht erforderlich ist, und ich würde mich nicht wundern, wenn Word solche JPEGs nicht verarbeiten würde. Nun, TBH wird nicht allgemein unterstützt (auch nicht in Open Source-Umgebungen), genau wie arithmetisches Codieren (oder noch schlimmer bei arithmetischem Codieren).

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

(Verwenden Sie unter Windows 416 anstelle dieser $(())in POSIX-Shells verfügbaren arithmetischen Erweiterung.)

Ich denke, dass Standard Mitchell gut für die Hochskalierung ist, aber wenn Sie wirklich solch ein pixeliges Bild wollen, dann gehen Sie mit Box wie @ceving vorgeschlagen. Natürlich sind die ersten 2 Dateien nur dann nützlich, wenn Sie (aus irgendeinem Grund) gefälschte PDF-Drucker verwenden müssen.

Ich habe alle drei Dateien hochgeladen.

test-300dpi-mitchell.jpg (426 KB) test-300dpi-box.jpg (581 KB) test.jpg (74 KB)

Wenn meine Hypothese richtig ist und Word JPEG-Bilder nicht erneut komprimiert, verwenden Sie einfach die letzte, die nicht hochskaliert ist, und verwenden Sie die integrierte PDF-Ausgabe, da sie weniger Mängel aufweist (zumindest vermeidet sie unnötiges Hochskalieren).

Öffnen Sie Datei > Einstellungen > Erweitert , dann in Bildgröße und Qualität Abschnitt, Prüfoption Do nicht komprimieren Bilder in Dateien (siehe Screen - Capture zu orientieren , wo ist diese Option befindet)

Das folgende Bild ist dasselbe JPG-Bild (Dokumentenerfassung 400% vergrößert, um den Unterschied beim Antialiasing anzuzeigen), das vor und nach dem Aktivieren dieser Option eingefügt wurde:

Es sieht so aus, als ob die Zoomfunktion von Microsoft Word eine bilineare Filterung verwendet. Dies sollte nicht das Bild selbst ändern, sondern nur, wie es mit einer anderen Vergrößerung als 100% angezeigt wird. Was Sie wollen, ist die Skalierung des nächsten Nachbarn, aber ich bezweifle, dass MS Word eine Option dafür hat.

Ich habe die Manipulation des Einfügens von Test.png in ein Dokument in Word 2007 wiederholt und zu meinem Erstaunen festgestellt, dass das Ergebnis von dem verwendeten Mechanismus abhängt.

Wenn man Einfügen / Bild verwendet, wird das Bild geglättet.
Aber wenn man einen Bildeditor betritt und kopiert, dann in Word einfügt, wird das Bild nicht geglättet.

Andere mögliche Problemumgehungen sind:

1. Versuchen Sie, Inhalte als Bitmap oder geräteunabhängige Bitmap einzufügen.
2. Fügen Sie keine Bilder ein. Verwenden Sie die Registerkarte Einfügen / Gruppe Illustrationen / Befehl Bild und ändern Sie die Dropdown-Schaltfläche "Einfügen" in "Mit Datei verknüpfen". Die Bilddatei kann so optimiert werden, dass das Web weniger Speicherplatz beansprucht.

Es ist wahrscheinlich die einfachste Lösung, die Originalbilder auf 300 dpi oder eine beliebige Auflösung zu skalieren, die Sie beim PDF-Export verwenden. Das Konvertierungsprogramm von ImageMagick kann dies zum Beispiel.

Das Originalbild hat eine Breite von 176 Pixel. Wenn Sie es auf 4 Zoll bei 300 dpi skalieren möchten, beträgt die Zielbreite 1200 Pixel. Dies wird es tun:

convert test.png -filter Box -resize 1200 test_300dpi.png

Ich habe die Erfahrung gemacht, dass es immer besser ist, Microsoft-Produkte davon abzuhalten, darüber nachzudenken, was für Sie gut sein könnte. Es ist immer besser, es selbst zu entscheiden.

Diese Frage ähnelt dieser

Es hat mit dem Umhüllungsstil zu tun ... stelle ihn nur oben und unten ein. Lesen Sie hier .

Korrigieren Sie mich, wenn dieser Kommentar zu offensichtlich oder nicht relevant ist:

Wenn ich beispielsweise ein gestochen scharfes Bild einer Textseite (.bmp und .png) in ein Word 2010-Dokument (.docx) einfüge, ist das Ergebnis eine verschwommene Version des Originals. Dies liegt an der automatischen Größenänderung und Bildverarbeitung durch Word, anscheinend unabhängig von den relevanten Einstellungen in "Optionen". Allerdings wenn ich dann

1. wähle das Bild aus
2. gehe zum Menüband Header "Format"
3. Wählen Sie das kleine Symbol ganz links im Menüband aus, das wie ein kleines Bild mit einem Pfeil zum Rückgängigmachen aussieht
4. Öffnen Sie das zugehörige Menü
5. wähle den unteren Punkt "Bild und Größe umkehren" (das war eine lose Übersetzung aus dem Deutschen),

dann erscheint das gestochen scharfe Bild, das ich eingefügt habe, wieder anstelle des unscharfen.

Hinweis: Wenn ich das in Acrobat Reader integrierte Fototool verwende und dann direkt in Word einfüge, funktioniert das oben Gesagte nicht. Ich muss einen Screenshot des gesamten Bildschirms machen oder über IrfanView gehen.