PDF Normen PDF X3 und PDF A

PDF Normen PDF/X3 und PDF/A

Hallo,

angeregt von einem Thread unter d.c.t.tex
vgl. Message-ID: <200903180628.a22117@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

Re: PDF Normen PDF/X3 und PDF/A

Andreas Weber schrieb in <news:gqiinb$po5$00$1@news.t-online.com>
> angeregt von einem Thread unter d.c.t.tex vgl. Message-ID: 
> <200903180628.a22117@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

Re: PDF Normen PDF/X3 und PDF/A

Hallo Thomas,

>> <200903180628.a22117@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:

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: <200903180628.a22117@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

Re: PDF Normen PDF/X3 und PDF/A

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.

[...]

Grüße
Christoph
-- 
+++ Typografie-Regeln: http://zvisionwelt.de/downloads.html (1.6)

Re: PDF Normen PDF/X3 und PDF/A

Christoph Bier schrieb am 27.03.2009 in <news:734b1oFt9bvjU1@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" 
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

Re: PDF Normen PDF/X3 und PDF/A

Thomas Kaiser schrieb:
> Christoph Bier schrieb am 27.03.2009 in <news:734b1oFt9bvjU1@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" 
> zahlen soll, [...]

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.

Grüße
Christoph
-- 
+++ Typografie-Regeln: http://zvisionwelt.de/downloads.html (1.6)

Re: PDF Normen PDF/X3 und PDF/A

Christoph Bier schrieb in <news:73btrvFtsdduU1@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). 

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

Re: PDF Normen PDF/X3 und PDF/A

On 2009-03-31 00:20, "Thomas Kaiser" wrote:

> [...]
>=20
> Nein. PDF/X f=C3=A4ngt zwar in erster Linie im Farbbereich Probleme ab.=
 Aber=20
> auch in reinen S/W-Szenarien hab ich selbst schon drei Problemklassen=20
> mitbekommen (bzw. reparieren d=C3=BCrfen):
>=20
> * Nicht eingebettete Fonts (sieht im Adobe Reader auf dem Rechner, auf =

>   dem die Datei erstellt wurde, noch toll aus. Bei der Ausgabe bzw. bei=
m=20
>   Ausgabedienstleister bleibt sowas im besten Fall in einem Preflight=20
>   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=C3=9Fer Firmen oder Beh=C3=B6=
rden
gesehen, die mit "Adobe Sans MM2 gar nicht h=C3=BCbsch aussahen ...

> [...]

Michael

--=20
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.

Re: PDF Normen PDF/X3 und PDF/A

Michael Unger schrieb in <news:73doviFtk57eU1@mid.individual.net>
> "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

Re: PDF Normen PDF/X3 und PDF/A

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?

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

Re: PDF Normen PDF/X3 und PDF/A

Markus Kohm schrieb in <news:1686733.cNA28lGFcR@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.

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.

Re: PDF Normen PDF/X3 und PDF/A

On 2009-03-31 23:57, "Thomas Kaiser" wrote:

> Markus Kohm schrieb in <news:1686733.cNA28lGFcR@mjk.komascript.de>
>> Thomas Kaiser wrote:
>>
>>> Und wer das schlichtweg nicht wei=C3=9F, wird Probleme bekommen ohne =
da=C3=9F er
>>> es will.
>>
>> Wie oft hast Du denn schon solche PDFs mit pdfTeX erzeugt?
>=20
> Ich selbst nie. Und da oben hab ich das W=C3=B6rtchen "evtl." vergessen=
=2E Mir=20
> ging's eigentlich nur um eine Abgrenzung zu Michaels Aussage, wer nicht=
=20
> um die Font-Einbettungs-Problematik wisse (und entsprechend falsch=20
> pr=C3=BCft), _wolle_ es nicht anders.

Das "wollen" war nat=C3=BCrlich leicht ironisch gemeint. Ich erlebe es ab=
er
nach wie vor _zu_ oft, dass eben _nicht_ _alle_ Schriften eingebettet
sind. HP hat "Futura" als "Hausschrift", in vielen Datenbl=C3=A4ttern zum=

Betriebssystem VMS oder zu AlphaServern fehlen dann halt etliche
Schnitte; "Futura" geh=C3=B6rt zumindest bei Windows _nicht_ zum normalen=

Schriftumfang, zum Mac kann ich nichts sagen. Auch bei Brosch=C3=BCren vo=
n
st=C3=A4dtischen =C3=84mtern, die auf dem offiziellen Webserver liegen, f=
ehlen
sehr oft die Schriften (die Dokumente werden h=C3=A4ufig mit Word erzeugt=
,
"Acrobat PDFMaker #.# f=C3=BCr 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=C3=B6rt eben ein bisserl Knowhow dazu (alternativ die passenden =
Tools=20
> bzw. das "narrensichere" Transportmedium -- mal wieder: PDF/X anstatt=20
> PDF)

Eben. Aber dieses Bewusstsein scheint selbst dort nicht fl=C3=A4chendecke=
nd
vorhanden zu sein, wo man es eigentlich voraussetzen sollte.

> [...]

Michael

--=20
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.

Re: PDF Normen PDF/X3 und PDF/A

Hallo Michael,

>> [...]
>> 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

Re: PDF Normen PDF/X3 und PDF/A

On 2009-03-31 14:22, "Andreas Weber" wrote:

>>> [...]
>>> Nein. PDF/X f=C3=A4ngt zwar in erster Linie im Farbbereich Probleme a=
b. Aber
>>> auch in reinen S/W-Szenarien hab ich selbst schon drei Problemklassen=

>>> mitbekommen (bzw. reparieren d=C3=BCrfen):
>>>
>>> * Nicht eingebettete Fonts (sieht im Adobe Reader auf dem Rechner, au=
f
>>>   dem die Datei erstellt wurde, noch toll aus. Bei der Ausgabe bzw. b=
eim
>>>   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=E4kchen 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=DFerdem werden eventuelle "Ersatzschriften" auch unter
"Datei" -> "Eigenschaften" -> "Schriften" entsprechend angezeigt.

> [...]
>=20
> 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=F6llig richtig.

>> Wer das nicht beachtet, _will_ eigentlich Probleme bekommen. Obwohl --=

>> ich habe auch schon genug PDF-Dokumente gro=C3=9Fer Firmen oder Beh=C3=
=B6rden
>> gesehen, die mit "Adobe Sans MM2 gar nicht h=C3=BCbsch aussahen ...
>=20
> btw: was ist an "Adobe Sans MM2" so besonders?

Eigentlich sollte da statt '2' n=E4mlich '"' stehen, nur war wohl die
Shift-Taste nicht kr=E4ftig genug gedr=FCckt -- 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 =FCbrigens ein "h=FCbsches" Beispiel, wie das o=
hne
eingebettete Schriften ganz gewaltig "in die Hose gehen" kann.

Michael


[1] <http://www.kednos.com/pli/king.pdf>

--=20
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.

Re: PDF Normen PDF/X3 und PDF/A

Hallo Michael,

>>>> [...]
>>> "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

Re: PDF Normen PDF/X3 und PDF/A

Andreas Weber schrieb:

[...]

> 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.

Grüße
Christoph
-- 
+++ Typografie-Regeln: http://zvisionwelt.de/downloads.html (1.6)

Re: PDF Normen PDF/X3 und PDF/A

Christoph Bier schrieb in <news:73gi84Fuih8qU1@mid.individual.net>
> 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

Re: PDF Normen PDF/X3 und PDF/A

Thomas Kaiser schrieb:
> Christoph Bier schrieb in <news:73gi84Fuih8qU1@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
Christoph
-- 
+++ Typografie-Regeln: http://zvisionwelt.de/downloads.html (1.6)

Re: PDF Normen PDF/X3 und PDF/A

Andreas Weber schrieb in <news:gquri0$9m8$02$1@news.t-online.com>
> 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

Re: PDF Normen PDF/X3 und PDF/A

On 2009-04-01 09:54, "Thomas Kaiser" wrote:

> [...]
>=20
> [...]         dann werden evtl. auch rein schwarze oder graue Elemente =

> Deines gelieferten PDFs anschlie=C3=9Fend bunt aufgebaut (Umwandlung vo=
n=20
> 0/0/0 RGB nicht in 0/0/0/100 CMYK sondern bspw. 60/50/49/70 -- Letztere=
s=20
> ist zwar ein sattes Schwarz, aber eines, das aus allen vier Druckfarben=
=20
> aufgebaut ist, d.h. extrem hohe Anforderungen an die Pa=C3=9Fgenauigkei=
t der=20
> Farbausz=C3=BCge darstellt bzw. bunte Farbs=C3=A4ume an schwarzen Eleme=
nten=20
> bedeutet). [...]

Sind HKS 90, 93 und 97 (K) jetzt "b=C3=B6se"? ;-)

> [...]

Michael

--=20
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.

Re: PDF Normen PDF/X3 und PDF/A

Michael Unger schrieb am 01.04.2009 in <news:73hf2kFulnluU5@mid.individual.net>
> 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

Re: PDF Normen PDF/X3 und PDF/A

On 2009-04-03 12:31, "Thomas Kaiser" wrote:

> [...]
>=20
> Wenn man die entsprechenden HKS-Farben in CMYK umzusetzen versucht und =

> druckt (wen's interessiert -- eine Tabelle findet sich bspw. in [1]), [=
=2E..]
>=20
> [...]
>=20
> [1] <http://www.tabelle.info/hks_farben.html>
>=20
> [...]

Der genannten Tabelle (die ich auch schon mal gefunden hatte) traue ich
nicht ganz =C3=BCber den Weg -- die dort angegebenen CMYK-Werte weichen z=
um
Teil deutlich von denjenigen ab, die auf den "HKS-Farbtafeln" stehen,
zudem gibt es ja noch die "K"-, "N"-, "E"- und "Z"-Varianten.

Michael

--=20
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.

[OT] Farbdefinitionen in Druckdaten und zu erwartendes Ergebnis (was: Re: PDF Normen PDF/X3 und PDF/A)

Michael Unger schrieb in <news:73mlkgF1041hnU2@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.

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

[1] <http://de.wikipedia.org/wiki/Prozess_Standard_Offset>

Re: [OT] Farbdefinitionen in Druckdaten und zu erwartendes Ergebnis

On 2009-04-03 17:33, "Thomas Kaiser" wrote:

> Michael Unger schrieb in <news:73mlkgF1041hnU2@mid.individual.net>
>> On 2009-04-03 12:31, "Thomas Kaiser" wrote:
>>
>>> Wenn man die entsprechenden HKS-Farben in CMYK umzusetzen versucht un=
d=20
>>> druckt (wen's interessiert -- eine Tabelle findet sich bspw. in [1]),=
 [...]
>>>=20
>>> [1] <http://www.tabelle.info/hks_farben.html>
>>>=20
>> Der genannten Tabelle (die ich auch schon mal gefunden hatte) traue=20
>> ich nicht ganz =C3=BCber den Weg -- die dort angegebenen CMYK-Werte we=
ichen=20
>> zum Teil deutlich von denjenigen ab, die auf den "HKS-Farbtafeln"=20
>> stehen, zudem gibt es ja noch die "K"-, "N"-, "E"- und "Z"-Varianten.
>=20
> Es ist doch eh alles Quatsch, genauso wie der Versuch, mittels=20
> DeviceCMYK konkrete Farborte auszudr=C3=BCcken. Welche Farbe die CMYK- =

> Kombination 50/50/10/10 im Druck bekommen wird, bestimmt die=20
> Papiersorte, der Druckstandard (in den die Beschaffenheit der=20
> Druckfarben -- also Viskosit=C3=A4t, opake/transparente Eigenschaften, =

> optische Dichte und nat=C3=BCrlich der konkrete Farbort -- einflie=C3=9F=
en als=20
> auch Farbmenge/Farbf=C3=BChrung des Druckprozesses wie auch konkrete=20
> Druckweise) und proze=C3=9Fimmanente Gr=C3=B6=C3=9Fen wie bspw. das ver=
wendete=20
> Rastersystem (frequenzmoduliert vs. autotypisch bspw.), die Art der=20
> Farb=C3=BCbertragung (an diversen Stellen, bspw. Plattenbelichtung/-kop=
ie,=20
> etc.), denen man mit Proze=C3=9Fkalibirierung beizukommen versucht.

HKS spezifiziert bleistiftsweise f=C3=BCr die "K"-Reihe: Phoeno-Grand
holzfrei gl=C3=A4nzend spezial-gestrichenes Bilderdruckpapier 115 g/m=C2=B2=
 von
Scheufelen, 1.5 =C2=B5 Farbschichtdicke. Irgendwie klingt das ziemlich
"wohldefiniert".

> Wenn Papierklasse und Druckbedingungen hingegen definiert sind (siehe=20
> ECI-Link im Thread), dann und wirklich erst dann entspricht eine=20
> Kombination vierer Prozentwerte einer konkreten Farbe --

Das oben Zitierte liest sich aber genau so, zumal es ja jeweils
verschiedene Werte f=C3=BCr *K*unstdruck-, *N*ormal-, *E*ndlos- und
*Z*eitungspapier gibt.

>                                                          das aber=20
> nat=C3=BCrlich auch nur unter Normlichtbedingungen, denn K=C3=B6rperfar=
ben h=C3=A4ngen=20
> ja von der Lichtquelle ab.
>=20
> In der HKS-Palette gibt es eine ganze Latte an Farbt=C3=B6nen, die=20
> schlichtweg nicht mit normalem 4-farbigen Offset (oder am Farbumfang vo=
n=20
> Offset ausgerichtetem Digitaldruck) dargestellt werden k=C3=B6nnen, wei=
l der=20
> HKS-Farbraum umf=C3=A4nglicher 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 =C3=BCbrigens =
die
Qualit=C3=A4t der CMYK-Approximation in drei "G=C3=BCteklassen" eingeteil=
t, da
wird also durchaus auf m=C3=B6gliche Probleme hingewiesen.

> [...]
>=20
> So, alles total OT hier. [...]

Um das wieder in Richtung on-topic zu drehen: Wenn man im PDF
ausschlie=C3=9Flich DeviceCMYK verwendet, keine zu "ausgefallenen" Farben=

benutzt und beim Gesamt-Farbauftrag nicht "=C3=BCbertreibt" -- ist das da=
nn,
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.

Michael

--=20
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.

Re: [OT] Farbdefinitionen in Druckdaten und zu erwartendes Ergebnis

Michael Unger schrieb am 03.04.2009 in <news:73n1liFvtaarU1@mid.individual.net>
> On 2009-04-03 17:33, "Thomas Kaiser" wrote:
>
>> Michael Unger schrieb in <news:73mlkgF1041hnU2@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

Re: PDF Normen PDF/X3 und PDF/A

On 2009-04-01 03:16, "Andreas Weber" wrote:

> [...]
>=20
> Damit habe ich wahrscheinlich schonmal 0.001% der Problematik
> verstanden ;-)

Bei derartigen Gr=F6=DFenordnungen 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:
>=20
> \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=FCr den _Druck_ ausgerechnet den RGB- und
nicht den CMYK-Farbraum benutzt.

> [...]
>=20
> [...]            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=FCr einfache Sachen nehme ich Word und konvertiere das=

dann mit Acrobat ("PDFMaker") nach PDF; schwierigere Sachen, wo es auf
einigerma=DFen 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

--=20
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.

Re: PDF Normen PDF/X3 und PDF/A

Michael Unger schrieb am 01.04.2009 in <news:73hf2jFulnluU4@mid.individual.net>
> 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

Re: PDF Normen PDF/X3 und PDF/A

Thomas Kaiser schrieb:
> Christoph Bier schrieb in <news:73btrvFtsdduU1@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.

> 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)

Grüße
Christoph
-- 
+++ Typografie-Regeln: http://zvisionwelt.de/downloads.html (1.6)

Re: PDF Normen PDF/X3 und PDF/A

Christoph Bier schrieb in <news:73dv3jFu8b65U1@mid.individual.net>
> Thomas Kaiser schrieb:
>> Christoph Bier schrieb in <news:73btrvFtsdduU1@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

Re: PDF Normen PDF/X3 und PDF/A

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Kaiser schrieb:
> Christoph Bier schrieb in <news:73dv3jFu8b65U1@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-----

Re: PDF Normen PDF/X3 und PDF/A

Josef Kleber schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Thomas Kaiser schrieb:
>> Christoph Bier schrieb in <news:73dv3jFu8b65U1@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.

Grüße
Christoph
-- 
+++ Typografie-Regeln: http://zvisionwelt.de/downloads.html (1.6)

Re: PDF Normen PDF/X3 und PDF/A

Thomas Kaiser schrieb:
> Christoph Bier schrieb in <news:73dv3jFu8b65U1@mid.individual.net>
>> Thomas Kaiser schrieb:
>>> Christoph Bier schrieb in <news:73btrvFtsdduU1@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!

Grüße
Christoph
-- 
+++ Typografie-Regeln: http://zvisionwelt.de/downloads.html (1.6)

Re: PDF Normen PDF/X3 und PDF/A

Christoph Bier schrieb in <news:73eip1FucqroU1@mid.individual.net>
> Thomas Kaiser schrieb:
>> Christoph Bier schrieb in <news:73dv3jFu8b65U1@mid.individual.net>
>>> Thomas Kaiser schrieb:
>>>> Christoph Bier schrieb in <news:73btrvFtsdduU1@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>

Re: PDF Normen PDF/X3 und PDF/A

Thomas Kaiser schrieb am 01.04.2009 00:31:

> Christoph Bier schrieb in <news:73eip1FucqroU1@mid.individual.net>
>> Thomas Kaiser schrieb:
>>> Christoph Bier schrieb in <news:73dv3jFu8b65U1@mid.individual.net>
>>>> Thomas Kaiser schrieb:
>>>>> Christoph Bier schrieb in <news:73btrvFtsdduU1@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

Re: PDF Normen PDF/X3 und PDF/A

Christoph Bier <christoph.bier@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.

-- 
MFG, Johannes.

PGP Fingerprint: 719A 160A 6643 889E 851D  CE3C 71CA 824A 2E44 AC29
PGP: keyID: 2E44AC29 0x71ca824a2e44ac29

Re: PDF Normen PDF/X3 und PDF/A

Johannes Starosta schrieb:
> Christoph Bier <christoph.bier@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: <74rpp1F159srvU1@mid.individual.net>

Grüße
Christoph
-- 
+++ Typografie-Regeln (1.6): http://www.zvisionwelt.de/?page_id=56

Re: PDF Normen PDF/X3 und PDF/A

Christoph Bier schrieb in <news:75t31vF19u3hjU2@mid.individual.net>
> Johannes Starosta schrieb:
>> Christoph Bier <christoph.bier@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: <74rpp1F159srvU1@mid.individual.net>

Ich -- als Nicht-Texer -- bleib jetzt mal hier. Hab den Thread ausgehend 
von <news:74rpp1F159srvU1@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>

Re: PDF Normen PDF/X3 und PDF/A

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. 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

Re: PDF Normen PDF/X3 und PDF/A

Markus Kohm schrieb in <news:1613931.yT8X08dbuN@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. 
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

Re: PDF Normen PDF/X3 und PDF/A

Thomas Kaiser schrieb am 30.04.2009 13:56:

> Markus Kohm schrieb in <news:1613931.yT8X08dbuN@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

Re: PDF Normen PDF/X3 und PDF/A

Christoph Bier schrieb in <news:75vpvlF1aqon2U1@mid.individual.net>
> 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

Re: PDF Normen PDF/X3 und PDF/A

Thomas Kaiser schrieb am 01.05.2009 13:43:

> Christoph Bier schrieb in <news:75vpvlF1aqon2U1@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!

Grüße
Christoph
-- 
+++ Typografie-Regeln (1.6): http://zvisionwelt.de/?page_id=56

Re: PDF Normen PDF/X3 und PDF/A

Thomas Kaiser schrieb:

> * 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.

Re: PDF Normen PDF/X3 und PDF/A

Stephan Hennig schrieb:

> Den Fehler habe ich lokal behoben, so dass die Datei RGBIEC61966-2.1.icm

sRGBIEC61966-2.1.icm  natürlich.

Viele Grüße
Stephan Hennig

Re: PDF Normen PDF/X3 und PDF/A

Stephan Hennig schrieb am 30.04.2009 in <news:49f9d286$0$31867$9b4e6d93@newsspool3.arcor-online.net>
> 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

[1] <http://www.pdfa.org/lib/exe/fetch.php?id=press%3Aen&cache=cache&media=press:press_new-pdfa-chapter-in-north-america_en.pdf>

Re: PDF Normen PDF/X3 und PDF/A

Thomas Kaiser wrote:

> 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

Re: PDF Normen PDF/X3 und PDF/A

Markus Kohm schrieb in <news:1940849.0gl0VrcTNs@mjk.komascript.de>
> Thomas Kaiser wrote:
>
>> 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.

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

    <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

Re: PDF Normen PDF/X3 und PDF/A

Thomas Kaiser schrieb:
> Markus Kohm schrieb in <news:1940849.0gl0VrcTNs@mjk.komascript.de>
>> 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...

... was inzwischen auch im Rahmen des "Bavaria Reports"
http://www.pdflib.com/developer/pdfa/validation-report
geschehen ist.

Gruß,
Rainer

Re: PDF Normen PDF/X3 und PDF/A

Rainer Plöckl schrieb am 05.05.2009 in <news:gtplgi$ov4$1@svr7.m-online.net>
> 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

Re: PDF Normen PDF/X3 und PDF/A

Thomas Kaiser schrieb:
...
> 
> 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

Re: PDF Normen PDF/X3 und PDF/A

Rolf Niepraschk schrieb am 05.05.2009 17:52:

> Thomas Kaiser schrieb:
> ...
>> 
>> 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.

Thomas hat mit TeX doch gar nichts am Hut ...

Grüße
Christoph
-- 
+++ Typografie-Regeln (1.6): http://zvisionwelt.de/?page_id=56

Re: PDF Normen PDF/X3 und PDF/A

Rolf Niepraschk schrieb am 05.05.2009 in <news:76b5mqF1c3e25U1@mid.individual.net>
> 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:

    <http://de.wikipedia.org/wiki/Open_Prepress_Interface>

Re: PDF Normen PDF/X3 und PDF/A

Thomas Kaiser wrote:

> 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

Re: PDF Normen PDF/X3 und PDF/A

Andreas Weber schrieb am 27.03.2009 in <news:gqisae$s3k$01$1@news.t-online.com>
> Hallo Thomas,
>
>>> <200903180628.a22117@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:
>
> 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

Re: PDF Normen PDF/X3 und PDF/A

Zum Thema passend:

==> http://www.cleverprinting.de/ratgeber2009.html

...Rolf

Re: PDF Normen PDF/X3 und PDF/A

Rolf Niepraschk schrieb in <news:73e8n4FudodlU2@mid.individual.net>
>
> Zum Thema passend:
>
>==> http://www.cleverprinting.de/ratgeber2009.html

Grundsätzlich Zustimmung. Der hier überwiegend vertretenen TeX-Fraktion 
wird das aber nicht als Frustration spendieren.

Gruss,

Thomas