Dokument für Druckereien akzeptabel machen - pdfx oder was?

[rstuby]

Hallo, hierzu mache ich wohl lieber ein neues Thema auf:
Hat einer Erfahrung, was man machen muss, damit die Druckerei das .pdf-Dokument so akzeptiert und druckt?
Alle Bilder auf CMYK gesetzt und die Pixelgrafiken auf mindestens 300dpi (so, dass es nach dem Skalieren so hinkommen müsste) habe ich schon.
Ich hoffe mal, die verlangen nicht, dass wir alle Fonts vollständig einbinden, denn ich benutze textcomp und wasysym und die Datei ist jetzt schon wegen der Bilder über drei MB groß.
Wegen der Größe kann ich sie nicht bei pdfcity.com prüfen lassen.
Unser Adobe Acrobat Professional 6.0 bemängelt im "preflight", die pdf-Version sei zu neu - tja, wer hätte das gedacht...?
Was bringen diese pdf-Standards wie pdf/X oder pdf/A? Macht es Sinn, das Paket pdfx zu nutzen (dann muss man aber wohl hyperref rausschmeißen, und da wollte ich eigentlich noch die Option Unicode angeben...) oder dem hyperref die Option pdfa mitzugeben?
Und wie gibt man die nötigen Angaben, Autor usw., dem Dokument vernünftig mit (oder besser nachträglich außerhalb von LaTeX in Acrobat Professional oder so angeben?)?
Mit Beispielen, die \def enthalten, sollte man doch eher vorsichtig sein, oder?

[Schweinebacke]

Das hängt von der Druckerei oder dem Verlag ab. Manche testen nur stur mit irgend einem Tool, das bereits motzt, wenn das PDF nicht mit Acrobat erstellt ist. Bei denen hilft nur, das PDF noch einmal mit Acrobat zu laden und unter Verwendung des entsprechenden Profils zu speichern. Die besseren Verlage/Druckereien testen aber eher darauf, dass das PDF alle verwendeten Fonts enthält (nein nicht komplett, sondern die Zeichen, die verwendet werden), dass die Abbildungen die gewünschte Auflösung haben etc. und werfen ggf. selbst ihr Acrobat an, um es nochmal umzuwandeln. Wenn das dann schief geht, können sie Dir auch sagen, was schief geht. Häufig bei PDFs von TeX ist, dass kein Farbprofi eingebettet ist. In der Regel wird dann ein Standardfarbprofil verwendet. Wenn Du ganz bestimmte Farben haben willst, musst Du aber ohnehin ein Proof anfordern.

pdfx lädt übrigens selbst hyperref und deaktiviert einige Features davon und legt andere Dinge hart fest, die eigentlich konfigurierbar sein sollten. Man könnte sagen, dass das Paket sehr speziell auf die Anforderungen der Autoren zugeschnitten ist.

[rstuby]

Ich habe jetzt bei hyperref die Option pdfa angegeben und die Angaben mit hypersetup eingefügt. Dann habe ich jeweils ein Bild rausgenommen und das Ergebnis, das dann kleiner als 3MB war, bei pdfcity.com getestet. Das einzige, was die zu meckern hatten, waren ein paar zu dünne Linien. fboxrule vergrößert - alles OK. Hoffentlich sehen das nicht nur die so :-)

[ellocco]

Das ist zwar nicht direkt eine Antwort zu den drei Beiträgen, aber ich wollte nicht
einen dritten Thread zum Paket pdfx eröffnen:
1.)
Das Stylefile ist fehlerhaft, ein Fehler ist u.a. die fehlende Definition
des Befehls "\Subject", hier meine Korrektur:

\def\Subject#1{\gdef\xmpKeywords{#1}}
\let\xmpSubject\@empty

2.)
Bei der Wahl der Option "x-1a" werden wichtige Maße fix auf die Papiergröße "letter" gesetzt:

\pdfpageattr{/MediaBox[0 0 595 793]
/BleedBox[0 0 595 793]
/TrimBox[25 20 570 773]}

Wer A4 benutzen will, kann Folgendes versuchen:

\usepackage[x-1a]{pdfx}
\makeatletter
\pdfpageattr{/MediaBox[0 0 595.276 841.89]
/BleedBox[0 0 595.276 841.89]
/TrimBox[25 20 570 820]}
\makeatother
Zu dem Thema hat sich auch "Heiko Oberdiek" geäußert (vgl. 17-Sep-2011, Newsgroup de.comp.text.tex).

3.
Das Paket ist ohne weitere Dateien nicht lauffähig, benötigt werden:

FOGRA39L.icc und
sRGBIEC1966-2.1.icm
(die müssen im Internet gesucht werden)

El Locco

[ellocco]

Aber vielleicht ist es auch besser, den Teil mit "MediaBox" ganz
aus dem Stylefile zu löschen, damit die "MediaBox" nicht doppelt
definiert wird.

\ifpdfxonea
\pdfminorversion=3
\else
\pdfminorversion=4
\fi

Die Werte für "BleedBox" und "TrimBox" können dann noch manuell
im LaTeX Dokument gesetzt werden (Hier meine Werte für A4.
Frage: sind die Werte für die TrimBox so sinnvoll?):

\makeatletter
\pdfpageattr{/BleedBox[0 0 595.276 841.89]
/TrimBox[25 20 570 820]}
\makeatother
Die Werte für die "BleedBox" entsprechen denen der "MediaBox", die
ohne die Verwendung von dem Paket "pdfx" gesetzt werden (die habe
ich mit einem Texteditor im PDF-File ausfindig gemacht).
Naja, nach dem Ändern des Style-Files muß dann natürlcih die LaTeX
Datenbank aufgefrischt werden, das geht unter "MiKTeX" mit Admin-Rechten
glaube ich so:

initexmf --admin --update-fndb

El Locco

[Schweinebacke]

\pdfpageattr arbeitet wie ein Tokenregister. Zuweisungen daran überschreiben also frühere Zuweisungen. Außerdem gilt es nur für die aktuelle Seite. Für alle Seiten gilt hingegen \pdfpagesattr. Auch das arbeitet wie ein Tokenregister. Will man also, dass bei mehrfachem Aufruf nicht nur der letzte Aufruf gültig ist, muss man selbst dafür sorgen, dass der alte Inhalt erhalten bleibt.

Dass man die MediaBox nicht selbst setzen sollte, liegt daran, dass pdfTeX diese über \pdfpaperwidth und \pdfpaperheight selbst setzt (und zwar für alle Seiten einzeln, so dass man die Längen auch innerhalb des Dokuments ändern kann).

BTW: \xmpSubject wird in pdfx.sty bereits per
\let\xmpKeywords\@empty
\let\xmpSubject\xmpKeywords auf \@empty gesetzt. Das selbst noch einmal zu machen, ist also überflüssig.

Weitere Beschränkungen und Nachteile des Pakets wurden auf de.comp.text.tex vor einiger Zeit ausführlich diskutiert. Markus Kohm hat dort sogar halb angeboten eine bessere Version zu schreiben, wenn ihm jemand dauerhaft die notwendige Spezifikation und Validierungssoftware zur Verfügung stellt - ein teurer Spaß.

[ellocco]

Danke für die schnelle Rückmeldung, also bei mir gibt es mit der Originalversion von "pdfx.sty" eine Fehlermeldung,
es fehlt einfach die Definition von "\Subject":

\def\Subject...
Probiere einfach mal folgendes mit der Originalversion von "pdfx.sty":

\begin{filecontents*}{\jobname.xmpdata}
\Subject{Thema}
\end{filecontents*}
[...]
(Vorher muß die alte Datei "\jobname.xmpdata" gelöscht werden, da sie von LaTeX nicht überschrieben wird.)
Ansonsten werde ich aus Deinen Anmerkungen nur teilweise schlau, kennst Du einen Artikel, der die
Funktionsweise von "Tokenregistern" erklärt, ich weis weder was ein "Token" noch was ein "Tokenregister" ist.
Und Deine Ausführungen zum Befehl "\pdfpagesattr" verstehe leider auch nicht, mein Workaround mit dem
Befehl "\pdfpageattr" scheint jedenfalls zu funktionieren, empfiehlst Du eher den Befehl "\pdfpagesattr"
zu verwenden?
Leider verstehe ich auch nicht, was ich da tuhe, kennst Du einen Artikel der die Parameter "BleedBox" und
"TrimBox" erklärt?
Können die evtl. auch eleganter automatisch berechnet und gesetzt werden?

[Schweinebacke]

es fehlt einfach die Definition von "\Subject": Habe ich das bestritten? Du hast nur mehr definiert als nur \Subject und dazu etwas, was bereits definiert ist. Darauf darf man doch hinweisen, oder?


Ansonsten werde ich aus Deinen Anmerkungen nur teilweise schlau,
Da Du auf TeX-Ebene hantierst, hatte ich natürlich angenommen, dass Du diese so weit beherrschst. Sonst hätte ich gleich auf die Literatur hingewiesen:


kennst Du einen Artikel, der die
Funktionsweise von "Tokenregistern" erklärt, ich weis weder was ein "Token" noch was ein "Tokenregister" ist.
Lies das TeXbook oder zumindest TeX by Topic, das frei auf CTAN (http://www.ctan.org/pkg/texbytopic) zu finden ist. Ich habe leider nicht die Zeit, Dir TeX bei zu bringen.


Und Deine Ausführungen zum Befehl "\pdfpagesattr" verstehe leider auch nicht
Es geht darum, was passieren kann(!), wenn diese Anweisungen in einem Dokument mehrfach oder gemischt verwendet werden. Siehe auch die Erklärung zu den beiden Anweisungen in der pdfTeX-Anleitung. Wenn Pakete diese Anweisungen bereits verwenden, muss man je nach gewünschtem Ergebnis unterschiedlich vorgehen oder zumindest ein wenig Vorsicht walten lassen. Das ist eben der Nachteil, wenn man sich auf die niederen Ebenen der pdfTeX-Programmierung herab begibt. Ich habe keineswegs behauptet, dass Deine Idee keine Lösung sein kann(!).

BTW: Code in \makeatletter und \makeatother einzuschließen, der kein at enthält, ist sinnlos. Ich erwähne das nur der Vollständigkeit halber.

Ebenso sei nur der Vollständigkeit halber erwähnt, dass man die geänderte Paketdatei besser umbenennen (und dann natürlich auch in seinem Dokument den neuen Namen verwenden) sollte. Wenn man das nicht tut, sollte man die geänderte Paketdatei zumindest in einem anderen TEXMF-Baum speichern. Sonst wird sie möglicherweise bei einem Update mal eben einfach so vom Paketmanager überschrieben …

[ellocco]

BTW: Code in \makeatletter und \makeatother einzuschließen, der kein at enthält, ist sinnlos.
Danke für den Tip :-)


Ebenso sei nur der Vollständigkeit halber erwähnt, dass man die geänderte Paketdatei besser umbenennen (und dann natürlich auch in seinem Dokument den neuen Namen verwenden) sollte. Wenn man das nicht tut, sollte man die geänderte Paketdatei zumindest in einem anderen TEXMF-Baum speichern. Sonst wird sie möglicherweise bei einem Update mal eben einfach so vom Paketmanager überschrieben …
Das wäre in dem Fall wirklich prima, das hieße, es hat sich jemand mit dem Paket beschäftigt.

[Schweinebacke]

Das wäre in dem Fall wirklich prima, das hieße, es hat sich jemand mit dem Paket beschäftigt.
Das kann auch nur derjenige gewesen sein, der das Paket zusammenstellt, beispielsweise eine Info dazu gepackt haben, wo man die icm-Dateien findet. Aber wenn Du das Risiko, Deine Änderungen zu verlieren, eingehen willst, bleibt das natürlich Dir überlassen. Ich wollte die Gefahr nur für diejenigen erwähnen, die an ihrer Arbeit hängen …