Pdf aus Word: Komprimieren, aber nicht neu komprimieren?

[Peter Konrad]

X-post, followupto de.comp.text.dtp

Hallo,

ich erstelle grad einen privaten DIN A3 Fotokalender, und zwar
entgegen meinen sonstigen Gepflogenheiten zähneknirschend nicht im DTP-
Programm, sondern in Word (wegen des besseren Tabellenhandlings, für
das Kalendarium).

Bislang sind die ersten zwei Seiten fertig, das .doc ist knapp 7 MB
groß.

Das Ergebnis muss/soll/will aber zum Ausbelichten als pdf eingereicht
werden.

Es sind naturgemäß einige recht großformatige Fotos in hoher Qualität
in der Datei, als jpeg ins Word eingefügt. Die Konversion des .doc ins
pdf erfolgt - bislang - mit dem ältlichen Acrobat PDF-Writer 4.0.

Um die Qualität zu maximieren, hab ich zum Test das Häkchen bei der
Kompression für Farb- und Graustufenbilder entfernt. Resultat: das pdf
wird 110 MB groß.

Das fand ich etwas viel, auch wenn es heute wohl nix mehr ausmacht
(früher hätte man ja ewig warten müssen, bis so eine Datei auch nur
vom Rechner an den Drucker übertragen ist.)

Leider bietet der PDFWriter bei Bildern nur die Wahl zwischen keiner
Kompression, zip-Kompression (pdf immerhin nur noch 54 MB groß) oder
aber vier verschieden starken jpeg-Komprimierungen.

Eigentlich erschiene es mir am Besten, wenn der PDFWriter die
Kompression der ins Word eingefügten Jpegs 1:1 übernähme, da ich einen
Qualitätsverlust befürchte, wenn die jpegs noch mal jpeg-komprimiert.

Oder mach ich mir da überflüssige Gedanken?

[Erich Brandt]

Hallo Peter,

Post by Peter Konrad
Eigentlich erschiene es mir am Besten, wenn der PDFWriter die
Kompression der ins Word eingefügten Jpegs 1:1 übernähme, da ich einen
Qualitätsverlust befürchte, wenn die jpegs noch mal jpeg-komprimiert.

Wenn's Dir nix ausmacht, zusätzliche (OpenSource-)Software zu
installieren, probiere doch mal den PDFCreator hier aus:

http://www.pdfforge.org/download

Das Teil installiert sich als zusätzlicher Druckertreiber und hat
unter anderem die Option, verlustfrei (zip) zu komprimieren.

Ciao, Erich

[Thomas Kaiser]

Post by Peter Konrad
Eigentlich erschiene es mir am Besten, wenn der PDFWriter die
Kompression der ins Word eingefügten Jpegs 1:1 übernähme

Wie soll er das denn machen? Der PDF-Writer ist ein Tool, das sich die
GDI-Ausgabe krallt und daraus wieder PDF bastelt. Selbst wenn Du den
PDF-Maker meinen/nutzen solltest: Auch der kann nicht zaubern: Wenn Du
JPEG in Word platzierst, wird Word -- wie nahezu jedes andere Programm
auch -- das Zeugs irgendwie für die Druckausgabe aufbereiten und als
unkomprimierten Bytestream ans Drucksystem rausreichen (PDF-Writer: GDI,
PDF-Maker: PostScript).

Einzige Chance: Den JPEGs ein EPS-Mäntelchen überstülpen (bspw. mittels
Thomas Merz' jpeg2ps), diese in Word platzieren, PostScript ausgeben
lassen und eine hinreichend aktuelle Distiller-Version das PS zu PDF
wandeln lassen. Ab irgendeiner Distiller-Version gibt's "JPEG
passthrough" und dann landen die ohne erneute Quantisierung im PDF. Das
klappt aber wirklich nur mittels Wandlung von PostScript zu PDF ab IIRC
Distiller 6 aufwärts.

Post by Peter Konrad
da ich einen Qualitätsverlust befürchte, wenn die jpegs noch mal
jpeg-komprimiert.
Oder mach ich mir da überflüssige Gedanken?

Das eh, außer die platzierten Bilder hatten schon visuell sichtbare
Kompressionsartefakte eingebaut. Wenn Du wirklich Qualitätsverluste
befürchtest, mußt Du eben größere Dateigröße in Kauf nehmen und ggf.
ZIP-/Flate-Kompression der Bilder erwägen (durch GhostScript
durchnudeln, da gibt's ja für Windows 'zig Tools, die sich als
virtueller GhostScript-Drucker ins System integrieren und hinten PDF
rausfallen lassen)

Gruss,

Thomas, würde sich ja eher über PDF/X Gedanken machen als über erneute
JPEG-Kompression...

[Michael Unger]

[...]
[...] Wenn Du wirklich Qualitätsverluste
befürchtest, mußt Du eben größere Dateigröße in Kauf nehmen und ggf.
ZIP-/Flate-Kompression der Bilder erwägen (durch GhostScript

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

durchnudeln, da gibt's ja für Windows 'zig Tools, die sich als
virtueller GhostScript-Drucker ins System integrieren und hinten PDF
rausfallen lassen)

Nach meiner Erfahrung ist LZW-/Lempel-Ziv-Kompression bei _wirklichen_
Bildern, also völlig unregelmäßig verteilten Farbwerten, eher
kontraproduktiv. LZW-"komprimierte" TIFFs sind gerne einmal um ein
Viertel größer als unkomprimierte ...

[...]

Ach ja: "jpeg2ps" hat auch so seine Tücken -- da wird nämlich an völlig
sinnloser Stelle ein "showpage" ausgegeben ...

Wenn man mehrere Bilder auf eine Seite setzen will, ergibt das gerne
"erklärungsbedürftige" Effekte.

Michael

[Thomas Kaiser]

Post by Michael Unger

[...]

Nach meiner Erfahrung ist LZW-/Lempel-Ziv-Kompression bei _wirklichen_
Bildern, also völlig unregelmäßig verteilten Farbwerten, eher
kontraproduktiv. LZW-"komprimierte" TIFFs sind gerne einmal um ein
Viertel größer als unkomprimierte ...

Da würden mich Beispiele interessieren. Mail-Adresse ist gültig.

Post by Michael Unger

[...]

Ach ja: "jpeg2ps" hat auch so seine Tücken -- da wird nämlich an
völlig sinnloser Stelle ein "showpage" ausgegeben ...

Bitte was? Was ist daran sinnlos? Das ist erlaubt und sinnvoll. Solche
EPS kann man dann auch einfach so auf ein PostScript-Device schubsen,
und sie werden ausgegeben.

Post by Michael Unger
Wenn man mehrere Bilder auf eine Seite setzen will, ergibt das gerne
"erklärungsbedürftige" Effekte.

Nee, die Software, die das macht, ist dann einfach kaputt. Die hat sich
nämlich bei der Kapselung des EPS selbst drum zu kümmern, daß showpage
unschädlich gemacht wird:

/showpage { } def

und fertig. Wenn Du selbst entsprechende Software (geschrieben) hast,
die damit nicht klarkommt, nochmal 5002.EPSF_Spec.pdf lesen.

Gruss,

Thomas

[Michael Unger]

Post by Thomas Kaiser

Post by Michael Unger

[...]

Nach meiner Erfahrung ist LZW-/Lempel-Ziv-Kompression bei _wirklichen_
Bildern, also völlig unregelmäßig verteilten Farbwerten, eher
kontraproduktiv. LZW-"komprimierte" TIFFs sind gerne einmal um ein
Viertel größer als unkomprimierte ...

Da würden mich Beispiele interessieren. Mail-Adresse ist gültig.

Nützt mir aber nichts -- für einen Versand per e-Mail sind das schlicht
zuviel Daten. Anfang der kommenden Woche sollte dann eine CD in Deinem
Briefkasten klappern ...

Ich habe mit 30 Fotos "gespielt", aus einer 12 MP Kamera und auf 50%
verkleinert; die unkomprimierten TIFFs sind (wie zu erwarten) alle 8.832
KB groß, die LZW-"komprimierten" variieren zwischen 7.828 und 11.527 KB,
wobei nur ein _einziges_ kleiner ist als unkomprimiert.

Post by Thomas Kaiser

Post by Michael Unger

[...]

Ach ja: "jpeg2ps" hat auch so seine Tücken -- da wird nämlich an
völlig sinnloser Stelle ein "showpage" ausgegeben ...

Bitte was? Was ist daran sinnlos? Das ist erlaubt und sinnvoll.

Ich kann die Stelle nicht zitieren, aber das muss aus einem der vielen
PDF-Dokumente zu PostScript gewesen sein, die Adobe auf der Website
("Developers Area"?) hat(te). Ich hatte da in Erinnerung, dass
"showpage" in einem *E*PS "pfui bäh" wäre.

Post by Thomas Kaiser
Solche
EPS kann man dann auch einfach so auf ein PostScript-Device schubsen,
und sie werden ausgegeben.

Post by Michael Unger
Wenn man mehrere Bilder auf eine Seite setzen will, ergibt das gerne
"erklärungsbedürftige" Effekte.

Nee, die Software, die das macht, ist dann einfach kaputt. Die hat sich
nämlich bei der Kapselung des EPS selbst drum zu kümmern, daß showpage
/showpage { } def
und fertig.

Nicht ganz; ein "gsave" und "grestore" an passender Stelle sollte man
schon noch "spendieren". Aber womöglich meinst Du das mit "Kapselung".

Post by Thomas Kaiser
Wenn Du selbst entsprechende Software (geschrieben) hast,
die damit nicht klarkommt, nochmal 5002.EPSF_Spec.pdf lesen.

Hast Du den "richtigen" Titel? Dann täte ich mich beim Suchen leichter.

Michael

[Norbert Hahn]

Post by Michael Unger

Post by Thomas Kaiser
Wenn Du selbst entsprechende Software (geschrieben) hast,
die damit nicht klarkommt, nochmal 5002.EPSF_Spec.pdf lesen.

Hast Du den "richtigen" Titel? Dann täte ich mich beim Suchen leichter.

Yahoo findet auf anhieb:
http://partners.adobe.com/public/developer/en/ps/5002.EPSF_Spec.pdf

Norbert

[Thomas Kaiser]

Post by Michael Unger

Post by Thomas Kaiser

Post by Michael Unger

[...]

Nach meiner Erfahrung ist LZW-/Lempel-Ziv-Kompression bei
_wirklichen_ Bildern, also völlig unregelmäßig verteilten
Farbwerten, eher kontraproduktiv. LZW-"komprimierte" TIFFs sind
gerne einmal um ein Viertel größer als unkomprimierte ...

Da würden mich Beispiele interessieren. Mail-Adresse ist gültig.

Nützt mir aber nichts -- für einen Versand per e-Mail sind das schlicht
zuviel Daten. Anfang der kommenden Woche sollte dann eine CD in Deinem
Briefkasten klappern ...

Ist angekommen, das nächste mal bitte trotzdem Mail schicken, ich sende
dann Zugangsdaten für "WebShare" zurück. HTTP-Uploads sind irgendwie
praktischer als CDs durch die Gegend zu schicken :-)

Post by Michael Unger
Ich habe mit 30 Fotos "gespielt", aus einer 12 MP Kamera und auf 50%
verkleinert; die unkomprimierten TIFFs sind (wie zu erwarten) alle
8.832 KB groß, die LZW-"komprimierten" variieren zwischen 7.828 und
11.527 KB, wobei nur ein _einziges_ kleiner ist als unkomprimiert.

TIFF/LZW ist für typische Bilder schon einigermaßen effizient -- das
Problem ist, daß zum einen ein Bug in der Implementierung steckt, der
aufgrund falscher Referenz-Implementierung seitens Adlus irgendwann dazu
führte, daß man den Fehler in die Specs (und damit allgemein vor-)
geschrieben hat anstatt ihn zu fixen (und das schränkt die Effizient des
Algorithmus ein, weil Bits verschwendet werden, siehe Link weiter
unten).

Zum anderen ist LZW bei "noisy" Bildern sehr schwach -- und Deine
Testbilder sind Prachtbeispiele dafür. Beim Runterskalieren auf das
endgültige Format wurde eine satte Scharfzeichnung vorgenommen und im
Bild steckten bereits leichte JPEG-Artefakte (deren Blöckchenbildung
wiederum die Effizienz von LZW beeinträchtigt [1]). Parallel hat Dein
Programm, mit dem Du die LZW-Varianten gespeichert hast, keine Idee von
Differencing, siehe

<http://www.fileformat.info/mirror/egff/ch09_04.htm#CH09-DMYID.1.1>

Heißt (am Beispiel "Stuttgart, Glemsweiher (DSC_0559)"):

- unkomprimiert: 9070300 Bytes
- Deine LZW-Variante: 10597720 Bytes
- LZW-kodiert inkl. Differencing: 9269341 Bytes

Differencing kann man bei tiffcp <http://linux.die.net/man/1/tiffcp>
bspw. simpel an- oder ausschalten, (die meisten Softwares machen's aus
Effizienzgründen eh automatisch):

tiffcp -c lzw:2 $quelle $ziel

erstellt ein entsprechend kleineres TIFF aus Deiner LZW-Variante, die
aber visuell zu 100% identisch ausfallen.

Ich hab Deine Original-JPEGs auch nochmal kurz genommen und ohne
Scharfzeichnungseffekt auf 50% skalieren lassen und diese Variante
geprüft:

- unkomprimiert: 9073324 Bytes
- LZW-kodiert inkl. Differencing: 8834609 Bytes
- LZW-kodiert ohne Differencing: 10561721 Bytes

Das ist einfach "schlechtes" Ausgangsmaterial für LZW (dito auch für
TIFF). Wenn aus der Kamera bereits JPEG kommt, würde ich einfach in dem
Format bleiben. Falls RAW aus der Kamera und Speicherplatz wirklich eine
Rolle spielt, dann ggf. eher als JPEG2000 speichern.

Wir haben aus einem konkreten Projekt auf der Basis einiger tausend kaum
geschärfter Produktabbildungen recht klare Vorstellungen davon, was LZW
im Vergleich zu unkomprimiert bringt: Reduktion der Datenmenge auf unter
die Hälfte des Speicherplatzes (ich hätte zwar auch da eher zu JPEG
geraten aber ich soll mich da nur um die konkrete Durchführung kümmern,
d.h. die Entscheidung war bereits vorher gefallen)

Gruss,

Thomas

[1] Differenzbild zwischen ungeschärft herunterskalierter Variante und
Deiner: Loading Image...

[Michael Unger]

Post by Thomas Kaiser

Post by Michael Unger

Post by Thomas Kaiser

Post by Michael Unger

[...]

Nach meiner Erfahrung ist LZW-/Lempel-Ziv-Kompression bei
_wirklichen_ Bildern, also völlig unregelmäßig verteilten
Farbwerten, eher kontraproduktiv. LZW-"komprimierte" TIFFs sind
gerne einmal um ein Viertel größer als unkomprimierte ...

Da würden mich Beispiele interessieren. Mail-Adresse ist gültig.

Nützt mir aber nichts -- für einen Versand per e-Mail sind das schlicht
zuviel Daten. Anfang der kommenden Woche sollte dann eine CD in Deinem
Briefkasten klappern ...

Ist angekommen, das nächste mal bitte trotzdem Mail schicken, ich sende
dann Zugangsdaten für "WebShare" zurück.

Davon hattest Du aber vorher nichts gesagt ...

Post by Thomas Kaiser
HTTP-Uploads sind irgendwie
praktischer als CDs durch die Gegend zu schicken :-)

Das ist nicht unbedingt richtig -- bei meiner Consumer-DSL-Leitung komme
ich "sendeseitig" nur auf gut 20 kB/s, für die Übertragung der
Datenmenge einer CD sind also etwa 8 Stunden anzusetzen, sofern keine
Leitungsstörungen auftreten. Manchmal ist der "Turnschuh-Admin" eben
doch schneller. (Mit FTP käme ich ebanfalls klar.)

Post by Thomas Kaiser

Post by Michael Unger
Ich habe mit 30 Fotos "gespielt", aus einer 12 MP Kamera und auf 50%
verkleinert; die unkomprimierten TIFFs sind (wie zu erwarten) alle
8.832 KB groß, die LZW-"komprimierten" variieren zwischen 7.828 und
11.527 KB, wobei nur ein _einziges_ kleiner ist als unkomprimiert.

TIFF/LZW ist für typische Bilder schon einigermaßen effizient -- [...]

Du wirst aber nicht ernsthaft erwartet haben, dass ich jetzt mit
Beispielen komme, die meine These widerlegen? ;-)

Post by Thomas Kaiser
Zum anderen ist LZW bei "noisy" Bildern sehr schwach -- und Deine
Testbilder sind Prachtbeispiele dafür.

Ich hatte wohlüberlegt bei den JPEG-Daten nach den "dicksten Brocken"
gesucht, weil, wenn JPEG schon nicht vernünftig klar kommt, vermutlich
LZW ebenfalls Probleme hat.

Post by Thomas Kaiser
Beim Runterskalieren auf das
endgültige Format wurde eine satte Scharfzeichnung vorgenommen

Ähm, nein; MS Paint aus Windows 2000 weiß gar nicht, was das ist. Das
dürfte nach der Methode "Holzhammer" 'runtergerechnet sein.

Post by Thomas Kaiser
und im
Bild steckten bereits leichte JPEG-Artefakte (deren Blöckchenbildung
wiederum die Effizienz von LZW beeinträchtigt [1]). Parallel hat Dein
Programm, mit dem Du die LZW-Varianten gespeichert hast, keine Idee von
Differencing, [...]

Das war "Kodak Imaging für Windows", das mit Windows 2000 ausgeliefert
wurde; das ist also rund ein Jahrzehnt alt.

Post by Thomas Kaiser
[...]
Ich hab Deine Original-JPEGs auch nochmal kurz genommen [...]

Ich habe das spaßeshalber noch mal mit MS Paint aus Windows XP, ohne
Verkleinerung auf 50%, konvertieren lassen; als TIFF ergibt das 40.316
kB, als PNG 30.154 kB, als normales 24-bit-BMP 35.312 kB.

Post by Thomas Kaiser
Das ist einfach "schlechtes" Ausgangsmaterial für LZW (dito auch für
TIFF). Wenn aus der Kamera bereits JPEG kommt, würde ich einfach in dem
Format bleiben. Falls RAW aus der Kamera und Speicherplatz wirklich eine
Rolle spielt, dann ggf. eher als JPEG2000 speichern.

Die Kamera kann "RAW" ("NEF", "Nikon Electronic Format", verlustfrei
komprimiert, 14 Bit Farbtiefe pro Kanal, Dateigröße laut Handbuch
typisch 16 MB, abhängig vom Bildinhalt; nicht komprimiert 25 MB), "TIFF"
(RGB, Dateigröße etwa 36 MB) sowie "JPEG" in drei Qualitätsstufen, wobei
ich die beste verwendet habe; von "JPEG2000" finde ich da nichts. Die
bislang vorhandenen JPEGs liegen zwischen etwa 4 und 11 MB bei 12 MP.

Da ich aber erst seit ein paar Monaten und nur als Hobby fotografiere,
ist das Thema "professionelle Bildbearbeitung" vorerst keines. Als
Speicherkarte verwende ich derzeit eine 8 GB CF-Karte.

Post by Thomas Kaiser
[...]

Michael

[Norbert Hahn]

Post by Thomas Kaiser

Post by Michael Unger
Ach ja: "jpeg2ps" hat auch so seine Tücken -- da wird nämlich an
völlig sinnloser Stelle ein "showpage" ausgegeben ...

Bitte was? Was ist daran sinnlos? Das ist erlaubt und sinnvoll. Solche
EPS kann man dann auch einfach so auf ein PostScript-Device schubsen,
und sie werden ausgegeben.

Naja, das ist aber neu! In...

Post by Thomas Kaiser
und fertig. Wenn Du selbst entsprechende Software (geschrieben) hast,
die damit nicht klarkommt, nochmal 5002.EPSF_Spec.pdf lesen.

... findet man auf Seite 32, dass showpage erst mit der Version 3 von
EPS erlaubt wurde:
"Changes Relevant to Applications Importing EPS Files
To help clarify the responsibilities of an application including an
EPS file, section 3, “Guidelines for Importing EPS Files,” specifies
the following new rules:
• The including application must define showpage as null."

Das Dokument stammt aus 1992, ist noch nicht mal 20 Jahre alt.

Norbert

[Thomas Kaiser]

Post by Norbert Hahn

Post by Thomas Kaiser
5002.EPSF_Spec.pdf

... findet man auf Seite 32, dass showpage erst mit der Version 3 von
"Changes Relevant to Applications Importing EPS Files
To help clarify the responsibilities of an application including an
EPS file, section 3, “Guidelines for Importing EPS Files,” specifies
• The including application must define showpage as null."
Das Dokument stammt aus 1992, ist noch nicht mal 20 Jahre alt.

Ja und? EPS selbst stammt aus dem Jahr 1987, d.h. obige Ergänzung wurde
fünf Jahre nach Geburt des Formats eingeführt und gilt schon mindestens
dreimal so lange. Sollte sich mittlerweile also langsam mal
rumgesprochen haben. Aber ist eigentlich eh wurscht -- (E)PS ist Stand
2010 sowas von deprecated. :-)

Gruss,

Thomas

[Michael Unger]

Post by Thomas Kaiser

Post by Norbert Hahn

Post by Thomas Kaiser
5002.EPSF_Spec.pdf

... findet man auf Seite 32, dass showpage erst mit der Version 3 von
"Changes Relevant to Applications Importing EPS Files
To help clarify the responsibilities of an application including an
EPS file, section 3, “Guidelines for Importing EPS Files,” specifies
• The including application must define showpage as null."

^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Post by Thomas Kaiser

Post by Norbert Hahn
Das Dokument stammt aus 1992, ist noch nicht mal 20 Jahre alt.

^^^^

Post by Thomas Kaiser
Ja und? EPS selbst stammt aus dem Jahr 1987, d.h. obige Ergänzung wurde
fünf Jahre nach Geburt des Formats eingeführt und gilt schon mindestens
dreimal so lange. Sollte sich mittlerweile also langsam mal
rumgesprochen haben.

Da ich die "PostScripterei" nur als Hobby betreibe, habe ich natürlich
noch nicht die komplette verfügbare Dokumentation gelesen; "learning by
doing" hat mich aber schnell auf die richtige Fährte gebracht.

Post by Thomas Kaiser
Aber ist eigentlich eh wurscht -- (E)PS ist Stand
2010 sowas von deprecated. :-)

Einspruch, Euer Ehren! Ich treibe "PostScript zu Fuß", wenn eine oder
mehrere der folgenden Konditionen zutreffen:

(1) Ich brauche absolut exakte Abmessungen. Das könnte demnächst einmal
relevant werden, wenn ich mal wieder eine individuelle Frontplatte für
einen 19"-Schrank haben will; Grundraster für Ausbrüche ist da meist
0,05", woran sich die Beschriftung dann zu orientieren hat.

(2) Es sind komplexere Rechnungen durchzuführen. Warum sollte ich das
vorher selber machen, wenn ich schon einen "Rechenknecht" zu diesem
Zweck habe?

(3) Für die Erzeugung der Ausgabe rennt die Prozedur in geschachtelten
Schleifen durch mehrdimensionale Arrays.

Michael

[Thomas Kaiser]

Post by Michael Unger

Aber ist eigentlich eh wurscht -- (E)PS ist Stand 2010 sowas von
deprecated. :-)

Einspruch, Euer Ehren! Ich treibe "PostScript zu Fuß", wenn eine oder

Ja, mag schon sein, daß es irgendwelche Nischen gibt, in denen man noch
PostScript spricht oder das Ganze sogar sinnvoll ist. Aber EPS als
Dateiformat, zumal wie es im grafischen Gewerbe häufig verwendet wird
(als Container für klassische Bilddaten, Stichwort "Photoshop EPS") ist
ein Auslaufmodell.

Nicht nur, daß gewisse Sachen mit (E)PS gar nicht bzw. maximal gaga
gehen (bspw. ICC-Farbmanagement -- funktioniert nur durch die Hintertür,
weil PostScript das eben nicht kennt. Und die Speicherung von Profilen
erfolgt laut Specs als ASCII-85-kodierte, de facto seitens Photoshop
aber als hexadezimal kodierte PostScript-Kommentare: Ein 1 MByte großes
Profil landet mit 2 MByte im EPS). Adobe selbst stellt sich inzwischen
einigermaßen taub, wenn man mit Bug-Reports, EPS betreffend, daherkommt.
An den Specs hat sich vor 10 Jahren das letzte mal was getan und der
Kram verschwindet in der Versenkung.

Ich hab bei 'nem Kunden demnächst die Aufgabe, "schnell mal eben" alle
Produktbilder (über 'ne halbe Mio.) von EPS nach TIFF umspeichern zu
lassen. Unter anderem aus Gründen der reduzierten Datenmenge: Als
TIFF-LZW verbraucht der Kram halt nicht mal die Hälfte Plattenplatz.
Insofern bin ich sehr gespannt auf Deine Beispieldaten bzgl. "LZW machen
Bilder größer" :-)

Gruss,

Thomas

[Michael Unger]

Post by Thomas Kaiser

Post by Michael Unger

Aber ist eigentlich eh wurscht -- (E)PS ist Stand 2010 sowas von
deprecated. :-)

Einspruch, Euer Ehren! Ich treibe "PostScript zu Fuß", wenn eine oder

Ja, mag schon sein, daß es irgendwelche Nischen gibt, in denen man noch
PostScript spricht oder das Ganze sogar sinnvoll ist.

Das "Übergabeformat" wäre im Zweifelsfall (natürlich) PDF.

Post by Thomas Kaiser
Aber EPS als
Dateiformat, zumal wie es im grafischen Gewerbe häufig verwendet wird
(als Container für klassische Bilddaten, Stichwort "Photoshop EPS") ist
ein Auslaufmodell.

Dem widerspreche ich ja gar nicht.

Post by Thomas Kaiser
[...]

Michael

[Norbert Hahn]

Post by Peter Konrad
Eigentlich erschiene es mir am Besten, wenn der PDFWriter die
Kompression der ins Word eingefügten Jpegs 1:1 übernähme, da ich einen
Qualitätsverlust befürchte, wenn die jpegs noch mal jpeg-komprimiert.

Ich kenne nicht alle Versionen von Word, aber bei einigen wird das
jpeg entpackt und als verlustfreie Rastergrafik (ähnlich PNG)
gespeichert. Der PDF-Writer sollte eigentlich diese Bitmap dann
bekommen und diese auf Deinen Wunsch hin nach jpeg eindampfen.

OpenOffice arbeitet da sehr ähnlich: Dort wird immer aus einer
Rastergrafik eine png-Datei erzeugt. Das Programm exportiert PDF
mit Bordmitteln. Details zur Grafikübergabe nach PDF kannst Du
einstellen.

Ich würde das PDF mal mit dem Adobe Reader aus der Nähe (=Zoom-
Funktion) ansehen. Evtl. sind die zusätzlichen Artefakte gar nicht
so schlimm.

Norbert

[Thomas Kaiser]

Post by Norbert Hahn

Post by Peter Konrad
Eigentlich erschiene es mir am Besten, wenn der PDFWriter die
Kompression der ins Word eingefügten Jpegs 1:1 übernähme, da ich einen
Qualitätsverlust befürchte, wenn die jpegs noch mal jpeg-komprimiert.

Ich kenne nicht alle Versionen von Word, aber bei einigen wird das
jpeg entpackt und als verlustfreie Rastergrafik (ähnlich PNG)
gespeichert. Der PDF-Writer sollte eigentlich diese Bitmap dann
bekommen und diese auf Deinen Wunsch hin nach jpeg eindampfen.

Und damit hat er die von ihm gefürchtete Neu-Kompressin der Bilddaten.

Post by Norbert Hahn
OpenOffice arbeitet da sehr ähnlich: Dort wird immer aus einer
Rastergrafik eine png-Datei erzeugt. Das Programm exportiert PDF
mit Bordmitteln. Details zur Grafikübergabe nach PDF kannst Du
einstellen.

D.h. wenn man mit Colormanagement nicht firm ist und das alte "RGB ist
schlecht, CMYK macht selig"-Mantra betet, wird man mit OpenOffice (dito
wohl Word, wenn man nicht EPS platziert) nicht froh? Da zwangsläufig
unprofiliertes RGB hinten rauskommt?

Post by Norbert Hahn
Ich würde das PDF mal mit dem Adobe Reader aus der Nähe (=Zoom-
Funktion) ansehen. Evtl. sind die zusätzlichen Artefakte gar nicht
so schlimm.

Genau das würde ich nicht machen, wenn das Ziel sein soll, die
Sichtbarkeit von Artefakten *im Druck* zu beurteilen. Das mag am
Bildschirm in Zoomstufe grottig aussehen aber verschwindet dann völlig
im Druck (BTDT schon vor 17 Jahren zu Beginn meiner Lehrzeit: Ein Bild
genommen, mit unterschiedlichen JPEG-Qualitätsstufen gesichert,
platziert, ausbelichtet, andrucken und die Herren Experten beurteilen
lassen. Einstimmig entschied sich die Expertenrunde nach kurzer
Beratschlagung für die "JPEG hoch"-Variante. "JPEG maximal" und
unkomprimiert fielen durch. Das Staunen nach Auflösung des Quiz war dann
zwar groß, änderte aber nichts an der verkrusteten Meinung, daß JPEG
Teufelszeug sei).

Dito starke USM (Unscharfmaskierung) beim Scannen. Am Bildschirm bei
100% betrachtet bluten einem die Augen, im Druck sieht's einfach nur
knackig scharf aus.

Wenn die Originalabbildungen 'ne ausreichend hohe Auflösung haben und
nicht schon bei 100% Betrachtung visuell sichtbare Artefakte mitbringen,
würde ich mir über eine Verschlechterung erstmal keine Gedanken machen
(außer die erneute JPEG-Kompression fällt vielzu hoch aus -- aber das
dürfte dem OP auch so klar sein).

Gruss,

Thomas

[Norbert Hahn]

Post by Thomas Kaiser

Post by Norbert Hahn
OpenOffice arbeitet da sehr ähnlich: Dort wird immer aus einer
Rastergrafik eine png-Datei erzeugt. Das Programm exportiert PDF
mit Bordmitteln. Details zur Grafikübergabe nach PDF kannst Du
einstellen.

D.h. wenn man mit Colormanagement nicht firm ist und das alte "RGB ist
schlecht, CMYK macht selig"-Mantra betet, wird man mit OpenOffice (dito
wohl Word, wenn man nicht EPS platziert) nicht froh? Da zwangsläufig
unprofiliertes RGB hinten rauskommt?

Ganz so schaurig ist OpenOffice nicht: Man kann den Farbraum beim
PDF-Export nicht ändern. An dieser Stelle geht nichts kaputt.
OpenOffice verwendet (wie die älteren Versionen von MS Office) nur
sRGB als Farbraum.

Norbert

[Thomas Kaiser]

Post by Norbert Hahn
Ganz so schaurig ist OpenOffice nicht: Man kann den Farbraum beim
PDF-Export nicht ändern. An dieser Stelle geht nichts kaputt.
OpenOffice verwendet (wie die älteren Versionen von MS Office) nur
sRGB als Farbraum.

Hmm... d.h. wenn ich in OpenOffice Bilder platziere, die bspw. in
ECI-RGB vorliegen, dann erledigt OpenOffice bei der Ausgabe die
Farbraumtransformation nach sRGB?

Gruss,

Thomas