Hallo,

wenn ich in Quark 7.2 Mac ein Original-Bild (300 dpi) platziere, darüber einen weißen Rahmen mit einer Deckkraft von 70 Prozent platziere erhalte ich ein korrektes PDF, in dem beide Objekte, das Bild und der weiße transparente Rahmen, die Auflösung von 300 dpi haben.

Aber:
wenn ich in Quark das Layout (72 dpi) für das Original-Bild (300 dpi) platziere, darüber einen weißen Rahmen mit einer Deckkraft von 70 Prozent platziere erhalte ich ein fehlerhaftes PDF, in dem das Bild 300 dpi und der weiße transparente Rahmen 72 dpi Auflösung haben.

Liegt das noch am Fehler der Helios-OPI-XTensions, die bis heute unverständlicherweise noch nicht verfügbar ist?

Gruß Daniel

hallo daniel

da verweise ich doch einfach auf georg obermayrs artikel zu transparenz, in dem er auch die -- meines erachtens plausible -- inkompatibilität zu opi-systemen erwähnt (unten im abschnitt "Warum keine Empfehlung?").

Hallo,

Antwort auf [ Daniel Richter ]

Liegt das noch am Fehler der Helios-OPI-XTensions

Nein, das liegt an Quark, die jetzt zwar erlauben, im Layout mit Transparenzen zu spielen aber keine Lust haben, es auch zu ermöglichen, diese Transparenzen ins PDF zu übertragen. Somit gelangt in den PostScript-Code, der zum Server gelangt, an den Stellen, wo Xpress bei der Ausgabe auf Transparenzen stößt, gar nicht mehr das Grobbild sondern transparenzreduzierte neue Bildobjekte natürlich dann ohne OPI-Kommentare, mit dem der OPI-Server selbstverständlich nichts mehr anfangen kann, weil Xpress bereits alle relevanten Informationen unterschlagen hat.

Lies Dir bzgl. Grundlangen mal den "Transparenz-Reduzierung in XPress 7.2" Thread hier parallel durch.

Antwort auf:

die bis heute unverständlicherweise noch nicht verfügbar ist?

Naja, was soll Helios schon machen?

Mit Xpress ab Version 7 kann man Produktionssicherheit mit OPI-Workflows eh vergessen. Insofern lohnen auch keine XTensions sondern nur Verzicht auf Version 7 (großes Problem --viele meiner Kunden im Prepress-Bereich schlafen schon seit geraumer Zeit schlecht bei der Aussicht, daß irgendwann deren Kunden dann doch auf XPress 7 umsteigen und die Transparenz-Reduzierungs-Katastrophe ihren Lauf nimmt, da Transparenzreduzierung ja schon zuschlagen kann, wenn man mal einen Rahmen ein bisserl zu weit aufzieht).

Dabei wäre es so einfach: Würde Quark es richtig machen und den /SetTransparency-PDFMark-Operator unterstützen, hätten wir das Problem nicht, aus Quarks PS-Code könnte mithilfe des Distillers PDF mit Transparenzen erzeugt werden, per "PDF native OPI" der Grob-/Feindatenaustausch geschehen und am Ende das PDF flachgerechnet werden und basta.

Aber so wird das Ganze bereits mit der PostScript-Erstellung seitens Xpress im Keim erstickt bzw. eben kaputtgeflattet. *seufz*

Gruss,

Thomas

hallo thomas

Antwort auf [ Thomas Kaiser ]

Würde Quark es richtig machen und den /SetTransparency-PDFMark-Operator unterstützen...

da du so explizit auf quark rumreitest:
welche software ausser dem adobe pdf-maker in ms office tut dies denn noch?

nicht dass wir uns falsch verstehen -- auch ich würde diese variante sehr begrüssen... vielleicht haben wir ja dann glück mit dem pdf-export in xpress 8 ;-)

Hallo Herr Richter,

wenn Sie ein Seitenobjekt transparent auf ein Bild platzieren (oder umgekehrt), dann findet bei der Verflachung dieser Transparenzsituation eine Verrrechnung auf Bitmapebene statt. Dies muss so sein, weil man ja schlecht aus dem Bild ein Vektorobjekt machen kann.
Da die Verflachung vor der OPI-Bildersetzung stattfindet, heißt das natürlich, dass das zum Zeitpunkt der Verflachung vorliegende Bild genutzt wird. Handelt es sich um ein 72 ppi Bild, dann resultiert auch eine 72 ppi aufgelöste Bitmap als Resultat der Verflachung (außer ein zweites Bild mit höherer Auflösung ist involviert).

Da QuarkXPress 7 das Ergebnis der Verflachung einfach auf das originale Seitenelement packt, ersetzt Ihr OPI-Server zwar das im Hintergrund liegende Grobbild, das bringt aber rein gar nichts (außer einem größeren Datenvolumen), weil das grob aufgelöste, bei der Verflachung entstandene Bildobjekt deckend im Vordergrund liegt.

Sie können es also drehen und wenden wie Sie wollen, Sie müssen entweder manuell oder automatisiert (durch eien XTension oder wie auch immer) vor der Verflachung die Grobbilder in den Bereichen, in denen die Transparenzverflachung aktiv wird, die Grobbilder durch die hochaufgelöste Bilddaten ersetzten. Da die Bereiche, wo und wann QuarkXPress 7 verflacht, nicht ganz einfach vorauszusagen sind, ist es sicherlich nicht ganz trivial so eine XTension zu bauen, wenn man gleichzeitig für sich den Anspruch erhebt nicht unnötig viele bzw. sogar alle Bilder auf einer Seite auszutauschen, sobald auf der Seite Transparenz im Einsatz ist (was natürlich die Performance unnötig reduziert).

Antwort auf [ gremlin ]

da du so explizit auf quark rumreitest:
welche software ausser dem adobe pdf-maker in ms office tut dies denn noch?

Hallo Gremlin,

auch das ist ja nur ein Krücke und ein ein Workaround für einen fehlenden nativen PDF-Export so wie er in den Adobe Applikationen zum Einsatz kommt.
Der Workaround mit den pdfmarks wäre aber entwicklungstechnisch noch relativ leicht in den Griff zu bekommen. Einen nativen PDF-Export zu implementieren wenn die Basis nicht stimmt, ist dagegen eine ganz andere Herausforderung.

Hallo gremlin,

Antwort auf [ gremlin ]

da du so explizit auf quark rumreitest:

Kommt das so rüber? ;-)

Nee, im Ernst: Ich betrachte das als hoffentlich noch konstruktive Kritik, denn eigentlich bemühe ich mich schon, nicht nur rumzunörgeln sondern auch noch einen Vorschlag zur Verbesserung der Situation zu machen -- siehe eben den /SetTransparency-Operator, der mit verhältnismäßig geringem Aufwand seitens Quark das Problem für die relevanten Workflows (also wo ausgabeseitig fettere Workflows am Laufen sind, die von OPI oder auch nur vom Parsing des PostScript-Datenstroms, der aus Xpress herauskommt, abhängig sind) beheben könnte.

Antwort auf:

welche software ausser dem adobe pdf-maker in ms office tut dies denn noch?

Tut der das in Bezug auf Transparenzen? Ich dachte immer, dort wären die PDFMarks nur für strukturellen Kram wie Hyperlinks, Lesezeichen, etc. in Benutzung.

Naja, egal. Ich finde, es tut nichts zur Sache, welche andere Software das nutzt, denn der Knackpunkt ist der: Quark gibt den Gestaltern mit Xpress 7 Transparenzen in die Hand und vergißt dabei total diejenigen, die am Ende der Produktionskette stehen -- die, die den Kram mal ausgeben müssen (und auch wenn "OPI" ja angeblich so tot ist, kenne ich viele Installationen, wo ohne OPI erstmal gar nix mehr gehen würde)

Das ist IMO einfach Fakt.

Andererseits ist Fakt, daß andere Anwendungen, die Transparenz erlauben, das Problem nicht haben, da sie eben nativen PDF-Export hinbekommen (seien es Adobe-Produkte, die mittels Adobes PDF-Library direkt zu Werke gehen -- und dabei auch das ein oder andere Ding drehen, das in OPI-Workflows für massive Bauchschmerzen sorgt -- oder seien es auch Einsteiger-Lösungen wie iCalamus, die sich MacOS X' Quartz PDF-Export bedienen)

Solange also Quark keinen nativen PDF-Export bieten kann, fände ich es mehr als schick, wenn sie denn dann wenigstens die existenten Lösungen, Transparenzen durch den PS-Code durchzuschleusen, auch nutzen würden. Solange sie das nämlich nicht machen, klappen erstaunlich viele Ausgabestrecken hintenraus nämlich einfach zusammen, selbst wenn der Gestalter Transparenz in Xpress 7 nicht mal ins Spiel bringen wollte :-(

Antwort auf:

nicht dass wir uns falsch verstehen -- auch ich würde diese variante sehr begrüssen... vielleicht haben wir ja dann glück mit dem pdf-export in xpress 8 ;-)

Das reicht nicht. Quark hat die Gestalter mit dem Transparenzkram angefixt und die wollen das auch haben. Nur die auf der Ausgabeseite haben solange verloren, solange Quark Transparenzen eben nicht auch vollwertig unterstützt, d.h. entweder nativer PDF-Export oder Einsatz von PDFMarks (die übrigens neben Acrobat -- auch der kann Transparenzen inzwischen mit Umweg über PostScript retten, wenn auf der anderen Seite wieder ein aktueller Distiller werkelt -- noch von wenigstens einer anderen Software unterstützt werden, die ich aktuell betateste)

Was in meinen Augen keine echte Lösung ist, sind Ansätze wie von Herrn Zacherl beschrieben, die es Stand heute für InDesign schon gibt, bspw. http://macademy.de/produkte/opi/opi.html. Einerseits weil der PS-Code irrsinnig fett wird, andererseits weil dann im entstehenden PS-Code relevante Bild-spezifische Metadaten fehlen, die zumindest bei einigen meiner Kunden automatisiert aus PostScript-Druckjobs extrahiert bzw. manipuliert werden.

Gruss,

Thomas

hallo robert

dies ist mir durchaus bewusst.

Antwort auf [ Robert Zacherl ]

... Der Workaround mit den pdfmarks wäre aber entwicklungstechnisch noch relativ leicht in den Griff zu bekommen.

und genau deshalb wär doch die erwartungshaltung gegenüber quark einigermassen realistisch, nicht? ;-)

Hallo,

bin überrascht, dass ich so viele Antworten bekommen habe. Also so unwahrscheinlich finde ich das nicht mit einer XTension, deswegen habe ich das erwähnt. Es gab zu früherer Zeit auch Informationen, die Quark nicht ins PS geschrieben hat, dafür gibt es ja die HELIOS OPI TuneUp XT für Quark bis zur Version 6. Wenn es denn technisch möglich ist, das habe ich nun nicht geprüft, da seid Ihr bzw. Helios wahrscheinlich schon im Thema, erwarte ich auch eine XTension von dieser Firma, da die Interessen von Helios nur sein können, bestehende OPI-Kunden weiterzubehalten und zu pflegen.
Den Artikel über Transparenzen kannte ich und habe ihn auch gelesen. Aber Georg hält hier ja nur fest, dass es Probleme gibt ...

@Thomas Kaiser: hast du das schon bei helios angefragt? wenn nicht, mache ich dann mal ne email fertig.

Vielen Dank für Eure Antworten.

hallo thomas

Antwort auf [ Thomas Kaiser ]

Antwort auf [ gremlin ]

da du so explizit auf quark rumreitest:

Kommt das so rüber? ;-)

halb ;-) aber ich dachte dabei eigentlich nur, dass du wohl noch mehr softwares kennst, die dies tun. xpress ist ja nicht die einzige, die transparenz oder entsprechende effekte anbietet (... freehand? ... corel draw? ...?).

Antwort auf [ Thomas Kaiser ]

Ich betrachte das als hoffentlich noch konstruktive Kritik ...

du hast sorgen...! ;-) es ginge sowas von über meine vorstellungskraft, wenn deine kritiken nicht musterbeispiele von konstruktiver kritik wären!

Antwort auf [ Thomas Kaiser ]

Tut der das in Bezug auf Transparenzen?

tut er. aber frag mich nicht ab welcher version und in welchem umfang. office ist nicht meine lieblingsdisziplin ;-)

[ot]

Antwort auf [ Thomas Kaiser ]

... oder seien es auch Einsteiger-Lösungen wie iCalamus ...

calamus? das gibt's noch?? das kenn ich ja noch aus atari-zeiten :-D
[/ot]

Hallo Daniel,

Antwort auf [ Daniel Richter ]

Es gab zu früherer Zeit auch Informationen, die Quark nicht ins PS geschrieben hat, dafür gibt es ja die HELIOS OPI TuneUp XT für Quark bis zur Version 6.

Yo, bis einschl. 6.5.x kann man ja Xpress auch noch zusammen mit OPI benutzen. Und die Aufgabenstellung damals war ja eine verhältnismäßig simple, nämlich nur bei bestimmten Bildobjekten (Graustufen-/Strichbilder mit getrennt eingefärbtem Vorder-/Hintergrund, wenn ich mich recht entsinne) zusätzliche Kommentare im PS-Code einzubauen, damit diese Sachen, die in den OPI-Spezifikationen nicht vorgesehen waren, auch korrekt Richtung Grob-/Feindatenaustausch auf dem Server transportiert wurden...

Die Herausforderung bei Xpress 7 wäre nun die Folgende: Xpress selbst komplett die PS-Erzeugung abnehmen, denn Xpress will ja in jedem Fall die Transparenzreduzierung bei der Ausgabe vornehmen.

Was anderes wäre es, wenn Xpress 7 einen Schalter hätte, bei dem man "Transparenzen ignorieren" einschalten könnte. An der Stelle könnte wohl Helios megaaufwändig den Part der PDFMark-Generierung mit dranprogrammieren. Ist aber meines Wissens nicht der Fall... zumal kaum einsehbar ist, warum die im Vergleich zur Personalstärke von Quark paar Mannen in Garbsen die Hausaufgaben der 600 Mann in Indien übernehmen sollen, die Transparenz halt nur halbherzig umgesetzt haben (also rein auf der Gestaltungs-Seite gewerkelt aber wichtige Teile der Ausgabeseite vergessen haben)

Antwort auf:

Den Artikel über Transparenzen kannte ich und habe ihn auch gelesen. Aber Georg hält hier ja nur fest, dass es Probleme gibt ...

Drum hab ich ja hinzugefügt, daß die auch auf der aktuellen Basis (Xpress kann nur PS erzeugen und PDF wird immer erst daraus generiert, egal ob per Jaws oder Distiller) umschiffbar sind, wenn Quark denn wollte...

Antwort auf:

@Thomas Kaiser: hast du das schon bei helios angefragt?

Klar, erst letzte Woche in größerer Runde (auch) dieses Thema durchdiskutiert. Helios hat an der Stelle keinerlei Chance, irgendwo anzusetzen (nebenbei bemerkt: kein anderer OPI-Server-Hersteller dito). Was mich bisserl ärgert, ist, daß das selbst Helios-Fachhändler nicht zu begreifen scheinen, daß eben wahnsinnig viel von der Anwendung an sich abhängt hinsichtlich dessen, was anschl. in einem OPI-Workflow noch machbar ist (trifft leider genauso für InDesign zu)

Aber egal: Die halbscharig angegangene Transparenz-Angelegenheit in Xpress 7 trifft ja jeden Anwender, nicht nur Nutzer von OPI-Systemen. Oder hat sich noch keiner gewundert, wo die Transparenzen plötzlich hin sind wenn man ein Seitenelement in Xpress 7 gestaltet, als PDF ex- und woanders wieder importiert hat? Das kann's doch nicht sein...

Gruss,

Thomas

hmm, ok verstanden.
Das bedeutet aber für mich, dass ich meinen Anwendern sagen muss, dass Sie mit Quark 7 allgemein keine Layouts mehr einbauen?!
Oder gibt es möglicherweise eine Funktion oder XTension, die mir anzeigen kann, dass dieser Druckjob Transparenzen enthält? Oder per AppleScript?

Hallo gremlin,

Antwort auf [ gremlin ]

(PDF Maker für Microsoft Office)

Antwort auf [ Thomas Kaiser ]

Tut der das in Bezug auf Transparenzen?

tut er.

Nee, oder?

Darf eigentlich nicht wahr sein, daß eine für ihre Ausgabequalitäten wahrlich nicht sonderlich berühmte Textverarbeitung also Transparenzen mit Umweg über PostScript ins PDF rettet, die Profi-DTP-Software Xpress selbiges aber nicht schafft?? (OK, ich bin unfair -- der PDFMaker-Code stammt ja nicht von Microsoft ;-)

Aber eigentlich ist das schon ein Witz -- ein schlechter noch dazu...

Antwort auf:

[ot]
calamus? das gibt's noch?? das kenn ich ja noch aus atari-zeiten :-D
[/ot]

iCalamus. Komplett anderer Ansatz als die alte Version. Das alte Calamus hat alles selbst gemacht und quasi bis aufs letzte Belichterpixel alles unter Kontrolle gehabt. Das neue iCalamus ist in erster Linie Technologie-Demonstration der in MacOS X eingebauten Fähigkeiten der diversen Frameworks, denn iCalamus verläßt sich zu 100% auf das, was mit Cocoa möglich ist (und kann deshalb leider so gut wie nichts, was für einen Prepress-/Workflow-Kasperl wie mich oder jeden erfahrenen Xpress-User spannend wäre ;-)

Gruss,

Thomas

Hallo Daniel,

Antwort auf [ Daniel Richter ]

Das bedeutet aber für mich, dass ich meinen Anwendern sagen muss, dass Sie mit Quark 7 allgemein keine Layouts mehr einbauen?!

Naja, sie sollten halt nicht auf Grob-/Feindatenaustausch hoffen, wenn sie Grobdaten eingebaut haben, da -- wie Georg ja so schön beschrieben hat -- ja abhängig von aufgezogenen Rahmen Xpress der Meinung sein könnte, Transparenzreduzierung habe in gewissen Bereichen der Seite zu erfolgen.

Antwort auf:

Oder gibt es möglicherweise eine Funktion oder XTension, die mir anzeigen kann, dass dieser Druckjob Transparenzen enthält?

Bei Xpress 7 weiß ich es mangels Beschäftigung damit nicht. Bei InDesign musste ich das mal so lösen, daß der PS-Code geparsed wurde auf Bildobjekte, die nicht von den typischen, von InDesign selbst eingestreuten OPI-Kommentaren (»%ALDImageFileName«, »%ALDImageDimensions«, etc.) umschlossen waren -- so hatte InDesign vor paar Jahren Bildobjekte in den PS-Stream eingebettet, wenn Transparenzreduzierung zugeschlagen hat (aber bei InDesign ist das ja heute kein Thema mehr, jetzt wo man OPI auch auf PDF-Basis machen kann und InDesign sowie nativen PDF-Export beherrscht)

Antwort auf:

Oder per AppleScript?

Ich denke nicht, daß sich das in Xpress' Objektmodell niederschlägt (also man die Objekte befragen könnte, ob sie von Transparenzreduzierung betroffen sind oder nicht). Wenn Du Glück hast, zücken die Xpress-Scripting-Profis hier im Forum aber parallel das Xpress Scripting Dictionary und gucken nach ;-)

Ansonsten müsstest Du den exakten Algorithmus kennen, den Xpress für die Aktivierung des Flattening verwendet und dann von hinten nach vorne die Seitenobjekte per Skript durchgehen, um die Situation, wann Transparenzreduzierung bei welchen Objekten zuschlagen könnte, selbst durch das Skript ermitteln zu lassen.

Gruss,

Thomas

Antwort auf [ Thomas Kaiser ]

Nee, oder?

Darf eigentlich nicht wahr sein, daß eine für ihre Ausgabequalitäten wahrlich nicht sonderlich berühmte Textverarbeitung also Transparenzen mit Umweg über PostScript ins PDF rettet, die Profi-DTP-Software Xpress selbiges aber nicht schafft?? (OK, ich bin unfair -- der PDFMaker-Code stammt ja nicht von Microsoft ;-)

Hallo Herr Kaiser,

wenn Sie sich schon so oft wie Adobe anhören hätten müssen, wie "miese" PDFs der Acrobat Distiller aus MS Word & Co. generiert, dann hätten Sie sicherlich auch recht schnell angefangen darüber nachzudenken wie man die eine oder andere Ursache dieser Beanstandungen eliminieren kann. Da wir alle wissen, dass es weder am Distiller noch am PDF-Format liegt, musste man das Problem eben an der Wurzel packen.

Eine Ursache ist das aberwitzige Vorgehen des GDIs, wenn "transparente" Bilder im Office-Layout vorkommen. Dies führt dann im Extremfall zur Zerlegung von Bildder auf Bildzeilenebene und somit zu einem oder gar mehreren PDF-Bildobjekten pro Bildzeile, multipliziert mit der Anzahl der Bildzeilen. Dass das weder der PDF-Dateigröße noch der Bildschirmanzeige- und Ausgabeperformance zugute kommt ist jedem klar.

Deshalb bettet der VisualBasic Code des PDFMaker Makros an geeigneter Stelle pdfmarks in den vom Treiber generierten PostScript-Code ein, um den kritischen Seitenelementen auf PDF-Ebene echte Transparenz angedeihen zu lassen. Setzt natürlich die Ausgabe in PDF 1.4 oder neuer voraus.