PDF Normen PDF/X3 und PDF/A
Andreas Weber
angeregt von einem Thread unter d.c.t.tex
vgl. Message-ID: <200903180...@b.maus.de>
interessiert mich nun ob und wie ich ueberpruefen
kann ob mein PDF Dokument PDF/X, bzw.
PDF/X3 konfrom ist. Oder auch PDF/A konform
Alles was ich bisher gefunden habe ist die "Preflight
Funktion" im acrobat von adobe oder andere Produkte
die speziell fuer Adobe Acrobat sind.
Gibt es freie/kostenfreie Tools die
a) eine solche Ueberpruefung ermoeglichen? und
b) wie, bzw. kann ich eine PDF/X(3) (eventuell auch PDF/A)
Erstellung mit latex/dvips und hyperref package und dann
mit ghostscript erstellen? Wenn ja wie?
vgl. http://de.wikipedia.org/wiki/PDF/A sowie
http://de.wikipedia.org/wiki/PDF/X-3 und
http://de.wikipedia.org/wiki/Portable_Document_Format
Andi
Thomas Kaiser
> angeregt von einem Thread unter d.c.t.tex vgl. Message-ID:
> <200903180...@b.maus.de> interessiert mich nun ob und wie ich
> ueberpruefen kann ob mein PDF Dokument PDF/X, bzw. PDF/X3 konfrom ist.
> Oder auch PDF/A konform
Für Letzteres gibt es hier eine Online-Demo, die auf pdfaPilot Server
(<http://www.callassoftware.com/callas/doku.php/de:products:pdfapilotserver>)
basiert:
<http://www.datalogics.com/products/callas/callaspdfA-onlinedemo.asp>
> Alles was ich bisher gefunden habe ist die "Preflight Funktion" im
> acrobat von adobe oder andere Produkte die speziell fuer Adobe Acrobat
> sind.
Bzgl. PDF/A gibt es noch Alternativen:
<http://www.pdfa.org/doku.php?id=pdfa:faq#pdf_a-validierung>
Bei PDF/X wirst Du meines Wissens nicht um Callas' Tools herumkommen
(Adobe hat die Engine für "Acrobat Preflight" von den Berlinern
lizensiert. Direkt von Callas gibt es mit erweiterter Funktionalität
noch die pdfToolBox als Plugin für Acrobat bzw. als CLI-Variante für den
Server-Betrieb)
> Gibt es freie/kostenfreie Tools die
> a) eine solche Ueberpruefung ermoeglichen? und
Siehe oben. Für PDF/X findest Du ggf. auch Online-Dienste, die so eine
Überprüfung gratis übernehmen. Die Crux dabei: Niemand wird Dir
garantieren, daß das Ganze auch wirklich verbindlich ist und der Upload
ist meist auf paar MByte beschränkt.
> b) wie, bzw. kann ich eine PDF/X(3) (eventuell auch PDF/A) Erstellung
> mit latex/dvips und hyperref package und dann mit ghostscript
> erstellen? Wenn ja wie?
GhostScript/pdflatex machen lassen, was sie wollen und das Ergebnis mit
pdfaPilot, pdfToolbox(CLI) oder Acrobat Pro passend machen. Im Ernst:
Wer über PDF/X nachdenkt, kommt um Acrobat Pro nicht drumherum. Wen nur
PDF/A interessiert, kann mit den oben aufgeführten Tools eventuell
glücklich werden. Für Wald-und-Wiesen-PDF tun's dann auch die bekannten
OpenSource-Kollegen.
> vgl. http://de.wikipedia.org/wiki/PDF/A sowie
> http://de.wikipedia.org/wiki/PDF/X-3 und
> http://de.wikipedia.org/wiki/Portable_Document_Format
Zur Vertiefung:
http://www.pdfa.org/
http://www.pdfx-ready.ch/index.php?show=27
Gruss,
Thomas
Andreas Weber
>> <200903180...@b.maus.de> interessiert mich nun ob und wie ich
>> ueberpruefen kann ob mein PDF Dokument PDF/X, bzw. PDF/X3 konfrom ist.
>> Oder auch PDF/A konform
>
> Für Letzteres gibt es hier eine Online-Demo, die auf pdfaPilot Server
Naja, eine Demo bringt ja wenig, wenn man seine
Promotionsarbeit, Master-Thesis (Diplom) oder aehnliches
in einer Druckerei drucken lassen will.
>> Alles was ich bisher gefunden habe ist die "Preflight Funktion" im
>> acrobat von adobe oder andere Produkte die speziell fuer Adobe Acrobat
>> sind.
>
> Bzgl. PDF/A gibt es noch Alternativen:
>
> <http://www.pdfa.org/doku.php?id=pdfa:faq#pdf_a-validierung>
>
> Bei PDF/X wirst Du meines Wissens nicht um Callas' Tools herumkommen
> (Adobe hat die Engine für "Acrobat Preflight" von den Berlinern
> lizensiert. Direkt von Callas gibt es mit erweiterter Funktionalität
> noch die pdfToolBox als Plugin für Acrobat bzw. als CLI-Variante für den
> Server-Betrieb)
Ja, das Drucken ist eigentlich das wichtige. ;-)
Auch sind, soweit ich das jetzt entsinne, die pdf/a Spezifikationen
doch so gehalten, dass ein pdf/x3 dokument auch gleichzeitig
ein pdf/a sein kann. Aber pdf/a ist zum druck einer wissenschaftlichen
nicht wichtig und war nur ein Nebengedanke von mir.
>> Gibt es freie/kostenfreie Tools die
>> a) eine solche Ueberpruefung ermoeglichen? und
>
> Siehe oben. Für PDF/X findest Du ggf. auch Online-Dienste, die so eine
> Überprüfung gratis übernehmen. Die Crux dabei: Niemand wird Dir
> garantieren, daß das Ganze auch wirklich verbindlich ist und der Upload
> ist meist auf paar MByte beschränkt.
Ja, das ist ja dumm. Gerade auch die Groessenbeschraenkung.
Dann muss ich ja wirklich damit rechnen, das die Druckerei nicht
mit meinem PDF zurechtkommt. :-(
Die Ironie dabei ist, dass ich mir vermutlich laengst ein Acrobat
oder anderes Produkt haette kaufen koennen. Selbst die Acrobat
Pro Extended, bei all der Zeit die fuer latex schon noetig war und
alles ist noch nicht geklaert. Naja, macht zwar auch irgendwo Spass,
aber ob ich das nicht doch noch bereue... mal sehen.
>> b) wie, bzw. kann ich eine PDF/X(3) (eventuell auch PDF/A) Erstellung
>> mit latex/dvips und hyperref package und dann mit ghostscript
>> erstellen? Wenn ja wie?
>
> GhostScript/pdflatex machen lassen, was sie wollen und das Ergebnis mit
> pdfaPilot, pdfToolbox(CLI) oder Acrobat Pro passend machen. Im Ernst:
> Wer über PDF/X nachdenkt, kommt um Acrobat Pro nicht drumherum. Wen nur
> PDF/A interessiert, kann mit den oben aufgeführten Tools eventuell
> glücklich werden. Für Wald-und-Wiesen-PDF tun's dann auch die bekannten
> OpenSource-Kollegen.
Wald und Wiesen PDF waere ja ok, wenn es nicht gedruckt werden
muesste und man dann kurz vor Abgabetermine die Arbeit von
der Druckerei zurueckbekommt. Das ist dann extrem unangenehm ;-)
vgl. den Fall den Message-ID: <200903180...@b.maus.de>
schildert.
Wie meinst du das mit Acrobat Pro "passend machen"? Kann man
quasi ein mit latex/gs erstelltes pdf mit Acrobat oeffnen und
normal weitereditieren? Ist ein mit Acrobat erstelltes PDF nicht
auch ganz anders aufgebaut? Gerade wenn ich an die von X3 geforderte
Dokumentenstruktur denke.
Mein PDF scheint das gar nicht zu haben. Da meckert schon der
Acrobat Reader wenn ich mit "Accessibility Quick Check" das
PDF ueberpruefe. "This document is not sructured..." :-(
Jedenfalls danke fuer deine Hinweise.
Andi
Christoph Bier
[...]
> Ja, das ist ja dumm. Gerade auch die Groessenbeschraenkung.
> Dann muss ich ja wirklich damit rechnen, das die Druckerei nicht
> mit meinem PDF zurechtkommt. :-(
Das habe ich noch *nie* erlebt und ich habe schon einige mit pdfTeX
erzeugte Dokumente und Bücher in den letzten Jahren drucken lassen (ja,
ich habe den Thread in dctt verfolgt ...). Und nicht nur in
Wald-und-Wiesen-Druckereien um die Ecke ... Lass Dich nicht verrückt machen.
[...]
Grüße
Christoph
--
+++ Typografie-Regeln: http://zvisionwelt.de/downloads.html (1.6)
Thomas Kaiser
> Hallo Thomas,
>
>>> <200903180...@b.maus.de> interessiert mich nun ob und wie ich
>>> ueberpruefen kann ob mein PDF Dokument PDF/X, bzw. PDF/X3 konfrom ist.
>>> Oder auch PDF/A konform
>>
>> basiert:
>
> Naja, eine Demo bringt ja wenig, wenn man seine Promotionsarbeit,
> Master-Thesis (Diplom) oder aehnliches in einer Druckerei drucken
> lassen will.
Tja. Aber Dir geht's ja eigentlich eh nicht um PDF/A sondern PDF/X.
> Dann muss ich ja wirklich damit rechnen, das die Druckerei nicht
> mit meinem PDF zurechtkommt. :-(
Nein, Du kannst bloß nicht auf Basis von exakt zu diesem Zweck
geschaffenen ISO-Standards (PDF/X) sicherstellen, daß Du der Druckerei
Daten lieferst, die formal korrekt sind, mit denen also jemand, der
technisch halbwegs auf der Höhe der Zeit ist, problemlos umgehen können
muß.
Der Punkt ist doch der: Mit PDF/X wurde ein Subset veralteter PDF-
Spezifikationen geschaffen, um das Thema _Produktionssicherheit_
anzugehen, d.h. nahezu alles an PDF-Features, was für Druckproduktion
nicht nötig ist, rauszuschmeißen und gewisse andere Sachen verbindlich
vorzuschreiben. Wenn man sich anschaut, was alles für Müll bei
Druckereien und Printshops abgeliefert wird, dann ist so ein Ansatz auch
nur nachvollziehbar.
PDF/X hilft dabei gerade in Bereichen, in denen besonders arge Malheurs
passierten: Dem Bereich Farbe (drum ja auch sowas wie ein Output Intent,
der dem PDF anhaften muß und die Zieldruckbedingungen charakterisiert,
damit eindeutig geklärt ist, _wie_ der Kram farblich zu interpretieren
ist -- alles jetzt arg vereinfacht)
Der ganze Bereich kann jemandem, der eh keine Farbe im Dokument hat,
reichlich wurscht sein.
Und auch eine PDF/X-konformes Datei kann dazu führen, daß ein Druck-
erzeugnis direkt in die Tonne wandert. PDF/X stellt ja nur gewisse
formale Mindestanforderungen an PDFs aber keine inhaltlichen dar (alle
Schriften eingebettet aber Encoding vorher vom Treiber zerdeppert worde
--> keine Umlaute, alle Farbräume korrekt charakterisiert aber durch
blöde Distiller-Einstellungen nur noch Matschbilder im PDF, etc. etc.)
D.h. mit PDF/X transportierst Du nur eine Aussage bzgl. der Druck-
fähigkeit Deiner Daten zum Ausgabedienstleister. Und machst ihm klar,
daß Du im Thema bist und hast eine sichere Ausgangsposition, falls in
der Druckerei was $Seltsames passiert (und da kann 'ne Menge geschehen,
denn da stehen bspw. ColorServer, die ins PDF reinlangen, um den
Gesamtfarbauftrag zu reduzieren oder betagte Ausschieß-Softwares, die
ein Refrying durchführen, d.h. eine temporäre Rückumwandlung nach PS und
erneute Destillation -- steter Quell der Freude)
Versaut die Druckerei aus welchen Gründen auch immer irgendwas, dann
passiert meist Folgendes:
* Du liefertest Wald- und Wiesen-PDF: Du bist pauschal schuld
(schließlich hast Du noch nicht mal das Werkzeug, um die formale
Druckfähigkeit Deiner Daten zu kontrollieren --> leichte Beute)
* Von Dir kam PDF/X: Die Sache wird intern geprüft, denn der Fehler
_muß_ ja bei der Druckerei liegen außer Deine Daten waren inhaltich
fehlerhaft (was aber wiederum schon in der Druckerei schnell
nachzuprüfen ist)
Das ist der Hauptunterschied, wenn sich das "/X" zum "PDF" gesellt.
>>> b) wie, bzw. kann ich eine PDF/X(3) (eventuell auch PDF/A)
>>> Erstellung mit latex/dvips und hyperref package und dann mit
>>> ghostscript erstellen? Wenn ja wie?
>>
>> GhostScript/pdflatex machen lassen, was sie wollen und das Ergebnis
>> mit pdfaPilot, pdfToolbox(CLI) oder Acrobat Pro passend machen. [...]
>
> Wie meinst du das mit Acrobat Pro "passend machen"?
Ganz einfach: Einem perfekten druckfertigen PDF (auch aus TeX oder Word
[1]) kann bspw. schlichtweg noch bisserl Metadaten fehlen, damit es zum
PDF/X wird (konkret das Überdrucken-Flag und die Angabe eines Output
Intents). D.h. der Unterschied zwischen PDF und PDF/X besteht nur im
Hinzufügen von Metadaten und damit Herstellung der Standard-Konformität
(klare Kommunikation Richtung Ausgabedienstleister, wie das Ding
farblich zu interpretieren ist und ob in der Druckerei noch Trapping
stattfinden soll/darf oder nicht)
Es kann aber auch passieren, daß die PDF/X-Konvertierung in Acrobat
gravierende Mängel erkennt, d.h. _rechtzeitig_ warnt und die
Konvertierung verweigert, wenn dem ursprünglichen PDF die Druckfähigkeit
definitiv fehlt (bspw. keine Schriften eingebettet und auch nicht
auftreibbar, d.h. nachträglich einbettbar -- was auch nur wiederum ein
Risikofaktor ist!)
Und das ist der Sicherheitsfaktor, den die PDF/X-Konvertierung bzw.
Preflight-Funktion in Acrobat bedeutet: Rechtzeitig erkennen, daß was
nicht stimmt.
Nicht falsch verstehen: Man kann sicherlich aus TeX heraus druckbares
PDF erstellen (das dann ggf. nur durch Anreicherung mit Metadaten in
Acrobat und ohne Korrektur an irgendwelchen Elementen auch in PDF/X
umgewandelt werden kann). Aber man kann evtl. auch leicht PDF erstellen,
auf das diese Kriterien nicht zutreffen. Und dann ist der unterbleibende
Preflight halt evtl. der erste Schritt zum Malheur. Muß nicht sein, kann
aber. Und ohne Prüfung weiß man's halt erst, wenn die Druckerei anruft
oder man die Makulatur dort abholt...
> Kann man quasi ein mit latex/gs erstelltes pdf mit Acrobat oeffnen und
> normal weitereditieren?
Editieren sollte man ganz schnell vergessen. Aber Acrobat kann an der
Struktur was ändern.
> Ist ein mit Acrobat erstelltes PDF nicht auch ganz anders aufgebaut?
> Gerade wenn ich an die von X3 geforderte Dokumentenstruktur denke.
> Mein PDF scheint das gar nicht zu haben. Da meckert schon der Acrobat
> Reader wenn ich mit "Accessibility Quick Check" das PDF ueberpruefe.
> "This document is not sructured..." :-(
Das geht jetzt alles schon sehr in den Wald. Accessibility hat nichts
mit PDF/X zu tun (mit PDF/A-1a dagegen schon) und das Thema ist auch
trotz PDF/X einigermaßen komplex. Drum würde ich mir einen
Druckdienstleister suchen, der anbietet, das angelieferte PDF wenigstens
durch einen Preflight durchrauschen zu lassen, der das prüft, ob das
Dokument nach PDF/X konvertiert werden kann. Und wenn's nicht klappt,
dann den Preflight-Report zurücksendet und das Ding nicht "auf eigenes
Risiko" (bzw. Dein Risiko) weiter in die Produktion schleust.
Sowas kann eigentlich recht simpel automatisiert werden (wissen aber die
wenigsten Dienstleister). Mir fehlt da auch bisserl der Überblick, was
es da im Kleinauflagenbereich an fertigen Lösungen gibt. Die großen
Workflow-Lösungen erlauben das jedenfalls alle. Aber die haben auch
wiederum nur "große Druckereien" im Einsatz (und das häßlich oft falsch
bzw. hirntot parametrisiert)
Gruss,
Thomas
Thomas Kaiser
> Andreas Weber schrieb:
>
> [...]
>
>> Ja, das ist ja dumm. Gerade auch die Groessenbeschraenkung. Dann muss
>> ich ja wirklich damit rechnen, das die Druckerei nicht mit meinem PDF
>> zurechtkommt. :-(
>
> Das habe ich noch *nie* erlebt und ich habe schon einige mit pdfTeX
> erzeugte Dokumente und Bücher in den letzten Jahren drucken lassen
> (ja, ich habe den Thread in dctt verfolgt ...). Und nicht nur in
> Wald-und-Wiesen-Druckereien um die Ecke ... Lass Dich nicht verrückt
> machen.
Das hat ja nichts mit Verrücktmachen zu tun. Nur damit, daß man nicht
sicherstellen kann, daß die eigenen Druckdaten formal korrekt sind und
daß man im Falle von Problemen und wenn's darum geht, wer den "Stampf"
zahlen soll, meist eine deutlich schlechtere Ausgangsposition hat im
Vergleich zu mit Prüfreport geliefertem PDF/X (was genau genommen der
allgemeinen Situation von vor ein paar Jahren entspricht, also der prä-
PDF/X-Ära. Und noch paar Jahre vorher, als noch PostScript-Daten oder
offene Dateien zum Dienstleister geschickt wurden, war es im Allgemeinen
deutlich unsicherer als mit $irgendeiner Spielart von PDF heutzutage)
Gruss,
Thomas
Christoph Bier
> Christoph Bier schrieb am 27.03.2009 in <news:734b1oF...@mid.individual.net>
>> Andreas Weber schrieb:
>>
>> [...]
>>
>>> Ja, das ist ja dumm. Gerade auch die Groessenbeschraenkung. Dann muss
>>> ich ja wirklich damit rechnen, das die Druckerei nicht mit meinem PDF
>>> zurechtkommt. :-(
>> Das habe ich noch *nie* erlebt und ich habe schon einige mit pdfTeX
>> erzeugte Dokumente und Bücher in den letzten Jahren drucken lassen
>> (ja, ich habe den Thread in dctt verfolgt ...). Und nicht nur in
>> Wald-und-Wiesen-Druckereien um die Ecke ... Lass Dich nicht verrückt
>> machen.
>
> Das hat ja nichts mit Verrücktmachen zu tun. Nur damit, daß man nicht
> sicherstellen kann, daß die eigenen Druckdaten formal korrekt sind und
> daß man im Falle von Problemen und wenn's darum geht, wer den "Stampf"
Ja. Aber unter »nicht zurechtkommen« verstehe ich etwas anderes. Und da
ohnehin immer ein Andruck verschickt wird, kann man auch überprüfen, ob
Murks beim Drucken rausgekommen ist -- wobei das ja auch »nur« die
Farben betreffen würde, richtig? WIMRE geht es dem OP aber um
wissenschaftliche Texte und nicht um farbige Kataloge. Mein »Lass Dich
nicht verrückt werden« bedeutete nicht, dass PDF/X Unfug sei. Es ist nur
keine absolute Notwendigkeit (so wie es die Druckerei anscheinend bei
dem Betroffenen in dctt dargestellt hat). Ansonsten hast Du alles
Weitere ja in Deiner Antwort an Andreas geschrieben.
Thomas Kaiser
[PDF/X vs. PDF]
> Ja. Aber unter »nicht zurechtkommen« verstehe ich etwas anderes. Und
> da ohnehin immer ein Andruck verschickt wird, kann man auch
> überprüfen, ob Murks beim Drucken rausgekommen ist
Hmm... unter "Andruck" versteht man inzwischen wohl was anderes, als was
mir noch beigebracht wurde (in meiner Lehrzeit, d.h. anno 1994 jammerten
die Andrucker schon, daß die goldenen Zeiten definitiv vorbei wären --
Stichwort: Proof/Digitalproof/Sachproof/Softproof).
Wäre mir aber neu, daß man grundsätzlich heute bei Drucksachen einen
Probedruck bekommt. Gerade bei Kleinauflagigem. Meine letzte Recherche
diesbzgl. brachte unverhältnismäßig hohe Aufpreise mit sich (50,- EUR
"Andruck" im Vergleich zu 100,- EUR Fortdruck für Briefbögen) und manche
Anbieter verlangen sogar für einen Softproof, der manchmal nicht mal den
simpelsten Grundlagen standhalten kann (anderes RIP wie Fortdruck bspw.)
schon 10,- - 15,- EUR.
> wobei das ja auch »nur« die Farben betreffen würde, richtig?
Nein. PDF/X fängt zwar in erster Linie im Farbbereich Probleme ab. Aber
auch in reinen S/W-Szenarien hab ich selbst schon drei Problemklassen
mitbekommen (bzw. reparieren dürfen):
* Nicht eingebettete Fonts (sieht im Adobe Reader auf dem Rechner, auf
dem die Datei erstellt wurde, noch toll aus. Bei der Ausgabe bzw. beim
Ausgabedienstleister bleibt sowas im besten Fall in einem Preflight
stecken, wird im zweitbesten Fall durch eine visuell auffällige
Schrift wie bspw. Courier ersetzt -- und fällt bei einer hoffentlich
durchgeführten visuellen Prüfung auf -- und endet im schlimmsten Fall
mit Font-Substitution einer gleichlautenden Schrift mit anderem
Encoding. Dann sind bspw. Umlaute oder Akzente weg oder einzelne
Sonderzeichen -- alles Dinge, die man gerne kurz vor Schluß auch bei
'ner visuellen Prüfung übersieht)
* Fehlende Kommunikation des Seitenformats bzw. Beschnitts (PDF/X
schreibt zwingend Trim- und Bleedbox vor). A4-Endformat geliefert aber
B5 "gemeint" und Sachbearbeiter telefonisch mitgeteilt --> Ggf. Pech
gehabt... Kann bei PDF/X gar nicht erst geschehen.
* Kaputtes PDF. Sieht lokal im Adobe Reader ggf. wunderbar aus (weil der
Reader wie auch Acrobat Standard/Pro einige Verrenkungen anstellt, um
nicht zu 100% korrekte PDF doch irgendwie einzulesen und darzustellen.
Bei der Ausgabe wird das PDF auch geschluckt aber anders gerendert...
Nix gewesen mit WYSIWYG. Solche Fehler fängt eben die Validierung des
PDF nach PDF/X ab. Positiver Prüfreport bedeutet immer syntaktisch
korrektes PDF, bedeutet weniger Überraschungen.
Wie simpel ist es denn, mit TeX PDF zu erstellen, bei dem die Schriften
nicht eingebettet sind (und das bitte immer als Untergruppe, damit auch
beim Ausgabedienstleister nix schiefgehen kann)? Würde mich vor dem
Hintergrund interessieren, daß ich die "Ohne Acrobat geht nix wenn
Druckproduktion im Sinn"-Keule evtl. nicht immer gar so heftig schwingen
"muß" :-)
Gruss,
Thomas
Michael Unger
> [...]
>
> Nein. PDF/X fängt zwar in erster Linie im Farbbereich Probleme ab. Aber
> auch in reinen S/W-Szenarien hab ich selbst schon drei Problemklassen
> mitbekommen (bzw. reparieren dürfen):
>
> * Nicht eingebettete Fonts (sieht im Adobe Reader auf dem Rechner, auf
> dem die Datei erstellt wurde, noch toll aus. Bei der Ausgabe bzw. beim
> Ausgabedienstleister bleibt sowas im besten Fall in einem Preflight
> stecken, [...]
"Bearbeiten" -> "Grundeinstellungen" -> "Seitenanzeige" -> "Rendern"
-> "[ ] Lokale Schriften verwenden" (Adobe Reader 8.1.1 hier)
Wer das nicht beachtet, _will_ eigentlich Probleme bekommen. Obwohl --
ich habe auch schon genug PDF-Dokumente großer Firmen oder Behörden
gesehen, die mit "Adobe Sans MM2 gar nicht hübsch aussahen ...
> [...]
Michael
--
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.
Christoph Bier
>> Ja. Aber unter »nicht zurechtkommen« verstehe ich etwas anderes. Und
>> da ohnehin immer ein Andruck verschickt wird, kann man auch
>> überprüfen, ob Murks beim Drucken rausgekommen ist
>
> Hmm... unter "Andruck" versteht man inzwischen wohl was anderes, als was
> mir noch beigebracht wurde (in meiner Lehrzeit, d.h. anno 1994 jammerten
> die Andrucker schon, daß die goldenen Zeiten definitiv vorbei wären --
> Stichwort: Proof/Digitalproof/Sachproof/Softproof).
Was hieß es denn damals? Ich kenne den Ausdruck aus der Kommunikation
mit Druckereien, die damit einen Probedruck (ohne Beschnitt) meinen.
> Wäre mir aber neu, daß man grundsätzlich heute bei Drucksachen einen
> Probedruck bekommt. Gerade bei Kleinauflagigem. Meine letzte Recherche
> diesbzgl. brachte unverhältnismäßig hohe Aufpreise mit sich (50,- EUR
> "Andruck" im Vergleich zu 100,- EUR Fortdruck für Briefbögen) und manche
> Anbieter verlangen sogar für einen Softproof, der manchmal nicht mal den
> simpelsten Grundlagen standhalten kann (anderes RIP wie Fortdruck bspw.)
> schon 10,- - 15,- EUR.
Zuletzt hatte ich eine Auflage von 100 und einen sehr günstigen Preis,
ohne dass der Probedruck extra bezahlt werden musste (davor auch ein Mal
eine Auflage von nur 75).
>> wobei das ja auch »nur« die Farben betreffen würde, richtig?
>
> Nein. PDF/X fängt zwar in erster Linie im Farbbereich Probleme ab. Aber
> auch in reinen S/W-Szenarien hab ich selbst schon drei Problemklassen
> mitbekommen (bzw. reparieren dürfen):
>
> * Nicht eingebettete Fonts [...]
Ok, da bin ich betriebsblind, da es bei modernen TeX-Distributionen
schon seit Jahren Standard ist, dass die Schriften eingebettet werden.
> * Fehlende Kommunikation des Seitenformats bzw. Beschnitts (PDF/X
> schreibt zwingend Trim- und Bleedbox vor). A4-Endformat geliefert aber
> B5 "gemeint" und Sachbearbeiter telefonisch mitgeteilt --> Ggf. Pech
> gehabt... Kann bei PDF/X gar nicht erst geschehen.
> * Kaputtes PDF. Sieht lokal im Adobe Reader ggf. wunderbar aus (weil der
> Reader wie auch Acrobat Standard/Pro einige Verrenkungen anstellt, um
> nicht zu 100% korrekte PDF doch irgendwie einzulesen und darzustellen.
> Bei der Ausgabe wird das PDF auch geschluckt aber anders gerendert...
> Nix gewesen mit WYSIWYG. Solche Fehler fängt eben die Validierung des
> PDF nach PDF/X ab. Positiver Prüfreport bedeutet immer syntaktisch
> korrektes PDF, bedeutet weniger Überraschungen.
Danke für die Aufklärung! Dann leistet TeX wohl auch im unsichtbaren
Bereich gute Arbeit. Zwei Dokumente hatte ich von einem mit Acrobat
ausgestatten Freund prüfen lassen, weil Fotos und farbige Abbildungen
enthalten waren (das war die Zeit, als ich überlegte, mir eine MS-freie
Plattform, auf der Acrobat läuft zuzulegen ;-)). Die Prüfreports waren
aber unproblematisch (ob sie absolut fehlerfrei waren, weiß ich nicht
mehr) und die gedruckten Dokumente kamen in sehr guter Qualität aus der
Druckerei.
> Wie simpel ist es denn, mit TeX PDF zu erstellen, bei dem die Schriften
> nicht eingebettet sind (und das bitte immer als Untergruppe, damit auch
> beim Ausgabedienstleister nix schiefgehen kann)?
Kommt drauf an. ;-) Ich wüsste es aus dem Stegreif nicht einzustellen,
müsste also erst mal recherchieren. Es muss jedenfalls in einer
Konfigurationsdatei von Hand eingestellt werden, es ist also keine
leicht zugängliche Option. Und seit Jahren ist es in allen mir bekannten
TeX-Distributionen voreingestellt, dass die Schriften eingebettet
werden. Wenn man weiß, wo man was eintragen muss, ist es simpel das
Einbetten der Schriften abzuschalten. ;-)
> Würde mich vor dem
> Hintergrund interessieren, daß ich die "Ohne Acrobat geht nix wenn
> Druckproduktion im Sinn"-Keule evtl. nicht immer gar so heftig schwingen
> "muß" :-)
Ich kann nur aus meiner Erfahrung berichten und hatte noch keine (auch
keine kleineren) Probleme mit von pdfTeX erzeugten Dokumenten im Druck.
Allerdings handelte es sich um textlastige Dokumente mit vergleichsweise
wenig farbigen Abbildungen oder Fotos. Prüf doch beispielsweise mal
typokurz. :-) (http://zvisionwelt.de/typokurz.pdf)
Thomas Kaiser
> "Bearbeiten" -> "Grundeinstellungen" -> "Seitenanzeige" -> "Rendern"
> -> "[ ] Lokale Schriften verwenden" (Adobe Reader 8.1.1 hier)
>
> Wer das nicht beachtet, _will_ eigentlich Probleme bekommen.
Und wer das schlichtweg nicht weiß, wird Probleme bekommen ohne daß er
es will. Das ist ja die Crux des Ganzen. Wird PDF/X geliefert, ist eben
auch schon kommuniziert, daß der Datenlieferant weiß, daß "PDF für die
Druckvorstufe" gewisse Anforderungen erfüllen muß.
Gruss,
Thomas
Rolf Niepraschk
Thomas Kaiser
> Thomas Kaiser schrieb:
>> Christoph Bier schrieb in <news:73btrvF...@mid.individual.net>
>> [PDF/X vs. PDF]
>
>>> Ja. Aber unter »nicht zurechtkommen« verstehe ich etwas anderes. Und
>>> da ohnehin immer ein Andruck verschickt wird, kann man auch
>>> überprüfen, ob Murks beim Drucken rausgekommen ist
>>
>> Hmm... unter "Andruck" versteht man inzwischen wohl was anderes, als
>> was mir noch beigebracht wurde (in meiner Lehrzeit, d.h. anno 1994
>> jammerten die Andrucker schon, daß die goldenen Zeiten definitiv
>> vorbei wären -- Stichwort: Proof/Digitalproof/Sachproof/Softproof).
>
> Was hieß es denn damals? Ich kenne den Ausdruck aus der Kommunikation
> mit Druckereien, die damit einen Probedruck (ohne Beschnitt) meinen.
Andruck war früher eine Abgrenzung zu Fortdruck, der auf speziellen
Andruckmaschinen erfolgte. Einen bis zehn Bogen mal einfach so auf der
Fortdruckmaschine durchlaufen zu lassen, um dem Auftraggeber einen
verbindlichen visuellen Eindruck zu geben war aufgrund der damals
üblichen Rüstzeiten (Druckplatten wechseln, Farbführung und sonstige
Parameter einstellen/feintunen, paar hundert Bogen Vorlauf durchjagen,
bis alles stimmt und dann in paar Sekunden die eigentlichen Andruckbogen
produzieren, rechnete sich einfach nicht)
Bei den heutigen im Kleinauflagendruck ausschließlich vorhandenen Toner-
basierten Verfahren ist das natürlich egal. Da dauert die Produktion
eines Blattes X Sekunden (+ Vorlaufzeit von Y Sekunden) und die von 100
Blättern 100 x X Sekunden (+ Vorlaufzeit von Y Sekunden). D.h. was einen
heutigen "Andruck" ggf. teuer macht, ist wenn dann das Handling, also
das Verschicken zum Auftraggeber, etc.
Einen Andruck in dem Sinn gibt es auch heute im Prinzip nicht mehr,
außer das Druckverfahren ist extrem exotisch oder es geht in den
handwerklichen Bereich hinein (hab neulich bspw. einen Siebdrucker auf
einem Konzert kennengelernt, der sich 'nen goldenen Ar*** verdient, weil
er Sachen wieder manuell mit Methoden produziert, die schon als
ausgestorben galten, weil das große Tintenspritzer in günstiger und mit
99% reproduzierbarer Qualität hinbekommen)
> Zuletzt hatte ich eine Auflage von 100 und einen sehr günstigen Preis,
> ohne dass der Probedruck extra bezahlt werden musste (davor auch ein
> Mal eine Auflage von nur 75).
Tonerbasiert -- siehe oben. Sowas druckt kein Mensch mehr im Offset --
zumindest hierzulande.
> Danke für die Aufklärung! Dann leistet TeX wohl auch im unsichtbaren
> Bereich gute Arbeit.
Daß aus TeX syntaktisch korrektes PDF hinten rausfällt, glaub ich gerne
(bei der Denke, der in dem Bereich Aktiven :-)
>> Wie simpel ist es denn, mit TeX PDF zu erstellen, bei dem die
>> Schriften nicht eingebettet sind (und das bitte immer als
>> Untergruppe, damit auch beim Ausgabedienstleister nix schiefgehen
>> kann)?
>
> Kommt drauf an. ;-) Ich wüsste es aus dem Stegreif nicht einzustellen,
> müsste also erst mal recherchieren. Es muss jedenfalls in einer
> Konfigurationsdatei von Hand eingestellt werden, es ist also keine
> leicht zugängliche Option. Und seit Jahren ist es in allen mir
> bekannten TeX-Distributionen voreingestellt, dass die Schriften
> eingebettet werden. Wenn man weiß, wo man was eintragen muss, ist es
> simpel das Einbetten der Schriften abzuschalten. ;-)
OK, kann also sein aber man muß sich wirklich anstrengen oder ein
"glückliches Händchen" haben (ich kenne bei Kunden Leute, die ich gerne
als Tester einsetze -- die machen sofort und aus dem Stand Dinge, auf
die ein normaler Mensch nicht im Leben kommen würde. Ideal für
Schwachstellenanalyse :-)
> Prüf doch beispielsweise mal typokurz. :-)
> (http://zvisionwelt.de/typokurz.pdf)
<http://kaiser-edv.de/tmp/1Q4GWL/typokurz_report.txt>
Kurz zusammengefaßt: Insgesamt unproblematisch. Die paar hundert
Problemstellen sind nichts, was wirklich im Druck negativ auffallen
kann. Dein PDF läßt sich durch Acrobat im Vollautomatik-Modus durchjagen
und harrt anschließend nur noch der folgenden vier Problemquellen, die
händisch korrigiert werden können:
* PDF/X-OutputIntent fehlt
* Der GTS_PDFXVersions-Schlüssel muss in jeder PDF/X-Datei vorhanden sein.
* Ein gültiger PDF/X-Bezeichner muss bestimmte Werte im
GTS_PDFXVersion-Schlüssel enthalten.
* Entweder ArtBox (Objekt-Rahmen) oder TrimBox (Endformat-Rahmen)
sollten für eine PDF-Datei definiert sein, die in der Druckvorstufe
verarbeitet werden soll. Für PDF/X-Dateien ist das Vorhandensein von
entweder TrimBox oder ArtBox vorgeschrieben.
Gruss,
Thomas
Thomas Kaiser
Grundsätzlich Zustimmung. Der hier überwiegend vertretenen TeX-Fraktion
wird das aber nicht als Frustration spendieren.
Gruss,
Thomas
Markus Kohm
> Und wer das schlichtweg nicht weiß, wird Probleme bekommen ohne daß er
> es will.
Wie oft hast Du denn schon solche PDFs mit pdfTeX erzeugt?
Bei den unzähligen PDFs (die meisten in s/w, diverse aber auch in Farbe),
die ich bisher mit pdfTeX erzeugt habe, gab es genau bei einem ein Problem.
In dem Fall saß das eigentliche Problem aber vor dem Rechner und bestand
nicht etwa in nicht eingebetteten Fonts (dazu müsste man pdfTeX schon
zwingen), sondern darin, dass mein Drucker und mein Monitor bezüglich der
Farben schlecht kalibriert sind (naja, mein Drucker passt zu meinem
Monitor, und beide geben einen Fogra-Medienkeil falsch wieder). Daran hätte
PDF/X genau gar nichts geändert.
An der Stelle sei auch noch auf das Paket pdfx hingewiesen, das derzeit
zumindest bei der Erzeugung von PDF/X-1a und PDF/A-1b behilflich ist.
Außerdem hilfreich mag Abschnitt 7 der ps2pdf-Anleitung mit der
Überschrift "Creating a PDF/X-3 document" sein. Dabei benötigt man aus
Ausgangsbasis nicht unbedingt eine PS-Datei. Eine PDF-Datei funktioniert
ebenfalls.
Die Druckereien, mit denen ich zusammenarbeiten, sind aber sehr gut mit den
mit pdfLaTeX produzierten PDFs zurecht gekommen, die ich ihnen geliefert
habe. Verlage (wenn solche zwischen mir und der Druckerei stehen) fummeln
ohnehin gerne noch selbst etwas an den PDFs, beispielsweise weil sie auf
die Impressumseite nur dann vertrauen, wenn sie für die Fehler dort
komplett selbst verantwortlich sind.
Gruß
Markus
Josef Kleber
Hash: SHA1
Thomas Kaiser schrieb:
> Christoph Bier schrieb in <news:73dv3jF...@mid.individual.net>
>> Prüf doch beispielsweise mal typokurz. :-)
>> (http://zvisionwelt.de/typokurz.pdf)
>
> <http://kaiser-edv.de/tmp/1Q4GWL/typokurz_report.txt>
>
> Kurz zusammengefaßt: Insgesamt unproblematisch. Die paar hundert
> Problemstellen sind nichts, was wirklich im Druck negativ auffallen
> kann. Dein PDF läßt sich durch Acrobat im Vollautomatik-Modus durchjagen
> und harrt anschließend nur noch der folgenden vier Problemquellen, die
> händisch korrigiert werden können:
>
> * PDF/X-OutputIntent fehlt
>
> * Der GTS_PDFXVersions-Schlüssel muss in jeder PDF/X-Datei vorhanden sein.
>
> * Ein gültiger PDF/X-Bezeichner muss bestimmte Werte im
> GTS_PDFXVersion-Schlüssel enthalten.
>
> * Entweder ArtBox (Objekt-Rahmen) oder TrimBox (Endformat-Rahmen)
> sollten für eine PDF-Datei definiert sein, die in der Druckvorstufe
> verarbeitet werden soll. Für PDF/X-Dateien ist das Vorhandensein von
> entweder TrimBox oder ArtBox vorgeschrieben.
>
Das sind aber alles "Probleme" im Zusammenhang mit PDF/X. LaTeX & Co.
erhob niemals den Anspruch PDF/X zu liefern. Es gibt aber mittlerweile
ein LaTeX-Paket pdfx (PDF/X-1a and PDF/A-1b support for pdfTeX) das mit
etwas Gefrimmel zumindest in die PDF/X Richtung geht.
http://support.river-valley.com/wiki/index.php?title=Generating_PDF/A_compliant_PDFs_from_pdftex
Interessant wäre demnach ein Test nachdem Christoph unter Einbindung von
pdfx sein Dokument neu erstellt hat! ;-)
Josef
- --
Keine Sicherheit ohne Schäuble:
GNUPG/PGP-Key unter http://www.josef-kleber.de/pgp/Josef_Kleber_News.asc
DSA 1024 / 0xF4B1EA2A / F832 6058 319E FFD4 0EFF 088C 521B 40D4 F4B1 EA2A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknR+f8ACgkQUhtA1PSx6ipWCgCfYVHDnjZLlVlEy6tGIjjTNhBo
cPYAoM1mzo+DV2cNmC4MFQVOU7vlWrk6
=oljF
-----END PGP SIGNATURE-----
Christoph Bier
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thomas Kaiser schrieb:
>> Christoph Bier schrieb in <news:73dv3jF...@mid.individual.net>
>>> Prüf doch beispielsweise mal typokurz. :-)
>>> (http://zvisionwelt.de/typokurz.pdf)
>> <http://kaiser-edv.de/tmp/1Q4GWL/typokurz_report.txt>
>>
>> Kurz zusammengefaßt: Insgesamt unproblematisch. Die paar hundert
>> Problemstellen sind nichts, was wirklich im Druck negativ auffallen
>> kann. Dein PDF läßt sich durch Acrobat im Vollautomatik-Modus durchjagen
>> und harrt anschließend nur noch der folgenden vier Problemquellen, die
>> händisch korrigiert werden können:
>>
>> * PDF/X-OutputIntent fehlt
>>
>> * Der GTS_PDFXVersions-Schlüssel muss in jeder PDF/X-Datei vorhanden sein.
>>
>> * Ein gültiger PDF/X-Bezeichner muss bestimmte Werte im
>> GTS_PDFXVersion-Schlüssel enthalten.
>>
>> * Entweder ArtBox (Objekt-Rahmen) oder TrimBox (Endformat-Rahmen)
>> sollten für eine PDF-Datei definiert sein, die in der Druckvorstufe
>> verarbeitet werden soll. Für PDF/X-Dateien ist das Vorhandensein von
>> entweder TrimBox oder ArtBox vorgeschrieben.
>>
>
> Das sind aber alles "Probleme" im Zusammenhang mit PDF/X. LaTeX & Co.
> erhob niemals den Anspruch PDF/X zu liefern.
Aber ich hatte behauptet, dass ich mit meinen mit pdfTeX erzeugten
Dokumenten noch nie Probleme in Druckereien hatte. Deshalb war es ja
interessant zu sehen, was ein Test ergeben würde, ohne dass spezielle
Vorkehrungen getroffen wurden.
> Es gibt aber mittlerweile
> ein LaTeX-Paket pdfx (PDF/X-1a and PDF/A-1b support for pdfTeX) das mit
> etwas Gefrimmel zumindest in die PDF/X Richtung geht.
>
> http://support.river-valley.com/wiki/index.php?title=Generating_PDF/A_compliant_PDFs_from_pdftex
>
> Interessant wäre demnach ein Test nachdem Christoph unter Einbindung von
> pdfx sein Dokument neu erstellt hat! ;-)
Auch das wäre interessant. Ich kann frühestens morgen Nachmittag
typokurz mit dem Paket pdfx erzeugen. Bisher fand ich es weniger
interessant, weil es eben nur *in die Richtung* PDF/X geht und ich ja
auch sonst bisher keine Probleme mit Druckereien hatte.
Andreas Weber
>> [...]
>> Nein. PDF/X fängt zwar in erster Linie im Farbbereich Probleme ab. Aber
>> auch in reinen S/W-Szenarien hab ich selbst schon drei Problemklassen
>> mitbekommen (bzw. reparieren dürfen):
>>
>> * Nicht eingebettete Fonts (sieht im Adobe Reader auf dem Rechner, auf
>> dem die Datei erstellt wurde, noch toll aus. Bei der Ausgabe bzw. beim
>> Ausgabedienstleister bleibt sowas im besten Fall in einem Preflight
>> stecken, [...]
>
> "Bearbeiten" -> "Grundeinstellungen" -> "Seitenanzeige" -> "Rendern"
> -> "[ ] Lokale Schriften verwenden" (Adobe Reader 8.1.1 hier)
Ja da muss ich doch mal in meiner naiven Art nachfragen,
ob es dann nicht sinvoll ist das Verwenden der lokalen
Schriftarten im Acro Reader abzustellen, um dann sehen
zu koennen was nun an Schriften eingebettet ist?
Oder bezieht sich das "lokale Schriftarten" auf die
Schriftarten die "lokal" im Dokument vorhanden (eingebettet?)
sind - oder wie? Oder doch auf den Rechner (so wuerde
ich es interpretieren)
Das wuerde dann ja zumindest aufzeigen, ob es beim
Druck zu Problemen mit nicht vorhandenen Schriftarten
kommen kann? Oder verstehe ich das gerade falsch?
> Wer das nicht beachtet, _will_ eigentlich Probleme bekommen. Obwohl --
> ich habe auch schon genug PDF-Dokumente großer Firmen oder Behörden
> gesehen, die mit "Adobe Sans MM2 gar nicht hübsch aussahen ...
btw: was ist an "Adobe Sans MM2" so besonders?
Ist das eine fuer Behoerden vorgeschriebene Standardschrift?
Andi
Christoph Bier
> Christoph Bier schrieb in <news:73dv3jF...@mid.individual.net>
>> Thomas Kaiser schrieb:
>>> Christoph Bier schrieb in <news:73btrvF...@mid.individual.net>
[...]
>> Zuletzt hatte ich eine Auflage von 100 und einen sehr günstigen Preis,
>> ohne dass der Probedruck extra bezahlt werden musste (davor auch ein
>> Mal eine Auflage von nur 75).
>
> Tonerbasiert -- siehe oben. Sowas druckt kein Mensch mehr im Offset --
> zumindest hierzulande.
Wenn das also ohnehin nicht mehr viel kostet, wie erklärst Du Dir dann
die von Dir recherchierten Beträge? Und woher kam dann Deine
Verwunderung, dass ich bisher fast immer einen Probedruck erhalten habe?
Oder bezog sich das auf den Begriff »Andruck«?
>> Danke für die Aufklärung! Dann leistet TeX wohl auch im unsichtbaren
>> Bereich gute Arbeit.
>
> Daß aus TeX syntaktisch korrektes PDF hinten rausfällt, glaub ich gerne
> (bei der Denke, der in dem Bereich Aktiven :-)
Dennoch wundert es mich, dass PDF/X und PDF/A noch nicht so die große
Rolle in der TeX-Entwicklung spielen.
>>> Wie simpel ist es denn, mit TeX PDF zu erstellen, bei dem die
>>> Schriften nicht eingebettet sind (und das bitte immer als
>>> Untergruppe, damit auch beim Ausgabedienstleister nix schiefgehen
>>> kann)?
>> Kommt drauf an. ;-) Ich wüsste es aus dem Stegreif nicht einzustellen,
>> müsste also erst mal recherchieren. Es muss jedenfalls in einer
>> Konfigurationsdatei von Hand eingestellt werden, es ist also keine
>> leicht zugängliche Option. Und seit Jahren ist es in allen mir
>> bekannten TeX-Distributionen voreingestellt, dass die Schriften
>> eingebettet werden. Wenn man weiß, wo man was eintragen muss, ist es
>> simpel das Einbetten der Schriften abzuschalten. ;-)
>
> OK, kann also sein aber man muß sich wirklich anstrengen oder ein
> "glückliches Händchen" haben (ich kenne bei Kunden Leute, die ich gerne
> als Tester einsetze -- die machen sofort und aus dem Stand Dinge, auf
> die ein normaler Mensch nicht im Leben kommen würde. Ideal für
> Schwachstellenanalyse :-)
LOL. Ich kenne solche Leute, ich weiß wovon Du sprichst ... Darüber
könnte man eigentlich ein Anekdoten-Buch schreiben.
>> Prüf doch beispielsweise mal typokurz. :-)
>> (http://zvisionwelt.de/typokurz.pdf)
>
> <http://kaiser-edv.de/tmp/1Q4GWL/typokurz_report.txt>
> Kurz zusammengefaßt: Insgesamt unproblematisch.
Musstest Du das aus dem ganzen Wust an Informationen selbst raus lesen
oder wird auch eine verständliche Form des Berichts ausgegeben?
> Die paar hundert
> Problemstellen sind nichts, was wirklich im Druck negativ auffallen
> kann. [...]
Danke für den Test!
Michael Unger
>>> [...]
>>> Nein. PDF/X fängt zwar in erster Linie im Farbbereich Probleme ab. Aber
>>> auch in reinen S/W-Szenarien hab ich selbst schon drei Problemklassen
>>> mitbekommen (bzw. reparieren dürfen):
>>>
>>> * Nicht eingebettete Fonts (sieht im Adobe Reader auf dem Rechner, auf
>>> dem die Datei erstellt wurde, noch toll aus. Bei der Ausgabe bzw. beim
>>> Ausgabedienstleister bleibt sowas im besten Fall in einem Preflight
>>> stecken, [...]
>>
>> "Bearbeiten" -> "Grundeinstellungen" -> "Seitenanzeige" -> "Rendern"
>> -> "[ ] Lokale Schriften verwenden" (Adobe Reader 8.1.1 hier)
^
Das fehlende Häkchen hat schon seine Bedeutung ...
> Ja da muss ich doch mal in meiner naiven Art nachfragen,
> ob es dann nicht sinvoll ist das Verwenden der lokalen
> Schriftarten im Acro Reader abzustellen, um dann sehen
> zu koennen was nun an Schriften eingebettet ist?
Genau so. Außerdem werden eventuelle "Ersatzschriften" auch unter
"Datei" -> "Eigenschaften" -> "Schriften" entsprechend angezeigt.
> [...]
>
> Das wuerde dann ja zumindest aufzeigen, ob es beim
> Druck zu Problemen mit nicht vorhandenen Schriftarten
> kommen kann? Oder verstehe ich das gerade falsch?
Nein, Du verstehst das völlig richtig.
>> Wer das nicht beachtet, _will_ eigentlich Probleme bekommen. Obwohl --
>> ich habe auch schon genug PDF-Dokumente großer Firmen oder Behörden
>> gesehen, die mit "Adobe Sans MM2 gar nicht hübsch aussahen ...
>
> btw: was ist an "Adobe Sans MM2" so besonders?
Eigentlich sollte da statt '2' nämlich '"' stehen, nur war wohl die
Shift-Taste nicht kräftig genug gedrückt -- eine 'MM2' gibt es nicht.
> Ist das eine fuer Behoerden vorgeschriebene Standardschrift?
Nein, das ist lediglich die zum Adobe Reader mitgelieferte "Sans-Serif
Multi-Master"-Schrift, die als Ersatzschrift benutzt wird, wenn die
verlangte nicht eingebettet ist und der Reader eine "Sans-Serif"-Schrift
annimmt. Hier [1] gibt es übrigens ein "hübsches" Beispiel, wie das ohne
eingebettete Schriften ganz gewaltig "in die Hose gehen" kann.
Michael
[1] <http://www.kednos.com/pli/king.pdf>
Thomas Kaiser
> Thomas Kaiser wrote:
>
>> Und wer das schlichtweg nicht weiß, wird Probleme bekommen ohne daß er
>> es will.
>
> Wie oft hast Du denn schon solche PDFs mit pdfTeX erzeugt?
Ich selbst nie. Und da oben hab ich das Wörtchen "evtl." vergessen. Mir
ging's eigentlich nur um eine Abgrenzung zu Michaels Aussage, wer nicht
um die Font-Einbettungs-Problematik wisse (und entsprechend falsch
prüft), _wolle_ es nicht anders.
Es gehört eben ein bisserl Knowhow dazu (alternativ die passenden Tools
bzw. das "narrensichere" Transportmedium -- mal wieder: PDF/X anstatt
PDF)
> Außerdem hilfreich mag Abschnitt 7 der ps2pdf-Anleitung mit der
> Überschrift "Creating a PDF/X-3 document" sein.
<http://pages.cs.wisc.edu/~ghost/doc/cvs/Ps2pdf.htm#PDFX>
> Dabei benötigt man aus Ausgangsbasis nicht unbedingt eine PS-Datei.
> Eine PDF-Datei funktioniert ebenfalls.
"Funktionieren" in welchem Sinn? Ungültiges bzw. kaputtes PDF/X zu
erzeugen bzw. den Sinn des Ganzen zu karikieren? ;-)
Bekommt man jedenfalls ohne Fachwissen und mit GhostScript relativ
schnell hin, ein PDF-Dokument, in dem alles im Farbmodell/Farbraum X
vorliegt, mit einem völlig unpassenden Output-Intent zu kennzeichnen und
damit wirklich Makulatur mit Absicht zu produzieren (wenn der Ausgabe-
betrieb einen modernen Workflow hat und entsprechende Parameter des PDF
auswertet, dann _darf_/_muß_ in der Druckerei noch was mit den Daten
geschehen -- bspw. eine Farbraumkonvertierung in den Zielfarbraum. Wenn
dann nur Mist im PDF steht bzw. die vom PDF/X-Standard vorgeschriebenen
Metadaten halt überhaupt nicht zum Inhalt des PDF passen, kommt Grütze
raus.
Die Tatsache, daß ich mit GhostScript und PDF-Marks $irgendwelche PDF/X-
relevanten Metadaten reinschreiben kann (und *nichts weiter* macht GS da
-- da ist nullkommanull Überprüfung im Spiel, ob das Ganze denn
überhaupt so richtig ist!), bedeutet noch lange nicht, daß dabei was
Sinnvolles rauskommt.
Also von sowas würde ich entweder gleich ganz Abstand nehmen bzw. nur
darüber nachdenken, wenn man wirklich in der Thematik drin ist *und* ein
taugliches PDF/X-Prüfwerkzeug zur Hand hat (und hoppala... da sind wir
schon wieder bei Acrobat Pro, was diesbzgl. die Einstiegshürde
darstellt)
Ich hab für 'nen Kunden vor ca. 2 Jahren evaluiert, ob man nur mit GS
ohhe Nachbearbeitung verläßlich PDF/A aus beliebiger Quelle erzeugen
kann. 2 Manntage in den Sand gesetzt für die Erkenntnis: "Geht nicht"
bzw. "Geht nicht ohne daß noch pdfInspektor hinterherwischt *und*
anschl. nochmal Validität prüft". Die Anforderungen hinsichtlich PDF/X
fallen noch strenger aus, also vergiß es erst recht.
Bzw. andersherum: Mit geeigneten Ausgangsdaten _kann_ man nur mit GS und
entsprechendem Knowhow PDF/X und PDF/A erzeugen. Passen die Ausgangs-
daten hingegen nicht, kann es nötig sein, daß man mit pdfInspektor,
pdfaPilot und Konsorten noch nacharbeiten/validieren muß.
> Die Druckereien, mit denen ich zusammenarbeiten, sind aber sehr gut
> mit den mit pdfLaTeX produzierten PDFs zurecht gekommen, die ich ihnen
> geliefert habe.
Das ist ja alles kein Widerspruch zu sowohl Idee als auch Praxis bzgl.
PDF/X.
Mit PDF/X ist man halt bzgl. formaler Kriterien, die Druckbarkeit des
PDFs betreffend auf der sicheren Seite (dito, falls es Streitereien
geben sollte)
Gruss,
Thomas, selbst vor Jahren in ein Projekt involviert gewesen, bei dem aus
Word, Framemaker und LaTeX (DocBook mittels TeX rendern lassen) mit
Umweg über Helios-Server und dessen OPI- und Farbmanagement-Engines
drucktaugliches "buntes" PDF gemacht wird. Vor paar Jahren, als der
pdfInspektor Teil der Helios-Software wurde, wurde der dann noch an den
Workflow drangeschnallt und seitdem kommt aus allen drei Quellen PDF/X
am Ende raus. Geht problemlos, wenn Eingangsdaten passend sind und das
Werkzeug paßt.
Thomas Kaiser
> Thomas Kaiser schrieb:
>> Christoph Bier schrieb in <news:73dv3jF...@mid.individual.net>
>>> Thomas Kaiser schrieb:
>>>> Christoph Bier schrieb in <news:73btrvF...@mid.individual.net>
>
> [...]
>
>>> Zuletzt hatte ich eine Auflage von 100 und einen sehr günstigen
>>> Preis, ohne dass der Probedruck extra bezahlt werden musste (davor
>>> auch ein Mal eine Auflage von nur 75).
>>
>> Tonerbasiert -- siehe oben. Sowas druckt kein Mensch mehr im Offset --
>> zumindest hierzulande.
>
> Wenn das also ohnehin nicht mehr viel kostet, wie erklärst Du Dir dann
> die von Dir recherchierten Beträge?
Einerseits, weil die letzten Drucksachen, die ich selbst bestellt habe,
Offset waren (und da die günstigsten Angebote für eine "Probedruck" nahe
bei 50% der Gesamtkosten lagen). Andererseits, weil wir grad für einen
Kunden an einem Online-Print-Portal schrauben und die internen Kosten-
rechnungen vorliegen haben. Wenn man's richtig durchrechnet, ist selbst
im reinen Digitaldruck die Bereitstellung eines Probedrucks recht teuer
-- außer man hat's logistisch im Kreuz und es kommt der Kram quasi
vorkonfektioniert inkl. Adreßlabel, Barcode (kein interner Schritt ohne
Barcode-Scanner!) und Trennblatt aus der Maschine so daß alles, was noch
zu tun ist, das DAU-Sichere Bestücken eines Fensterkuverts ist.
> Und woher kam dann Deine Verwunderung, dass ich bisher fast immer
> einen Probedruck erhalten habe? Oder bezog sich das auf den Begriff
> »Andruck«?
Letzteres.
>> Daß aus TeX syntaktisch korrektes PDF hinten rausfällt, glaub ich
>> gerne (bei der Denke, der in dem Bereich Aktiven :-)
>
> Dennoch wundert es mich, dass PDF/X und PDF/A noch nicht so die große
> Rolle in der TeX-Entwicklung spielen.
Na, aber das ist doch klar bzw. Grundtenor seitens aller TeXer hier im
Thread: "Es gibt zu wenig Probleme mit PDF aus TeX". Wo kein (Leidens-)
Druck, da kein Antrieb, was zu ändern.
Wenn Du viel Zeit und Muße hast, dann lad' Dir die hier im Thread schon
erwähnten Cleverprinting-Ratgeber der letzten Jahre runter und verfolg'
die historische Entwicklung. Also welche Fallen sich im "klassischen"
DTP (InDesign/Quark, Illustrationen aus Corel/Freehand/Illustrator und
Bilder aus diversen Quellen) im Laufe der Jahre aufgetan haben. Sei es
durch idiotische Programm-Defaults, nicht abgefangene Komplexität der
Materie (nur weil quasi "alles geht", muß man es nicht auch für den
Laien beklickbar machen) oder Ignoranz beim Anwender, der partout nicht
einsehen will, daß er als Einzelkämpfer heute auf einmal all das können
soll, wofür es vor 2 Dekaden noch diverse spezialisierte Ausbildungs-
berufe in zweistelliger Anzahl gab.
TeX ist in der Hinsicht beschränkter bzw. muß man sich eben deutlich
mehr anstrengen, in den Grenzbereichen (v.a. wieder Farbe) Murks zu
bauen. Und was gar nicht erst verfügbar ist, kann auch nicht falsch
gemacht werden.
>>> Prüf doch beispielsweise mal typokurz. :-)
>>> (http://zvisionwelt.de/typokurz.pdf)
>>
>> <http://kaiser-edv.de/tmp/1Q4GWL/typokurz_report.txt>
>
>> Kurz zusammengefaßt: Insgesamt unproblematisch.
>
> Musstest Du das aus dem ganzen Wust an Informationen selbst raus lesen
> oder wird auch eine verständliche Form des Berichts ausgegeben?
Acrobat faßt den Prüflauf knapp zusammen (diese Art der Zusammenfassung
gibt es wirklich nur in Acrobat selbst). Das zugrundeliegende Tool
(hinter Acrobat Preflight steckt ja Callas' pdfInspektor-Technologie --
teils gemischt mit Korrekturfunktionen via Adobe-APIs) kennt wiederum
drei grundsätzliche Reporttypen: PDF (Problemstellen hervorgehoben
wahlweise durch Masken, Ebenen oder Kommentare), Text und XML.
Und Letzteres kann man via XSLT ganz nach Gusto bzw. Problemlage
zusammenfassen (lassen).
Ich bastel grad an 'ner Acrobat-Automatisierung, die Preflight- und
Korrektur-Möglichkeiten remote verfügbar macht. Hab da gaudihalber Dein
PDF in den Hotfolder geworfen... im Hintergrund wird Acrobat gestartet,
die Prüfung ausgeführt, die resultierende XML-Datei via xsltproc nach
HTML gewandelt und das dann via WebKit nach PDF. Sieht dann bspw. so aus
(nicht schimpfen wg. Aussehen des Ganzen -- das XSL ist nicht von mir
sondern nur aus 'nem anderen OpenSource-Projekt [1] entliehen):
<http://kaiser-edv.de/tmp/1Q4GWL/typokurz%20Report.pdf>
> Danke für den Test!
Kein Problem. Wenn Du morgen 'ne PDF/X-Variante aus TeX am Start hast,
dann gerne erneut rüberschieben.
Gruss,
Thomas
[1] <http://hilfdirselbst.org/index1.php?t=pdfcheck&read_article=36>
Andreas Weber
>>>> [...]
>>> "Bearbeiten" -> "Grundeinstellungen" -> "Seitenanzeige" -> "Rendern"
>>> -> "[ ] Lokale Schriften verwenden" (Adobe Reader 8.1.1 hier)
^
> Das fehlende Häkchen hat schon seine Bedeutung ...
achso wird ein Schuh draus. Sorry, das habe ich nicht
gesehen... dann ist es klar...
>> Das wuerde dann ja zumindest aufzeigen, ob es beim
>> Druck zu Problemen mit nicht vorhandenen Schriftarten
>> kommen kann? Oder verstehe ich das gerade falsch?
> Nein, Du verstehst das völlig richtig.
Damit habe ich wahrscheinlich schonmal 0.001% der Problematik
verstanden ;-)
Aber der Rest des Threads ueberfordert mich total.
Momentan habe ich das Gefuehl das ich nur beten kann
dass alles gut geht. ich habe halt auch a) Farben und
b) auch diverse Grafiken im Dokument. Das ganze wollte
ich auch farbig Ausdrucken lassen. Wobei mich geringe
Abweichungen der Farben nicht stoeren. Nur wenn es
total andere Farben sind. So definiere ich z.B. in LaTex
die Farben:
\usepackage{xcolor}
\definecolor{darkred}{rgb}{0.5,0,0} % maroon
\definecolor{darkgreen}{rgb}{0,0.5,0} % oliv
\definecolor{darkblue}{rgb}{0,0,0.5} % marine
und setze z.B. die Ueberschriften dunkelblau.
Am Bildschirm sieht das zumindest sehr gut aus.
(Sieht dann so aus wie die Ueberschriften in der
pdf-Doku zu etoolbox. vgl.
http://www.ctan.org/tex-archive/macros/latex/contrib/etoolbox#jha7c5965086e031f43e1c9413945a83fa
)
btw: Wuerde dieses dunkelblau der Ueberschriften auch
so "ungefaehr" beim Druck beibehalten oder muss ich damit
rechnen dass es dann rot oder ein reines blau oder
ein gelb rauskommt?
Jedenfalls vielen Dank fuer die ganzen Infos von dir
und auch von allen Anderen.
Langsam betrifft es zwar nicht mehr so sehr mein im
ersten Posting geschildetes Problem, aber mir kommen
so eingige Gedanken und Fragen die sich mir eben in diesem
Zusammenhang auftun.
Wie machen das z.B. Schriftsteller oder (Sach)Buchautoren?
Schreiben die alles eher z.B. mit MS Word oder einem
aehnlichen Wordprozessor und geben das dann einfach ab
und die Druckerei/Verlag kuemmert sich um eine "richtige"
Umsetzung?
Kostet das dann wesentlich mehr oder mit wieviel Mehrkosten
ist dann zu rechnen?
Hier sind ja nach meiner Einschaetzung auch einige Druckprofis
am Start. Waere nett wenn die mal etwas aus dem Naehkaestchen
plaudern koennten und wie das "ueblicherweise" ablaeuft und
gehandhabt wird. Ich vermute das nur die wenigsten Schriftsteller
[pdf](La)TeX,GS,etc. oder Acrobat benutzen und sich eher auf
typische WYSIWYG Word-Prozessoren und das Koennen der Druckerei
bzw. Verlages verlassen.
Ein Karasek schreibt IMHO sogar per Hand bzw. mit Fueller ;-)
Aber bei seinen Auflagen fallen die Kosten fuer ein Abtippen
und Formatiern mit Sicherheit nicht ins Gewicht.
Welche Anteile hat eigentlich eine Druckerei am Formatieren
und Aussehen des Endresultates?
Oder ist das ausschliesslich die Aufgabe des Verlages?
Ich vermute dass nicht immer ein Verlag dazwischen steht.
Z.B. werden fuer Festschriften bei Vereinen sicher keine
Verlage damit betraut, sondern direkt eine Druckerei, oder?
Andi
Christoph Bier
[...]
> Aber der Rest des Threads ueberfordert mich total.
> Momentan habe ich das Gefuehl das ich nur beten kann
> dass alles gut geht. ich habe halt auch a) Farben und
> b) auch diverse Grafiken im Dokument. Das ganze wollte
> ich auch farbig Ausdrucken lassen. Wobei mich geringe
> Abweichungen der Farben nicht stoeren. Nur wenn es
> total andere Farben sind. So definiere ich z.B. in LaTex
> die Farben:
>
> \usepackage{xcolor}
> \definecolor{darkred}{rgb}{0.5,0,0} % maroon
> \definecolor{darkgreen}{rgb}{0,0.5,0} % oliv
> \definecolor{darkblue}{rgb}{0,0,0.5} % marine
>
> und setze z.B. die Ueberschriften dunkelblau.
> Am Bildschirm sieht das zumindest sehr gut aus.
> (Sieht dann so aus wie die Ueberschriften in der
> pdf-Doku zu etoolbox. vgl.
> http://www.ctan.org/tex-archive/macros/latex/contrib/etoolbox#jha7c5965086e031f43e1c9413945a83fa
> )
> btw: Wuerde dieses dunkelblau der Ueberschriften auch
> so "ungefaehr" beim Druck beibehalten oder muss ich damit
> rechnen dass es dann rot oder ein reines blau oder
> ein gelb rauskommt?
Ob so etwas denkbar ist, müssen andere beantworten, ich kann nur immer
wieder sagen, dass ich das noch nicht erlebt habe und es nach meinem
Verständnis auch nicht wahrscheinlich ist. Echte Farbtreue spielte
allerdings dabei nie eine Rolle, wobei mir von verschiedenen Leuten
versichert wurde, das echte Farbtreue mit einem entsprechend
kalibrierten Monitor und definiertem Umgebungslicht beginne ...
[...]
> Wie machen das z.B. Schriftsteller oder (Sach)Buchautoren?
> Schreiben die alles eher z.B. mit MS Word oder einem
> aehnlichen Wordprozessor und geben das dann einfach ab
> und die Druckerei/Verlag kuemmert sich um eine "richtige"
> Umsetzung?
In der Regel kümmert sich der Verlag um Satz und Gestaltung, wobei
zumindest der Satz in den allermeisten Fällen ausgelagert wird.
> Kostet das dann wesentlich mehr oder mit wieviel Mehrkosten
> ist dann zu rechnen?
Das kommt auf die Höhe der Auflage an. Bei einer 100er Auflage wirkt
sich das auf die Kosten pro Exemplar natürlich stärker aus als bei einer
Auflage von 100000.
> Hier sind ja nach meiner Einschaetzung auch einige Druckprofis
> am Start. Waere nett wenn die mal etwas aus dem Naehkaestchen
> plaudern koennten und wie das "ueblicherweise" ablaeuft und
> gehandhabt wird. Ich vermute das nur die wenigsten Schriftsteller
> [pdf](La)TeX,GS,etc. oder Acrobat benutzen und sich eher auf
> typische WYSIWYG Word-Prozessoren und das Koennen der Druckerei
> bzw. Verlages verlassen.
Du vergisst einen kompletten Arbeitssschritt/Berufstand in diesem
Szenario: das Setzen beziehungsweise den Setzer/Gestalter. Noch vor gar
nicht allzu langer Zeit waren an der Produktion eines Buches
*mindestens* drei Menschen beteiligt: Autor, Setzer, Drucker. Dass Autor
und Setzer inzwischen häufig in Personalunion auftreten ist ein neues
Phänomen. Eine der daraus resultierenden Problematiken erlebst Du gerade
hier. LaTeX ist ein Autorenwerkzeug, der Setzer wird sozusagen durch TeX
ersetzt, das beim Setzen auch wirklich sehr gute Arbeit leistet. Doch
das alleine ist heute nicht mehr unbedingt ausreichend, da auch an das
Format von Seiten der Druckerei Anforderungen gestellt werden. TeX kann
diese aber noch nicht erfüllen -- ich vermute, weil es bei den
Entwicklern bisher keinerlei Leidensdruck gibt, mit TeX gesetzte Dateien
scheinen beim Druck eher selten Probleme zu machen. Und natürlich
besteht ja immer noch die Möglichkeit eine solche PDF-Datei durch
Acrobat zu jagen.
> Ein Karasek schreibt IMHO sogar per Hand bzw. mit Fueller ;-)
> Aber bei seinen Auflagen fallen die Kosten fuer ein Abtippen
> und Formatiern mit Sicherheit nicht ins Gewicht.
>
> Welche Anteile hat eigentlich eine Druckerei am Formatieren
> und Aussehen des Endresultates?
> Oder ist das ausschliesslich die Aufgabe des Verlages?
> Ich vermute dass nicht immer ein Verlag dazwischen steht.
> Z.B. werden fuer Festschriften bei Vereinen sicher keine
> Verlage damit betraut, sondern direkt eine Druckerei, oder?
Häufig bieten Druckereien auch den Satz an. Jedenfalls habe ich das
schon häufig erlebt, gerade wenn es beispielsweise um
Vereinszeitschriften oder kostenlose, lokale Wochenzeitungen geht. Das
ist aber keine Garantie dafür, dass das Endprodukt gut gesetzt
beziehungsweise gut gestaltet ist. Bei den mir bekannten Drucksachen,
für deren Gestaltung/Satz Druckereien verantwortlich sind, sieht das
immer schrecklich aus.
Thomas Kaiser
> Damit habe ich wahrscheinlich schonmal 0.001% der Problematik
> verstanden ;-)
>
> Aber der Rest des Threads ueberfordert mich total.
Auch auf die Gefahr hin, jetzt noch mehr Demotivation zu betreiben. Auch
der Rest des Threads kratzt nur an der Oberfläche. Du schneidest im
Folgenden absolute Grundlagen an (was ist ein Farbraum, was ist ein
Farbmodell, in welchen Grenzen können die Farben eines Farbraums in die
eines anderen transformiert werden, warum druckt der Drucker mit CMYK
und stellt der Monitor RGB dar, etc. etc.)
> Momentan habe ich das Gefuehl das ich nur beten kann dass alles gut
> geht.
Dann solltest Du seitens des Ausgabedienstleisters einen "Andruck"
fordern. Da Du offensichtlich kein PDF/X lieferst (und damit *alles*,
was Farbe betrifft, reine Willkür respektive Definitionssache respektive
Programm-interne Defaults sind), muß dieser Andruck die PDF-Weiter-
verarbeitungskette beim Druckdienstleister widerspiegeln. Es ist absolut
unzureichend, _hier_ einen farbigen Ausdruck des PDFs anzufertigen und
_dort_ das PDF in die Druckproduktion einzuschleusen (denn DeviceRGB,
was vermutlich bei Deiner Art Farbdefinition entsteht bzw. im PDF
landet, sagt nur sehr wenig über die konkreten Farben an sich aus,
eigentlich nur was über das Farbmodell)
> ich habe halt auch a) Farben und b) auch diverse Grafiken im Dokument.
> Das ganze wollte ich auch farbig Ausdrucken lassen. Wobei mich geringe
> Abweichungen der Farben nicht stoeren. Nur wenn es total andere Farben
> sind.
Lad Dir den Cleverprinting-Ratgeber 2009, lies die ersten zwei Kapitel
so lange, bis Du sie verstanden hast. Davor ist jegliches Weiterreden
nutzlos. Oder besorg Dir irgendwoher einen Helfer, der das Knowhow
mitbringt.
> So definiere ich z.B. in LaTex die Farben:
So definierst Du definitiv *keine* Farben sondern lediglich RGB-Tupel.
Daraus wird erst ein konkreter Farbort, indem Du den RGB-Tupeln einen
Farbraum respektive ein ICC-Profil zuweist.
> \definecolor{darkblue}{rgb}{0,0,0.5} % marine
>
> und setze z.B. die Ueberschriften dunkelblau.
> Am Bildschirm sieht das zumindest sehr gut aus.
Irgendwie dunkelblau halt.
> (Sieht dann so aus wie die Ueberschriften in der
> pdf-Doku zu etoolbox. vgl.
> http://www.ctan.org/tex-archive/macros/latex/contrib/etoolbox#jha7c5965086e031f43e1c9413945a83fa
> )
Ja, das sieht so aus wie dort (dort ist das blau 0, 0.2, 0.6 definiert,
was aber gar nichts macht, da diese Informationen kaum was bzgl. der
Farbigkeit aussagen solange kein Quellprofil bzw. -farbraum definiert
ist)
> btw: Wuerde dieses dunkelblau der Ueberschriften auch so "ungefaehr"
> beim Druck beibehalten oder muss ich damit rechnen dass es dann rot
> oder ein reines blau oder ein gelb rauskommt?
Die Wahrscheinlichkeit ist extrem hoch, daß es auch im Druck ungefähr
als "irgendwie dunkelblau" rauskommt. Wenn Du bspw. obiges PDF mit
Standard-Einstellungen in Acrobat nach PDF/X-1a für die Druckbedingungen
"FOGRA 27" konvertierst, wird das Dunkelblau als 100/88/0/0 separiert
(Cyan, Magenta, Yellow, Black). Auch die doofste Farbraumtransformierung
wird immer irgendwas mit sehr viel Cyan, bisserl weniger Magenta und
evtl. verschmutzende Anteile in Gelb und Schwarz als Ergebnis haben,
d.h. "irgendwie dunkelblau".
Bei sehr reinen Farben sieht's aber völlig anders aus. D.h. da kann in
Abhängigkeit von den Grundeinstellungen in den Programmen beim
Druckdienstleister aus einem 1/0/0 in RGB mal ein sehr reines Rot
entstehen und mal ein eher flaues Ergebnis, das einem nicht zusagt.
Und wenn jemand mit wenig Knowhow angesichts ungetaggter RGB-Farben in
Deinem PDF es "gut meint" und eine sehr doofe Farbkonvertierung ins
Spiel bringt, dann werden evtl. auch rein schwarze oder graue Elemente
Deines gelieferten PDFs anschließend bunt aufgebaut (Umwandlung von
0/0/0 RGB nicht in 0/0/0/100 CMYK sondern bspw. 60/50/49/70 -- Letzteres
ist zwar ein sattes Schwarz, aber eines, das aus allen vier Druckfarben
aufgebaut ist, d.h. extrem hohe Anforderungen an die Paßgenauigkeit der
Farbauszüge darstellt bzw. bunte Farbsäume an schwarzen Elementen
bedeutet). So 'ne Konvertierung konnte noch vor paar Jahren sogar völig
aus Versehen geschehen (auch ein Grund für die Etablierung des PDF/X-
Standards)
Stichwort PDF/X: In Deinem Fall würde ein formal korrektes PDF/X
natürlich auch nichts bringen, da hier einfach die Ausgangsbedingungen
nicht passen (Du willst eigenverantwortlich farbige Druckvorlagen
erstellen, Dir fehlen aber jegliche Grundkenntnisse). Hier hilft
eigentlich nur ein Mensch mit bisserl Fachwissen und Willen, zu helfen,
der Dir die Ausgangsbasis auf vernünftigem Weg in ein druckfähiges PDF
mit farblich reproduzierbaren Ergebnissen inkl. Andruck konvertiert.
Gruss,
Thomas
Thomas Kaiser
> Echte Farbtreue spielte allerdings dabei nie eine Rolle, wobei mir von
> verschiedenen Leuten versichert wurde, das echte Farbtreue mit einem
> entsprechend kalibrierten Monitor und definiertem Umgebungslicht
> beginne ...
Naja, konkreter nennt sich das Soft-Proof-Bedingungen und dabei geht's
noch darum, daß a) der Monitor überhaupt einen ausreichen großen
Farbraum für die Simulation der Druck-/Proofbedigungen hat und b) das
Umgebungslicht noch das Merkmal "kontinuierliches Spektrum" aufweist
(wenn Du eine Lichtquelle hast, die Löcher im Spektrum hat, dann kannst
Du Körperfarben -- also Farben, deren Farbeindruck nur durch Reflektion
von Licht erzeugt wird, bspw. ein bunt bedrucktes Blatt Papier -- nicht
beurteilen, weil gewisse Farbbereiche völlig falsch widergegeben werden.
Im Kontext PDF vs. PDF/X geht's aber um was viel Grundsätzlicheres. In
einem PDF (so eines, wie es aus LaTeX kommt bspw.) können sich Elemente
befinden, deren "Farbigkeit" in DeviceRGB definiert ist. Also ohne
Definition konkreter Farben sondern nur auf Basis einer historischen
Altlast (daß man mal im Steinzeit-DTP glaubte, mit RGB-Tupeln vage
Farben ausdrücken zu können).
Schau Dir mal diesen Farbraumvergleich von ECI-RGB und sRGB an:
<http://kaiser-edv.de/tmp/1Q4GWL/Vergleich%20ECI-RGB%20und%20sRGB%20Farbraum.png>
Ein RGB-Tupel, das als 0/1/0 (kein Rot, voll Grün, kein Blau) definiert
ist, sieht *deutlich* weniger rein/gesättigt/"leuchtend" aus, wenn man
als Farbraum für dieses Tupelchen sRGB zugrundelegt anstatt bspw.
ECI-RGB.
Wenn einem das nicht klar ist, braucht man über halbwegs verläßliche
Farben gar nicht erst nachdenken. Es bringt übrigens auch nichts,
einfach RGB "irgendwie" nach CMYK umzuwandeln, um irgendwas zu gewinnen
(eher im Gegenteil). Wenn man wirklich an reproduzierbarer Farbe
interessiert ist, kommt man nicht drumherum, sich mit diesen Grundlagen
zu beschäftigen, kalibrierte Farbe im Dokument zu verwenden (sei es in
LAB, RGB oder CMYK definiert) und sich drüber klarzuwerden, daß
beliebige Quellfarbräume immer in den konkreten zum Druckprozeß
passenden Zielfarbraum konvertiert werden sollten/müssen (bspw. FOGRA39
bei Bogenoffset --> "ISO Coated v2")
<http://www.eci.org/doku.php?id=de:colourstandards>
Wenn man sich mit diesen Grundlagen nicht wenigstens vertraut macht,
braucht man sich auch nicht wundern, wenn die Farben im Druck halt
"irgendwie" ausfallen (je reiner der Farbton, desto größer die Chance,
daß das Ergebnis unbefriedigend respektive nicht reproduzierbar
ausfällt)
> Du vergisst einen kompletten Arbeitssschritt/Berufstand in diesem
> Szenario: das Setzen beziehungsweise den Setzer/Gestalter. Noch vor
> gar nicht allzu langer Zeit waren an der Produktion eines Buches
> *mindestens* drei Menschen beteiligt: Autor, Setzer, Drucker.
Stimmt nicht (das ist schon lange her) bzw. trifft es nur auf eine
inzwischen nur noch im Buchkunst-Sektor anzutreffende Produktionsart zu:
Bleisatz/Hochdruck.
Wenn andere Druckverfahren im Spiel sind, braucht's immer noch die (so
isoliert auch nicht mehr existierenden) Berufsstände Druckvorlagen- und
Druckformhersteller.
Das ganze Farbthema, das vor paar Jahrzehnten noch auf 'zig Berufstände
aufgeteilt war (Reprofotograf, Lithograph, Scanner-Operator, etc.) fiel
in das Metier des Druckvorlagenherstellers. Die Montage der Ganzseiten
zu Druckbögen (d.h. auch Vorbereitung auf die Weiterverarbeitung in der
Buchbinderei) war Sache des Druckformherstellers.
Bedingt durch die technische Entwicklung kann sich der heutige
Druckformhesteller auch mit Problemen aus dem kreativen Prozeß
herumschlagen (weil er PDF ausschießen soll, und nach der Bogenmontage
auf der "Blaupause", d.h. dem Prüfdruck, der die ausgeschossenen
Druckbögen enhtält, auf einmal vormals transparente Objekte opak sind
und sich Encoding-Verschiebungen in Schriften eingestellt haben, bspw.
EUR-Zeichen fehlen).
Und die Rolle des Druckvorlagenherstellers tendiert inzwischen Richtung
Alchemie (aus Sch*** Gold machen). Die paar Leute, die noch die ganzen
verschiedenen Fachdisziplinen (Farbe "an sich", PDF-Grundlagen bzw.
damit einhergehende sattsam bekannte Problematiken, Kenntnisse der
Druckverfahren, Bedürfnisse der Weiterverarbeitung, etc.) parallel
beherrschen, werden in goldenen Käfigen in großen Druckhäusern als
Datenklempner gehalten.
Wenn jemand heute im Alleingang eine farbige Druckproduktion auf die
Reise bringen will, muß er nicht nur das Berufsbild des Setzers (also
Ahnung von Seitengestaltung, mikro-/makrotypographische Grundlagen)
mitbringen sondern auch noch spezifisches Wissen in früher ganz klar
voneinander abgegrenzten Fachdisziplinen.
Die Komplexität der Materie wird mit jedem Versionssprung (sei es auf
Seiten der PDF-Version, die immer mehr ermöglicht, sei es auf Seiten der
DTP-Programme, wo Gleiches geschieht) immer größer. Ansätze wie PDF/X,
die das Thema Produktionssicherheit angehen und Verglichen zum Austausch
von offenen Dateien oder PostScript wie noch vor einer Dekade deutlich
mehr an Sicherheit mitbringen hinläßlich, daß das, was der Datenerzeuger
ausgegeben haben möchte, auch wirklich ausgegeben wird, wirken manchmal
wie der Tropfen auf den heißen Stein, wenn man sich anschaut, wie sich
das Feature-Wettrüsten ringsherum und die Verlagerung von Kompetenzen,
die früher bei Fachleuten aufgehoben waren, immer weiter nach "vorne"
auswirkt.
Unterm Strich nicht mehr sondern weniger Produktionssicherheit. Aber das
auch nur im "klassischen" DTP-Bereich (alleine die Einführung von
Transparenzen in InDesign und Quark hat abseits der unbestreitbar tollen
kreativen Möglichkeiten zu richtiggehenden Albträumen bei denen gesorgt,
die weiter hinten, d.h. Richtung Druck an den Prozessen beteiligt sind)
Alles Themen, von denen die TeX-Gemeinde weitestgehend verschont
geblieben ist, weil sich diese Thematiken da erst gar nicht auftun (man
kann AFAIK in TeX nicht schnell mal eben aus Versehen Transparenz-
Situationen erzeugen). Das bitte nicht als Kritik an TeX verstehen. Das
ist ein perfekt für eine gewisse Sorte Publikationen (Mengensatz mit
perfekter Typographie) funktionierendes Tool. Und solange man die
Ansprüche gering hält, gelingt damit auch der Druck von farbigen
Objekten.
Wenn einem "irgendwie dunkelblau" reicht und man das auch kriegt...
perfekt. Wenn die Aufgabe nicht "dunkelblau" sondern CI-Farbe XY des
Neukunden lautet, dann muß man sich entweder mit den Grundlagen
beschäftigen oder Experten anheuern. Wir haben jedenfalls in einem
Workflow mit Erzeugnissen aus Word, TeX und FrameMaker hinsichtlich
Farbmanagement und 100% verläßliche Ausgabe null Probleme. Einfach weil
wir das ganze Thema aus der Erzeuger-Anwendung rausnehmen und dahinter
im Workflow abhandeln.
So, genug gelabert.
Gruss,
Thomas
Michael Unger
> Markus Kohm schrieb in <news:1686733.c...@mjk.komascript.de>
>> Thomas Kaiser wrote:
>>
>>> Und wer das schlichtweg nicht weiß, wird Probleme bekommen ohne daß er
>>> es will.
>>
>> Wie oft hast Du denn schon solche PDFs mit pdfTeX erzeugt?
>
> Ich selbst nie. Und da oben hab ich das Wörtchen "evtl." vergessen. Mir
> ging's eigentlich nur um eine Abgrenzung zu Michaels Aussage, wer nicht
> um die Font-Einbettungs-Problematik wisse (und entsprechend falsch
> prüft), _wolle_ es nicht anders.
Das "wollen" war natürlich leicht ironisch gemeint. Ich erlebe es aber
nach wie vor _zu_ oft, dass eben _nicht_ _alle_ Schriften eingebettet
sind. HP hat "Futura" als "Hausschrift", in vielen Datenblättern zum
Betriebssystem VMS oder zu AlphaServern fehlen dann halt etliche
Schnitte; "Futura" gehört zumindest bei Windows _nicht_ zum normalen
Schriftumfang, zum Mac kann ich nichts sagen. Auch bei Broschüren von
städtischen Ämtern, die auf dem offiziellen Webserver liegen, fehlen
sehr oft die Schriften (die Dokumente werden häufig mit Word erzeugt,
"Acrobat PDFMaker #.# für Word"). Andererseits habe ich auch schon
Dokumente gefunden, bei denen das Stadtwappen (Hoheitszeichen!) als
_Schrift_ (TrueType) eingebettet war. Nun denn, jeder macht irgendwann
einmal einen Fehler ...
> Es gehört eben ein bisserl Knowhow dazu (alternativ die passenden Tools
> bzw. das "narrensichere" Transportmedium -- mal wieder: PDF/X anstatt
> PDF)
Eben. Aber dieses Bewusstsein scheint selbst dort nicht flächendeckend
vorhanden zu sein, wo man es eigentlich voraussetzen sollte.
Michael Unger
> [...]
>
> [...] dann werden evtl. auch rein schwarze oder graue Elemente
> Deines gelieferten PDFs anschließend bunt aufgebaut (Umwandlung von
> 0/0/0 RGB nicht in 0/0/0/100 CMYK sondern bspw. 60/50/49/70 -- Letzteres
> ist zwar ein sattes Schwarz, aber eines, das aus allen vier Druckfarben
> aufgebaut ist, d.h. extrem hohe Anforderungen an die Paßgenauigkeit der
> Farbauszüge darstellt bzw. bunte Farbsäume an schwarzen Elementen
> bedeutet). [...]
Sind HKS 90, 93 und 97 (K) jetzt "böse"? ;-)
> [...]
Michael
Michael Unger
> [...]
>
> Damit habe ich wahrscheinlich schonmal 0.001% der Problematik
> verstanden ;-)
Bei derartigen Größenordnungen rechnet man aber besser mit "ppm" ...
> [...] Das ganze wollte
> ich auch farbig Ausdrucken lassen. Wobei mich geringe
> Abweichungen der Farben nicht stoeren. Nur wenn es
> total andere Farben sind. So definiere ich z.B. in LaTex
> die Farben:
>
> \usepackage{xcolor}
> \definecolor{darkred}{rgb}{0.5,0,0} % maroon
> \definecolor{darkgreen}{rgb}{0,0.5,0} % oliv
> \definecolor{darkblue}{rgb}{0,0,0.5} % marine
Von "TeX" in seinen Varianten habe ich bislang keine Ahnung -- mich
wundert lediglich, dass Du für den _Druck_ ausgerechnet den RGB- und
nicht den CMYK-Farbraum benutzt.
> [...]
>
> [...] Ich vermute das nur die wenigsten Schriftsteller
> [pdf](La)TeX,GS,etc. oder Acrobat benutzen und sich eher auf
> typische WYSIWYG Word-Prozessoren und das Koennen der Druckerei
> bzw. Verlages verlassen.
Vorab: Ich produziere nichts "Offizielles", die Anforderungen sind also
nicht so streng. Für einfache Sachen nehme ich Word und konvertiere das
dann mit Acrobat ("PDFMaker") nach PDF; schwierigere Sachen, wo es auf
einigermaßen exakte Farben ankommt oder wo Strukturen bis an den
Blattrand gehen, schreibe ich "von Hand" in PostScript und scheuche das
Ergebnis dann durch den Distiller.
> [...]
Michael
Christoph Bier
> Christoph Bier schrieb in <news:73gi84F...@mid.individual.net>
[...]
> Wenn einem das nicht klar ist, braucht man über halbwegs verläßliche
> Farben gar nicht erst nachdenken. Es bringt übrigens auch nichts,
> einfach RGB "irgendwie" nach CMYK umzuwandeln, um irgendwas zu gewinnen
> (eher im Gegenteil). Wenn man wirklich an reproduzierbarer Farbe
> interessiert ist, kommt man nicht drumherum, sich mit diesen Grundlagen
> zu beschäftigen, kalibrierte Farbe im Dokument zu verwenden (sei es in
> LAB, RGB oder CMYK definiert) und sich drüber klarzuwerden, daß
> beliebige Quellfarbräume immer in den konkreten zum Druckprozeß
> passenden Zielfarbraum konvertiert werden sollten/müssen (bspw. FOGRA39
> bei Bogenoffset --> "ISO Coated v2")
>
> <http://www.eci.org/doku.php?id=de:colourstandards>
Mir ist das klar. Aber ich habe entschieden, dass das für die Art Texte,
die ich setze, nicht wichtig ist. In den zwei Fällen, in denen es
aufgrund farbiger Logos notwendig war, habe ich mich mit der Thematik
befasst und auch zur Zufriedenheit aller bewältigt (mit Hilfe von Acrobat).
> Wenn man sich mit diesen Grundlagen nicht wenigstens vertraut macht,
> braucht man sich auch nicht wundern, wenn die Farben im Druck halt
> "irgendwie" ausfallen (je reiner der Farbton, desto größer die Chance,
> daß das Ergebnis unbefriedigend respektive nicht reproduzierbar
> ausfällt)
In beiden genannten Fällen musste ich das erst mal den Auftraggebern
klar machen, die mir zunächst als Logo GIFs ihrer Homepage geschickt
hatten, die mit den CI-Farben nun gar nichts zu tun hatten. Leider waren
auch die jeweiligen für die Logo-Erstellung zuständigen Grafiker nicht
ganz fit in der Thematik. Letztlich hat aber alles funktioniert, nachdem
sich beide Seiten schlau gemacht hatten.
>> Du vergisst einen kompletten Arbeitssschritt/Berufstand in diesem
>> Szenario: das Setzen beziehungsweise den Setzer/Gestalter. Noch vor
>> gar nicht allzu langer Zeit waren an der Produktion eines Buches
>> *mindestens* drei Menschen beteiligt: Autor, Setzer, Drucker.
>
> Stimmt nicht (das ist schon lange her) bzw. trifft es nur auf eine
> inzwischen nur noch im Buchkunst-Sektor anzutreffende Produktionsart zu:
> Bleisatz/Hochdruck.
>
> Wenn andere Druckverfahren im Spiel sind, braucht's immer noch die (so
> isoliert auch nicht mehr existierenden) Berufsstände Druckvorlagen- und
> Druckformhersteller.
Ich hatte doch extra »mindestens« fett ausgezeichnet ... :-)
[...]
> Alles Themen, von denen die TeX-Gemeinde weitestgehend verschont
> geblieben ist, weil sich diese Thematiken da erst gar nicht auftun (man
> kann AFAIK in TeX nicht schnell mal eben aus Versehen Transparenz-
> Situationen erzeugen). Das bitte nicht als Kritik an TeX verstehen. Das
> ist ein perfekt für eine gewisse Sorte Publikationen (Mengensatz mit
> perfekter Typographie) funktionierendes Tool. Und solange man die
> Ansprüche gering hält, gelingt damit auch der Druck von farbigen
> Objekten.
>
> Wenn einem "irgendwie dunkelblau" reicht und man das auch kriegt...
> perfekt. Wenn die Aufgabe nicht "dunkelblau" sondern CI-Farbe XY des
> Neukunden lautet, dann muß man sich entweder mit den Grundlagen
> beschäftigen oder Experten anheuern.
Genau.
> Wir haben jedenfalls in einem
> Workflow mit Erzeugnissen aus Word, TeX und FrameMaker hinsichtlich
> Farbmanagement und 100% verläßliche Ausgabe null Probleme.
Eben, es ist möglich, mit dem entsprechenden Hintergrundwissen, das ich
inzwischen wieder fast völlig vergessen habe. Kein Interesse, kein
Leidensdruck. Ich finde es spannend, habe aber hauptberuflich einfach
mit ganz anderen Dingen zu tun und Zeit ist ein knappes Gut. :-) Hut ab
vor denen, die sich damit wirklich auskennen.
[...]
Schöne Grüße
Thomas Kaiser
> On 2009-04-01 03:16, "Andreas Weber" wrote:
>
>> \usepackage{xcolor}
>> \definecolor{darkred}{rgb}{0.5,0,0} % maroon
>> \definecolor{darkgreen}{rgb}{0,0.5,0} % oliv
>> \definecolor{darkblue}{rgb}{0,0,0.5} % marine
>
> Von "TeX" in seinen Varianten habe ich bislang keine Ahnung -- mich
> wundert lediglich, dass Du für den _Druck_ ausgerechnet den RGB- und
> nicht den CMYK-Farbraum benutzt.
Ist doch eh egal. Weder das eine noch das andere hat mit definierter
Farbe zu tun. Sind beides in Grenzen willkürliche Definitionen
$irgendwelcher Farbwerte, die mal im einen, mal im anderen Farbmodell
ausgedrückt werden. Ein absoluter Farbort wird (abseits LAB oder
verwandter Farbraum-Repräsentationen) daraus erst, wenn Profile nebst
CMM ins Spiel kommen, die aus einer Definition von bspw. 0/1/0 in RGB
oder 1/0/1/0 in CMYK (beides mal "irgendwie grün") einen farbmetrisch
"greifbaren" Farbort machen.
Auch irgendwelche DeviceRGB-Definitionen in den Ausgangsdaten kann man
irgendwie richtig umwandeln. Problematisch wird's immer erst, wenn
derjenige, der die Daten erstellt hat und derjenige, der die Umwandlung
durchführt, unterschiedliche Vorstellungen darüber haben, was richtig
ist, bzw. wenn das Ergebnis nicht so ausfällt wie erwartet.
Am Beispiel willkürlicher RGB-Definitionen:
Es ist definitiv falsch, ein aus Word oder LaTeX kommendes PDF mit in
DeviceRGB definierten Elementen einfach so durch eine Colormanagement-
Engine zu schicken, die farbmetrisch "richtig" umwandeln würde. Weil man
eben weiß, daß der Fließtext, der in RGB 0/0/0 (schwarz) definiert ist,
nach 0%/0%/0%/100% CMYK, daß eine Fläche mit 0.1/0.1/0.1 (hellgrau)
idealerweise nach 0%/0%/0%/18% und daß eine Zwischenüberschrift in 1/0/0
(rot) nach 0%/100%/100%/0% konvertiert werden soll.
Die jeweiligen Ergebnisse aus dem Farbrechner unter Zuhilfenahme von
ICC-Profilen würden zu CMYK-Umsetzungen führen, die arge Probleme im
Druck nach sich ziehen würde (Registerhaltigkeit). Drum muß ein RIP bzw.
eine CMM-Engine, die mit "Wald- und Wiesen-PDF" umgehen können soll,
bisserl mehr an Intelligenz mitbringen bzw. der Operator beim
Ausgabedienstleister eben wissen, was er da tut. Und genau das ist der
Risikofaktor, den man an der Stelle durch Setzen auf PDF/X bequem
ausschalten kann (weil die Probleme rechtzeitig erkannt werden können
bzw. nicht erst im Fortdruck sichtbar sind)
Gruss,
Thomas
Thomas Kaiser
> On 2009-04-01 09:54, "Thomas Kaiser" wrote:
>
>> [...]
>>
>> [...] dann werden evtl. auch rein schwarze oder graue Elemente Deines
>> gelieferten PDFs anschließend bunt aufgebaut (Umwandlung von 0/0/0
>> RGB nicht in 0/0/0/100 CMYK sondern bspw. 60/50/49/70 -- Letzteres
>> ist zwar ein sattes Schwarz, aber eines, das aus allen vier
>> Druckfarben aufgebaut ist, d.h. extrem hohe Anforderungen an die
>> Paßgenauigkeit der Farbauszüge darstellt bzw. bunte Farbsäume an
>> schwarzen Elementen bedeutet). [...]
>
> Sind HKS 90, 93 und 97 (K) jetzt "böse"? ;-)
Nein, als Sonderfarben (also als eigens angemischter Farbton, der in
separatem Druckwerk aufs Papier gebracht wird -- geht bei 99% der in
irgendeiner Weise digitalen Druckmaschinen heute eh nicht mehr, d.h. ist
ein Refugium der klassischen Druckverfahren) eh schon mal nicht.
Wenn man die entsprechenden HKS-Farben in CMYK umzusetzen versucht und
druckt (wen's interessiert -- eine Tabelle findet sich bspw. in [1]),
dann ist zumindest der Gestaler Designer böse/blöd/grob fahrlässig, der
Fließtext bzw. generell dünne grafische Elemente in solchen Farbtönen
aufbaut, weil diese extem hohe Anforderungen an die Registerhaltigkeit
der Druckmaschine bzw. des Druckverfahrens stellen)
Aber obige Farbtöne vollflächig bspw. als Fonds einzusetzen und dann
_überdruckend_ mit schwarz draufzudrucken, stellt gar kein Problem dar.
Weil aber diese Zusammenhänge den wenigstens Gestaltern/Reinzeichnern
klar sind, bzw. die alle nicht die mindestens 4 Wochen Praktikum in
sowohl Buchbinderei als auch Druckerei absolviert haben, die sie
eigentlich absolvieren sollten, damit nicht andauernd nicht druck-/
weiterverarbeitbarer Murks produziert wird, enthalten die Preflight-
Profile, durch die man PDFs typischerweise "vor dem Druck"
durchschleust, neben formalen Kriterien wie "Alle Fonts eingebettet",
"Trim/Artbox definiert", etc. (der PDF/X-Schraddel halt) auch
inhaltliche Überprüfungen, bspw.:
* Weißes Element steht auf überdrucken [2]
* Registerfarbe (100/100/100/100) innerhalb Trimbox verwendet
* Text kleiner 6 Pt in mehr als einer Farbe definiert
* Text kleiner 6 Pt ist aufgerastert (d.h. Tonwert < 100%)
usw. usf. Als Beispiel mal eine Acrobat/pdfInspektor-Prüfung, die
relativ tolerant ist:
<http://kaiser-edv.de/tmp/1Q4GWL/Bild%205.png>
Gruss,
Thomas
[1] <http://www.tabelle.info/hks_farben.html>
[2] Dieser Test reicht allerdings nicht: In Kombination mit Logos aus
Illustrator und irgendwelchen Sachen in Layout-Anwendungen kann es
dazu kommen, daß man anschl. Farben im PDF hat, die eben nicht
"weiß" sind sondern in CMYK ausgedrückt bspw. 0%/0%/0,2%/0% --
formal ein sehr sehr helles Hellgelb. Und für so einen Mist, muß man
dann die Preflight-Checks wieder anpassen
Michael Unger
> [...]
>
> Wenn man die entsprechenden HKS-Farben in CMYK umzusetzen versucht und
> druckt (wen's interessiert -- eine Tabelle findet sich bspw. in [1]), [...]
>
> [...]
>
> [1] <http://www.tabelle.info/hks_farben.html>
>
> [...]
Der genannten Tabelle (die ich auch schon mal gefunden hatte) traue ich
nicht ganz über den Weg -- die dort angegebenen CMYK-Werte weichen zum
Teil deutlich von denjenigen ab, die auf den "HKS-Farbtafeln" stehen,
zudem gibt es ja noch die "K"-, "N"-, "E"- und "Z"-Varianten.
Thomas Kaiser
> On 2009-04-03 12:31, "Thomas Kaiser" wrote:
>
>> Wenn man die entsprechenden HKS-Farben in CMYK umzusetzen versucht und
>> druckt (wen's interessiert -- eine Tabelle findet sich bspw. in [1]), [...]
>>
>>
> Der genannten Tabelle (die ich auch schon mal gefunden hatte) traue
> ich nicht ganz über den Weg -- die dort angegebenen CMYK-Werte weichen
> zum Teil deutlich von denjenigen ab, die auf den "HKS-Farbtafeln"
> stehen, zudem gibt es ja noch die "K"-, "N"-, "E"- und "Z"-Varianten.
Es ist doch eh alles Quatsch, genauso wie der Versuch, mittels
DeviceCMYK konkrete Farborte auszudrücken. Welche Farbe die CMYK-
Kombination 50/50/10/10 im Druck bekommen wird, bestimmt die
Papiersorte, der Druckstandard (in den die Beschaffenheit der
Druckfarben -- also Viskosität, opake/transparente Eigenschaften,
optische Dichte und natürlich der konkrete Farbort -- einfließen als
auch Farbmenge/Farbführung des Druckprozesses wie auch konkrete
Druckweise) und prozeßimmanente Größen wie bspw. das verwendete
Rastersystem (frequenzmoduliert vs. autotypisch bspw.), die Art der
Farbübertragung (an diversen Stellen, bspw. Plattenbelichtung/-kopie,
etc.), denen man mit Prozeßkalibirierung beizukommen versucht.
Wenn Papierklasse und Druckbedingungen hingegen definiert sind (siehe
ECI-Link im Thread), dann und wirklich erst dann entspricht eine
Kombination vierer Prozentwerte einer konkreten Farbe -- das aber
natürlich auch nur unter Normlichtbedingungen, denn Körperfarben hängen
ja von der Lichtquelle ab.
In der HKS-Palette gibt es eine ganze Latte an Farbtönen, die
schlichtweg nicht mit normalem 4-farbigen Offset (oder am Farbumfang von
Offset ausgerichtetem Digitaldruck) dargestellt werden können, weil der
HKS-Farbraum umfänglicher ist als Standard-Offset. Solche Farbtöne
können eh nur $irgendwie im Vierfarbdruck substutiert werden. Muß man
mehrere gleichzeitig in CMYK abbilden, stellt sich auch noch die Frage,
wie man den größeren HKS-Farbraum auf bspw. ISO Coated abbildet
(abschneiden oder zusammenstauchen -- Stichwort "Gamut Mapping")
Die ganze HKS-in-$irgendwas-umsetzen-Diskussion läßt sich historisch
zudem noch in zwei (sogar drei -- aber führt hier viel zu weit)
einteilen: Prä-ICC- und ICC-Ära. Heute, d.h. in der ICC-Ära mit halbwegs
verbreitetem Wissen rund um Farbe und so Standards wie PSO [1] _kann_
man wenigstens tatsächlich die meisten HKS-Töne farbmetrisch korrekt im
Vierfarbdruck abbilden. Das ging früher schon vom Prinzip her nicht (der
sog. "Eurostandard", an dem man sich noch vor 10 Jahren orientiert hat,
krankte bspw. daran, daß bzgl. der Druckfarben so ziemlich alles
geregelt war, bspw. maximale Viskosität, optische Dichte, etc., aber
"witzigerweise" der konkrete Farbort der 4 Grundfarben nicht. Im Rahmen
des Eurostandards hätte man als "Cyan" bspw. auch ein Hellgrün verkaufen
_dürfen_).
So, alles total OT hier. Der sinnvollste Platz für sowas in deutsch ist
leider ein Webforum, so maximal dämlich ich auch Webforen als
Diskussionsmedium finde:
<http://www.hilfdirselbst.ch/foren/gforum.cgi?forum=31;>
(die Empfehlung gilt eigentlich auch für "PDF in der Druckvorstufe")
Gruss,
Thomas
Michael Unger
> Michael Unger schrieb in <news:73mlkgF...@mid.individual.net>
>> On 2009-04-03 12:31, "Thomas Kaiser" wrote:
>>
>>> Wenn man die entsprechenden HKS-Farben in CMYK umzusetzen versucht und
>>> druckt (wen's interessiert -- eine Tabelle findet sich bspw. in [1]), [...]
>>>
>>> [1] <http://www.tabelle.info/hks_farben.html>
>>>
>> Der genannten Tabelle (die ich auch schon mal gefunden hatte) traue
>> ich nicht ganz über den Weg -- die dort angegebenen CMYK-Werte weichen
>> zum Teil deutlich von denjenigen ab, die auf den "HKS-Farbtafeln"
>> stehen, zudem gibt es ja noch die "K"-, "N"-, "E"- und "Z"-Varianten.
>
> Es ist doch eh alles Quatsch, genauso wie der Versuch, mittels
> DeviceCMYK konkrete Farborte auszudrücken. Welche Farbe die CMYK-
> Kombination 50/50/10/10 im Druck bekommen wird, bestimmt die
> Papiersorte, der Druckstandard (in den die Beschaffenheit der
> Druckfarben -- also Viskosität, opake/transparente Eigenschaften,
> optische Dichte und natürlich der konkrete Farbort -- einfließen als
> auch Farbmenge/Farbführung des Druckprozesses wie auch konkrete
> Druckweise) und prozeßimmanente Größen wie bspw. das verwendete
> Rastersystem (frequenzmoduliert vs. autotypisch bspw.), die Art der
> Farbübertragung (an diversen Stellen, bspw. Plattenbelichtung/-kopie,
> etc.), denen man mit Prozeßkalibirierung beizukommen versucht.
HKS spezifiziert bleistiftsweise für die "K"-Reihe: Phoeno-Grand
holzfrei glänzend spezial-gestrichenes Bilderdruckpapier 115 g/m² von
Scheufelen, 1.5 µ Farbschichtdicke. Irgendwie klingt das ziemlich
"wohldefiniert".
> Wenn Papierklasse und Druckbedingungen hingegen definiert sind (siehe
> ECI-Link im Thread), dann und wirklich erst dann entspricht eine
> Kombination vierer Prozentwerte einer konkreten Farbe --
Das oben Zitierte liest sich aber genau so, zumal es ja jeweils
verschiedene Werte für *K*unstdruck-, *N*ormal-, *E*ndlos- und
*Z*eitungspapier gibt.
> das aber
> natürlich auch nur unter Normlichtbedingungen, denn Körperfarben hängen
> ja von der Lichtquelle ab.
>
> In der HKS-Palette gibt es eine ganze Latte an Farbtönen, die
> schlichtweg nicht mit normalem 4-farbigen Offset (oder am Farbumfang von
> Offset ausgerichtetem Digitaldruck) dargestellt werden können, weil der
> HKS-Farbraum umfänglicher ist als Standard-Offset. [...]
Ich rede hier -- ohne das bislang explizit benannt zu haben -- nur von
den (knapp hundert) HKS-Grundfarben. In den Farbtafeln ist übrigens die
Qualität der CMYK-Approximation in drei "Güteklassen" eingeteilt, da
wird also durchaus auf mögliche Probleme hingewiesen.
> [...]
>
> So, alles total OT hier. [...]
Um das wieder in Richtung on-topic zu drehen: Wenn man im PDF
ausschließlich DeviceCMYK verwendet, keine zu "ausgefallenen" Farben
benutzt und beim Gesamt-Farbauftrag nicht "übertreibt" -- ist das dann,
beispielsweise in Acrobat Pro, "mit zwei Handgriffen druckerei-tauglich"
zu bekommen? Die Druckerei respektive deren Vorstufen-Dienstleister
sollten den eigenen Prozess ja eigentlich optimal kennen.
Thomas Kaiser
> On 2009-04-03 17:33, "Thomas Kaiser" wrote:
>
>> Michael Unger schrieb in <news:73mlkgF...@mid.individual.net>
>>> On 2009-04-03 12:31, "Thomas Kaiser" wrote:
>>>
>>>> [1] <http://www.tabelle.info/hks_farben.html>
>>>>
>>> Der genannten Tabelle (die ich auch schon mal gefunden hatte) traue
>>> ich nicht ganz über den Weg -- die dort angegebenen CMYK-Werte
>>> weichen zum Teil deutlich von denjenigen ab, die auf den
>>> "HKS-Farbtafeln" stehen, zudem gibt es ja noch die "K"-, "N"-, "E"-
>>> und "Z"-Varianten.
>>
>> Es ist doch eh alles Quatsch, genauso wie der Versuch, mittels
>> DeviceCMYK konkrete Farborte auszudrücken. Welche Farbe die CMYK-
>> Kombination 50/50/10/10 im Druck bekommen wird, bestimmt die
>> Papiersorte, der Druckstandard (in den die Beschaffenheit der
>> Druckfarben -- also Viskosität, opake/transparente Eigenschaften,
>> optische Dichte und natürlich der konkrete Farbort -- einfließen als
>> auch Farbmenge/Farbführung des Druckprozesses wie auch konkrete
>> Druckweise) und prozeßimmanente Größen wie bspw. das verwendete
>> Rastersystem (frequenzmoduliert vs. autotypisch bspw.), die Art der
>> Farbübertragung (an diversen Stellen, bspw. Plattenbelichtung/-kopie,
>> etc.), denen man mit Prozeßkalibirierung beizukommen versucht.
>
> HKS spezifiziert bleistiftsweise für die "K"-Reihe: Phoeno-Grand
> holzfrei glänzend spezial-gestrichenes Bilderdruckpapier 115 g/m² von
> Scheufelen, 1.5 µ Farbschichtdicke. Irgendwie klingt das ziemlich
> "wohldefiniert".
Ja, bloß bzgl. was? Bzgl. der Druckbedingungen des HKS-Farbfächers. Die
sind auf eben jenem Papier gedruckt worden und der Drucker hat versucht,
sich an 1,5 µ Dicke heranzutasten (die Meßgeräte im Drucksaal messen
Dichte und nicht Dicke, d.h. die Opazität. Grenzwerte dafür gibt es aber
nur für die normalen Prozeßfarben).
Und was hast Du davon, wenn Du weißt, unter welchen Bedingungen Dein
HKS-Farbfächer gedruckt worden ist? Also hinsichtlich Umsetzung in
"CMYK-Tabellen"? Exakt gar nichts, weil es um die Druckbedingungen des
Vierfarbdrucks per se geht. Der ganze HKS-Schmodder bzw. der HKS-CMYK-
Zuordnungs-Unsinn stammt aus der Prä-ICC-Ära, dito die Denke drumherum.
Wenn man's richtig machen wollte, müssen Druckbedingungen als auch
Farbort (in LAB ausgedrückt) bekannt sein. Dann kann man eine Aussage
treffen, welcher HKS-Ton in welchem standardisierten Druckverfahren
a) überhaupt druckbar ist
b) wie konkret zusammengemischt werden müsste
Für alles Weitere bitte wirklich im richtigen Forum weiterlesen, bspw.
ab hier:
<http://www.hilfdirselbst.ch/foren/gforum.cgi?post=390104#390104>
> In den Farbtafeln ist übrigens die Qualität der CMYK-Approximation in
> drei "Güteklassen" eingeteilt, da wird also durchaus auf mögliche
> Probleme hingewiesen.
"Daumen mal pi" halt.
> Um das wieder in Richtung on-topic zu drehen: Wenn man im PDF
> ausschließlich DeviceCMYK verwendet, keine zu "ausgefallenen" Farben
> benutzt und beim Gesamt-Farbauftrag nicht "übertreibt" -- ist das
> dann, beispielsweise in Acrobat Pro, "mit zwei Handgriffen
> druckerei-tauglich" zu bekommen?
Ja, klar. Nahezu jedes PDF ist "druckerei-tauglich" zu bekommen. Das
"wie" ist die Frage.
> Die Druckerei respektive deren Vorstufen-Dienstleister sollten den
> eigenen Prozess ja eigentlich optimal kennen.
Aber die können nicht anhand des "Wald- und Wiesen-PDF", das ihnen
geliefert wird, hellsehen, was der Kunde eigentlich farblich meinte bzw.
will. Das einzige, was sie anhand des Ausgangsmaterials wissen, ist, daß
der Kunde von Farbe keine Ahnung hat. Sonst hätte er PDF/X und konkrete
Farben anstatt DeviceCMYK geliefert.
Gruss,
Thomas
Helmut Wollmersdorfer
> Hmm... unter "Andruck" versteht man inzwischen wohl was anderes, als was
> mir noch beigebracht wurde (in meiner Lehrzeit, d.h. anno 1994 jammerten
> die Andrucker schon, daß die goldenen Zeiten definitiv vorbei wären --
> Stichwort: Proof/Digitalproof/Sachproof/Softproof).
Wie ich gelernt habe (1972 - 1977) hat es schon Ersatz-Andruckverfahren
gegeben. Und da war die Druckwelt noch komplett analog. Richtige
Andrucke wurden nur mehr von Klischees gemacht, aber damals war der
Hochdruck und damit der Beruf des Chemographen schon am Sterben.
> Wäre mir aber neu, daß man grundsätzlich heute bei Drucksachen einen
> Probedruck bekommt. Gerade bei Kleinauflagigem. Meine letzte Recherche
> diesbzgl. brachte unverhältnismäßig hohe Aufpreise mit sich (50,- EUR
> "Andruck" im Vergleich zu 100,- EUR Fortdruck für Briefbögen) und manche
> Anbieter verlangen sogar für einen Softproof, der manchmal nicht mal den
> simpelsten Grundlagen standhalten kann (anderes RIP wie Fortdruck bspw.)
> schon 10,- - 15,- EUR.
Klingt aber angemessen, wenn Du bedenkst, was 'Probedruck' bedeutet:
komplette Kosten für die Druckform, sofern noch eine notwendig ist und
Einrichtekosten für die Maschine, bei Sonderfarben noch Waschen der
Maschine.
> Nein. PDF/X fängt zwar in erster Linie im Farbbereich Probleme ab. Aber
> auch in reinen S/W-Szenarien hab ich selbst schon drei Problemklassen
> mitbekommen (bzw. reparieren dürfen):
> * Nicht eingebettete Fonts [...]
> * Fehlende Kommunikation des Seitenformats bzw. Beschnitts [...]
> * Kaputtes PDF. Sieht lokal im Adobe Reader ggf. wunderbar aus (weil der
> Reader wie auch Acrobat Standard/Pro einige Verrenkungen anstellt, um
> nicht zu 100% korrekte PDF doch irgendwie einzulesen und darzustellen.
> Bei der Ausgabe wird das PDF auch geschluckt aber anders gerendert...
> Nix gewesen mit WYSIWYG. Solche Fehler fängt eben die Validierung des
> PDF nach PDF/X ab. Positiver Prüfreport bedeutet immer syntaktisch
> korrektes PDF, bedeutet weniger Überraschungen.
Ja, klar.
Bin zwar ausgebildeter 'Reproduktions- und Drucktechniker', arbeite aber
seit 1992 nicht mehr in der Branche, daher - abgesehen von den
Grundlagen - Laie. Trotzdem musste ich aus einer Not heraus (Verlag sagt
3 Wochen vor Publikation ab, Grafiker schafft den Termin nicht) selbst
druckreife PDFs für ein Kunstbuch erstellen. Das hat sich etwa so
abgespielt:
- bei Druckerei Papier, Bindung und Einband bemustern
- Angebot, Termin und Zuschlag
- Blindband zwecks Layout des Umschlages
- Termin für PDFs: Dienstag, 8:00
- Mittwoch in der Woche davor sagt der Grafiker ab
- nach einigen Telefonaten und genauerem Studium der Anforderungen
seitens der Druckerei (PDF/X-3, Farbprofile ...), sehe ich
zähneknirschend ein, dass ich unter Windows mit Photoshop und Indesign
arbeiten muss.
- Donnerstag abends: 30 Tage Probeversionen von Photoshop und Indesign
installieren
- Freitag nachmittags: Umgang mit der neuen Software erlernen
- Samstag: die Repros von den Aquarellen sind von der Beleuchtung zu
uneinheitlich, als dass man sie noch vernünftig korrigieren könnte.
Originale holen, Blitzanlage aufstellen, einmessen und 80 Aquarelle
nochmals mit einer Nikon D70 aufnehmen. Dann diese 80 TIFFs
nachbearbeiten, wobei der Künstlerin im Nebenraum noch neue Ideen hat
und Aquarelle produziert, um noch welche auszutauschen ...
- Sonntag: Layout fertigstellen, Text und Bilder einbetten
- Montag: Druckerei bekommt 10 Probeseiten und Einband per Mail zwecks
technischer Prüfung
- Dienstag liegt die CD in der Druckerei, ich bekomme gleich Proofs und
unterschreibe sie.
Vermutlich wäre es für den OP auch schneller, sicherer auf jeden Fall,
seine Inhalte nach Indesign zu transferieren.
Helmut Wollmersdorfer
Christoph Bier
> Christoph Bier schrieb in <news:73eip1F...@mid.individual.net>
>> Thomas Kaiser schrieb:
>>> Christoph Bier schrieb in <news:73dv3jF...@mid.individual.net>
>>>> Thomas Kaiser schrieb:
>>>>> Christoph Bier schrieb in <news:73btrvF...@mid.individual.net>
>>>> Prüf doch beispielsweise mal typokurz. :-)
>>>> (http://zvisionwelt.de/typokurz.pdf)
[...]
>>> Kurz zusammengefaßt: Insgesamt unproblematisch.
[...]
>> Danke für den Test!
>
> Kein Problem. Wenn Du morgen 'ne PDF/X-Variante aus TeX am Start hast,
> dann gerne erneut rüberschieben.
Hatte ich doch glatt vergessen. Aber mein gestriger Versuch typokurz
mit pdfx.sty zu übersetzen, ist fehlgeschlagen, die Fehlersuche habe
ich nach ein paar Stunden aufgegeben.
Grüße
Christoph
--
+++ Typografie-Regeln (1.6): http://zvisionwelt.de/?page_id=56
Johannes Starosta
> Hatte ich doch glatt vergessen. Aber mein gestriger Versuch typokurz
> mit pdfx.sty zu übersetzen, ist fehlgeschlagen, die Fehlersuche habe
> ich nach ein paar Stunden aufgegeben.
Was gab es denn für Fehlermeldungen? Ich leite mal nach
de.comp.text.tex um.
--
MFG, Johannes.
PGP Fingerprint: 719A 160A 6643 889E 851D CE3C 71CA 824A 2E44 AC29
PGP: keyID: 2E44AC29 0x71ca824a2e44ac29
Christoph Bier
> Christoph Bier <christo...@web.de> schrieb:
>> Hatte ich doch glatt vergessen. Aber mein gestriger Versuch typokurz
>> mit pdfx.sty zu übersetzen, ist fehlgeschlagen, die Fehlersuche habe
>> ich nach ein paar Stunden aufgegeben.
>
> Was gab es denn für Fehlermeldungen? Ich leite mal nach
> de.comp.text.tex um.
Dann auch nochmal hier dir Info: In dctt hatte ich das schon
angesprochen: <74rpp1F...@mid.individual.net>
Grüße
Christoph
--
+++ Typografie-Regeln (1.6): http://www.zvisionwelt.de/?page_id=56
Thomas Kaiser
> Johannes Starosta schrieb:
>> Christoph Bier <christo...@web.de> schrieb:
>>> Hatte ich doch glatt vergessen. Aber mein gestriger Versuch typokurz
>>> mit pdfx.sty zu übersetzen, ist fehlgeschlagen, die Fehlersuche habe
>>> ich nach ein paar Stunden aufgegeben.
>>
>> Was gab es denn für Fehlermeldungen? Ich leite mal nach
>> de.comp.text.tex um.
>
> Dann auch nochmal hier dir Info: In dctt hatte ich das schon
> angesprochen: <74rpp1F...@mid.individual.net>
Ich -- als Nicht-Texer -- bleib jetzt mal hier. Hab den Thread ausgehend
von <news:74rpp1F...@mid.individual.net> mal durchgelesen und
kommentiere kurz (BTW: "news:"-Präfix machen Msg-IDs Archiv-freundlich)
* Das pdfx-Paket, das Ihr da benutzt, versucht sich an PDF/X-1a, das
voraussetzt, daß im Dokument keinerlei Farb-Definitionen in RGB
vorliegen (vgl. <http://www.pdfx-ready.ch/index.php?show=230>). Wie
soll das denn klappen, wenn Ihr im Dokument Farben andauernd nur in
RGB angebt bzw. RGB-Bilder einbettet? Wer sorgt sich um die Farbraum-
konvertierung? Falls niemand, dann kann's nicht klappen (bzw. dann
wäre das einzige, was mit Euren Mitteln möglich ist, das Erzeugen von
PDF/A und Nutzen eines RGB-Profils als "Output Intent" [1]. Alternativ
PDF/X-3, das auch RGB zuläßt -- aber das würde wieder eine Anpassung
des pdfx-Packerls nötig machen)
* Den vermuteten Lizenzkram bzgl. der XMP-Metadaten würde ich mit den
Autoren klären -- die müssten doch per Mail erreichbar sein, wenn das
<http://ctan.math.utah.edu/tex-archive//macros/latex/contrib/pdfx/>
hier bzw. das dort enthaltene README nicht täuscht? Besagte Autoren
würde ich auch bzgl. PDF/3 triggern. Das dürfte für TeX-Anhänger der
schmerzfreieste Weg sein, an PDF/X zu kommen (verlagert zwar die Frage
exakter Farborte Richtung Ausgabedienstleister -- aber das ist ja
heute schon so :-)
* Die Profile von eci.org sind frei verwendbar und dürfen auch keine
Restriktionen triggern.
* Das Einbetten eines ICC-Profils ist übrigens nicht zwangsweise Pflicht
in jeder PDF/X-Norm -- es reicht evtl. auch, das Ganze als Metadaten
bzw. URL zu deklarieren. Wird allerdings ein ICC-Profil eingebettet,
dann darf ein ebenfalls angebebener OutputConditionIdentifier nicht
dazu in Konflikt stehen (das zu Euren Diskussionen in der tex-Gruppe
von wegen "Welches ISOCoated nehmen wir denn..." -- das muß zusammen
passen)
Gruss,
Thomas
[1] Der Output Intent bezeichnet die Druckbedingungen für die das
Druckerzeugnis aufbereitet wurde (weil andernfalls ja der Ausgabe-
dienstleister keinen Peil hat, wie der Datenlieferant das Ganze
gedruckt/geprooft haben möchte). Für Details siehe bspw.:
<http://www.pdfx-ready.ch/index.php?show=242>
Markus Kohm
> * Das pdfx-Paket, das Ihr da benutzt, versucht sich an PDF/X-1a, das
> voraussetzt, daￜ im Dokument keinerlei Farb-Definitionen in RGB
> vorliegen
Deshalb steht in der Anleitung des Pakets auch entsprechendes. Wenn es
allerdings nur um Farben geht, die mit LaTeX-Mitteln gesetzt werden, also
nicht Farben eingebetteter Dokumente, dann ist das xcolor-Paket das Mittel
zur Wahl von CMYK-Farbdefinitionen. Siehe dazu die Anleitung zum Paket.
Bei PDF/A-1b, was das Paket auch ermï¿œglicht, sind allerdings RGB-Farben
vorgesehen. Deshalb wird in der Anleitung in Abschnitt 3.3 auch das
erwï¿œhnt.
Gruￜ
Markus
Thomas Kaiser
> Thomas Kaiser wrote:
>
>> * Das pdfx-Paket, das Ihr da benutzt, versucht sich an PDF/X-1a, das
>
> Deshalb steht in der Anleitung des Pakets auch entsprechendes.
Das ist mir schon klar. Ob es das auch Christoph ist, weiß ich nicht.
Dessen "typokurz.pdf" kommt jedenfalls auf 14 Seiten mit schlappen 898
Treffern für
Objekt verwendet einen geräteunabhängigen Farbraum (ICC-basiertes
Grau/RGB/CMYK, Lab, CalRGB oder CalGray).
daher, was exakt 898 mal zu viel für PDF/X-1a ist :-)
> Wenn es allerdings nur um Farben geht, die mit LaTeX-Mitteln gesetzt
> werden, also nicht Farben eingebetteter Dokumente, dann ist das
> xcolor-Paket das Mittel zur Wahl von CMYK-Farbdefinitionen. Siehe dazu
> die Anleitung zum Paket.
Da bin ich der falsche Adressat.
> Bei PDF/A-1b, was das Paket auch ermöglicht, sind allerdings
> RGB-Farben vorgesehen.
"Erlaubt", nicht "vorgesehen".
> Deshalb wird in der Anleitung in Abschnitt 3.3 auch das erwähnt.
Mag alles sein... ich wollte nur auf ein paar generelle Stolperschwellen
für Euch TeXies Richtung PDF/X hinweisen. Mit dem "pdfx"-Paket wird
jedenfalls nur glücklich, wer stur (auch und vor allem bei platzierten
Bildern/Grafiken) auf CMYK setzt und wenigstens halbwegs weiß, was er
tut, wenn's um Farbe geht.
Gruss,
Thomas
Stephan Hennig
> * Das pdfx-Paket, das Ihr da benutzt, versucht sich an PDF/X-1a, das
> voraussetzt, da� im Dokument keinerlei Farb-Definitionen in RGB
> vorliegen (vgl. <http://www.pdfx-ready.ch/index.php?show=230>). Wie
> soll das denn klappen, wenn Ihr im Dokument Farben andauernd nur in
> RGB angebt bzw. RGB-Bilder einbettet? Wer sorgt sich um die Farbraum-
> konvertierung?
Niemand. Also der Anwender.
> Falls niemand, dann kann's nicht klappen (bzw. dann
> w�re das einzige, was mit Euren Mitteln m�glich ist, das Erzeugen von
> PDF/A und Nutzen eines RGB-Profils als "Output Intent" [1].
Wie Markus schon bemerkte, ist es mit TeX einfach m�glich, Farben im
CMYK-Farbraum zu definieren. TeX-Anwendern geht es eher selten um
Fotografien; die Farbdefinitionen liegen h�ufig in der Hand des
Anwenders. Mir w�re es jedenfalls egal, welchen Farbraum ich
verwendete. Hauptsache, es gibt hinterher eine verl�ssliche
Farbdarstellung und das PDF besteht einen Konformit�tstest.
> Besagte Autoren
> w�rde ich auch bzgl. PDF/3 triggern. Das d�rfte f�r TeX-Anh�nger der
> schmerzfreieste Weg sein, an PDF/X zu kommen (verlagert zwar die Frage
> exakter Farborte Richtung Ausgabedienstleister -- aber das ist ja
> heute schon so :-)
Solange es keine freie Testm�glichkeiten f�r PDF/X-Konformit�t gibt,
n�tzt mir ein PDF/X-Dokument allerdings wenig. Falls es mit der
Druckerei Probleme gibt, w�rde ich gern ein Testergebnis in der Hand
haben. Mir reichte daher f�r's erste auch PDF/A-1b. Damit habe ich
aber auch Probleme. Das folgende vorgebliche PDF/A-1b-Dokument,
\listfiles
\begin{filecontents}{\jobname.xmpdata}
\Title{Test-Dokument}
\Author{Von und Zu}
\end{filecontents}
\documentclass{article}
\usepackage[a-1b]{pdfx}
\usepackage{hyperref}
\hypersetup{
pdfauthor={Von und Zu},
pdftitle={Test-Dokument}
}
\begin{document}
text
\end{document}
<URL:http://home.arcor.de/stephanhennig/Downloads/LaTeX/test.pdf>
welches mit pdfTeX 1.40.9 nach Anleitung des Pakets pdfx erstellt wurde,
besteht diesen Test nicht:
<URL:http://www.datalogics.com/products/callas/callaspdfA-onlinedemo.asp>
> callas pdfaPilot Report
>
> PDF/A-1b conversion failed
> 411420test.pdf
> Title: <No Entry>
> Author: <No Entry>
> Pages: 1 - 612.0x792.0 pt
> Size: 17.2 KBytes - PDF-Version: 1.4
> Origin: pdfTeX
> Created with: pdfTeX
> Last Change: 4/30/2009 10:22 AM
>
> No additional checks
> Report created: 4/30/2009 10:22 AM
> pdfaPilot-Version: 1.2.077
>
> Fixups
>
> Document information corrected
>
> Color definition made device independent
>
>
> Unfixable Problems
>
> Document information not properly defined
>
> Properties in the XMP Metadata are not properly defined.
>
>
> XMP property is predefined but is not used in accordance with the definition
>
>
>
> XMP property neither predefined nor defined in extension schema
Liegt das an der PDF-Datei oder am Testprogramm? Was bedeuten die
Fehler �berhaupt? Was sagt Adobe Acrobat zu der PDF-Datei?
> * Das Einbetten eines ICC-Profils ist �brigens nicht zwangsweise Pflicht
> in jeder PDF/X-Norm -- es reicht evtl. auch, das Ganze als Metadaten
> bzw. URL zu deklarieren. Wird allerdings ein ICC-Profil eingebettet,
> dann darf ein ebenfalls angebebener OutputConditionIdentifier nicht
> dazu in Konflikt stehen (das zu Euren Diskussionen in der tex-Gruppe
> von wegen "Welches ISOCoated nehmen wir denn..." -- das mu� zusammen
> passen)
Ich habe f�r dieses Dokument das Profil
sRGB_IEC61966-2-1_black_scaled.icc
verwendet[1], umbenannt in sRGBIEC61966-2.1.icm, wie es dem Quelltest
des Pakets pdfx zu entnehmen ist.[2] Am OutputConditionIdentifier
d�rfte es diesmal daher nicht liegen.
Viele Gr��e
Stephan Hennig
[1] <URL:http://www.color.org/srgbprofiles.xalter>, unten
[2] In Zeile 137 von pdfx.sty
\immediate\pdfobj stream attr{/N 4} file{sRGBIEC1966-2.1.icm}
fehlt offensichtlich eine 6 im Dateinamen. In den folgenden Zeilen 144
und 145 steht es richtig
/OutputConditionIdentifier (sRGB IEC61966-2.1)
/Info(sRGB IEC61966-2.1)
Den Fehler habe ich lokal behoben, so dass die Datei RGBIEC61966-2.1.icm
verwendet wird.
Stephan Hennig
> Den Fehler habe ich lokal behoben, so dass die Datei RGBIEC61966-2.1.icm
sRGBIEC61966-2.1.icm nat�rlich.
Thomas Kaiser
> Thomas Kaiser schrieb:
>
> Wie Markus schon bemerkte, ist es mit TeX einfach möglich, Farben im
> CMYK-Farbraum zu definieren.
Machen muß man's halt...
> TeX-Anwendern geht es eher selten um Fotografien; die Farbdefinitionen
> liegen häufig in der Hand des Anwenders. Mir wäre es jedenfalls egal,
> welchen Farbraum ich verwendete. Hauptsache, es gibt hinterher eine
> verlässliche Farbdarstellung und das PDF besteht einen
> Konformitätstest.
Tja, da wäre PDF/X-3 besser...
>
>> Besagte Autoren würde ich auch bzgl. PDF/3 triggern. Das dürfte für
>> TeX-Anhänger der schmerzfreieste Weg sein, an PDF/X zu kommen
>> (verlagert zwar die Frage exakter Farborte Richtung
>> Ausgabedienstleister -- aber das ist ja heute schon so :-)
>
> Solange es keine freie Testmöglichkeiten für PDF/X-Konformität gibt,
> nützt mir ein PDF/X-Dokument allerdings wenig.
Jeder Ausgabedienstleister, der PDF/X fordert hat sowas. Und bereits das
hilft ja bereits.
><URL:http://home.arcor.de/stephanhennig/Downloads/LaTeX/test.pdf>
>
> welches mit pdfTeX 1.40.9 nach Anleitung des Pakets pdfx erstellt wurde,
> besteht diesen Test nicht:
>
><URL:http://www.datalogics.com/products/callas/callaspdfA-onlinedemo.asp>
Ich hab's einmal durch Acrobat 8 und einmal durch 9 gejagt:
<http://kaiser-edv.de/tmp/1Q4GWL/test_report_8.1.txt>
<http://kaiser-edv.de/tmp/1Q4GWL/test_report_9.1.txt>
> Liegt das an der PDF-Datei oder am Testprogramm?
Tja... schwierig. Bei PDF/A bin ich ein wenig überfragt, warum Acrobat 8
Dein PDF durchwinkt und 9 ablehnt.
> Was bedeuten die Fehler überhaupt?
Hilft der Acrobat 9 Report weiter oben weiter? Acrobat 9 scheint sich an
den erweiterten Metadaten (in XMP/RDF) zu stören. Wenn man mal per
"exiftool -g1" vergleicht, dann steckt in Deinem test.pdf
---- PDF ----
Page Count : 1
Creator : pdfTeX
Producer : pdfTeX
Trapped : False
GTS PDFA1 Version : PDF/A-1b:2005
Create Date : 2009:04:30 17:18:23+02:00
Modify Date : 2009:04:30 17:18:23+02:00
PTEX.Fullbanner : This is MiKTeX-pdfTeX 2.7.3235 (1.40.9)
---- XMP-dc ----
Format : application/pdf
Title : Test-Dokument
Subject :
Publisher :
---- XMP-prism ----
Aggregation Type : journal
Copyright :
---- XMP-pdfaid ----
Part : 1
Conformance : B
---- XMP-xmp ----
Creator Tool : pdfTeX
Metadata Date : 2009:04:30 17:18:23+02:00
---- XMP-xmpRights ----
Marked : True
In dem PDF/A-Dokument, das ich noch parallel validiert habe ([1]) steckt
dagegen:
---- PDF ----
Page Count : 3
Title : PDF/A Competence Center
Author : Nicole
Creator : Writer
Producer : OpenOffice.org 3.0
Create Date : 2009:04:22 14:30:37+02:00
---- XMP-pdfaid ----
Part : 1
Conformance : A
---- XMP-xmp ----
Creator Tool : Writer
> Was sagt Adobe Acrobat zu der PDF-Datei?
Siehe oben. Ich hab zur Sicherheit auch mal ein definitiv PDF/A
konformes PDF durch Acrobat 9 und Datalogics' pdfaPilot durchgejagt
([1]). Da paßt alles.
Gruss,
Thomas
Christoph Bier
> Markus Kohm schrieb in <news:1613931.y...@mjk.komascript.de>
>> Thomas Kaiser wrote:
>>
>>> * Das pdfx-Paket, das Ihr da benutzt, versucht sich an PDF/X-1a, das
>>> voraussetzt, daß im Dokument keinerlei Farb-Definitionen in RGB
>>> vorliegen
>>
>> Deshalb steht in der Anleitung des Pakets auch entsprechendes.
>
> Das ist mir schon klar. Ob es das auch Christoph ist, weiß ich nicht.
Ist es ihm. :-) Nur bisher hat er sich bei typokurz nicht um PDF/X
geschert.
[...]
> Mag alles sein... ich wollte nur auf ein paar generelle Stolperschwellen
> für Euch TeXies Richtung PDF/X hinweisen. Mit dem "pdfx"-Paket wird
> jedenfalls nur glücklich, wer stur (auch und vor allem bei platzierten
> Bildern/Grafiken) auf CMYK setzt und wenigstens halbwegs weiß, was er
> tut, wenn's um Farbe geht.
Dafür bin auch zumindest ich Dir dankbar. Kann Acrobat jedes PDF in
PDF/X umwandeln, also beispielsweise auch ein in TeX erzeugtes, das
auf PDF/X keinerlei Rücksicht nimmt?
Grüße
Christoph
--
+++ Typografie-Regeln (1.6): http://zvisionwelt.de/?page_id=56
Thomas Kaiser
> Kann Acrobat jedes PDF in PDF/X umwandeln
Nein. Bspw. wenn Fonts verwendet werden, die nicht eingebettet sind.
Alleine das ist hundertprozentiges K.O.-Kriterium.
> also beispielsweise auch ein in TeX erzeugtes, das auf PDF/X keinerlei
> Rücksicht nimmt?
Das wohl in ca. 99,9% der Fälle schon. Einfach weil man in TeX nicht so
viel Grenzwertiges anstellen kann wie bspw. in InDesign.
Ich hab Dein typokurz.pdf jetzt mal mittels Acrobat 9.1 nach PDF/X-1a
und PDF/X-3 konvertiert (kommt so ziemlich das Gleiche dabei heraus,
weil die Konvertiersettings quasi identisch agieren, d.h. auch in der
PDF/X-3-Variante befindet sich anschl. alles nur noch in DeviceCMYK oder
DeviceGray -- wenn man aus TeX heraus direkt PDF/X-3 erzeugen würde,
_könnte_ man auch mit RGB-Farbdefinitionen arbeiten)
Was macht das Konvertierprofil alles? Hier in deutsch und hoffentlich
verständlich:
<http://kaiser-edv.de/tmp/1Q4GWL/Nach%20PDF_X-3%20konvertieren%20(Coated%20FOGRA39).pdf>
Ergebnisse/Reports siehe selbe URL (alles von 1. Mai spannend).
So 'ne Konvertierung nach PDF/X mittels Acrobat funktioniert aber immer
auf Basis gewisser Annahmen, bspw. daß Deine RGB-Farbdefinitionen im PDF
im Farbraum AdobeRGB vorliegen (sieht das Konvertierungsprofil halt
einfach so vor) und aufgrund der Wahl meines Profils (FOGRA39)
entsprechend in DeviceCMYK für genau das anvisierte Druckverfahren
"Kommerzieller und Spezial-Offsetdruck entsprechend ISO 12647-2:2004 /
Amd 1, Papiertyp 1 oder 2, d.h. glänzend- oder mattgestrichenes
Offsetpapier, 115 g/m2, Rasterweite 60/cm" vulgo "FOGRA39" durchgeführt
wurde.
Hättest Du in Wirklichkeit Deine RGB-Tupelchen in sRGB interpretiert
sehen wollen und wüsstest, daß typokurz mit 'ner halben Millionen
Auflage im Rollenoffset auf Klo^WZeitungspapier gedruckt wird, dann wär'
obige Farbraumkonvertierung natürlich falsch (weil sRGB deutlich kleiner
als AdobeRGB, ist, der wiederum annähernd so groß ist wie ECI-RGB --
siehe Farbraumvergleich unter obiger URL -- und weil die konkreten
Druckbedingungen u.v.a. der Bedruckstoff anders aussehen)
Da es bei Dir aber eh nur um "irgendwie dunkelblau" geht (und dieser
Farbton auch noch relativ stabil hinsichtlich falscher Profile ist)
macht es konkret auch nichts aus, wenn man hier mehr oder weniger
danebenhaut, d.h. die quasi willkürliche Zuweisung von Quell- und
Zielprofilen zur Erreichung von PDF/X-Konformität ignoriert, daß PDF/X
eigentlich unter anderem genau dazu geschaffen wurde, Farbe klar vom
Datenerzeuger zum -verarbeiter zu transportieren.
Die anderen Sachen, die sich noch hinsichtlich Ausgabe/Weiter-
verarbeitung auswirken könnten, konkret fehlende Trim-/Artbox und
fehlender Überfüllungsschlüssel, können bei TeX als Quelle eigentlich
auch immer gefahrlos gesetzt werden (Trim-/Artbox auf Mediabox, PDF noch
nicht überfüllt).
Das könnte Dir erst dann um die Ohren fliegen, wenn Du in TeX
hinsichtlich Farben zauberst (bspw. ein Illustrator-EPS platzierst, das
den Overprint-Modus nutzt, um Farbmischeffekte zu erzielen, und dessen
Einstellungen aufgrund "overprint:false" von einem Workflow-Tool beim
Ausgabedienstleister zerdeppert werden) oder eine Anzeige mit
Beschnittzugabe bastest, die dann aufgrund automatisch gesetzter Artbox
falsch platziert wird (beides Sachen, die aber in für diese Szenarien
typischen Proofs sofort auffallen würden)
All die restlichen Korrekturen an typokurz.pdf gehen in die Richtung,
daß Sachen, die halt in PDF/X verboten sind (bspw. Sprungziele/Aktionen
oder Kommentare/Hyperlinks im PDF, etc.) eliminiert werden. Bei diesen
Sachen geht es eben darum, in PDF/X ein möglichst sicheres Subset von
PDF 1.3 zu definieren, damit bei Transfer/Interpretation der Daten so
wenig wie möglich schiefgehen kann. Aber sowas zählt eben zu den 100%
korrigierbaren "Fehlern", bei denen sich auch inhaltlich bzw. vom zu
erwartenden Druckergebnis her nichts ändern kann.
Gruss,
Thomas
Christoph Bier
> Christoph Bier schrieb in <news:75vpvlF...@mid.individual.net>
>> Kann Acrobat jedes PDF in PDF/X umwandeln
[...]
>> also beispielsweise auch ein in TeX erzeugtes, das auf PDF/X keinerlei
>> Rücksicht nimmt?
[ausführliche Erläuterungen]
Danke für die Erläuterungen!
Markus Kohm
> Hilft der Acrobat 9 Report weiter oben weiter? Acrobat 9 scheint sich an
> den erweiterten Metadaten (in XMP/RDF) zu stï¿œren.
Wie aus zuverlï¿œssiger Quelle verlautet, wird das Paket ï¿œbrigens aufgrund der
Normeninterpretation von Acrobat 9 gerade ï¿œberarbeitet. Dabei soll auch das
Lizenzproblem mit der einen Datei beseitigt werden.
Es ist ï¿œbrigens nicht das erste Mal, dass Adobe eine Spezifikation bei einer
neuen Acrobat-Version neu bewertet und dann die neue Version PDF-Dokumente
anders beurteilt. Es ist sogar schon vorgekommen, dass eine neue Version
ein mit ï¿œlteren Versionen problemlos lad- und verarbeitbares PDF als
fehlerhaft beurteilt hat. Ob im konkreten Fall Acrobat 8 oder Acrobat 9 die
Konformitï¿œt besser prï¿œft, kann ich jedoch nicht beurteilen. Leider gibt es
kein (herstellerunabhï¿œngiges) Testwerkzeug, dessen Ergebnis verbindlich
wï¿œre. Ob von Acrobat 9 zusï¿œtzlich gemeldeten Probleme ggf.
produktionsrelevant sind, ist wiederum eine andere Frage.
Gruￜ
Markus
Thomas Kaiser
> Thomas Kaiser wrote:
>
>> Hilft der Acrobat 9 Report weiter oben weiter? Acrobat 9 scheint sich
>
> Wie aus zuverlässiger Quelle verlautet, wird das Paket übrigens
> aufgrund der Normeninterpretation von Acrobat 9 gerade überarbeitet.
Wenn das der einzige Grund ist, dann schade ;-)
Weil vermutlich meckert Acrobat 9 zurecht. Vergleich mal diese beiden
PDF, um die wir im Teilthread herumdiskutieren:
* <http://home.arcor.de/stephanhennig/Downloads/LaTeX/test.pdf>
Extrahier Dir dann den XMP/RDF-Block (bspw. per "pdfinfo -meta") und
wirf beide Blöcke (alles ab "<?xpacket begin...") mal dem RDF-Validator
des W3C vor
<http://www.w3.org/RDF/Validator/>
Stephans bzw. das mit pdfx.sty erstellte PDF/A produziert die folgenden
Fehler
Error: {W107} Bad URI: Expected scheme-specific part at index 4: <doi:>[Line = 15, Column = 35]
Error: {W107} Bad URI: <doi:> A bare scheme name is not a XercesURI: 'doi:'[Line = 15, Column = 35]
Das andere PDF bzw. dessen eingebettete XMP/RDF-Metadaten validieren.
Zum Thema:
<http://www.pdflib.com/developer/xmp-metadata/xmp-in-pdfa/>
> Dabei soll auch das Lizenzproblem mit der einen Datei beseitigt
> werden.
PDF/X-3 wäre für TeX-Anwender auch noch toll...
> Es ist übrigens nicht das erste Mal, dass Adobe eine Spezifikation bei
> einer neuen Acrobat-Version neu bewertet und dann die neue Version
> PDF-Dokumente anders beurteilt.
Nur zur Info:
Die ganze Prüf- bzw. Preflight-Technik stammt aus Berlin. Adobe hat das
von Callas lizensiert. Die gleiche Engine steckt auch in Callas'
Produkten, bspw. pdfInspektor(CLI) oder pdfaPilot. D.h. die in Acrobat
enthaltene Engine entspricht immer grob einer uralten Produktversion bei
Callas.
Problemlage ist nämlich, daß Adobe immer hübsch in der Zukunft
entwickelt und im hier und jetzt die Schotten dicht macht (auch für
Callas, d.h. die können dann bitten und betteln, auch gravierende Fixes
in der Prüfengine nachliefern zu dürfen -- das interessiert bei Adobe in
der Regel niemand, solange es sich nicht um die aktuell in der
Entwicklung befindliche Release, also aktuell 10, vielleicht sogar schon
eher 11, handelt)
Adobe fixt in bereits herausgekommenen Releases nur wirklich kritische
Sachen (oder was sie dafür halten). Und im Prinzip ist das Ganze schon
gegessen, wenn eine Release in den geschlossenen Betatest kommt. D.h.
wenn ein Drittanbieter-Modul in einer Acrobat-Release enthalten ist, die
bspw. Ende 2006 herauskommt (Acrobat 8), dann wird die Drittanbieter-
Komponente evtl. auf Stand von Anfang 2006 sein... und bleiben.
> Es ist sogar schon vorgekommen, dass eine neue Version ein mit älteren
> Versionen problemlos lad- und verarbeitbares PDF als fehlerhaft
> beurteilt hat.
Was meinst Du damit konkret? Validierung mittels "Acrobat Preflight"
oder "normales" Öffnen/Rendern eines PDF?
> Ob im konkreten Fall Acrobat 8 oder Acrobat 9 die Konformität besser
> prüft, kann ich jedoch nicht beurteilen.
Ich tippe auf Acrobat 9, einfach weil der XMP/RDF-Validator auch schon
meckert. Bei PDF/X muß man übrigens noch berücksichtigen, daß es hier
verschiedene PDF/X-1a- und PDF/X-3-Standards gibt (mit Jahreszahlen
gekennzeichnet)
> Leider gibt es kein (herstellerunabhängiges) Testwerkzeug, dessen
> Ergebnis verbindlich wäre.
Mei, bei der Komplexität der Thematik kann man's irgendwann nur noch auf
"de facto" Standards runterbrechen (und der heißt: "Acrobat Pro" in
ausreichend gereifter aktueller Version). Bzgl. PDF/A gibt's wenigstens
in Form der "Isartor-Testsuite" ein Werkzeug, um die Validatoren zu
validieren...
<http://www.pdfa.org/doku.php?id=artikel:validierung_von_pdfa>
Gruss,
Thomas
Rainer Plöckl
>> Ergebnis verbindlich wäre.
>
> Mei, bei der Komplexität der Thematik kann man's irgendwann nur noch auf
> "de facto" Standards runterbrechen (und der heißt: "Acrobat Pro" in
> ausreichend gereifter aktueller Version). Bzgl. PDF/A gibt's wenigstens
> in Form der "Isartor-Testsuite" ein Werkzeug, um die Validatoren zu
> validieren...
... was inzwischen auch im Rahmen des "Bavaria Reports"
http://www.pdflib.com/developer/pdfa/validation-report
geschehen ist.
Gruß,
Rainer
Rolf Niepraschk
...
>
> Wenn das der einzige Grund ist, dann schade ;-)
>
> Weil vermutlich meckert Acrobat 9 zurecht. Vergleich mal diese beiden
> PDF, um die wir im Teilthread herumdiskutieren:
>
> * <http://home.arcor.de/stephanhennig/Downloads/LaTeX/test.pdf>
>
> * <http://www.pdfa.org/lib/exe/fetch.php?id=press%3Aen&cache=cache&media=press:press_new-pdfa-chapter-in-north-america_en.pdf>
>
> Extrahier Dir dann den XMP/RDF-Block (bspw. per "pdfinfo -meta") und
> wirf beide Blöcke (alles ab "<?xpacket begin...") mal dem RDF-Validator
> des W3C vor
Es wäre dann sicher eine gute Idee, wenn Du die beobachteten Fehler oder
Unzulänglichkeiten den Paketautoren melden würdest.
...Rolf
Christoph Bier
Thomas hat mit TeX doch gar nichts am Hut ...
Grüße
Christoph
--
+++ Typografie-Regeln (1.6): http://zvisionwelt.de/?page_id=56
Thomas Kaiser
> Thomas Kaiser schrieb:
>> Bzgl. PDF/A gibt's wenigstens in Form der "Isartor-Testsuite" ein
>> Werkzeug, um die Validatoren zu validieren...
>
> ... was inzwischen auch im Rahmen des "Bavaria Reports"
> http://www.pdflib.com/developer/pdfa/validation-report geschehen ist.
Priml. Danke für die Info und all die Arbeit dahinter! Werde dann mal
(_wenn Zeit ist_) gucken, ob die Ergebnisse auch für Acrobat 9.1 Mac
passen und wie sich der von der Performance her schlägt (in sowohl
Batch-Betrieb als auch Droplet-Automatisierung). Dito für pdfToolboxCLI
in aktueller Ausführung, wenn ein Kunde von mir mitspielt.
Bzgl. der Ergebnisse des Reports kann man eigentlich nur auf 2010
hoffen. Bzw. daß die Hersteller draus lernen und ihre Werkzeuge
anpassen.
Gruss,
Thomas
Thomas Kaiser
> Es wäre dann sicher eine gute Idee, wenn Du die beobachteten Fehler
> oder Unzulänglichkeiten den Paketautoren melden würdest.
Ganz sicher nicht, weil ich kein TeX-User bin. Sprich: Das Ganze für
mich viel zu aufwändig ist. Meine Idee dahinter: Irgendwer aus dem TeX-
Umfeld, der sich hier für die Bedeutung von PDF/X und PDF/A ausreichend
sensibilisieren läßt, bereitet das auf und sorgt _wie auch immer_ dafür,
daß PDF/X-3 und PDF/A-1b problemlos aus TeX herausfallen.
Ich war bisher einmal in einen TeX-PDF-Workflow involviert (vor Jahren).
Da läuft alles zur vollsten Zufriedenheit, weil OPI [1] im Einsatz und
entsprechende Postprocessing-Tools aus dem Prepress-Sektor mittels
Farbmanagement und Preflight automatisiert für PDF/X-Konformität sorgen
(wir "fälschen" auch noch gleich die PDF-Metadaten und eliminieren
jegliche TeX-Referenz, um keine "Fachleute" in den Druckereien zu
irritieren. Wie heißt's in Bayern so schön? "Was der Bauer ned kennt,
frißt^Wdruckt er ned". Und Quark kennt er halt)
Will sagen: Ein persönlicher Leidensdruck diesbzgl. ist nicht vorhanden,
da entsprechende Tools im Einsatz, mit denen TeX problemlos zum
_qualifizierten_ Druckdatenzuspieler wird.
Gruss,
Thomas
[1] Grob-/Feindaten-Austausch. Damit bekommt man Bilder in den Workflow
bzw. durch Programme durchgeschleust, die diesbzgl. eher schwach auf
der Brust sind, wie bspw. Word oder TeX: