So,
das ist alles sehr lustig (wenn man nicht direkt davon betroffen ist).
Der Unterschied zwischen dem PS-Code von 10.5.4 und 10.5.5 auf Intel ist wie Folgt: Bei 10.5.4 wird der PS-Code, der die Applesche Papierformat-Definition enthält, vor der Adobeschen Adobe_AGM_Utils-Funktion aufgerufen, die die Custom Paper Size definiert. Bei 10.5.5 ist es genau umgekehrt -- siehe ganz unten [1]. Schuld daran ist wohl irgendeine Änderung im CUPSschen pstops-Filter, der unter 10.5.4 noch so und unter 10.5.5 ganz anders agiert.
Das eigentlich Lustige ist aber der PS-Code von 10.5.5 PPC. Hier geschieht etwas völlig anderes und der pstops-Filter kommt überhaupt nicht zum Einsatz. Denn hier schickt InDesign nicht reines PostScript (application/postscript) ins Spoolsystem sondern "PICT with embedded PostScript" (application/pictwps). Dieses wird dann auch nicht vom pstops-Filter verarbeitet sondern von Apples pictwpstopsfilter, der auch in 10.5.5 noch für die korrekte Reihenfolge der Papierformat-Definitionen sorgt (erst Apple bzw. PPD, dann Adobes Custom Paper Size). Wen der PS-Code interessiert, siehe [2].
Die Unterschiede beim Durchlaufen des Spoolsystems sind wie folgt (laut /var/log/cups/error_log:
Was übrigens auch bedeutet, daß auf dem PPC-Rechner der Workaround für die kaputten Job-Titles, wenn Umlaute im Dateinamen enthalten waren, überhaupt nicht aufgerufen wird (im obigen Beispiel wird der fixidcs3jobtitle-Filter aufgerufen, der dann seinerseits den pstops-Filter aufruft, nachdem er Adobes krankes Dateinamen-Encoding repariert hat (siehe
http://kaiser-edv.de/...ostscript-title.html)
@Yann: Haben die PPC-Macs bei Euch kein Problem mit Umlauten im Dateinamen von ID CS3 Dateien?
Gruss,
Thomas
[1] Unterschiede im PS-Code zwischen MacOS X Intel 10.5.4 und 10.5.5 hinsichtlich Custom Paper Size:
10.5.4
10.5.5:
[2] PostScript-Ausgabe via pictwpstopsfilter aus 10.5.5 PPC: