Also ich habe mit meinem Drucker (Oki C321 Postcript) nun auch mal getestet und habe die gleichen Ergebnisse wie mit dem (virtuellen) CUPS-PDF Drucker.
So sieht meine Testseite mit libcupsfilters 2.1.1-4 auf dem Cups-PDF aus:
Das gleiche kriege ich mit dem realen Drucker.
Und so mit dem aktuellen libcupsfilters 2.2.1.r23.gdee3b387-1 auf dem Cups-PDF aus:
Der obere Teil ist nicht gerendert, fehlt, und der äußere schwarze Rahmen ist nach innen verkleinert. Gleiches Ergebnis mit dem Oki.
Cups wurde nach den Wechseln der Pakete logischerweise neu gestartet. Andere Test mit Querformat, Kopien oder Duplex(am Oki) spare ich mir.
Dirk Eventuell Treiber vs. IPP Everywhere?
Hmm, mein OKI geht noch über eine PPD Datei(die funktionierte immer tadellos, inkl. Duplex usw.). IPPe muß ich im Drucker-Setup erst einschalten. Aber das Argument sollte eigentlich beim Cups-PDF Drucker nicht gelten(?). Es sieht für mich ja nach einem Problem mit der Aufbereitung der Daten ins jeweilige vom Drucker akzeptierte Format aus (also ein cups filter problem).
Ich drucke real sehr wenig (schützt den Wald und so...), mein "Hauptdrucker" ist eigentlich der CUPS-PDF. Und wenn der funktionieren soll muß ich z.Z. halt auf die 2.1.1-4 zurückgehen (behalten, solange der Rest mit dieser Version mitspielt)
% pacman -Qs cups | grep \/
local/cups 2:2.4.19-1
local/cups-filters 2.0.1-3
local/cups-pdf 3.0.3-1
local/libcups 2:2.4.19-1
local/libcupsfilters 2.1.1-4
//Edit: IMHO hat das eher was mit dem verwendeten Filter zu tun, soweit ich weiß verarbeiten sowohl Cups-PDF als auch mein Oki in der aktuellen Konfiguration ihre Druckdaten nach/als Postscript (also wohl via ghostscript und Konsorten). Evtl. liegt das Problem hier (in Bezug auf die libcupsfilters Version). PCL (oder was auch immer) macht ggf. kein Problem, am Oki zumindest). Aber Postscript ist halt immer noch (der)/ein renommierter Standard, früher(tm) war man "König" mit einem Postscript-fähigem Drucker (egal ob Windows, Linux, Mac...)