Hallole

Seite heute ist der Quark eigene CUPS-Filter als Download verfügbar.
http://downloads.quark.com/...?fid=117&lang=de
Wie die Lösung jetzt genau aussieht, kann ich nicht sagen - also Rückmeldungen erwünscht.

Hallole Zusammen

Komisch keine Rückmeldungen, hat jetzt der Fix funktioniert oder nicht ?

Ich würde gerne unsere Bug-/Wunschliste in diesem Punkt überarbeiten.

Den Bug noch nicht streichen.
Verwende einen Canon i560 mit Printfab 2.08 unter QXP 6.52. - einwandfrei -
Unter QXP 7.X will das überhaupt nicht funktionieren.

gruß suppel

Antwort auf [ suppel ]

Den Bug noch nicht streichen.
Verwende einen Canon i560 mit Printfab 2.08 unter QXP 6.52. - einwandfrei -
Unter QXP 7.X will das überhaupt nicht funktionieren.

gruß suppel

das war aber hier nicht die frage :)
es geht um das lokale drucken mit dem adobepdf-printer ...

Bernd, was erwartest du? :-D
OK, hier auf meinem kleinen Test-Mac funktioniert's.
Falls du eine La-Ola wünschst - die gab's schon bei Thomas K.

Gruß
Bernhard

Hallo Bernhard

Das mit Thomas seinem Fix ist mir klar, aber ich wollte wissen ob der Fix von Quark das Problem auch beseitigt. Welcher Weg der bessere ist kann ich nicht beurteilen, das will ich auch gar nicht.

Mein Anliegen ist nur, können wir diesen Punkt in der Bugliste streichen ja oder nein.

Hallo,

das was Quark da liefert funktioniert.
Es ist eine sehr triviale Lösung in der Form, dass mit Hilfe einer eigenen CUPS Filter Funktion von der von QuarkXPress 7 standardmässig genutzten 6-Parameter Schnittstelle, die die zu druckenden Daten per Temp-Datei übergibt, auf die 5-Parameter Schnittstelle konvertiert wird, bei der die zu druckenden Daten per stdin übergeben werden.

Die Lösung ist aber keinesfalls mit der von Herrn Kaiser gelieferten Lösung vergelicgbar, weil sich diese auch diverser anderer potentieller Probleme annimmt.

Hi Bernd,

auch ich habe ein paar Versuche gemacht und nichts konkretes gefunden warum man den Filter nicht benutzen sollte. Ansonsten schließe ich mich Roberts Meinung an.
Ich hoffe das ist das was Du meintest.

Hallo Conny

Ja, ich wollte nur wissen ob der Fix funktioniert.

Hi Bernd,

Antwort auf [ Drienko ]

Ja, ich wollte nur wissen ob der Fix funktioniert.

Er funktioniert in sehr limitierter Weise... und mit relativ hoher Wahrscheinlichkeit auch nur, bis man das nächste System-Update einspielt. Quark hat sich "intelligenterweise" dafür entschieden, in CUPS' eigenen Steuer-Dateien herumzufummeln, konkret:

Code

/etc/cups/mime.types 
/etc/cups/mime.convs 

anstatt den für Drittanbieter vorgegebenen Weg zu nutzen und eigene Dateien beizusteuern, bspw.

Code

/etc/cups/quark.types 
/etc/cups/quark.convs 

Naja, Mac-Support bei Quark scheint keinen besonders hohen Stellenwert zu haben. Jedenfalls habe ich eine Vorabversion des CUPS-Filters (die auf den ersten Blick identisch zu sein scheint mit dem, was Quark da jetzt als "finale Lösung" ausliefert) am 28. 6. 2007, also vor mehr als einem schlappen Vierteljahr, wie folgt Richtung Quark-Entwicklung kommentiert:

Zitat

Just a short list what's wrong with Quark's "Distiller Fix":

* You alter the contents of both /etc/cups/mime.types and
  /etc/cups/mime.convs which is not the best idea since these files might be
  overwritten by Apple's software update mechanism and the like.

  Why not use quark.convs and quark.types instead?

* You use a newly created MIME type "application/quark-ps" which is a
  violation of several Internet RFCs unless this MIME type is registered
  with IANA. If in doubt consult http://www.iana.org/assignments/media-types
  or Hannes Scheidler at hscheidler (at) quark.com

  Why not use application/vnd.quark-postscript instead?

* Your CUPS filter simply sends the temporary file to stdout leading to
  Adobe's distiller backend creating a new temporary file. So Xpress creates
  the first temporary file, your filter pick's this file up and sends it to
  stdout and a second temporary file will be created?

  Why not simply move the temporary file to a sane location using mktemp?

* Your "Fix" is only able to work correctly with Xpress 7.3 or above since
  it needs an application spooling the postscript data with a MIME type that
  differs from "application/vnd.cups-postscript"

  Why not providing your customers with a solution that works for older 7.x
  releases as well?

Or in other words: Why not solving the problem finally with 7.3 instead of supplying an ugly "fix" with a non functional CUPS filter approach? Why not simply spool with MIME type "application/vnd.quark-postscript" and adding one simple rule to CUPS' filter chain (using /etc/cups/quark.convs) that prevents Xpress' PostScript data from being manipulated by Apples pstops filter?

    application/vnd.quark-postscript application/vnd.cups-postscript 0 -

The latter approach is all you need. So why still create a temporary PostScript file and care about permissions? Simple do it _right_ and you're done. And provide your pre 7.3 customers with a _sane_ CUPS filter solution and not stuff like that in your installer...

Eigentlich könnte man ja nur noch über Quark lachen, wenn es nicht ein so entsetzliches Trauerspiel wäre und das Ganze, da es ja eh nur ab 7.3 "gefixt" werden soll, so simpel an Quarks Stelle zu lösen wäre -- siehe Anleitung oben. Man kommt sich halt irgendwie verarscht vor, wenn man es den Leuten in Denver auch noch detailliert aufs Brot schmiert und sie trotzdem nur Ignoranz üben und häßliche Workarounds veröffentlichen.

Gruss,

Thomas

Hallo Thomas

Wie ich heute im Quark-forum gelesen habe, funktioniert der Installer des Quark Cups-Fix nicht unter 10.5.
http://www.quark.com/...iewtopic.php?t=21127

Hallo Bernd,

Antwort auf [ Drienko ]

Wie ich heute im Quark-forum gelesen habe, funktioniert der Installer des Quark Cups-Fix nicht unter 10.5.
http://www.quark.com/...iewtopic.php?t=21127

Hmm... geht's da nicht um den Quark-eigenen Fix?

Was man allerdings so hört, scheint es generelle Probleme mit den AdobePDF-Backends unter 10.5 zu geben. Sollte da was dran sein, ist die Wahrscheinlichkeit groß, daß auch mein Quark-Fix nicht mehr funktioniert. Vielleicht kann dazu hier irgendein Xpress-Anwender, der schon auf Leo setzt, Feedback geben.

Hab aber eigentlich grad Wichtigeres zu tun, als Probleme der Kombination eines Betriebsystems auf einem Versionsstand, der es als reines Testsystem qualifiziert (vor 10.5.3/10.5.4 empfehle ich Leo keinem) und eines Layout-Programms, das weder ich noch das Gros meiner Kunden verwenden, zu lösen

Gruss,

Thomas

Hallo Thomas

Klar um den Fix von Quark, ich wollte das auch nur als Info an dich und deiner Arbeit sehen (und wiederrum eine kleine Bestätigung, das die QuarkMACProgrammierer noch einiges zu lernen haben.).

hallo bernd

Antwort auf [ Drienko ]

(und wiederrum eine kleine Bestätigung, das die QuarkMACProgrammierer noch einiges zu lernen haben.).

mit os X 10.5 haben nicht nur die programmierer von quark noch was zu lernen, sondern die meisten. und dies nicht, weil sie unfähig wären, sondern, weil apple am betriebssystem so einiges verändert hat (vgl. z.b. acrobat 8, dessen 10.5-kompatibilitätsupdate voraussichtlich im januar erscheinen wird). so zur info für einen nicht-mac-anwender ;-)

Hallo gremlin

Stimmt, ich habe mir die Meldung von Quark noch einmal durchgelesen.
Allerdings habe ich erwartet, das Quark nicht nur QXP7 10.5 reif macht, sondern natürlich auch seinen CUPS-Fix, bzw. diesen in QXP7 integriert.

Grüzi zusammen,

bin neu hier im Forum, und ich hoffe ich mach mich hier nicht gleich unbeliebt ;-) weil ich den Thread hier weitermach.
Hab zwar schon seit Stunden rumgesucht, aber ich werde nicht schlauer. ***grrr***

System (jetzt):
MAC G5
OS 10.5.1
Quark 7.32
Acrobat 8.1.1

Habe heute den Acrobat und das OS upgedated.
Dummerweise nicht vorher in Foren rumgestöbert.
Naja, später ist man immer schlauer, dann hätte ich das mal lieber gelassen.

Also bei mir funzt das mit dem PDF schreiben auch nicht wirklich. Hab´s auch schon mit einem Kopfstand versucht, bringt aber auch nix. Über die Export Funktion aus Quark kommen nur A4 Seiten raus, der Rest wird abgeschnitten.
Über den Drucken Dialog geht´s bekanntlich auch net. Da geht der "Drucker" dann immer in Wartestellung.

Die Quark CUPS Filter lassen sich unter 10.5 nicht updaten :-(

Bis heute morgen hat auch noch das mit der Zeile im Terminal funktioniert...

Zitat

sudo chmod 711/Privat/var/spool/cups

Aber der Trick funzt auch nicht mehr.

Und jetzt weis ich nimme weiter.

Hat da vielleicht jemand einen Rat,
oder gibt es vielleicht eine Möglichkeit da wieder ein PDF rauszubekommen, mit dem man auch was anfangen kann ???

Danke im vorraus !!!

Gruß Toni

Antwort auf [ Mr.T ]

System (jetzt):
MAC G5
OS 10.5.1
Quark 7.32
Acrobat 8.1.1

XPress 7.31 ??

Antwort auf [ Mr.T ]

Habe heute den Acrobat und das OS upgedated.

Das machen nur "Masochisten" :-) , schon so früh auf ein neues Betriebssystem mit nur einer "1" hinterm Punkt. Es ist auch noch keine zum Leopard kompatible Version von Acrobat auf dem Markt.

Antwort auf [ Mr.T ]

Über die Export-Funktion aus Quark kommen nur A4-Seiten raus, der Rest wird abgeschnitten.

Das höre ich zum ersten Mal. Bitte die Dokumentation zu XPress bei PDFX-ready (direkter Link http://www.pdfx-ready.ch/files/Rezept_QuarkXPress7_d.pdf) durchlesen. Da muss ein Bedienerfehler vorliegen. Beim PDF-Export sollte unter 10.5.1 jedoch "direkt" exportiert werden und nicht in eine PS-Datei.

Sorry, XPress 7.31 natürlich !
Gibt es sowas wie einen Rückwärtsgang ;-) ?
Ich meine, komm ich irgendwie zurück auf mein altes OS ??

Hallole Zusammen

Quark hat den aktualisierten CUPS Filter online gestellt,
der alte Link führt zum neuen Filter, trotzdem hier noch einmal der Link.

http://euro.quark.com/.../details.jsp?idx=714

Hier die Beschreibung des CUPS Filters.
+++++
The Quark® CUPS Filter fixes a problem that prevented users from creating a PDF by printing to the Adobe® PDF Printer as well as printing to some PostScript printers from QuarkXPress on Mac® OS. Version 1.01 adds support for Mac OS X 10.5.2 and Adobe Acrobat 8.1.2. If you have already installed version 1.0 on Mac OS X 10.4, there is no need for you to download and install this update.
+++++

Update

Traurig aber wahr: für QXP 8.01 und Acrobat 9 unter 10.5.6 wird dieser Filter immer noch benötigt. Ebenfalls wird weiterhin die TrimBox (Endformat-Rahmen) nicht korrekt gesetzt, weshalb die MediaBoXT von JoLauterbach benötigt wird ...

Gruß
Bernhard

Hallo,

Zitat

Ebenfalls wird weiterhin die TrimBox (Endformat-Rahmen) nicht korrekt gesetzt, weshalb die MediaBoXT von JoLauterbach benötigt wird ...

Das ist auch unser Problem. Für Quark XPress 7 und Distiller 7 hatten wir die Creo-Distiller-Assistant und Impressed Printers-Marks-Patch installiert. Das funktionierte mit der Trimbox problemlos. Nachdem wir nun diese Woche auf XPress 8 und Distiller 9 upgedated haben fehlt die Trimbox wieder. Am neuen Distiller 9 liegt es nicht, da ein PostScript aus XPress 7 hier korrekt funktioniert.

Aber wenn wir aus XPress 8 drucken, dann kommt die Trimbox nicht korrekt im PDF an. Die Creo-Distiller-Assistant und Impressed Printers-Marks-Patch sind ebenfalls installiert, aber das scheint nicht mehr zu funktionieren. Gibt es hier eine Lösung ohne die XTension?

Unser erster PDF-Export aus XPress 8 hat auch nicht das gewünschte Ergebnis erbracht, da der Acrobat-Preflight ein Glyphen-Problem gemeldet hat. Per Export ist zwar die Trimbox korrekt definiert, aber das PDF/X-3 ist in Acrobat 9 nicht gültig.

Ein befreundeter Vorstufen-Profi hat recherchiert, dass das Glyphen-Problem eventuell mit einer von uns benutzten Helvetica in Verbindung steht, auf die wir aber nicht verzichten können, da sie osteuropäische Zeichen enthält. Er vermutet, dass es zum Konflikt mit der Seitenbeschreibung von XPress 8 kommt, da die ja nun ebenfalls in Helvetica statt wie zuvor in Courier ist.

Wir müssen also weiterhin über den Distiller unsere PDFs erstellen. Das scheitert aber an der nicht korrekten Trimbox. Beim Start des Distillers steht bei dem Impressed Printers-Marks-Patch auch nur bis XPress-Version 7. Gibt es da ein Update für XPress 8, der das wieder fixt?

Hallo Farbenhuhn

Der Cups-Fix sollte auch bei einer QXP8 Installation verwendet werden.

Die Trimbox kommt nur beim PDF-/PS-Export mit, das ist auch der beste Weg und aus meiner Sicht korrekte PS-Datei zu erstellen.

Eine gute XT für die Boxen ist die Mediabox von Jo Lauterbach.
http://www.jolauterbach.de/...roducts/mediabox.htm

@..herchiert, dass das Glyphen-Problem...
Von diesem Problem habe ich schon gehört.
Die Prüfprotokolle PDF/X-3 von Acrobat 9 sind wohl etwas scharf definiert,
diese mag die Helevtica nicht unbedingt.
Stelle einmal in den "Vorgaben/Fallback-Schrift/Schrift der Infozeile " hier eine andere Schrift ein, z.b. Courier.
Läuft jetzt, die Prüfung durch ?

Aktuell ist übrigens die Verison 8.02, nur noch zur Info.

Hallo,

Zitat

Der Cups-Fix sollte auch bei einer QXP8 Installation verwendet werden.

Wir arbeiten noch unter Mac-OS 10.4.11 auf Intel-iMacs. Jetzt mit Acrobat 9 aus der CS4. Diese Systemumgebung ist auf der Quark-Homepage unter dem angegebenen Link nicht erwähnt. Kann oder sollen wir es trotzdem installieren?
Für Acrobat 8 und den dazugehörigen Adobe-PDF-Drucker hatten wir die Erweiterung von Thomas Kaiser hier aus dem Forum installiert.

Damit waren wir auch glücklich endlich wieder direkt per Adobe-PDF-Drucker unsere PDFs erstellen zu können. Ohne Umweg über den Distiller-Hotfolder oder den PS-Export aus XPress 7.

Zitat

Die Trimbox kommt nur beim PDF-/PS-Export mit, das ist auch der beste Weg und aus meiner Sicht korrekte PS-Datei zu erstellen.

Das Update haben wir u.a. gerade deshalb gekauft. Eigentlich hätten wir auch noch bei XPress 7 bleiben können, aber zusammen mit der CS4 erschien es uns konsequent auch auf XPress 8 upzudaten, um aktuell zu sein. Im Vorfeld haben wir hier im Forum ja auch gelesen, dass man durchaus den XPress-Export nutzen kann.

Schade, dass das nun so überhaupt nicht funktioniert. Jetzt haben wir einige Lizenzen bezahlt und wir können keine korrekten PDFs mehr erzeugen. Per Drucken fehlt die Trimbox und per Export kommt der Fehler im Acrobat Preflight. Beides war mit XPress 7 kein Problem. Also viel Geld für nichts ausgegeben wie es scheint. Mein Chef wird verrückt werden, wenn er davon erfährt. Wie soll ich ihm das erklären? Wird das bei Quark eigentlich nicht vorher getestet? InDesign CS4 konnten wir dazu im Vergleich völlig problemlos einrichten.

Zitat

Stelle einmal in den "Vorgaben/Fallback-Schrift/Schrift der Infozeile " hier eine andere Schrift ein, z.b. Courier.
Läuft jetzt, die Prüfung durch ?

Danke der Tip ist gut. Aber wenn ich das wieder auf Courier umstelle und nur ein Bild auf einer Seite platziere, dann werden die Glyphen in der Courier trotzdem als Fehler gemeldet bei einem exportierten PDF. Auch wenn sonst gar kein anderer Text auf der Seite im PDF enthalten ist. Die Diskussionen dazu im PDF-Board erklären, dass es sich in so einem Fall um einen Fehler des Erstellungsprogramm handeln soll.

Hallo liebe Forengemeinde,
Die Frage vom Farbenhuhn ist noch nicht beantwortet. Gibt es, oder wird es ein Distiller-Patch-Update geben, das die TrimBox beim Drucken wieder richtig setzt?

Dann könnte man sich das lästige manuelle Setzen der TrimBox in Acrobat sparen.

Grüße an alle eifrigen Forenschreiber
Lars

Was spricht _für_ die Verwendung des 9er Acrobats?

Hallo Farbenhuhn,

wie sieht es denn aus, wenn Du aus Quark 8 über den PDF-Export ein PostScript exportierst (Voreinstellugnen) und dieses über den Distiller in PDF umwandelst? Erhältst Du dann eine TrimBox?

Hallo:

1.
XPress selbst schreibt nur eine Trim- und eine Bleedbox ins Postscript, wenn man über den PDF-Export geht (egal, ob man als PDF oder PS exportiert).

2.
XPress selbst schreibt niemals Trim- und Bleedbox in den Datenstrom, wenn man druckt oder EPS exportiert.

2a.
Im Druck kann man die günstige MediaBoxXT von JoLauterbach einsetzen, damit doch Mediabox und Trimbox gesetzt werden.

2b.
Wenn man mit Beschnittmarken druckt, kann theoretisch der Distiller aus den Schnittmarken Trimbox und Bleedbox ableiten, dazu muss er aber mit Distiller-Startup-Dateien von Impressed erweitert worden sein.

2c.
Kann man im PDF die Trimbox händisch setzen.

3.
Ist der Preflight von Acrobat 9 keinesfalls optimal (Notiz von Thomas Richard und Bernd Drienko)


Zusammengefasst und einfachste Lösung:
Drucken mit der MediaBoxXT von JoLauterbach - oder PDF-Export als PS-Datei.
Preflighten des PDFs mit Acrobat 8.

Hallo,

Zitat

XPress selbst schreibt nur eine Trim- und eine Bleedbox ins Postscript, wenn man über den PDF-Export geht (egal, ob man als PDF oder PS exportiert).

traurig genug. Gibt es dafür eine logische Erklärung oder ist es nur Schlamperei? Ich tituliere das mal als Bug - und der besteht ja schon seit der Vorversion. Warum wird so etwas Elementares nicht gefixt?

Zitat

Im Druck kann man die günstige MediaBoxXT von JoLauterbach einsetzen, damit doch Mediabox und Trimbox gesetzt werden.

was zusätzliche Kosten erzeugt für eine absolut selbstverständliche Funktion, die direkt in das Programm integriert gehört

Zitat

Wenn man mit Beschnittmarken druckt, kann theoretisch der Distiller aus den Schnittmarken Trimbox und Bleedbox ableiten, dazu muss er aber mit Distiller-Startup-Dateien von Impressed erweitert worden sein.

habe ich bisher auch bevorzugt, aber laut Impressed, Herr Zacherl, wird Printers-Marks-Patch nicht für XPress 8 aktualisiert werden. Wobei auch noch nicht geklärt ist, ob es überhaupt mit 8 funktionieren würde.

Zitat

Kann man im PDF die Trimbox händisch setzen.

Großartige Idee. Damit wäre man dann wieder auf dem Stand von Freehand vor einigen Jahren. Ich dachte, dass wir das endlich hinter uns gelassen hätten.
Welches Werkzeug soll der normale Anwender zur Definition der Trimbox denn nutzen? In den Druckereien stehen ja diverse Acorbat-Plugins der Workflow-Hersteller hierfür zur Verfügung, aber die hat ja der normale XPress-Anwender nicht.

Zitat

Ist der Preflight von Acrobat 9 keinesfalls optimal (Notiz von Thomas Richard und Bernd Drienko)

das sehe ich genau andersherum. Wenn ich die Aussagen von Herrn Drümmer lese, dann sind die verschärften Preflihgt-Regeln wichtig, um evtl. Fehlbelichtungen zu vermeiden. Es wäre also fahrlässig den Acrobat 9 nicht zum Preflight einzusetzen.

Zitat von Polylux

wie sieht es denn aus, wenn Du aus Quark 8 über den PDF-Export ein PostScript exportierst (Voreinstellugnen) und dieses über den Distiller in PDF umwandelst? Erhältst Du dann eine TrimBox?

meine Erfahrung zeigt, daß dann die Trimbox korrekt definiert ist. Das setzt dann aber einen Distiller-Hotfolder voraus. Ist ein legitimer Workaround. Aber ist das wirklich notwendig? Warum nicht einfach per Adobe-PDF drucken? Ist das für die Firma Quark ein so exotischer Weg der PDF-Erstellung, daß man den nicht korrekt supporten kann?

Zitat von Thomas Richard

Was spricht _für_ die Verwendung des 9er Acrobats?

Ich würde sagen, um einiges mehr, als für die Verwendung von XPress 8 !
(im Vergleich zur jeweiligen Vorversion wenn man den Funktionsumfang betrachtet)

Gruß

Antwort auf [ rohrfrei ]

Hallo,

Zitat

XPress selbst schreibt nur eine Trim- und eine Bleedbox ins Postscript, wenn man über den PDF-Export geht (egal, ob man als PDF oder PS exportiert).

traurig genug. Gibt es dafür eine logische Erklärung oder ist es nur Schlamperei? Ich tituliere das mal als Bug - und der besteht ja schon seit der Vorversion. Warum wird so etwas Elementares nicht gefixt?

Das besteht nicht seit der Vorversion. Das war schon immer so. Das ist kein Bug – und das scheint für Quark keinerlei Priorität zu haben, denn aus Quarks Sicht besteht ja der Weg über den PDF-Export.
Das einzige, was sich gegenüber uralten Zeiten geändert hat, ist, dass der Distiller auf Hilfsmittel angewiesen ist (für 6 und 7 (25 Euro) – für 8 gibt es also keine Möglichkeit von Robert Zacherl) um aus den Beschnittmarken die Trim- und Bleedboxen ableiten zu können.

Antwort auf [ rohrfrei ]

was zusätzliche Kosten erzeugt für eine absolut selbstverständliche Funktion, die direkt in das Programm integriert gehört

Zitat

Wenn man mit Beschnittmarken druckt, kann theoretisch der Distiller aus den Schnittmarken Trimbox und Bleedbox ableiten, dazu muss er aber mit Distiller-Startup-Dateien von Impressed erweitert worden sein.

habe ich bisher auch bevorzugt, aber laut Impressed, Herr Zacherl, wird Printers-Marks-Patch nicht für XPress 8 aktualisiert werden.

Das bedeutet ja, dass die Leute immer noch composite-PDFs mit Schnittzeichen erzeugen müssten, obwohl die bei korrekt gesetzter Trim- und Bleedbox überflüssig und beim Ausschießen hinderlich sind.

Zur Verhältnismäßigkeit: Die MediaBoxXT kostet als einzelne Lizenz 39.- Euro plus Steuer. Sie hängt sich in den Druckstil. Die Eingabe von Papierformat wird damit überflüssig.
Wenn ich diesen Zeit- und Sicherheitsgewinn mit einrechne, ist jede Diskussionszeit über die Kosten dieser XTension schon teurer als die XTension selbst.
Dass XPress auch beim Drucken Trim- und Bleedbox hineinschreiben könnte, bleibt bei diesen Argumenten unbenommen.

Hallo rohrfrei

Warum hat der Weg "Drucken in eine Datei über Adobe PDF" zur Erzeugung einer PS-Datei, immer noch Vorrang vor dem PDF-/PS-Export von QXP ?

Hallo Bernd,

auch wenn es andere Möglichkeiten gibt die TrimBox zu erreichen, so hat rohrfrei doch Recht, dass es für eine professionelle Layoutsoftware dazu gehört, mit den Adobe Acrobat problemlos zusammenzuarbeiten.
Und dazu gehört nun mal eine TrimBox!

Hallo,

Zitat

Das besteht nicht seit der Vorversion. Das war schon immer so.

Tatsächlich? Als Anlage mal zwei PS aus Uralt-Zeiten. Bitte mal in einen nackten Distiller 9 ohne Startups werfen und die Trimbox checken. Ich denke, das ist alles ok. Also muß sich die Firma Quark von mir die Frage gefallen lassen, warum etwas in XPress 6,7,8 nicht funzt, was früher ok war. Ist die Frage so widersinnig?

Zitat

Das bedeutet ja, dass die Leute immer noch composite-PDFs mit Schnittzeichen erzeugen müssten, obwohl die bei korrekt gesetzter Trim- und Bleedbox überflüssig und beim Ausschießen hinderlich sind.

Die Aussage verstehe ich nicht! Auch nicht im Ansatz der Sinn, der da evtl. dahinter stecken könnte. Ich möchte als Datenverarbeiter eigentlich keine PDFs ohne Schneidezeichen bekommen. Auch wenn die in der Bogenmontage montiert werden, sind sie doch eine gute Orientierungshilfe bei angelieferten Daten. Aber evtl. ist man hier in der Schweiz schon fortschrittlicher... oder man verwechselt das mit den Paßkreuzen, da würde ich natürlich zustimmen.

Zitat

Wenn ich diesen Zeit- und Sicherheitsgewinn mit einrechne, ist jede Diskussionszeit über die Kosten dieser XTension schon teurer als die XTension selbst.

Verstehe ich auch nicht. Wozu gibt es die Druckstile?
Nur mal so nebenbei. Ich hatte bereits ---EDIT: 2003 und 2006 EDIT-ENDE---- 2006 eine 5er-Lizenz der MediaboxXT. Ich kenne es also sehr gut. Nur ich sehe nicht ein, bei jedem Quarkupdate noch zusätzliche Drittkomponenten ebenfalls kostenpflichtig mit upzudaten für Sachen - wo ich sage - es ist selbstverständlich. Nur weil Quark sein eigenes Süppchen kocht.
Und so elegant wie der InDeisgn-PDF-Export wird es sowieso nicht. Denn DA muß ich mich um rein gar nichts kümmern mit einer entsprechenden PDF-Exportvorgabe. DA muß ich noch nicht einmal das Seitenformat eingeben, das geht alles automatisch - von Hause aus.

Gruß

Hallo Bernd,

Zitat

Warum hat der Weg "Drucken in eine Datei über Adobe PDF" zur Erzeugung einer PS-Datei, immer noch Vorrang vor dem PDF-/PS-Export von QXP ?

Habe ich doch gar nicht gesagt. Ich habe nur gesagt, daß die Erstellung per Adobe-PDF nicht exotisch ist. Das wirst du wohl kaum absprechen können.

Und es ist doch wohl tagtägliche Praxis das ich aus allen Feld-Wald-und-Wiesenprogrammen von Mac und Win per Adobe-PDF immer ein PDF erzeugen kann. Egal, ob das Corel, Outlook, Powerpoint, Scribus, Works usw. ist. Also das funktioniert immer und das ist der kleinste gemeinsame Nenner auf allen Systemen, die professionell PDFs erzeugen (Share- und Freeware mal ausgenommen). Ich sage nur, daß Quark da im Prinzip keinen Bogen drumherum machen kann/darf. Das sie es trotzdem beratungsresistent seit einigen Versionen machen, darf ich doch wohl kritisieren und in Frage stellen. Immerhin bin ich zahlender Kunde und (nebenbei) vertrete noch weitere Kunden von mir - deren Dateien ich weiterverarbeiten muß und da wäre eine Trimbox nunmal sehr nett.

Gruß

Hallo,

vielen Dank für Eure Tipps. Ich drucke auf den Helios PDF Drucker.
Der verarbeitet meine Quark 8 Dateien jetzt mit der richtigen Trim Box dank Jo Lauterbachs Extension. Und das sogar im Demo-Modus!!


Vielen Dank
Lars

Antwort auf [ rohrfrei ]

Hallo,

Zitat

Das besteht nicht seit der Vorversion. Das war schon immer so.

Tatsächlich? Als Anlage mal zwei PS aus Uralt-Zeiten. Bitte mal in einen nackten Distiller 9 ohne Startups werfen und die Trimbox checken. Ich denke, das ist alles ok. Also muß sich die Firma Quark von mir die Frage gefallen lassen, warum etwas in XPress 6,7,8 nicht funzt, was früher ok war. Ist die Frage so widersinnig?

Moin rohrfrei,

mit dem falschen Bein aufgestanden? Da kommt ja gerade jede Menge Frust raus...

Meines Wissens nach hat der Distiller eine Funktion automatisch mit eingebaut, welche die Schnittmarken von Quark ausgelesen und an Hand derer die TrimBox gesetzt hat. Mit der Version 6 hat Quark wohl die Art und Weise, wie diese Information in den PostScript-Code geschrieben wird verändert, so dass seit dem Zusatzsoftware nötig ist.
Natürlich sieht sich Adobe nun auch nicht in der Pflicht diesem Ding wieder (und bei jeder neuen Änderung) hinterherzulaufen. Die haben ja eher was ganz anderes vor...;o)

Viele Grüße

Antwort auf [ rohrfrei ]

Zitat

Das besteht nicht seit der Vorversion. Das war schon immer so.

Tatsächlich? Als Anlage mal zwei PS aus Uralt-Zeiten. Bitte mal in einen nackten Distiller 9 ohne Startups werfen und die Trimbox checken. Ich denke, das ist alles ok. Also muß sich die Firma Quark von mir die Frage gefallen lassen, warum etwas in XPress 6,7,8 nicht funzt, was früher ok war. Ist die Frage so widersinnig?

Hallo Rohrfrei, in Deinen PS-Dateien aus XPress 4 und 5 sind keine Trimboxen enthalten, sondern der Distiller erzeugt aufgrund der Beschnittzeichen die Trimbox.
So bleibt, wie schon geschrieben, meine Aussage bestehen: XPress hat noch nie Trim- und Bleedbox bei der Postscript-Ausgabe in den Datenstrom geschrieben.

Antwort auf [ rohrfrei ]

Zitat

Das bedeutet ja, dass die Leute immer noch composite-PDFs mit Schnittzeichen erzeugen müssten, obwohl die bei korrekt gesetzter Trim- und Bleedbox überflüssig und beim Ausschießen hinderlich sind.

Die Aussage verstehe ich nicht! Auch nicht im Ansatz der Sinn, der da evtl. dahinter stecken könnte. Ich möchte als Datenverarbeiter eigentlich keine PDFs ohne Schneidezeichen bekommen. Auch wenn die in der Bogenmontage montiert werden, sind sie doch eine gute Orientierungshilfe bei angelieferten Daten.

Meine Dienstleister wünschen die Beschnittzeichen nicht, wenn Trim- und Bleedbox gesetzt sind.

Antwort auf [ rohrfrei ]

Zitat

Wenn ich diesen Zeit- und Sicherheitsgewinn mit einrechne, ist jede Diskussionszeit über die Kosten dieser XTension schon teurer als die XTension selbst.

Verstehe ich auch nicht. Wozu gibt es die Druckstile?

Ich bin es Leid jeweils einen Druckstil für A4+, A5+, A6+ A4+quer usw. usf. zu haben, wenn ich direkt mit der MediaBox ein einziges "Riesenformat" in den einen einzigen Druckstil hängen kann und dann automatisch das PDF auf das richtige Format beschnitten erhalte.

Antwort auf [ rohrfrei ]

Nur mal so nebenbei. Ich hatte bereits ---EDIT: 2003 und 2006 EDIT-ENDE---- 2006 eine 5er-Lizenz der MediaboxXT. Ich kenne es also sehr gut. Nur ich sehe nicht ein, bei jedem Quarkupdate noch zusätzliche Drittkomponenten ebenfalls kostenpflichtig mit upzudaten für Sachen

War das Upgrade der MediaBoxXT kostenpflichtig?

Antwort auf [ rohrfrei ]

Und so elegant wie der InDeisgn-PDF-Export wird es sowieso nicht. Denn DA muß ich mich um rein gar nichts kümmern mit einer entsprechenden PDF-Exportvorgabe. DA muß ich noch nicht einmal das Seitenformat eingeben, das geht alles automatisch - von Hause aus.

Wo ist der Unterschied zur PDF-Ausgabe aus XPress?

Antwort auf [ Detlev Hagemann ]

Meine Dienstleister wünschen die Beschnittzeichen nicht, wenn Trim- und Bleedbox gesetzt sind.

Leider wissen nicht alle Grafiker, was eine TrimBox ist und ob Sie diese uns "mitgeben". Mit Schnittmarken, die 3 mm vom Endformat entfernt sind, gibt es da die wenigsten Probleme und bei manchem wird durch die Schnittmarken automatisch eine TrimBox gesetzt [hatten wir ja grad ;o)] - wir haben die TrimBox und den Grafiker interessiert es nicht.
Bei Einzelseitenausdrucken sind aktivierte Schnittzeichen aber auch eine hervorragende Sache.

Antwort auf [ Detlev Hagemann ]

Ich bin es Leid jeweils einen Druckstil für A4+, A5+, A6+ A4+quer usw. usf. zu haben, wenn ich direkt mit der MediaBox ein einziges "Riesenformat" in den einen einzigen Druckstil hängen kann und dann automatisch das PDF auf das richtige Format beschnitten erhalte.

Zum Beispiel das macht InDesign super vor. Ich habe im Drucken-Dialog ein benutzerdefiniertes Papierformat und InDesign passt es automatisch an (so wie Quark beim Export). Warum geht das nicht auch bei Quark? Dann wärest Du die diversen Druckstile los.

Auch wenn es Wege gibt die angesprochenen Probleme elegant und ohne großen Aufwand zu umgehen, so wäre es doch wünschenswert, wenn sich auch da bei Quark etwas tun würde.

Hallo Thomas,

natürlich wäre es schön, und ich wäre der letzte, der sich sich das nicht auch wünscht.

Aber viele Diskussionsrunden drehen sich immer mehrfach im Kreis, und der geht so:
Xpress 4 hat Fehler in der Ausgabe gemacht. Das wussten alle, inklusive der Ausschießer. Also haben sich Workarounds etabliert. Nun macht XPress beim PDF-Export als PS alles richtig! Aber, oh Schreck, die alten Workarounds funktionieren nun nicht mehr und führen gar zur Konfusion.
So dass sogar der sehr geschätzte Rohrfrei Ursache und Wirkung bei der Trimbox verwechselt hat.

Warum wird die PDF-Ausgabe aus Word mit der PDF-Ausgabe aus XPress verglichen? Word kann keinen eigenen speziellen PS-code fürs Distillieren erzeugen – XPress kann das. Word braucht das OS und/oder Acrobat dazu – XPress 7 und 8 nicht mehr.

An unserem XPress-8-Buch haben Matthias Günther und ich am eigenen Leibe erfahren: Viermal haben wir das Ausgabe-Kapitel komplett neu geschrieben, immer wieder waren wir argumentativ in Alt-XPress-Zeiten gelandet, hatten die gerade Linie verloren.

(Ich schließe mich hier ein:) Warum ist es so schwer, einfach mal anzunehmen, dass der PDF-Export (sei es als PDF oder PS) aus XPress und InDesign der bessere Ausgabewege ist, der auch von PDFX-ready empfohlen wird?
Warum ist es so schwer, einfach Ausgabestile von PDFX-ready oder ähnlichen zu nehmen (evtl etwas abändern)? Warum müssen denn Layouter oder Druckereien immer wieder das Rad neu erfinden und eigene Stile anlegen? Warum müssen wir immer wieder alte Ausgabe-Wege wie das Drucken in Adobe PDF diskutieren? – Ich persönlich kenne niemanden, der aus Illustrator in Adobe PDF druckt, um eine PDF-Datei zu erhalten.

Hoppla,

habe ich diese Diskussion losgetreten?

Zitat

Warum wird die PDF-Ausgabe aus Word mit der PDF-Ausgabe aus XPress verglichen? Word kann keinen eigenen speziellen PS-code fürs Distillieren erzeugen – XPress kann das. Word braucht das OS und/oder Acrobat dazu – XPress 7 und 8 nicht mehr.

Aber aus Word stimmt die Trimbox. Ist dann Word besser als XPress? Wenn ich eine DIN A4-Seite aus Word in den Adobe-PDF-Drucker drucke, dann hat die Trimbox im PDF anschließend auch DIN A4. Die Schneidezeichen fehlen natürlich, aber die kann Word ja sowieso nicht.

Zitat

Warum ist es so schwer, einfach mal anzunehmen, dass der PDF-Export (sei es als PDF oder PS) aus XPress und InDesign der bessere Ausgabewege ist, der auch von PDFX-ready empfohlen wird?

Warum soll das der bessere Weg sein, wenn der Preflight im Acrobat anschließend Fehler meldet, die per Distiller nicht entstehen? Also das verstehe selbst ich, das diese Argumentation nicht logisch sein kann. Leider hat auf meine Nachfrage im PDF-Board noch niemand geantwortet. Aber hier hat mir auch noch keiner stichhaltig das Gegenteil beweisen können, dass die Fehler im Preflight von Acrobat 9 vernachlässigt werden können. Und solange das so ist, möchte ich doch nur ein druckfähiges PDF/X an eine Druckerei weitergeben. Und wenn die da auch schon Acrobat 9 einsetzen, was ja nicht mehr so brandneu ist, dann muß das doch funktionieren. Verlange ich zuviel?
Die Trimbox berücksichtige ich da jetzt mal gar nicht, da es dafür ja scheinbar Lösungen gibt. Auch wenn ich es schade finde, dass Impressed da kein Update anbieten wird.

Zitat

Warum ist es so schwer, einfach Ausgabestile von PDFX-ready oder ähnlichen zu nehmen (evtl etwas abändern)?

Zum Beispiel weil die einfach nicht aktuell genug sind. Meine Stammdruckerei war bisher jedesmal um Wochen schneller mit angepassten Settings wenn neue Programmupdates herauskamen. Und die nehme ich auch für andere jobs. So wie noch vor einigen Jahren, das ich im Distiller mehrere unterschiedliche joboptions habe, machen wir schon lange nicht mehr so. Eine funktionierende PDF/X-Vorgabe reicht meiner Meinung nach auch aus.

Zitat

Ich persönlich kenne niemanden, der aus Illustrator in Adobe PDF druckt, um eine PDF-Datei zu erhalten.

Weil Illustrator und InDesign aber auch ein funktionierendes PDF exportieren können, welches sowohl die Trimbox korrekt enthält und auch den aktuellen Acrobat-Preflight einhält. Beides zusammen ist aus XPress nicht möglich.

Arbeiten Sie eigentlich für Quark?

Hallo Farbenhuhn

Antwort auf [ Farbenhuhn ]

Aber hier hat mir auch noch keiner stichhaltig das Gegenteil beweisen können, dass die Fehler im Preflight von Acrobat 9 vernachlässigt werden können. Und solange das so ist, möchte ich doch nur ein druckfähiges PDF/X an eine Druckerei weitergeben.

Schicke deine QXP8er PS-Datei durch den Acrobat 8, merkt er diese an ?

Wenn nein, warum wird diese dann im Preflight von Acrobat 9 als fehlerhaft deklariert ?

Hallo,

weil laut Herrn Drümmer, der Acrobat 9 verschärfte Prüfregeln enthält:

Zitat

- Acrobat 7 hat nicht in Schriften hineingesehen, konnte also nicht herausfinden, ob ein Glyph da ist oder nicht
- Acrobat 8 und 9 sehen in Schriften hinein und finden heraus, ob ein benötigter Glyph auch wirklich in der eingebetteten Schrift existiert und erreichbar ist
- die Zählweise zwischen 8 und 9 unterscheidet sich, Acrobat 8 führt das Fehlen eines Glyphs nur einmal pro Schrift auf (meckert also sozusagen die betreffende Schrift an), während Acrobat 9 jede Stelle anmeckert, an der ein Glyph verwendet wird, aber nicht in der eingebetteten Schrift vorhanden ist (Acrobat 9 meckert also Textstellen an). Natürlich gibt es in letzterem Fall evtl. nur einen Font, in dem ein Glyph fehlt, wobei dieser Glyph aber evtl. mehrmals benutzt wird.

Zitat

Das wurde in PDF/A-1 und PDF/X-4 in noch ausdrücklicherer Weise zur Vorschrift gemacht, und die Ghent PDF Working Group hat das auch in ihre aktuellen Profile übernommen, die noch garnicht auf PDF/X-4 basieren.

Ich persönlich halte das durchaus für sinnvoll - aber bin mir schon darüber im Klaren, dass es grad bei 'älteren' Tools mal zu Konflikten kommen kann (sprich: die Prüfung schlägt an, aber es ist kein echtes Problem).

Demnach würde eine Prüfung in Acrobat 7 das Problem ja ganz elegant für Quark aus der Welt schaffen. Ist es das, was einige hier wollen? Mit Acrobat 7 arbeiten und einfach wegsehen und das Problem ist gelöst? Kann das sinnvoll sein?

Hallo

Habe ich irgendwo Acrobat 7 erwähnt ?

Nein natürlich nicht. Das war ja auch überspitzt formuliert in Anlehung an die Aussage von Herrn Drümmer. Ich verstehe die Aussage so, als wenn die neueren Acrobat-Versionen genauer prüfen als die alten. Wenn ich also max. Sicherheit möchte bei der Datenweitergabe, dann würde sich auch die neueste Acrobatversion anbieten und das wäre dann Acrobat 9. Warum wird Acrobat 9 hier so verteufelt? Ich habe das Gefühl, das hier verzweifelt der Acrobat 9 schlecht geredet wird, um das Ergebnis von XPress 8 zu rechtfertigen. Ich stelle dem noch einmal ein exportiertes PDF aus InDesign CS4 entgegen, welches die Prüfungen in Acrobat 9 besteht. Also kann doch der Acrobat 9 nicht die Ursache allen Übels sein.

Es ist doch ganz einfach so, dass mir das ganze auch überhaupt keinen Spaß macht. Den Freitagnachmittag habe ich damit verbracht, einen Teil des Wochenendes und jetzt schon wieder. Ich möchte doch nur, dass es funktioniert. Wir werden wohl wieder einen Distiller-Hotfolder installieren.

Ich habe übrigens Kollegen in der Visualisierung und im Screen-Design, die arbeiten unter Windows. Denen wurde bei der Installation der CS4 die alte Acrobat-Version 8 deinstalliert und die haben nur noch Acrobat 9 auf dem Rechner. Jetzt arbeiten die nicht mit XPress und PDF aber was sollen die denn machen? Die können nicht mal eben auf eine ältere Acrobat-Version ausweichen, weil sie die nicht mehr haben. Also ist doch diese Argumentation nicht praxisgerecht.

Hallo,

Zum Glyphen-Problem:
Die Sache wurde an alle beteiligten Firmen (Adobe, Quark, Callas) eskaliert.
Es ist wirklich so, dass Acrobat 9 hier zu "scharf" prüft. Ich würde ein solches PDF, dass beide besagten Errors aufweist, als problemlos druckfähig ansehen (von anderen Meldungen natürlich abgesehen).
Weiterhin wäre es möglich in den XPress Vorgaben einen anderen Font für die Infozeile zu verwenden - das muss allerdings ein PostScript-Font sein!
((Ich habe den Fehler zwar auch noch in anderen Bereichen festgestellt, dazu möchte ich aber öffentlich noch nichts sagen))

Georg Obermayr

Hallo Herr Obermayr,

Zitat

Weiterhin wäre es möglich in den XPress Vorgaben einen anderen Font für die Infozeile zu verwenden - das muss allerdings ein PostScript-Font sein!

Sie sind ein Schatz. Das könnte die Lösung sein. Ein erster Test brachte keinen Fehler im Acrobat 9. Es muß tatsächlich ein PS-Font sein. Auf jeden Fall ein fettes Dankeschön. Ich werde das morgen in der Agentur mal auf anderen Rechnern testen, ob das mit echten jobs auch so funktioniert. Dann wäre ja alles in Butter und die ganze Aufregung umsonst. Dann wäre ja auch meine Intention mit der Investition in XPress 8 und der Nutzung des PDF-Exports erfüllt. Ich kann es noch gar nicht glauben. Hoffentlich klappt es so einfach.

Hallo,

ganz so einfach ist es dann wohl doch nicht. Bei meinem Test vorhin hatte ich auf einer Testseite nur PS- und OT-Fonts verwendet. In so einem Fall erzeugt der Preflight von Acrobat 9 keinen Fehler.

Gerade habe ich einen weiteren Test gemacht und auf der Seite auch TT-Fonts platziert. Dann erzeugt jede TT-Schrift wieder den Glyphen-Fehler in Acrobat 9. Es scheint also am verwendeten Fontformat zu liegen.

Kann man die TT-Fonts beim Export in PS-Fonts konvertieren lassen? Ich habe mal in Acrobat so eine Einstellung gesehen. Leider können wir auf die TT-Helvetica mit den osteuropäischen Glyphen nicht verzichten.

Antwort auf [ Farbenhuhn ]

Zitat

Warum wird die PDF-Ausgabe aus Word mit der PDF-Ausgabe aus XPress verglichen? Word kann keinen eigenen speziellen PS-code fürs Distillieren erzeugen – XPress kann das. Word braucht das OS und/oder Acrobat dazu – XPress 7 und 8 nicht mehr.

Aber aus Word stimmt die Trimbox. Ist dann Word besser als XPress? Wenn ich eine DIN A4-Seite aus Word in den Adobe-PDF-Drucker drucke, dann hat die Trimbox im PDF anschließend auch DIN A4. Die Schneidezeichen fehlen natürlich, aber die kann Word ja sowieso nicht.

Weil XPress seinen (aus meiner Sicht nicht mehr weiter entwickelten) PostScript-Code schickt und nicht den des OS oder den des Acrobat-Pakets.

Antwort auf [ Farbenhuhn ]

Zitat

Warum ist es so schwer, einfach mal anzunehmen, dass der PDF-Export (sei es als PDF oder PS) aus XPress und InDesign der bessere Ausgabewege ist, der auch von PDFX-ready empfohlen wird?

Warum soll das der bessere Weg sein, wenn der Preflight im Acrobat anschließend Fehler meldet, die per Distiller nicht entstehen? Also das verstehe selbst ich, das diese Argumentation nicht logisch sein kann. Leider hat auf meine Nachfrage im PDF-Board noch niemand geantwortet. Aber hier hat mir auch noch keiner stichhaltig das Gegenteil beweisen können, dass die Fehler im Preflight von Acrobat 9 vernachlässigt werden können. Und solange das so ist, möchte ich doch nur ein druckfähiges PDF/X an eine Druckerei weitergeben. Und wenn die da auch schon Acrobat 9 einsetzen, was ja nicht mehr so brandneu ist, dann muß das doch funktionieren. Verlange ich zuviel?
Die Trimbox berücksichtige ich da jetzt mal gar nicht, da es dafür ja scheinbar Lösungen gibt. Auch wenn ich es schade finde, dass Impressed da kein Update anbieten wird.

Erst durch CS4 gelangt Acrobat 9 wirklich in den Einsatz – vorher war es nur selten im Einsatz. Die Schwächen werden also jetzt erst spürbar. Zum Glyphen-Fehler von Acrobat hat sich ja Georg Obermayr schon gemeldet. Aber warum überhörst Du die Aussage: Benutze doch den PS-über-PDF-Export von XPress. Ich habe keine Probleme mit XPress 8 , mit TrueType und dann mit Acrobat 9.

Antwort auf [ Farbenhuhn ]

Zitat

Warum ist es so schwer, einfach Ausgabestile von PDFX-ready oder ähnlichen zu nehmen (evtl etwas abändern)?

Zum Beispiel weil die einfach nicht aktuell genug sind. Meine Stammdruckerei war bisher jedesmal um Wochen schneller mit angepassten Settings wenn neue Programmupdates herauskamen. Und die nehme ich auch für andere jobs. So wie noch vor einigen Jahren, das ich im Distiller mehrere unterschiedliche joboptions habe, machen wir schon lange nicht mehr so. Eine funktionierende PDF/X-Vorgabe reicht meiner Meinung nach auch aus.

Eine (!) – das halte ich für fast grob fahrlässig. Warum gibt PDFX-ready wohl unterschiedliche Distiller-Joboptions/InDesign-PDF-Vorgaben heraus? So schön die Adobe-Welt auch sein mag, man sollte nicht die Distiller-Joboptions aus InDesign heraus einsetzen und nicht die InDesign-Ausgabesettings als Distiller-Joboptions missbrauchen. Und eine weitere Frage bleibt mir: Warum muss man bei den PDFs aktueller sein als andere? Da ich nicht nur mit einem "besonders aktuellen" Dienstleister zusammen arbeiten möchte, sondern mit es mit (fast) jedem Dienstleister der Welt können möchte, arbeite ich lieber mit verbesserten Normsettings.

Antwort auf [ Farbenhuhn ]

Zitat

Ich persönlich kenne niemanden, der aus Illustrator in Adobe PDF druckt, um eine PDF-Datei zu erhalten.

Weil Illustrator und InDesign aber auch ein funktionierendes PDF exportieren können, welches sowohl die Trimbox korrekt enthält und auch den aktuellen Acrobat-Preflight einhält. Beides zusammen ist aus XPress nicht möglich.

Das wäre ja noch schöner, wenn Adobe mit Acrobat 9 darüber entscheidet, was ein gültiges PDF/X wäre und was nicht. Wenn die GWG oder die ISO darüber entscheidet, was ein PDF-X ist, dann ist es ok. Wenn aber eine Firma wie Adobe den Scharfrichter über PDF-X spielen darf oder will, dann sind wir in der Druckvorstufe langsam wohl im falschen Gewerbe.

Antwort auf [ Farbenhuhn ]

Arbeiten Sie eigentlich für Quark?

Nein. http://www.amazon.de/...d=1234210855&amp. Aber manchmal rufen die mich bei speziellen Aufträgen als Consultant hinzu. Nun zur Ausgewogenheit: Ich gebe bei der SMI den PDF-PrePress-Grundkurs und den InDesign-Ausgabe-Kurs.
Und ich glaube den Marketing-Versprechen von Adobe und Quark grundsätzlich erst mal nicht.

Antwort auf [ Farbenhuhn ]

Gerade habe ich einen weiteren Test gemacht und auf der Seite auch TT-Fonts platziert. Dann erzeugt jede TT-Schrift wieder den Glyphen-Fehler in Acrobat 9. Es scheint also am verwendeten Fontformat zu liegen.

Exakt das meinte ich mit Dingen, die ich noch nicht mit Sicherheit sagen kann. Ich bin auch darüber gestolpert, konnte es aber nicht genauer anschauen.
Es scheint also wohl doch mehr im Busch zu sein, als nur die Infozeile.

Georg Obermayr

Antwort auf [ Detlev Hagemann ]

Und ich glaube den Marketing-Versprechen von Adobe und Quark grundsätzlich erst mal nicht.

Willkommen im Klub der Glaubensgenossenschaft.

Hallo Detlev,

Antwort auf [ Detlev Hagemann ]

Warum wird die PDF-Ausgabe aus Word mit der PDF-Ausgabe aus XPress verglichen? Word kann keinen eigenen speziellen PS-code fürs Distillieren erzeugen – XPress kann das. Word braucht das OS und/oder Acrobat dazu – XPress 7 und 8 nicht mehr.

Eine Frage, die mit dem CUPS-Filter wirklich nichts zu tun hat aber irgendwie trotzdem hierher passt:
Beim ersten PDF-Export aus Quark 6 war es notwendig, eine PS-Drucker zu installieren, damit XPress das PS/PDF exportiert. Ist dies eigentlich bei den Versionen 7 und 8 immer noch so? Oder hat Quark da irgendwas eigenes eingebaut?

Auf meinen Rechnern ist auch immer der "Adobe PDF", also ein PS-Drucker vorhanden, so fällt mir das nie auf.

Hallo Thomas,
passt hier her.

Seit XPress 7 ist XPress vollkommen autonom. Es werden keine Bestandteile des OS oder vom Acrobat-Paket mehr gegriffen (es sei denn, Du wählst die Acrobat PPD oder den Drucker "Adobe PDF" oder die OS-X-PDF-Engine).

Deswegen hinken auch alle Vergleiche zwischen XPress 7/8 und anderen Programmen.

Hallo,

Zitat von Detlev Hagemann

Das wäre ja noch schöner, wenn Adobe mit Acrobat 9 darüber entscheidet, was ein gültiges PDF/X wäre und was nicht. Wenn die GWG oder die ISO darüber entscheidet, was ein PDF-X ist, dann ist es ok. Wenn aber eine Firma wie Adobe den Scharfrichter über PDF-X spielen darf oder will, dann sind wir in der Druckvorstufe langsam wohl im falschen Gewerbe.

OK, ich verstehe was du damit sagen willst. Das kann man sicherlich zur Disposition stellen. Ich werde weiter unten nochmal auf die Unterschiede von Acrobat eingehen. Aber ich sehe in dieser Aussage ein Problem. Adobe ist kein ISO-Gremium, sondern ein profitorientiertes Unternehmen, das ist klar. Aber wir haben doch über die Jahre alle stillschweigend akzeptiert, daß Adobe in Sachen PDF die "Norm" vorgibt. Wir alle betrachten Acrobat-Prof. als DIE Referenzanzeige schlechthin bei korrekt justierter Ausgabevorschau. Bei der Transparenzreduzierung ist es ähnlich. Und bisher war der Preflight auch das Maß der Dinge. Das soll jetzt alles plötzlich keine Gültigkeit haben, weil es nicht mehr mit der anderen Firma Quark zusammenpasst? Ich kann und will das so nicht akzeptieren. Das ist mir zu einfach. Es hat nicht nur einer "Schuld".

Ich habe heute nochmal einige Tests gemacht. Und ich konnte mit einem betagten Freehand-MX, einem noch älteren Corel12 und auch einem aktuellen Corel-X4 problemlos PDFs erzeugen, die dem Glyphen-Preflight von Acrobat 9 problemlos stand hielten. Also würde ich das Problem bestimmt nicht ausschließlich bei Adobe sehen. Andere Programme können offensichtlich problemlos damit zusammenarbeiten.

Aber es kommt noch besser, und das ist auch der Punkt, wo ich Quark in die Pflicht nehme und nicht Adobe.
Ich habe auf DEMSELBEN MAC mit DENSELBEN aktivierten Schriften PDFs aus XPress 7 und XPress 8 erstellt. Dabei habe ich ebenfalls einen signifikanten Zusammenhang im Umgang mit Truetype-Schriften festgestellt. XPress 8 behandelt die völlig anders als XPress 7. Im Anhang mal die screenshots aus Acrobat 9:
"8-export.png" zeigt die enthaltenen Fonts im PDF. Da ist eine Helvetica als Truetype eingebettet. Und das ist auch exakt die, die vom Acrobat-Preflight bei den Glyphen angemeckert wird.
"7-export.png" zeigt die enthaltenen Fonts DERSELBEN QXD-Datei im PDF. Da ist die Helvetica als Type1 eingebettet. Und siehe da, der Acrobat-Preflight meckert keine Glyphen an.
"7-distiller.png" zeigt ein ähnliches Verhalten, d.h. keine Glyphenprobleme. Zusätzlich ist noch die Courier für die Seiteninfo enthalten. Wo die Arial herkommt habe ich jetzt nicht weiter untersucht. Es ist aber alles identisch getestet.

Ich stelle fest, das XPress 7 bei identischer Vorgehensweise per Export die Fonts anders behandelt als XPress 8. Und das führt u.a. zu den Problemen im Acrobat-Preflight, obwohl andere Programme damit keine Probleme haben. Das ist nunmal fakt.

Ich sehe aber ein, daß Acrobat 8 die problembehaftete Datei aus XPress 8 eindeutig als PDF/X-konform betrachtet. Also wieder zurück zu Deiner Aussage. Unterschiedliche Acrobat-Versionen dürfen eigentlich nicht zu unterschiedlichen Ergebnissen bezgl. der PDF/X-konformität für den gleichen bekannten Standard PDF/X-3 kommen. Du hast die GWG erwähnt. Ich würde die Zitate von Herrn Drümmer also auch so verstehen, als wenn der Acrobat-9-Preflight GWG-konform wäre. So richtig eindeutig steht das aber nicht, das gebe ich gerne zu.

Als Gegenbeweis kann man aber mal die Prüfregel von Acrobat 9 wählen, die eindeutig den GWG-Specs genügt in der neuesten Generation "Bogenoffset (CMYK und Schmuckfarbe)". Da fällt mir auf, daß das XPress7-PDF die Prüfung besteht hinsichtlich Glyphen und das das XPress-8-PDF sogar gleich zweimal durch die Prüfung durchfällt, nämlich wegen der fehlenden Glyphen und auch wegen der anderen Melung im PDF-Board ".notdef Glyphen".

Daher stelle ich die Ausgabequalität von XPress 8 einfach mal zur Diskussion. Und wenn es erstmal rein auf die eigene Vorgängerversion eingegrenzt wird. Das Problem verdichtet sich auf die Truetypes.

Gruß

P.S.: die Mediabox-XTension habe ich jetzt übrigens auch wieder, das mal nur als Randnotiz

Hallo Rohrfrei,

ich zitiere mal aus dem Manuskript zum 8er-Buch von Matthias Günther und mir:
Früher (in XPress 7) wurden TrueType-Schriften ins PostScript-Format umgewandelt, mit der Konsequenz, dass das Hinting im PDF verloren ging.

Mit XPress 8 werden beim direkten PDF-Export die TrueType-Schriften zu Type 42 gewandelt.

Das ist die Hauptveränderung durch Quark im Exportmodul für XPress 8.


Nicht nur die XPress-Glyphen-Problematik sondern auch andere Punkte des Preflights lassen mich ständig unentschlossen, ob ich persönlich den Preflight-Job mit Acrobat 8 oder 9 machen soll.
Die Reaktion von Preflight-Anfängern in PDF-Schulungen ist fast unisono: Bitte, bitte Acrobat 8. Dort haben sie das Gefühl, etwas zu verstehen … in Acrobat 9 geht ihnen fast alles über die verstehende Hutschnur.

Für mich stehen folgende Fragen im Mittelpunkt:
1.
Überschreitet Adobe zum ersten Mal in der Acrobat-Geschichte die Kompetenzen und erklärt durch seine eingebauten Prüfmechanismen (von callas?) tatsächlich gültige PDF-X-Dateien (das ist ISO-Standard!!!!) für ungültig?

oder

2.
XPress 8 schreibt nach seinen Prüfregeln gültige PDF-X (das ist ISO-Standard!!!!) raus. Erklärt also der Quark-Jaws-Callas-Überprüfer tatsächlich ungültige PDF-X "lügenderweise" zu gültigen PDF-X?

Hallo Detlev Hagemann,
mir geht der Acrobat 9 allmählich mit seiner "oberlehrerhaften" Art ziemlich auf den Geist.

Siehe Diskussion:
http://www.hilfdirselbst.ch/...nicode)_P383447.html
vorletzter Beitrag mit der Antwort von callas
Hier wird aus einem "should not" von callas ein "darf nicht" gemacht.
Viele Grüße

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

Hallo, Rohrfrei!

Zitat

Tatsächlich? Als Anlage mal zwei PS aus Uralt-Zeiten. Bitte mal in einen nackten Distiller 9 ohne Startups werfen und die Trimbox checken. Ich denke, das ist alles ok.

Leider nein.
Die Ursache wurde schon genannt: der Distiller benutzt die Schnittmarken für die Erstellung der TrimBox.
Schlimmer noch: er verrechnet sich dabei, weil QuarkXPress die Marken nicht exakt setzt! Du erhälst also keine 210 x 200 mm wie im Beispiel wohl beabsichtigt, sondern gerundete Werte: 209,91 x 200,03 mm. Bei auszuschießenden Seiten entsteht ein möglicherweise gut sichtbarer Spalt zwischen den Seiten.

Was kann man stattdessen tun?
Z.B. prinzipiell für jede zu schreibende PostScript-Datei eine MediaBox-Zugabe von, sagen wir 'mal, 20 mm in Breite und Höhe machen. Den Distiller so einstellen, daß dann die korrekte TrimBox geschrieben wird. Kann man für feste Werte in den Joboptions einstellen. Ist exakt, ohne Rundungsfehler, wenn's korrekt definiert wird. Das wäre also der Praxis-Workaround für die TrimBox-Problematik.

Diese Vorgehensweise ist unabhängig von QuarkXPress, InDesign etc.pp. Falls eine TrimBox-Information bereits ins PostScript geschleust wurde, überschreiben die Definitionen der joboptions-Datei diese nicht. Vorrang hat, nach meiner Erfahrung, dann die Definition in der PostScript-Datei. Getestet habe ich diese Vorgehensweise mit PostScript-Daten aus FreeHand, PageMaker und InDesign.

Noch ne Ergänzung:
Die ungenaue (gerundete) TrimBox entseht mit QuarkXPress 4, bei Version 5 scheint es ok zu sein (siehe das Rohrfrei-Beispiel mit der XPress 5-PostScript-Datei; dort entsteht nach dem Distillen eine exakte A4-TrimBox). Ich kann's leider nicht weiter mit anderen Versionen austesten, hab kein XPress mehr laufen.

Moin rohrfrei,

leider (oder glücklicherweise?) habe ich hier noch XPress 7 und Acrobat 8 auf WinXP.

Aber mir war aufgefallen, dass bei irgendeinem 7er Update im Druckmenü die Option "Optimierte Schriftformate" dazu kam. Wenn ich dieses Häckchen nicht mache, dann wandelt Quark 7.5 alles in Type1 um. Mit aktiviertem Häckchen passiert laut Quark Folgendes:

Roman TTF/OTF wird zu Type 42
East Asian TTF/OTF wird zu CID Type2
Type 1 CFF bleibt Type 1
CFF CID wird zu Type 0

Vielleicht hat Quark ja davon auch was in den nun propagierten PDF-Export gepackt, bei dem ich bis 7.5 ich keine "Optimierung" vornehmen konnte.

Viele Grüße

Hallo,

vollkommen richtig beobachtet. Du hast im PDF-Ausgabedialog keine Wahl der "optimierten" Schriftformate: in Xpress 7 war diese Funktion inaktiv – in XPress 8 ist er immer angeschaltet.

Hallo miteinander,

das ist ja doch noch eine richtig gute Diskussion geworden. Eigentlich fand ich den letzten Beitrag von Georg Obermayr auch ein gutes Fazit und Schlußplädoyer. Mittlerweile ist da schon wieder so viel dazugekommen.

Zitat von Detlev Hagemann

ich zitiere mal aus dem Manuskript zum 8er-Buch von Matthias Günther und mir:
Früher (in XPress 7) wurden TrueType-Schriften ins PostScript-Format umgewandelt, mit der Konsequenz, dass das Hinting im PDF verloren ging.

Mit XPress 8 werden beim direkten PDF-Export die TrueType-Schriften zu Type 42 gewandelt.

Das ist die Hauptveränderung durch Quark im Exportmodul für XPress 8.

Ah, ok, danke für die Erklärung. Das wußte ich nicht. Ich bin mittlerweile von der täglichen Arbeit zu weit weg von XPress und darf dann immer nur den Feuerwehrmann spielen, wenn irgendwas nicht geht.
In meinem obigen Test fehlte noch das Ergebnis der Schriftenübersicht der PDF-Datei aus XPress 8 über den Distiller. Das nochmal der Vollständigkeithalber angehängt. Da ist aber auch keine Truetype mehr vorhanden. Offensichtlich ist das dann ja auch der Grund, warum ein solches PDF im Acrobat9-Preflight fehlerfrei durchläuft. Wie erklärt sich das denn? Das bedeutet doch, das XPress 8 beim Druck über den Adobe-PDF die TT-Fonts ebenfalls konvertiert zu Type1.

Zitat von Uwe Laubender

Die Ursache wurde schon genannt: der Distiller benutzt die Schnittmarken für die Erstellung der TrimBox.

Ja, das wird wohl bis XPress 5 untersützt werden. Ab XPress 6-7 sind dann die Impressed-Startups notwendig. Müsste wohl so gewesen sein, ist ja schon wieder so lange her.

Zitat von Uwe Laubender

Schlimmer noch: er verrechnet sich dabei, weil QuarkXPress die Marken nicht exakt setzt! Du erhälst also keine 210 x 200 mm wie im Beispiel wohl beabsichtigt, sondern gerundete Werte: 209,91 x 200,03 mm. Bei auszuschießenden Seiten entsteht ein möglicherweise gut sichtbarer Spalt zwischen den Seiten.

Richtig, so war es damals. Das war auch der Grund, warum ich 2003 die 5er-Lizenz von Jo Lauterbach schon gekauft hatte. Im geposteten PS aus Mac-QXD4 habe ich die sogar extra vor dem Drucken deaktiviert, daher die gewohnt ungenauen Werte der Trimbox.

Zitat von Polylux

Aber mir war aufgefallen, dass bei irgendeinem 7er Update im Druckmenü die Option "Optimierte Schriftformate" dazu kam.

Das ist mir auch aufgefallen und ich konnte mir bisher noch keinen Reim darauf machen, was diese Funktion tatsächlich bewirkt. Also habe ich bisher immer die Finger davon gelassen. "Optimierte Bildauflösung" bei ID ist ja auch nicht wirklich optimal ;-)

Gruß

Hallo TrimBox-Geschädigte,

ab sofort ist die hier mehrfach angesprochene Distiller Startup-Datei "QXP_Printers_Marks_Patch" in Version 1.0.3 verfügbar. Diese bietet nun auch Unterstützung für QuarkXPress 8.0x und nutzt darin die neue Möglichkeit optional Anschnittmarken mit auszugeben. Sind diese aktiviert, kann auch eine BleedBox im PDF generiert werden (dazu muss in der Startup-Datei nur der entsprechende "Schalter" aktiviert werden). Somit wird die BleedBox nicht mehr wie früher basierend auf dem Druckmarkenversatz errechnet, sondern spiegelt die tatsächliche Anschnittbreite wider.

Hier die darin enthaltenen Funktionen:
- Setzen von TrimBox und BleedBox aus Druck- und EPS-Dateien von QuarkXPress 7 und 8.0x, welche mit der Druckoption "Passkreuze" (zentriert oder nicht zentriert) ausgegeben wurden (Acrobat Distiller bis einschließlich Version 9.0.0 bietet dies Feature nicht).

- Aufteilung der Beschnittzeichen und Passkreuze in Einzelobjekte, so dass in Preflight-Produkten eine Überprüfung deren Lage in Bezug auf den Endformat-Rahmen möglich ist

- Umfärbung der Beschnittzeichen und Passkreuze in den Farbraum Separation "All" bei separierter Ausgabe um auch in diesem Ausgabe-Modus die Positionierung der Marken per Preflight prüfen zu können

Die Startup-Datei ist im "Distiller Secrets" Download-Paket enthalten und ist für registrierte Kunden der Impressed GmbH kostenlos. Andere Interessenten können dieses Paket für EUR 25,- zzg. MwSt. online erwerben.

Der Link zur Produktseite lautet:
http://www.impressed.de/t/produkt.taf?fn=detail&PR_ID=1108

Hallo Herr Zacherl,

mit Freude lese ich Ihren Beitrag. Gerne bestätige ich den hier Mitlesenden, daß der Patch ausgezeichnet funktioniert. Vielen Dank für die darin geleistete Arbeit.

Gruß

abschließend sei noch erwähnt, daß der CUPS-Filter von Quark sowohl unter Tiger als auch unter Leopard funktioniert, in beiden Fällen auch mit Distiller 9. Quark könnte da also ruhig die Systemanforderungen auf der Homepage konkretisieren.

Unter Tiger habe ich jedoch den Fall, daß bei Verwendung des Adobe-PDF-9 in den Dokumenteigenschaften des erzeugten PDFs der Distiller 8 als Ersteller angezeigt wird. Und unter Leopard ist es genau umgekehrt. Da wird immer der Distiller 9 als Ersteller angezeigt. Auch wenn ich bewußt den Adobe-PDF-8 anwähle. Ich kann nicht sagen, ob das überall so ist, ist mir nur bei mir so aufgefallen. Ist aber sicherlich nicht tragisch, nur auffällig.

Wäre gut, wenn Quark für XPress 9 folgendes verbessern würde:
1. Direkte PDF-Erstellung über Adobe-PDF-Drucker inkl. korrekter Trimbox ohne erforderliche Zusatzerweiterungen durch Drittfirmen:
- wenn CUPS-Erweiterung notwendig ist, dann soll das Installationsprogramm das bitte automatisch mit installieren
2. PDFs per Export bitte so erzeugen, daß es im Acrobat 9 keine Glyphen-Probleme gibt. In der Diskussion sind genug andere Programme genannt worden, die damit keine Probleme haben.
3. PDF/X-4 inkl. nativer Transparenzen wäre nett.

Gruß

Hallo,

hier noch eine Info zu TrueType-Schriften in XPress 8, Erstellung von PDF/X und der PDF/X-Prüfung in Preflight Acrobat 9:

- mit XPress 8 werden anders als vorher TrueType-Schriften im XPress-Dokument auch als TrueType-Schriften in ein PDF (und PDF/X) exportiert; das ist durchaus richtig und positiv zu bewerten

- die TrueType-Schriften werden als sog. symbolische TrueType-Fonts eingebettet ('nonsymbolic' geht nur, wenn ausschließlich 'westliche/lateinische Buchstaben' in dem betreffenden Font zur Verwendung kommen; 'symbolic' ist aber immer erlaubt und wird wohl deswegen hier immer verwendet, auch wenn manchmal 'nonsymbolic' ginge)

- die eingebetteten (als symbolisch gekennzeichnete) TrueType-Schriften enthalten zwei cmap-Encoding-Einträge; das ist zumindest laut PDF 1.3 bzw. 1.4-Spezifikation (die auch dem PDF/X-1a bzw. PDF/X-3-Standard zugrunde liegt) suboptimal: "A symbolic font should not specify an Encoding entry; its font program’s “cmap” table should contain exactly one encoding."

- allerdings sind sich die beiden cmap-Encoding-Einträge im Prinzip einig: egal welchen der beiden man benutzt, um die Glyphen zu finden, die ausgegeben werden sollen, kommt das gleiche dabei heraus (wobei man hierzu mehr wissen muss, als aus den PDF 1.3/1.4-Spezifikationen bzw. den zugrundeliegenden TrueType-Spezifikationen ersehen kann, vgl. hierzu den übernächsten Punkt).

- es ist also so, dass sich die durch XPress 8 eingebetteten TrueType-Fonts auf dem Hintergrund von PDF 1.3/PDF 1.4 bzw.PDF/X-1a/PDF/X-3 in einer syntaktischen Grauzone bewegen (should ist in der Tat nicht shall oder must - andererseits ist man in der Regel gut beraten, den "should's" in der PDF-Spezifikation zu folgen...)

- eine interessante Wendung bekommt diese ganze ja eh' schon unübersichtliche Thematik dadurch, dass ISO 32000-1 (die ISO-Standard-Variante von PDF 1.7) nunmehr folgendes sagt: "The font descriptor’s Symbolic flag (see Table 123) should be set, and its font program’s “cmap” table should contain a (1, 0) subtable. It may also contain a (3, 0) subtable; ..." Hier soll also doch alles anders ein...

- noch spannender wird es, wenn man berücksichtigt, dass PDF/X-4 ausdrücklich erzwingt, dass es für symbolische TrueType-Fonts nur genau einen cmap-Encoding-Eintrag geben darf: "All symbolic TrueType fonts shall not specify an Encoding entry in the font dictionary, and their font programs' “cmap” tables shall contain exactly one encoding."


Falls mir bis hierher jemand folgen konnte (oder mochte): je nachdem aus welchem Blickwinkel man drauf schaut, sind die XPress-8-mit-TrueType-PDFs OK oder nicht so richtig OK. Eigentlich weiss man auch nur unter Zuhilfenahme neuerer PDF-Spezifikationen genau, wie man mit zwei cmap-Encoding in einem symbolischen TrueType-Font umgehen sollte (wenn denn diese beiden Encoding-Einträge Windows Symbol und MacRoman sind - das ist nämlich eine weitere, von den XPress 8-PDFs aber eingehaltene Voraussetzung, dass das klappt)

Es ist glaube ich auch müßig, weiter viel Zeit damit zu verbringen, den eigentlichen und absolut Schuldigen zu identifizieren. Hier ist einfach im Dickicht der Spezifikationen und Standards etwas in die Hose gegangen. callas hat einen Teil dazu beigetragen, da man in diesem Fall die PDF/X-Absolution nicht unbedingt hätte verweigern müssen. Quark wäre durchaus gut damit beraten, die PDFs künftig ein kleines bisschen anders zu bauen, da PDF/X-4 die jetzige Konstruktion ausdrücklich nicht erlaubt. Und das ISO-PDF-Komitee sollte sich abschließend überlegen, wie denn das alles bitte schön wirklich sein soll... (Dass callas' nächste Version der pdToolbox diesen XPress-8-PDFs wieder den PDF/X-1a oder PDF/X-3-Segen erteilt, wird leider nicht allen nützen).

In den Hintern gekniffen ist am Schluss der Anwender, der ja kein einwöchiges Fontformat-Training absolvieren wollte, sondern sich durch PDF-Technologie bei seiner Arbeit unterstützen lassen wollte. So ganz auf die Schnelle wird weder Quark noch Adobe passende Updates herausgeben - das dauert bei Firmen, die etwas größer sind als callas, halt alleine schon wegen der nötigen Qualitätsssicherung immer seine Zeit.


Leider habe ich die charmante und rundum befriedigende Lösungsidee auch nicht zur Hand...

Olaf Drümmer