beschriebene Problem, habe ich eben beschlossen, meinen Fix fürs Problem zu veröffentlichen (weil ich alle Hoffnung fahren gelassen habe, daß Quark da was Vernünftiges rausbringen wird -- siehe weiter unten)
* Drei klitzekleine CUPS-Backends installieren, die für Distiller 6, 7 und 8 zuständig sind (wenn die entsprechende Distiller-Version nicht auf dem Mac aktiv sind, bleibt das Backend inaktiv)
* Wenn ein "Distiller-Drucker" bereits eingerichtet ist, für diesen einen neuen gleichlautenden Drucker anlegen, der noch die Ergänzung "(Xpress 7.x Distiller-Fix") im Namen trägt. Es wird auch die selbe PPD genutzt wie für den korrespondierenden Distiller-Drucker
Das Ganze sieht dann anschl. bspw. so aus wie in beigefügtem Screenshot.
Was hat man anschließend? Die Möglichkeit, wieder direkt aus Xpress 7.x heraus "direkt in den Distiller" zu drucken, indem man die gefixten Varianten benutzt (Handhabung 1:1 wie beim originalen Adobe-PDF-Drucker: D.h. Joboptions im Druckdialog auswählen, dito Speicherort des PDF -- wenn hier was nicht klappt, dann ist eine falsche PPD ausgewählt worden).
Was geschieht dabei im Hintergrund? Xpress erzeugt wie gehabt eine temporäre Datei, schiebt die ins Drucksystem und mein Backend wird dann mit dem Pfad zu dieser Datei aufgerufen. Mein Backend verschiebt dann die temporäre Datei an eine sichere Stelle, ruft Adobes Backend auf und fertig.
Wer sollte das Ganze einsetzen? Eigentlich jeder, der direkt den Distiller aus Xpress heraus nutzen will (zu den Risiken und Nebenwirkungen des Ganzen hinsichtlich "PDF-Boxen" gibt es ja geteilte Meinungen) und nicht auf den "offiziellen Fix" seitens Quark warten will. Ich will das definitiv nicht mehr, denn abgesehen davon, daß der eh erst mit Xpress 7.3 funktionieren kann, so wie es Quark aktuell vorhat, bemüht sich Quarks Lösung redlich alle Nachteile der beiden in
skizzierten Ansätze zu vereinigen (also ab 7.3 wieder PS-Datei mit anderem MIME-Type spoolen und diesen dann von einem Mini-CUPS-Filter einlesen und an "standard out" Richtung Adobe Distiller duplizieren).
Warum Quark das Problem mit 7.3 nicht einfach aus der Welt schafft, wenn sie eh nur vorhaben, einen Fix anzubieten, der ab 7.3 funktioniert, will mir zwar nicht in den Kopf. Ist mir inzwischen aber auch egal, da ich dem Spielchen "Gratis-Consulting Richtung Quark" nicht mehr allzu viel abgewinnen kann.
Obige Lösung funktioniert jedenfalls mit jeder Xpress 7.x Version und ohne Performance-Einbußen wie die Quarksche. Dafür halt mit dem ästhetischen Makel, daß je installiertem "AdobePDF"-Drucker noch eine zusätzliche Queue im Druckdialog auftaucht (diese kann aber aus jeder Anwendung heraus und nicht nur Xpress genutzt werden)
Das funktioniert. Ausgehend vom ersten Ansatz, den wir in einem Parallelthread besprochen haben, habe ich die Backends (eben für jede Distiller-Version eine -- geht beim Backend-Ansatz nicht anders) so umgebaut, daß sie Xpress' temporäre PostScript-Datei nicht per "stdout" Richtung Distiller werfen, weil das ja nur für noch eine weitere temporäre Datei sorgt (so will Quark das aber jetzt allen Ernstes "lösen") sondern einfach die Datei mit korrekten Berechtigungen versehen und dann an Adobes Distiller-Backend übergibt.
Bernhard Werner hat mir sehr viel geholfen, diese erste vernünftige Version zu programmieren, indem er den Tester spielte. Der eigentliche Installer ging dann an die Moderatoren-Riege des Xpress-Forums hier auf HDS und von denen, die getestet haben, kam positive Rückmeldung. Ich gehe also davon aus, daß das problemlos funktioniert.
Man sollte aber vor Installation des Ganzen drauf achten, daß man Adobes Distiller-Backend installiert und einen entsprechenden "Adobe PDF" Drucker eingerichtet hat (am Besten einfach Acrobat und Distiller vorher anwerfen, dann sorgt Adobes "Self Heal" Mechanismus dafür, daß alles paßt).
Man kann anschl. auch Adobes originalen Drucker umbenennen und das Häkchen wegnehmen, daß der in den Druckmenüs auftauchen soll und dann einfach generell über "meinen" Adobe PDF Drucker ausgeben (auch aus anderen Anwendungen als Xpress -- schadet quasi nix)
Denn: In meinem Backend ist noch ein Fix drin: Falls man nicht mit Adobes Printer Dialog Extension arbeiten will, d.h. den Fragedialog vermeiden möchte, der normalerweise jedesmal aufpoppt und nach dem Speicherort der PDF-Datei fragt, dann rennt man leicht in ein altes Problem des Distillers. Wenn der nämlich auf Druckjobnamen stößt, die ein "/"- oder ":"-Zeichen enthalten, dann verweigert er die Mitarbeit. Deswegen filtert mein Backend derlei Zeichen und ersetzt sie im Namen der PS- bzw. PDF-Datei durch Unterstriche.
Beitrag