Der Drucker ist ein HP 1320; auf der Herstellerseite steht:
"Standarddruckersprachen: HP PCL 6, HP PCL 5e, HP Postscript Level 2 Emulation" 
Aha. Es könnte(!) evtl. daran liegen, dass das eine Programm ziemlich schlanken PostScript-Code schickt (schnell) und das andere die Daten als Grafik (langsam). Vergleichbar mit Vektorgrafik direkt (kleine Datei) als Bitmap gerastert (grosse Datei).
Zum ersten mal ist mir das Problem allerdings aufgefallen, als ich eine .pdf-Datei, die ich mittels pdfmergeX erstellt (verkleinert) hatte, drucken wollte, und das ewig gedauert hat. Das Drucken von Teilen der viel größeren original Datei ging ohne Probleme, weshalb ich auf einen Zusammenhang mit dem pdfmergex schloß.
Könnte gut sein. Es kommt darauf an, wie das Verkleinern funktioniert. Evtl. wird aus der "kleinen (Dateigrösse)" PostScript-Datei eine Bitmap gerendert, verkleinert und dann in eine PDF gepackt, was dann eine grosse (Dateigrösse) PDF erzeugt.
Wie kann man denn mit pdfmergex verkleinern? Ich sehe da nur Funktionen zum Zusammenfügen?
Daß das jetzt bei Ragtime auch auftritt....
Sicher, dass das erst jetzt auftritt?
Bei allen RagTime-Dokumenten?
Das einzige, was irgendwie geändert wurde (außer der Installation von pdfmergex), war ein Softwareupdate auf 10.4.10 bzw. Security Update.
Kann ich mir als Grund auf Anhieb so nicht vorstellen, denn warum sollte ein Systemupdate RagTime veranlassen deutlich grössere Dateien zu schicken? Ausser es tritt dort so ein Problem mit einer fehlerhaften Versionabfrage von .10 auf, wie sie mbs für einige Programme andeutete.
Ich werde vielleicht morgen ein paar Druck-Tests machen, vielleicht läßt sich das Problem eingrenzen (z.B. den Drucker direkt an den Rechner anschließen).
Kann mir nicht vorstellen, dass das das Problem ist. Sicherlich wird der Effekt lokal nicht so stark sein (evtl. auch kaum beobachtbar sein), weil Du dann die grössere Datenmenge nicht übers Netzwerk und dann USB 1, sondern direkt über USB 2(?) schicken kannst.