expertenaustausch > comp.* > comp.text.pdf

Ralf Koelbach (19.08.2007, 10:27)
Hallo,

meine wissenschaftlichen Texte habe ich immer in LaTex erstellt. PDFs
erzeugte ich dabei mit ps2pdf.

Nun sprach mich ein Verlag zwecks Veröffentlichung an. Dafür aber soll
die abzuliefernde PDF nicht mit einem Freeware-Programm, sondern mit
Adobe Acrobat 8 Pro erzeugt werden. Außerdem unter Verwendung einer
speziellen vdm-Konfigurationsdatei.

Dazu habe ich ein paar Fragen:

1. Den Adobe Acrobat Pro 8 habe ich nicht, aber die Version 7 Standard.
Sollte die ausreichen?

2. Den Adobe kann ich AFAIK nicht als Druckertreiber in LaTex einbinden
(mein Editor dort ist WinEdt). Ist es stattdessen der richtige Weg, im
Adobe Acrobat über "Datei einlesen" zu gehen und die PS-Datei (die habe
ich mir im LaTex-Editor mit dvi2ps erzeugt) des Dokumentes einzulesen
und diese dann in PDF zu konvertieren?

3. Wird bei "Datei einlesen" eigentlich der Distiller oder der PDF-Maker
genutzt? Falls es eine Auswahl gibt - welcher ist der richtige, um die
Konformität hinzubekommen?

4. Gibt es bessere Wege als den in 2. beschriebenen, um aus der PS-Datei
eine Acrobat-konforme PDF zu erzeugen?

Herzlichen Dank vorab!

Ralf
Rolf Niepraschk (20.08.2007, 00:29)
Ralf Koelbach schrieb:
> Hallo,
> meine wissenschaftlichen Texte habe ich immer in LaTex erstellt. PDFs
> erzeugte ich dabei mit ps2pdf.


Eine sicher nicht zu unterschätzende Alternative ist pdfLaTeX.

> Nun sprach mich ein Verlag zwecks Veröffentlichung an. Dafür aber soll
> die abzuliefernde PDF nicht mit einem Freeware-Programm, sondern mit
> Adobe Acrobat 8 Pro erzeugt werden. Außerdem unter Verwendung einer
> speziellen vdm-Konfigurationsdatei.


Ich habe es bisher noch nicht erlebt, dass Ergenisse von den in Rede
stehenden Freeware-Programmen (richtiger: OpenSource) irgendwelche
Probleme bereiten. Du solltest Dich nicht durch irgendwelche dummen
Sprüche ins Bockshorn jagen lassen.

....Rolf
Michael Zedler (20.08.2007, 08:22)
Rolf Niepraschk schrieb:
> Ich habe es bisher noch nicht erlebt, dass Ergenisse von den in Rede
> stehenden Freeware-Programmen (richtiger: OpenSource) irgendwelche
> Probleme bereiten. Du solltest Dich nicht durch irgendwelche dummen
> Sprüche ins Bockshorn jagen lassen.


<fa449m$e5d$00$1>

Michael
Nikolaus Breuer (23.08.2007, 12:14)
Rolf Niepraschk schrieb:
> Ich habe es bisher noch nicht erlebt, dass Ergebnisse von den in Rede
> stehenden Freeware-Programmen (richtiger: OpenSource) irgendwelche
> Probleme bereiten.

Davon bin aus Erfahrung auch überzeugt. Mitunter stellt sich höchstens
schon 'mal die Frage, ob bzw. wann sie den mitunter unabdingbar
benötigten Funktionsumfang bereitstellen, den die großen teuren
kommerziellen Brüder erlauben.
Konkret kämpfe ich gerade konkret mit dem Problem, ein komplett in LaTex
gesetztes Buch mit vielen Digital-Photos (.jpg im sRGB Farbraum) in ein
von der Druckerei akzeptiertes pdf (EuropeISOCoated CMYK) zu
konvertieren (weitere Details in meinem Beitrag im Thread "Distiller vs.
PSNormalizer vs. GhostScript" von heute).
In einer Anfrage in TEX-D-L erhielt ich einen lapidaren
Hinweis 'pdftex kann das, samplepdf.tex zeigt wie', der mir leider nicht
sehr viel weitergeholfen hat (denn dort wird lediglich - in der mir
nicht vertrauten 'pure' pdftex Syntax - angedeutet, wie man ein
_einzelnes_ (RGB) file mit einem anderen RGB-profil 'verschönern' kann).

Ich würde natürlich gerne pdflatex (mit direktem jpg support) benutzen,
habe aber bislang nichts gefunden, das von der Verwendung von input und
output icc-profiles handelt. Also ist Einzel-Bild-Behandlung der einzige
workaround, der mit bisher dazu eingefallen ist:

1. Nach Bearbeitung der Original .jpg's als tif's (verlustlos) speichern.
2. Mit tifficc in den korrekten Offset Colorspace konvertieren
3. Mit tiff2pdf (oder besser wg. neuerer language levels: tiff2ps plus
pstopdf) für jedes Bild ein .pdf (jetzt CMYK für den richtigen
Offset-Farbraum).
4. pdflatex mit \includegraphics{..} der .pdf Bilder.

Geht es (das Color-Management mit Open-Source-Tools LaTex + ??)
vielleicht doch viel einfacher mit der richtigen 'magischen' gs
Kommandozeile ?

MfG NB

PS Kurioserweise findet man in der 'einschlägigen' (m.E. ansonsten
ausgezeichneten!) ganz aktuellen LaTex Literatur wie ('Begleiter' von
2007, PSTricks von 2007, und auch im gerade neu aufgelegten 'Graphics
Companion' von 2007) keinen einzigen Hinweis auf Color-Management
und/oder ICC-Profile. Na klar ist das kein genuines Tex-Thema, aber für
die Verwendung von tex, pdftex, ... zur Erzeugung eines für die
Druckvorstufe brauchbaren pdf Dokumentes doch eigentlich ein
unabweisbares Thema, wenn es nicht nur um Zeichnungen, sondern auch z.B.
um Photos geht, deren Farben halbwegs ähnlich im Buchdruck erscheinen
soll ... Wie machen das eigentlich die scientific publisher, machen die
das dann mit 'ihrem' Distiller ?
Mathias Lindner (24.08.2007, 14:10)
Nikolaus Breuer schrieb:
[...]
> 1. Nach Bearbeitung der Original .jpg's als tif's (verlustlos) speichern.
> 2. Mit tifficc in den korrekten Offset Colorspace konvertieren
> 3. Mit tiff2pdf (oder besser wg. neuerer language levels: tiff2ps plus
> pstopdf) für jedes Bild ein .pdf (jetzt CMYK für den richtigen
> Offset-Farbraum).
> 4. pdflatex mit \includegraphics{..} der .pdf Bilder. [...]


Hallo,

da ich auch desöfteren viele Bilder umwandeln muss (in meinem Fall von
eps in pdf) habe ich mir ein kleines Batchfile geschrieben, dass die
Sache für mich erledigt. Zumindest die Punkte 2 und 3 kannst du ja auch
dementsprechend automatisieren:

eps2pdf.bat:

dir *.eps /B > temp.txt
For /f %%i in (temp.txt) Do epstopdf %%i
del temp.txt
pause

Einfach die bat-Datei in den Ordner mit den Bildern kopieren und
ausführen...

Hoffe, das hilft dir weiter...

Mathias
Nikolaus Breuer (24.08.2007, 17:29)
Mathias Lindner schrieb:
da ich auch desöfteren viele Bilder umwandeln muss (in meinem Fall von
> eps in pdf) habe ich mir ein kleines Batchfile geschrieben, dass die
> Sache für mich erledigt. Zumindest die Punkte 2 und 3 kannst du ja auch
> dementsprechend automatisieren:

Hi Mathias,
danke für den Hinweis, so ähnlich (shell script unter Linux, den tif
Zwischenschritt brauche ich wegen der icc-tools) mache ich 's dann auch,
das geht, ist aber bei 100+ Bildern, die gelegentlich nochmals
bearbeitet werden müssen, kein richtiges Vergnügen, etwas länglich und
unübersichtlich/fehleranfällig.
Daher suche ich eigentliche ja nach wie vor eine Möglichkeit, das
(Umwandeln der Farbräume von sRGB nach Offset CMYK) 'auf einen Schlag'
am fertigen .ps zu machen, wie 's mit dem 'richtigen' zwar Distiller
geht, aber den habe ich nun 'mal nicht) ..., Leider hat mit bislang noch
keiner der TeX und/oder PostScript/GhostScript Guru's verraten, ob das
mit ghostscript nun geht oder nicht, und wenn ja, wie genau ;-( ...

Gruß NB
Mathias Lindner (24.08.2007, 18:41)
Nikolaus Breuer schrieb:
[..]
> keiner der TeX und/oder PostScript/GhostScript Guru's verraten, ob das
> mit ghostscript nun geht oder nicht, und wenn ja, wie genau ;-( ...
> Gruß NB


Wenn ich dich richtig verstanden habe, wäre vielleicht das Tool ps2pdf
für dich geeignet. Das hat eine Option zum Einstellen des Farbraums:

dProcessColorModel=device_color_space
mit: device_color_space may be /DeviceGray, /DeviceRGB, or /DeviceCMYK

Infos gibt's z.B. hier:


Mehr kann ich dazu leider nicht sagen, ich habe das Tool noch nie
benutzt. Aber das klang sehr vielversprechend.

Gutes Gelingen,

Mathias
Mathias Lindner (24.08.2007, 18:42)
Mathias Lindner schrieb:
[..]
> benutzt. Aber das klang sehr vielversprechend.
> Gutes Gelingen,
> Mathias


Sehe gerade, dass du ps2pdf ja schon verwendest... Geht das mit dem
Farbraum nicht, oder ist das was anderes?
Rolf Niepraschk (24.08.2007, 20:32)
Mathias Lindner schrieb:
....
> Hoffe, das hilft dir weiter...


Kaum anzunehmen, da der Hinweis nahezu gar nichts mit dem geschilderten
Problem zu tun hat.

....Rolf
Mathias Lindner (25.08.2007, 11:08)
Rolf Niepraschk schrieb:
> Mathias Lindner schrieb:
> ...
>> Hoffe, das hilft dir weiter...

> Kaum anzunehmen, da der Hinweis nahezu gar nichts mit dem geschilderten
> Problem zu tun hat.
> ...Rolf


Wenn schon keiner eine Idee hat, wollte ich wenigstens zeigen, wie der
bisherige Weg ein bisschen schneller gegangen werden kann... Wo hat das
denn bitte nichts mit dem Problem zu tun???

Mathias
Thomas Kaiser (25.08.2007, 21:37)
Ralf Koelbach schrieb am 19.08.2007 in <news:fa8usv$jdu$01$1>
> Nun sprach mich ein Verlag zwecks Veröffentlichung an. Dafür aber soll
> die abzuliefernde PDF nicht mit einem Freeware-Programm, sondern mit
> Adobe Acrobat 8 Pro erzeugt werden. Außerdem unter Verwendung einer
> speziellen vdm-Konfigurationsdatei.


Was ist eine "vdm-Konfigurationsdatei"?

> Dazu habe ich ein paar Fragen:
> 1. Den Adobe Acrobat Pro 8 habe ich nicht, aber die Version 7 Standard.
> Sollte die ausreichen?


IMO ist Acrobat Pro *Grundvoraussetzung* für PDFs, die Richtung
Druckerei gehen sollen.

> 2. Den Adobe kann ich AFAIK nicht als Druckertreiber in LaTex einbinden
> (mein Editor dort ist WinEdt). Ist es stattdessen der richtige Weg, im
> Adobe Acrobat über "Datei einlesen" zu gehen und die PS-Datei (die habe
> ich mir im LaTex-Editor mit dvi2ps erzeugt) des Dokumentes einzulesen
> und diese dann in PDF zu konvertieren?


Yep.

> 3. Wird bei "Datei einlesen" eigentlich der Distiller oder der PDF-Maker
> genutzt? Falls es eine Auswahl gibt - welcher ist der richtige, um die
> Konformität hinzubekommen?


Der PDF-Maker ist nur eine Komponente für paar Anwendungen (M$-Office,
Autocad, keine Ahnung, was noch), die den PS-Code aus diesen Anwendungen
mittels PDF-Marks anreichert, die dann dafür sorgen, daß Metadaten und
Strukturinformationen (Hyperlinks, klickbares Inhaltsverzeichnis, etc.)
im PDF landen. Die Umwandlung von PS nach PDF geschieht in jedem Fall
per Distiller (oder DistillerLib, wenn der "Druckertreiber-Weg"
beschritten wird)

> 4. Gibt es bessere Wege als den in 2. beschriebenen, um aus der
> PS-Datei eine Acrobat-konforme PDF zu erzeugen?


Wenn Du mit pdflatex werkeln solltest, dann ggf. ein Pimpem des PDF in
Acrobat Pro.

Gruss,

Thomas
Christoph Bier (27.08.2007, 11:42)
Thomas Kaiser schrieb am 25.08.2007 21:37:

> Ralf Koelbach schrieb am 19.08.2007 in <news:fa8usv$jdu$01$1>


[...]

>> 1. Den Adobe Acrobat Pro 8 habe ich nicht, aber die Version 7 Standard.
>> Sollte die ausreichen?

> IMO ist Acrobat Pro *Grundvoraussetzung* für PDFs, die Richtung
> Druckerei gehen sollen.


Kannst Du das vielleicht konkret anhand eines Beispiels begründen?
Ich habe natürlich schon öfter gelesen, dass man für die digitale
Druckvorstufe an Acrobat Pro nicht vorbei käme. Aber ich habe noch
nie erlebt, dass es Probleme mit nicht von Acrobat Pro erzeugten
PDF-Dateien gab (auch nicht bei Freunden und Kollegen). Ich habe
schon einige von pdfTeX erzeugte Bücher und andere Drucksachen
drucken lassen und es gab nie Probleme; auch am Druckergebnis war
nichts auszusetzen. Mag sein, dass in der Druckerei nochmal Acrobat
Pro auf die Dateien losgelassen wurde. Aber in etwa fünf Fällen weiß
ich genau, dass dies nicht der Fall war, weil ich aus Neugier
nachgefragt hatte. -- Was macht Acrobat Pro denn besser als andere
Programme, die PDF erzeugen?

[...]

Grüße
Christoph
Markus Kohm (31.08.2007, 11:16)
Christoph Bier wrote:

> Was macht Acrobat Pro denn besser als andere
> Programme, die PDF erzeugen?


Es beachtet die Beschränkungen des AdobeReaders - auch diejenigen, die nicht
dokumentiert sind und bisher noch niemand zufällig herausgefunden hat. Ich
erinnere mich da beispielsweise an Probleme mit einigen PDFs, die beim
Umstieg von AcroReader 4 auf 5 (oder war das bei 3 auf 4?) plötzlich nicht
mehr angezeigt werden konnten, weil Adobe die Spezifikation plötzlich
anders ausgelegt hatte.

Wenn man Quellen mit unterschiedlichen Farbräumen hat, ist Acrobat Pro wohl
auch recht komfortabel in der Druckvorstufe zu verwenden. Ich habe da
durchaus schon erlebt, dass PDFs von pdflatex mit ein paar Klicks
nachbearbeitet wurden. Ich habe das nie selbst gemacht - nur zugesehen.

> Ich habe schon einige von pdfTeX erzeugte Bücher und andere
> Drucksachen drucken lassen


Weil das normalerweise sehr gut funktioniert und ggf. mit Acrobat Pro
problemlos nachgeholfen werden kann, habe ich bei einem Verlag dafür
gekämpft bzw. kämpfen lassen, dass die Anforderung, der Autor müsse die
PDFs mit Acrobat Pro erstellen, in den Autorenrichtlinien aufgeweicht wird
und auch pdfTeX zugelassen wird. Die haben das nicht kapiert und ich weiß
jetzt nicht einmal, ob meine diversen Versuche, es ihnen trotzdem
unterzuschieben, letztlich erfolgreich waren. Von einem Autor Acrobat Pro
zu verlangen, ist jedenfalls unverschämt und nur dann sinnvoll, wenn der
Verlag und die Druckerei selbst kein Acrobat Pro oder nur unfähige Leute
hat. Ein Problem ist dabei in der Regel eher der Verlag und seltener die
Druckerei. Verlage haben gerne automatische Vorlagenprüfungen. Da kann
schon ein falscher Creator-Eintrag dafür sorgen, dass das PDF zurück an den
Autor geht.

Gruß
Markus
Christoph Bier (31.08.2007, 19:34)
Markus Kohm schrieb am 31.08.2007 11:16:

> Christoph Bier wrote:
>> Was macht Acrobat Pro denn besser als andere
>> Programme, die PDF erzeugen?


[Antwort]

>> Ich habe schon einige von pdfTeX erzeugte Bücher und andere
>> Drucksachen drucken lassen


[Antwort]

Danke für Deine Antworten!

Grüße
Christoph
Thomas Kaiser (02.09.2007, 15:32)
Christoph Bier schrieb am 27.08.2007 in <news:5jfkkoF3t16ndU1>
> Thomas Kaiser schrieb am 25.08.2007 21:37:
>> IMO ist Acrobat Pro *Grundvoraussetzung* für PDFs, die Richtung
>> Druckerei gehen sollen.

> Kannst Du das vielleicht konkret anhand eines Beispiels begründen?


Ich hol einfach bisserl aus :-)

Bzgl. einer Konvertierung von PostScript Richtung PDF ist IMO der
Distiller sowas wie "Industriestandard" in der Form, daß man dort zum
einen die meisten Optionen hat, prepress-taugliches PDF zu erzeugen, zum
anderen die Macken der jeweiligen Distiller-Version allgemein bekannt
sind und schließlich sich relativ simpel schon beim PDF-Ersteller
dokumentieren läßt, mit welchen Settings aus PS PDF gemacht wird:

<http://www.impressed.de/t/produkt.taf?fn=detail&PR_ID=1108>

Andere PS-zu-PDF-Konverter unterstützen meist nur ein Subset der
Features (wird dann v.a. im mehrfarbigen Bereich spannend) als auch ein
Subset der Parametrisierungsoptionen -- Joboptions, vgl. bspw. mit:

<http://cvs.ghostscript.com/cgi-bin/viewcvs.cgi/*checkout*/ghostscript/tags/ghostscript-8.60/doc/Ps2pdf.htm?rev=8164#Options>

Und dann gibt es noch welche, bei denen alleine schon durch Abweichungen
beim GUI Anwender in Fehler laufen, die einfach nicht sein müssten.
Wieviel Drucksachen schon direkt Richtung Papiercontainer wanderten oder
mit versauten Bilddaten dann doch ausgeliefert wurden, nur weil die
Genies bei Quark bei der Ansteuerung des von denen lizensierten JAWS
PDF-Creator die Parametrisierung der JPEG-Kompression für Bilddaten
genau andersrum wie beim Distiller gewählt haben, möchte ich mir gar
nicht vorstellen müssen ("hoch" bedeutet bei Quark, starke Kompression
und nicht hohe Qualität -- ich kenne kaum einen Quark-Anwender, der da
nicht schon auf die Fresse gefallen ist 'mit)

Nun gibt es heutzutage aber genügend PDF-Erzeugungsprozesse, bei denen
PostScript gar keine Rolle mehr spielt. Und auf der anderen Seite kann
es eigentlich auch wurscht sein, _wie_ ein PDF entstanden ist, solange
es nur den relevanten Specs/Standards entspricht (bspw. PDF/X als
branchenweit akzeptiertes PDF-Subset mit Druckbarkeit im Hinterkopf).

Und hier kommt die IMO wichtigere Komponente ins Spiel. Acrobat *Pro*
ist ja mehr als nur der Distiller und primitver PDF-Viewer. Sondern eben
auch Prüfwerkzeug (seit Acrobat 6 ist Callas' pdfInspektor Bestandteil
der Pro-Version, ein IMO unverzichtbares Werkzeug, um Spezifikations-
konformität zu prüfen/einzuhalten und Fehler abzufangen, die man mit
rein formalen Kontrollen nicht abfangen kann), PDF-Konverter und -- in
Grenzen -- PDF-Editor.

Zum Prüfen gehören Sachen wie eben "PDF Preflight" AKA pdfInspektor
(Prüfung formaler Kriterien) aber auch die Überdruckenvorschau

Die Editierfähigkeit fängt bei so Primitivkram an, daß ein Output
Profile gesetzt werden kann, um PDF/X-Kompatibilität zu erreichen, geht
über weitere eher formale Korrekturen hinaus (Setzen von Boxen, Fonts
nachträglich einbetten, Farbdefinitionen korrigieren/konsolidieren,
Transparenzreduzierung, etc.) bis schließlich hin zu relativ komplexen
Korrekturen per bspw. Pitstop Plugin.

Brauchen tut man das alles nicht zwangsweise, wenn man spezifikations-
konformes PDF erzeugen kann *und* beim PDF-Weiterverarbeiter mal nicht
gerade irgendwelche Pfeifen an den Rechnern sitzen.

Während Ersteres vielleicht noch durch Fixierung des Workflows und
einmalige Überprüfung der Spezifikationskonformität in der Vergangenheit
geleistet werden kann (um bei Deinem Beispiel zu bleiben: Publikationen
aus pdflatex heraus produzieren ohne daß an den Randbedingungen was
geändert wird), hast Du Letzteres nicht in der Hand.

Sogar wenn Du völlig korrektes PDF ablieferst, kann irgendwer beim
Datenempfänger damit noch Murks anstellen (alles schon erlebt --
irgendein Hirni öffnet das PDF dann bspw. in Preview.app am Mac und
druckt dann aus dem Ding direkt auf einen Belichter. Bloß schade, daß
dabei sowohl einiges vom Seiteninhalt auf der Strecke bleibt als auch
die auf der Titelseite des PDF platzierten Hinweise -- als Annotation --
niemanden interessierten, weil Preview.app das erst seit MacOS X 10.4
überhaupt anzeigt).

In so einem Fall ist es Gold wert, parallel zum PDF einen Prüfreport an
der Hand zu haben bzw. gleich mitgeliefert zu haben, weil dann beim die
Ausgabe verbockt habenden Dienstleister erst gar keiner auf die Idee
kommt, Dir die Schuld für den Berg Makulatur in die Schuhe schieben zu
wollen.

Ich habe das, was alles bei Transfer von PDF-Druckdaten und Ausgabe
derselben alles schief laufen kann, im letzten Jahrzehnt wohl aus jeder
Perspektive kennengelernt (sowohl als Verarbeiter, als Ersteller, als
Autor, dessen angelieferte Daten seitens Verlag quasi einmal durch den
Fleischwolf gedreht im PDF gelandet sind, als Designer von konzern-
weiten PDF-Standards, etc.). Und es ist erstaunlich, wie viel Fehler-
potential der ganze Prozeß mitbringt, wie oft tatsächlich was schief-
läuft und wie normalerweise ganz reflexmäßig überall die Schuld erstmal
wem anders zugeschoben werden soll (Bemühungen hinsichtlich Erhöhung der
Produktionssicherheit gehören in den meisten Läden irritierenderweise
fast schon zu den geradezu obszönen Ansinnen)

Vor dem Hintergrund ist Acrobat *Pro* einfach sowohl absolut preiswertes
Werkzeug, um die Ausgabefähigkeit von PDF-Daten sicherzustellen als auch
Versicherung für den Makulatur-Fall. Ich zumindest würde mir das
Vabanque-Spiel nicht mehr antun wollen, ohne Aufwertung von PDF zu
PDF/X, inhaltlicher Kontrolle der Seiteninhalte via Acrobat und "PDF
Preflight" und mit Prüfprotokoll in der Hand, Druckdaten in die
Produktion zu geben. Mag man vielleicht anders sehen, wenn noch nie so
richtig was schiefgelaufen ist (und bspw. nur absolut unnötige
Qualitätsverluste auftreten, die man dann evtl. auch erst viel zu spät
für 'ne Mängelrüge entdeckt)... aber gebranntes Kind scheut das Feuer
und so ;-)

Gruss,

Thomas, zwischendurch die Gruppe im Newsreader verschusselt, daher so
späte Antwort

Ähnliche Themen