Hallo zusammen,
Bei diesem Thema (Glypen) bewegen wir uns wieder im "Bermuda-Dreieck" zwischen den Herstellern. Statt Apple ist dieses mal eben neben Adobe und Quark Callas involviert. Und auch dieses mal gibt es wohl wieder keine einfachen Lösungen.
Acrobat 8's Profile prüfen gemäß den GWG Specifications V3. Acrobat 9 prüft dagegen gemäß GWG V4.
QuarkXPress 7 und 8 evaluieren PDF/X mit dem PDFinspector 3. In Acrobat 9 ist dagegen die Engine des Inspector 4 verbaut.
Eine Prüfung in Acrobat 8 verhält sich also zwangsläufig anders als in Version 9. Weiterhin ist es so, dass erst in Acrobat 9 eine Prüfung gemäß GWG 4 möglich ist, da bestimmte Checks erst dort integriert wurden.
Ein gutes Beispiel ist der Hash-Wert für das ICC-Profil des OutputIntents: Erst Acrobat 9 erlaubt dessen Abprüfung. GWG 4 schreibt eine Prüfung auf Basis dieser MD5 Checksumme vor. Jede Prüfung in Acrobat 8 kann daher GWG 4 nur "annähern" aber nie vollständig erfüllen.
Die PDF/X-4 Norm hat das Vorhandensein des .notdef Glyphen stärker reglementiert. Dies leitet sich aber ab aus (schon länger existenten) Vorgaben in den Font- und PDF-Spezifikationen. Die GWG hat diese Einschränkungen in die V4 Regeln übernommen, auch wenn diese noch auf PDF/X-1a basieren. Demzufolge funktioniert auch erst in Acrobat 9 die .notdef Prüfung zu 100% zuverlässig.
Der selbe Fall ist es mit der Konsistenz der Weiten-Informationen. PDF/X-4 formuliert das sauber aus, die PDF reference verlangt es schon lange, die GWG hat es in die 4er Specs mit übernommen.
Dass durch die Konkretisierungen ein paar schon lange tickende Zeitbomben hochgehen würden war wohl leider zu befürchten.
Die Fragen, die Detlev in den Raum stellt, müssen also neben dem PDF selbst und dessen Erzeugerprogramm noch eine weitere Variable berücksichtigten: Das PDF-Prüftool und den Standard auf dem es basiert. Hätten wir außer Callas und PitStop noch andere wichtige Prüfwerkzeuge hätten wir vermutlich auch noch unterschiedlichere Ergebnisse.
Zum XPress-Problem:
Das Problem beschränkt sich wohl wirklich nicht nur auf die Infozeile sondern generell auf den Seiteninhalt. Jeder TrueType-Zeichen im PDF stellt eine Fundstelle dar. Allgemeiner kann man daraus wohl ableiten, dass es ein Problem mit der Ausgabe von TrueType Fonts aus XPress 8 gibt. Es wurde ja schon darauf hingewiesen, dass Quark etwas an der Font-Ausgabe geändert hat.
Das Preflight sieht also in jedem Glyphen des Fonts einen .notdef Glyphen. Das deutet für mich schon auf ein XPress-Problem hin, zumal man das Problem ja ansonsten auch anderen Programmen nachstellen können müsste (laut Rohrfrei aber nicht der Fall).
Weiterhin ist es so, dass XPress 8 PDFs auch in Acrobat
8 durch den .notdef Glyphen Check fallen!
Die benutzerdefinierte Prüfung "Effectively uses .notdef glyph" (bzw. "Zeichen wird als ".notdef" dargestellt" => trifft zu) schlägt auch hier bei den TrueType Fonts an.
Der einzige Unterschied scheint mir zu sein, dass Acrobat 8 beim Check "Zeichen referenziert ".notdef" Glypen" => "trifft zu" nicht anschlägt, Acrobat 9 dagegen schon. Hier ist es wohl ein Stück weit restriktiver geworden.
Das Grundproblem wird also auch schon von Acrobat 8 erkannt.
In Acrobat 9 kommen dann die oben erwähnten Erweiterungen und Ergänzungen aufgrund der veränderten Normsituation dazu.
Für mich liegt der Ball damit eindeutig bei Quark.
Trotzdem würde ich solche PDFs aus XPress 8 mit TrueType Fonts weiterhin als "druckfähig" ansehen.
Georg Obermayr
------
NEU: Das Buch zu agilem Publishing: http://www.agile-publishing.de/go-book Twitter:
http://www.twitter.com/georgobermayr