Hallo,
kurzes Followup nach langer Zeit, weil ich da gestern mit Bernhard Werner kurz drüber diskutiert habe...
Das wäre vermutlich gar nicht so falsch, wenn Quark noch einen Unterordner weiter stolpern würde, d.h. nach /private/var/spool/cups/tmp oder wo auch immer CUPS' "TempDir"-Variable aktuell hinzeigt. Siehe die Ausgabe von
powerbook-tk:~ tk$ grep "TempDir" /etc/cups/cupsd.conf
# TempDir: the directory to put temporary files in. This directory must be
#TempDir /private/var/spool/cups/tmp
und die Anmerkungen in den CUPS Manuals:
http://www.cups.org/doc-1.1/spm.html#4_1_1 Unglücklicherweise sind die Standard-Zugriffsrechte auf dieses Verzeichnis recht restriktiv (710) und ganz offensichtlich zu restriktiv als dass die Acrobat Distiller Library ihrem Job nachkommen könnte, was zum Scheitern der PDF-Erzeugung führt. Schon erstaunlich, daß das bei Quark bis heute niemand gemerkt zu haben scheint und dort niemand daran denkt, daß da was schief laufen muß, wenn man ein Spoolsystem, das partiell auf root-Berechtigungen aufsetzt mit einem Prozeß zur PDF-Erzeugung verheiraten will, der im Kontext des lokal angemeldeten Benutzers läuft. Für solche Sachen wäre die Ablage temporärer Dateien unterhalb /Users/Shared eigentlich prima geeignet. Oder auch unterhalb /tmp mittels mktemp(3).
Gott sei Dank ist das Problem aber, nachdem es erkannt ist, leicht lösbar. Man passt einfach die Zugriffrechte des obigen Ordners an. Durch Eingabe vonsudo chmod 755 /private/var/spool/cups
im Terminal und Eingabe des Administrator-Passworts werden die Zugriffsrechte so angepasst, dass nun der Distiller Zugriff auf die Daten bekommt und diese wie gewohnt konvertieren kann. Nur hat das ganze zwei Nachteile: Zum einen scheint der CUPS Scheduler bei jedem Neustart die Rechte des Verzeichnis wieder neu zu setzen -- kann man Ausprobieren, indem man ihm ein "SIGHUP"-Signal schickt und sich die Berechtigungen anschließend anschaut:
D.h. wenn dann müsste man die Änderung der Verzeichnisrechte in oder nach Apples CUPS-Aufruf-Skript unterbringen, also an zwei Stellen in /System/Library/StartupItems/PrintingServices/PrintingServices den chmod-Befehl einfügen und darauf hoffen, daß Apple niemals eine neue Version der Datei mit einem Systemupdate ausliefert oder ein eigenes StartupItem als bspw. "Xpress7PDFCreationPermissionFix" in /Library/StartupItems legen, das in seiner StartupParameters.plist Property List das da enthält:
{
Description = "Xpress 7 PDF creation permission fix";
Provides = ("Xpress7PDFCreationPermissionFix");
Requires = ("PrintingServices");
Uses = ("NetworkTime", "Resolver");
OrderPreference = "Last";
Messages =
{
start = "Applying Permission Fix for Xpress 7 PDF creation";
stop = "Nothing to do";
};
}
und als ausführbares Skript "Xpress7PDFCreationPermissionFix" dann eben nur
#!/bin/sh
chmod 755 /private/var/spool/cups
Zum anderen halte ich lasche Berechtigungen für das CUPS-Spoolverzeichnis grundsätzlich für keine so gute Idee, da die diversen CUPS-Exploits in der Vergangenheit immer wieder gezeigt haben, daß es eben auch in solchen Komponenten wie dem Spoolsystem immer wieder auszunutzende Lücken gibt. Und da zumindest ein Teil des Spoolsystems mit vollen root-Berechtigungen läuft (laufen muß), können die Konsequenzen fatal sein. Siehe bspw.
http://labs.idefense.com/...es/display.php?id=30 Zum Punkt PDF-Erzeugung aus PS-Datei direkt aus Xpress heraus per Druckdialog (was ja nicht so prickelnd sein soll, wenn man nicht Erweiterungen von Impressed oder Jo Lauterbach nutzt), fällt mir aber ein, daß man den hier als "Virtual Printer" bekannten Ansatz benutzen könnte. Der kann ja schon immer Distiller Hotfolder direkt erkennen und stellt die als stinknormale Drucker zur Verfügung in die dann auch direkt per Druckdialog hineingedruckt werden kann.
Kann man aber mit Xpress eh vergessen, oder? Da kommt man über den "intuitiven" Umweg "PDF-Export", wenn man eine PS-Datei will, eh nicht drumherum, weil sonst Informationen im PS-Code fehlen?
Gruss,
Thomas