Servus Bernhard,
Antwort auf: ohne es getestet zu haben, gibt es (für mich) noch drei unschöne Dinge:
- der Distiller muss immer laufen/gestartet sein
- die erzeugte PDF-Datei wird nicht direkt nach dem Distillen geöffnet
- die erzeugte PDF-Datei tummelt sich in irgendwelchen Hotfoldern
Oder sehe ich das falsch?
Nö, alles korrekt. Aber ein paar Anmerkungen:
1. Der Distiller muß aktuell laufen und im Hotfolder-Betrieb agieren (zur Erinnerung: Ich hab die Lösung zu einem Zeitpunkt programmiert, als gerade 10.2 frisch rausgekommen war, ein paar Verrückte schon unter MacOS X mit DTP-Anwendungen gearbeitet haben aber der Distiller nur in der Classic-Umgebung zur Verfügung stand --> genau dafür und für paar anschl. hinzugekommene Anforderungen war dieser Hotfolder-Modus gedacht)
Es gibt dazu Alternativen, d.h.
* Distiller selbst ansteuern und ihm Pfad zu PS-Datei und Settings direkt übergeben (hat ein Anwender mal gemacht, weil in irgendeiner Kombi aus Distiller und MacOS X die Hotfolder nur sehr schleppend liefen). Anbei Dieter Mays Skript ("Ordneraktion", d.h. auch nur Hotfolder aber eben mit MacOS X Bordmitteln anstatt Distiller-Bordmitteln), unkommentiert und ungetestet -- das Wesentliche fürs Verständnis bzgl. Distiller-Aufruf kann man sich aber rauspuhlen:
property PDF_Settings : "/PDF/Settings/PDF_Settings/DIGI.joboptions"
property KeepPS : false
on adding folder items to this_folder after receiving these_items
repeat with i from 1 to number of items in these_items
set this_item to item i of these_items
set PosixFile to («event SystPsix» of this_item)
if (this_item as text) ends with ".ps" then
tell application "Acrobat Distiller 6.0.2"
Distill adobePDFSettingsPath PDF_Settings sourcePath PosixFile
set s to the result
end tell
if KeepPS is false and s is true then
set theCommand to "/bin/rm -f " & (quoted form of (POSIX path of this_item))
do shell script theCommand
end if
end if
end repeat
end adding folder items to
* Dann gäbe es die Möglichkeit, die DistillerLib zu nutzen, so wie es bspw. Helios macht -- dafür muß der Distiller als Anwendung nicht klassischerweise laufen sondern es wird einfach ein eigenes Progrämmchen gegen die Lib gelinkt und die Distiller-Funktionalität ausgeliehen. Das werde ich aber nicht machen, da man dazu mit C oder anderen Hochsprachen agieren müsste aber das CUPS-Backend ein simpel zu durchblickendes Skript bleiben soll.
* Dann schließlich gäbe es die Möglichkeit, aus dem Backend heraus Adobes pdf- (Distiller 6 oder 7) bzw. pdf800-Backend (Distiller 8) anzusteuern. Nur wozu? Die Funktionalität hat man ja heute auch schon so (wenn sie denn funktionieren würde -- siehe weiter unten)
2) Mit ein Feature des Distiller-Hotfolder-Ansatzes ist ja, daß man nicht bei jedem Druckvorgang von der Adobe-PDE genervt wird, die fragt, wohin die PDF-Datei gespeichert werden soll (wichtig, v.a. für automatisiertes Drucken per Skript, wo einem die "Printer Dialog Extension" jedesmal in die Suppe spucken würde). Wenn man die Ziel-Datei nicht im Hotfolder haben will, kann man ja am Ende von meinem Backend einfach ein Postprocessing-Skript aufrufen lassen, daß das PDF sonstwohin verschiebt (in der Version, die ich jetzt gerade baue, alternativ zu Unix-Skripten auch mittels Automator-Workflows, d.h. Nutzer von MacOS X ab 10.4 können sich nahezu beliebige Funktionalität in Automator zusammenklicksen und die dann automatisch vom Backend im Anschluß ausführen lassen (bspw. PDF kopieren oder PDF zippen lassen und irgendwohin mailen oder Bilder in PDF komprimieren und Wasserzeichen drauf setzen, PDF in Acrobat öffnen lassen, etc. etc.)
Zur Vertiefung:
Apfelwiki-Artikel, v.a. Links am Ende checken
3. Was Du offensichtlich willst, ist schlichtweg Adobes PDF-Erstellung in funktionierend, oder? Also daß Du nach dem Speicherort gefragt wirst, die DistillerLib im Hintergrund die Arbeit übernimmt und anschließend das PDF in Acrobat geöffnet wird?
Falls ja, dann soll das halt Quark und/oder Adobe fixen. Ich meine, es ist ja schon ein Witz... da haben die ersteren 600 Mann in Indien sitzen und die letzteren alleine 1100 für Acrobat (auch in Indien)... und die scheitern an so einer Trivialität? [;)]
Wie im Thread schon angemerkt:
* Quark schiebt die entstandende PS-Datei wohin, wo sie eigentlich nach meinem Wissen gar nicht hin sollte (direkt ins Spool-Verzeichnis und nicht in CUPS' $TempDir)
* Dann wird die PDF-Datei nicht an stdin beim pdf-Backend von Adobe abgeliefert (was Adobe den schwarzen Peter zuschieben würde, sich um den weiteren Ablauf inkl. passender Permissions, etc. zu kümmern) sondern als zus. Dateiargument
* Das Adobe-Backend prüft seinerseits nicht die Berechtigungen der temporären Datei und fällt auf die Nase
Quark könnte das
einen Neustart überdauernd fixen, indem sie so ein StartupItem, wie hier im Thread schon von mir aufgemalt, ins Spiel bringen würden.
Oder sie würden ein Mini-CUPS-Backend ins Spiel bringen, das von der reinen Funktionalität her wirklich nur eine Zeile Code enthalten müsste:
if [ $# -ge 5 ]; then cat "$6" | "$(dirname "$0")"/pdf800 "$1" "$2" "$3" "$4" "$5" && rm "$6"; fi
und schon würde das Permission-Problem nur noch alleine Sache von Adobe bzw. gelöst sein, weil besagte seltsame Konstellation gar nicht mehr auftreten könnte...
Oder Adobe würde innerhalb ihres pdf/pdf800-Backends
vorher einfach prüfen, ob ein übergebenes Spoolfile überhaupt die für ihre eigenen Weiterverarbeitungs-Mechanismen nötigen Berechtigungen aufweist und diese dann halt in Herrgottsnamen ebenfalls
vorher korrigieren. Das ist doch alles keine Hexerei sondern eigentlich nur ein Klacks.
Obiger Einzeiler könnte natürlich leicht modifiziert auch aus meinem Backend aus als Postprocessing-Mechanismus aufgerufen werden. Würde dann vermutlich auch einen Workaround für das Problem mit dem nicht funktionierenden Standardweg, PDF aus dem Druckdialog per Distiller zu erstellen, darstellen.
Wie auch immer... ich denk mal drüber nach und bin gespannt, ob Dave von Quark sich diesbzgl. äußert (hab im US-Forum mal nachgefragt)
Gruss,
Thomas
