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.

Liebe Grüße
Das Farbenhuhn

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.

Liebe Grüße
Das Farbenhuhn

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.


Mit freundlichen Grüssen
Detlev Hagemann

detlev-hagemann.de |•| Wie XPress upgraden? |•| XPress und Apps

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.



gruss xpressio

Phantasie ist wichtiger als Wissen, denn Wissen ist begrenzt.
Albert Einstein

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.

Thomas Nagel

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.


Mit freundlichen Grüssen
Detlev Hagemann

detlev-hagemann.de |•| Wie XPress upgraden? |•| XPress und Apps

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?


Mit freundlichen Grüssen
Detlev Hagemann

detlev-hagemann.de |•| Wie XPress upgraden? |•| XPress und Apps

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
Reitschuster / Catch-22

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.
*****
Mit herzlichem Gruß,
Uwe Laubender

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.
*****
Mit herzlichem Gruß,
Uwe Laubender

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

Thomas Nagel

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.


Mit freundlichen Grüssen
Detlev Hagemann

detlev-hagemann.de |•| Wie XPress upgraden? |•| XPress und Apps