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