Hallo,

auf einem PowerPC habe ich doch die 7.01 installiert. Nach den positiven Erfahrungen mit dem neuen PDF-Export der 7er unter Win dachte ich, man könnte das Adobe-PDF-Problem bis zum nächsten Update umschiffen und mit dem PDF-Export leben.

Nun habe ich aber ein Problem, daß ich überhaupt nicht kapiere.
Ich habe ein Layout mit mehreren grafischen Objekten und auch platzierten EPSen. Die EPSe kommen aus PDF/X-3s, die korrekt mit allen Fonts aus Acrobat 7 exportiert wurden, d.h. alle Fonts sind korrekt eingebettet. Wenn man so ein EPS wieder distielliert ist alles ok (Distiller-Font-Handling ist sauber !).

Wenn ich nun aber das Quark-Layout als PDF/X-3 exportiere, da ja der Adobe-PDF streikt, passiert was ganz komisches. Zunächst kommen zwei Meldungen während des Exports:
1. Ein EPS enthält Binärdaten - ok, sollte kein Problem sein.
2. Ein EPS enthält Daten der Stufe 3 - also das ist mal eine totol bekloppte Meldung. Wahrscheinlich will mir der besoffene Übersetzer mitteilen, daß ein EPS PS3 enthält, oder? Kann das jemand bestätigen?

Dann geht es weiter. Nächste Meldung:
PDF/X-3-Erstellung ist fehlgeschlagen, aber PDF wurde erzeugt. Äh, habe ich was verpasst? Ist das Quark-Philosophie? Warum bricht er dann nicht ab, wenn ich explizit die Erstellung von X3 eingestellt habe? Das erzeugte PDF liegt tatsächlich am Speicherort zusammen mit der Callas-Logdatei - das ist ja schon mal gut.

In der Log-Datei steht, daß er 3 Fonts nicht einbinden konnte. Courier und zweimal ITCEras. Die Eras ist in dem oben beschriebenen platzerten EPS enthalten - aber ich kann garantieren, daß die Fonts im EPS korrekt sind. Lasse ich das von XPress erzeugte PDF durch den Acrobat-Preflight jagen, dann kommen auch die Fonts im platzierten EPS zum Vorschein, natürlich nicht korrekt eingebettet.

Und es kommt noch dicker:
Die Courier ist in der Informationszeile aus XPress (also oben links bei den Schnittzeichen) enthalten - nicht im eigentlichen Layout. Allerdings ist laut Preflight nur der Projekt-Layout-Name als Courier nicht eingebettet. Das Datum sehr wohl. Das ist ja wohl total unlogisch.

Gegentest per EPS-Export:
Festhalten. Das aus XPress exportierte EPS auf den Distiller geworfen wird problemlos zu X3 gewandelt. Keinerlei Schriftenproblem. Wie gesagt, der Distiller hat nur seinen eigenen Fontordner zugewiesen bekommen. Der kann das nicht hinzugefügt haben.

Nun bin ich - zumindest auf Mac - total verunsichert. Das ist alles so unlogisch und durcheinander, das kann ich überhaupt nicht eingrenzen. Werde sicherlich noch mit weiteren Daten testen, aber vielleicht weiß jemand an der einen oder anderen Stelle schon mal was.

Das Layout kommt ursprünglich aus 6.5.
Alle Ausgabestile sind korrekt definiert - also Fontincluding usw.
XPress 7.01 auf PowerPC G4 unter 10.4.7

Gruß

Hallo rohrfrei,

Das Dokument wurde aus 6.5 übernommen? Besteht das Problem nach einer Miniaturseitenverschiebung auch noch?
Wenn ja, wäre es dann möglich, dass ich mal ein solches Projekt bekomme, würde auch gerne einen Blick drauf werfen?
Auf die Sache wegen der PDF/X-Evaluierung kann ich dann noch genauer Antwort geben, mir wäre jetzt erst mal wichtig, welcher Gestalt das Problem ist.

Georg Obermayr

Hallo,

könnte es frühestens nächste Woche machen. Ich habe mir davon nichts mitgenommen. Werde bis dahin nochmal drüber nachdenken und testen. Melde mich dann ggflls. nochmal.

Gruß

Hallo nochmal Herr Obermayr,

nach Rücksprache mit dem Kunden, kann ich Ihnen die fraglichen Dateien leider nicht zum Test überlassen.

Ich habe es aber nochmals komplett heute durchgespielt auf meiner neu installierten 7.0 auf PPC. Das Problem ließ sich genau so reproduzieren wie letzte Woche mit 7.01. Mit der Ergänzung natürlich, daß ich jetzt auch über Adobe-PDF ein X3 drucken konnte. Das dauerte zwar relativ lange aber letztendlich kam ein perfektes X3 raus. Kann es sein, daß die erzeugte PS-Datei aus 7 um ein vielfaches größer ist, als die gleiche Datei von 6.5 losgesendet? Leider kann man das ja nicht mehr gegenchecken, da 6.5 ja intelligenterweise deaktiviert wurde. Oder soll ich sagen "beschädigt" wurde? (Sie merken, daß ich nach dem heutigen Tag ziemlich angefressen bin)

Per PDF-Export waren die gleichen Probleme wie letzte Woche: X3-Prüfung ist anhand des Fontproblems in Fehler gelaufen und trotzdem wurde ein PDF erzeugt - mit drei nicht eingebetteten Fonts ITCEras.

Zur Ansicht mal die Meldungen als Anhang. Ich kann Quark nur dringend raten, die X3-Konventionen einzuhalten und XPress so zu programmieren, daß sich das Programm so verhält, wie es der (erfahrene) Anwender erwartet. So ist das echter Bockmist. Die Meldungen sollten auch vernünftig übersetzt werden, so daß sie Sinn machen. Zu dem kommt es vor, daß einige Meldungen auf englisch sind - macht natürlich auch Sinn in einer deutschen Passport-Version...

Gruß

Hallo,


A
Zur Logik der Verdrahtung der PDFX-Überprüfung von XPress 7

Du möchtest ein PDF der Version 1.4? Du wählst nicht PDF/X

Du möchtest ein PDF der Version 1.3? Du wählst PDF/X

Die Validierung wird bestanden oder nicht bestanden und mit Meldung quittiert. Deine PDF bekommst Du. (Bei Acrobat hast Du die Wahl, ob bei nicht bestandener X-Prüfung die PDF-Datei erzeugt wird oder nicht. Diese Wahl hast Du bei XPress nicht – XPress erzeugt sie).



B
Das Thema der Schriftmeldung scheint wegen der Weigerung des Kunden für andere momentan nicht nachvollziehbar zu sein? Oder kann der Weg zur Fehlermeldung so bsechrieben werden – ohne die Kundendaten –, dass der Fehler doch nachvollziehbar wird?

Antwort auf [ rohrfrei ]

nach Rücksprache mit dem Kunden, kann ich Ihnen die fraglichen Dateien leider nicht zum Test überlassen.

Schade, denn
- Ich habe das jetzt mal bei mir kurz nachgestellt: Illu CS2 EPS mit meiner ITC Eras in allen vorhanden Schnitten in QXP 7.0 platziert und ausgegeben. Ebenfalls mit Passkreuzen und QXP-Seiteninfos. Alles kommt einwandfrei heraus, also Schriften eingebunden, und zwar in allen durchgespielten Ausgabe-Konstellationen. So einfach lässt sich die Sache (zum Glück) nicht nachstellen, das wäre ja doch ein kapitaler Bock!

- Die Level 3 Warnung habe ich bei mir jetzt gerade auch nicht, evtl. sind in Ihrem EPSen noch andere komplexe Elemente. Ich denke, die Warnung können Sie übergehen, solange es später keine Probleme gibt. (Okay, ist jetzt zwar der Fall, aber trotzdem...)

- Konnten Sie wenigstens eine Miniaturseitenverschiebung testen? Die Probleme erscheinen mir doch recht seltsam, evlt. hat das File irgendein Problem. Kommt es denn aus QXP 6?
- Könnte es sein, dass beim PDF-Export das Font-Downloading für diese Schriften, oder global für alle, deaktiviert ist?
Leider hat QuarkXPress in dieser Sektion keinen Mechanismus (wie etwa bei den Hyperlinks) der den kompletten Reiter gemäß PDF/X-Spezifikation ausrauht wenn die X-Verifzierung aktivert wird.

Antwort auf:

Kann es sein, daß die erzeugte PS-Datei aus 7 um ein vielfaches größer ist, als die gleiche Datei von 6.5 losgesendet?

Das ist gut möglich, da der PS-Code von QXP 7 meinens Wissens tlw. komplexer ist als der von QXP 6.x. Getestet habe ich diesen Faktor aber noch nicht.

Antwort auf:

Ich kann Quark nur dringend raten, die X3-Konventionen einzuhalten und XPress so zu programmieren, daß sich das Programm so verhält, wie es der (erfahrene) Anwender erwartet. So ist das echter Bockmist.

Da muss ich jetzt ein wenig wiedersprechen. Ich denke es geht um das Erzeugen einer PDF-Datei obwohl die PDF/X-Evaluierung scheitert? Hier sollte wohl besser KEINE PDF-Datei erstellt werden, oder?
Erst mal würde mich interessieren, an welcher PDF/-X Konvention sich letzeres Verhalten orientieren sollte und warum das von QXP 7 dem jetzt wiedersprechen würde. Ich bin mir jetzt nicht ganz sicher, aber ist dieser Passus Bestandteil der Norm, oder von irgendwelchen Implementierungsrichtlinien?
Auch Acrobat 7 bietet ja die Möglichkeit, trotz gescheitertem PDF/X Status ein PDF zu erzeugen. Das kann ja auch sehr sinnvoll sein, bei weitergehenden Fehleranalysen. Nicht immer reicht dazu ja das Logfile aus. Gut, evlt. wäre es für QXP 7 nett, wenn diese Wahlmöglichkeit ähnlich dem Distiler auch vorhanden wäre. Aber grundsätzlich "falsch" finde ich das jetzige Verhalten nicht, im Gegenteil.
Evtl könnte Quark aber kurzfristig die Warnmeldung umformulieren, dass es etwas deutlicher wird, etwa: "Achtung: Die PDF/X Evaluierung ist gescheitert. Detaills im Logfile. Zur genaueren Fehleranalyse wurde eine PDF-Datei erstellt, die jedoch nicht den gewünschten Standards entspricht" Oder so.

Antwort auf:

Die Meldungen sollten auch vernünftig übersetzt werden, so daß sie Sinn machen. Zu dem kommt es vor, daß einige Meldungen auf englisch sind - macht natürlich auch Sinn in einer deutschen Passport-Version...

Da geben ich Ihnen recht. Die Logfiles sind sehr kryptisch und tlw. schlicht unverständlich.

Was mir dagegen nicht gefällt, wenn die PDF/X Evaluierung scheitert: Das resultierende PDF hat ALLE PDF/X-Flags AUSSER dem Output Intent. Das finde ICH gefährlich. Indien sagt, es hat etwas mit der Art zu tun wie und wann diese Flags zwischen QXP und Callas getauscht und gesetzt werden. Der OI wird scheinbar von Callas gesetzt und das erst ganz zum Schluss. Der Rest kommt schon vorher durch QXP und ist daher immer drinn. Trotzdem finde ich dieses Verhalten nicht besonders gut und sicher für einige sehr verwirrend.

Wenn eine MSV oder andere Routinen das Problem nicht lösen, läst sich die Sache dann etwas eingrenzen? Lässt sich eine Abfolge herausarbeiten, wie es sich unabhängig von diesem speziellen Dokument und EPS reproduzieren lässt?

Georg Obermayr

Guten Abend,

Zitat

Ich habe das jetzt mal bei mir kurz nachgestellt: Illu CS2 EPS mit meiner ITC Eras in allen vorhanden Schnitten in QXP 7.0 platziert und ausgegeben.

Das entspricht nicht ganz dem hier vorliegenden Fall. Ich habe herausgefunden, daß das EPS wie folgt entstanden ist:
QXP-Layout in 6.5 Mac -> per Adobe-PDF zu PDF/X-3 "gedruckt" -> per Acrobat 7 als EPS PS3 inkl. aller Fonts gesichert. Das kann man ja durchaus so machen anstatt das Layout direkt als EPS zu sichern. So hat das PDF/X-3 aus dem das EPS hervorgegangen ist zumindest schonmal mind. einen Preflight hinter sich - das kann ja nicht schaden.

Zitat

Ich denke, die Warnung können Sie übergehen, solange es später keine Probleme gibt.

Das denke ich auch, da ja wieder auf den Adobe-PDF gedruckt wird, der ja problemlos PS3 kann. Ich störe mich halt nur an der total unglücklichen und unfähigen Übersetzung. Das ist ja offensichtlich, daß das einfach wort-wörtlich aus dem englischen übersetzt wurde ohne das da ein fachkundiger die fach-englischen Termini korrekt in's deutsche übertragen hat.

Zitat

- Konnten Sie wenigstens eine Miniaturseitenverschiebung testen? Die Probleme erscheinen mir doch recht seltsam, evlt. hat das File irgendein Problem. Kommt es denn aus QXP 6?

ja, es kommt aus 6. MSV hatte ich noch keine Zeit zu. Wenn das File ein Problem hätte, würde sich dann ein solches nur auf den PDF-Export und das Fonthandling auswirken? Und beim EPS-Export und beim Distiller wäre alles ok? Kann sein, klingt aber irgendwie unlogisch.

Zitat

- Könnte es sein, dass beim PDF-Export das Font-Downloading für diese Schriften, oder global für alle, deaktiviert ist?

nein, absolut ausgeschlossen, alles korrekt und mehrfach gegengecheckt

Zitat

Da muss ich jetzt ein wenig wiedersprechen. Ich denke es geht um das Erzeugen einer PDF-Datei obwohl die PDF/X-Evaluierung scheitert? Hier sollte wohl besser KEINE PDF-Datei erstellt werden, oder?

genau, wenn ich PDF/X-Prüfung wähle, sollte auch nur PDF/X erstellt werden. Wenn kein PDF/X möglich ist aus dateitechnischen Problemen, dann sollte idealerweise gar kein PDF erstellt werden

Zitat

Erst mal würde mich interessieren, an welcher PDF/-X Konvention sich letzeres Verhalten orientieren sollte und warum das von QXP 7 dem jetzt wiedersprechen würde. Ich bin mir jetzt nicht ganz sicher, aber ist dieser Passus Bestandteil der Norm, oder von irgendwelchen Implementierungsrichtlinien?

Ein Widerspruch zur Norm liegt sicherlich nicht vor, da haben Sie und Herr Hagemann recht und das muß ich in der Aussage korrigieren. Ich ging vielmehr von der - wahrscheinlich - verbreiteten Erwartungshaltung aus, daß eine Nicht-Erfüllung der X3-Norm zu einem Abbruch führt, so wie die meisten InDesigns und Distillers eingerichtet sein dürften. Es wäre in meinen Augen sinnvoll, wenn sich XPress dem weit verbreitetem Verhalten anpassen würde. Wobei die entsprechende Wahlmöglichkeit natürlich noch besser wäre.

Zitat

Evtl könnte Quark aber kurzfristig die Warnmeldung umformulieren, dass es etwas deutlicher wird

Wobei ich das eigentlich recht eindeutig finde. Kurz und knackig und im Prinzip selbsterklärend. Es war zuvor das Verhalten an sich, welches ich unglücklich fand und nicht die Fehlermeldung. Aber das Verhalten haben wir ja offensichtlich geklärt mit dem Wunsch, nach einer Einflußnahme, wie er sich verhalten soll.

Zitat

Was mir dagegen nicht gefällt, wenn die PDF/X Evaluierung scheitert: Das resultierende PDF hat ALLE PDF/X-Flags AUSSER dem Output Intent. Das finde ICH gefährlich.

Stimmt. Zuerst habe ich das Acrobat-Preflight-Ergebnis auch nicht kapiert. Bis ich dahinter gekommen bin, was da anders ist, als bei einer "normalen" Nicht-PDF-X-Datei. Wäre sicherlich gut, wenn sich XPress auch hier den weitverbreitetem Verhalten anpassen könnte.

Ich werde am Problem noch dranbleiben. Immer wenn mal ein wenig Zeit zwischendurch ist. Wenn es neue Erkenntnisse gibt oder ich es an einen anderen Dokument reproduzieren kann, melde ich mich nochmal.

Gruß