Re: Drucken funktioniert nicht gut
Am 12.08.22 um 14:08 schrieb Dirk S.:
[...]
> Als Drucker habe ich einen Netzwerkdrucker Lexmark X544dw.
>
> Der hat jahrelang klaglos seinen Dienst getan. Tut er auch heute noch,
> allerdings:
>
> Unter Debian (zur Zeit stable), und nur darunter, braucht er für das
> Drucken einer Seite mitunter bis zu fünf Minuten. D.h., er denkt,
> druckt, denkt wieder, druckt wieder ususf. Egal aus welcher
> Software. IMHO liegt das an CUPS, vielleicht an der zugehörigen PPD
> (welche ich seit Jahren unverändert nutze). Ich kann nur leider nicht
> erkennen, woran es konkret liegt, denn:
> - Testausdrucke kommen quasi sofort
> - Ausdrucke z.B. von Texten aus Libreoffice dito
> - Das Problem betrifft in erster Linie *PDF* (auf die ich keinen Einfluß
> habe), und da ist es unabhängig davon, aus welcher Software heraus
> ich drucke (z.Zt. nutze ich Evince, habe aber qpdfview auch
> installiert, damit tritt es auch auf). Drucke ich diese PDF aus Win,
> so werden sie genauso wie alles andere "on demand" sofort gedruckt.
>
> Jemand eine Idee, worin das Problem liegen könnte?
Nein, aber eine Idee, wie Du es debuggen könntest.
Leite den Ausdruck der PDFs in eine Datei um. Entweder aus der Anwendung
heraus oder in CUPS:
Verwaltung->Drucker ändern->AppSocket/HP JetDirect->socket://localhost:9100
Merk Dir bitte vor dem Speichern die zuletzt eingestellte Verbindung,
vermutlich steht da so was wie socket://deine-drucker-ip:9100 oder
lpd://deine-drucker-ip/lp
Nachdem Du das geändert hast, lässt Du bei Dir lokal netcat laufen:
nc -l -p 9100 -q 2 >/tmp/spoolfile.prn
Und während das in einer Shell läuft, setzt Du den Druckauftrag über die
Anwendung und CUPS ab.
Danach wäre dann
file /tmp/spoolfile.prn
interessant, um zu erfahren, welche Sprache CUPS mit Deinem Drucker
reden will (PCLirgendwas, PostScript 2 oder 3, oder gar native PDF).
Laut Webseite spricht der Lexmark X544dw: "PDF 1.6 Emulation, PCL5c
Emulation, PCL 6 Emulation, Persönlicher Druckerdatenstrom (PPDS),
PostScript 3-Emulation, Direktes Bild"
(Die Übersetzungen sind grausig, aber egal)
Du kannst dann als nächstes schauen, ob der Druck immer noch so lange
dauert, wenn Du das Spoolfile direkt an den Drucker schickst.
Laut Webseite beherrscht er: "LPR/LPD, Direkte IP (Port 9100), IPP 1.1
(Internet Printing Protocol), FTP, TFTP, Erweiterte IP (Port 9400)"
Interessant ist dabei Port 9100. Wenn Du das nicht am Drucker abgestellt
hast, kannst Du das Spoolfile ebenfalls mit netcat von der Kommandozeile
aus an den Drucker schicken:
cat /tmp/spoolfile.prn | nc -q 2 deine-drucker-ip 9100
Falls Du nur per lpr/lpd drucken kannst, solltest Du Dir das Paket rlpr
installieren und dann:
rlpr -Hdeine-drucker-ip -Plp /tmp/spoolfile.prn
als Befehl verwenden.
Dauert es da genauso lange, dann ist es wirklich der Drucker, der da
"nachdenkt", bzw. Dein Netz gibt halt nicht mehr her.
Da der Drucker nativ PDF bis Level 1.6 spricht, kannst Du auch noch
probieren, statt /tmp/spoolfile.prn ein PDF mittels des obigen Befehls
(nc bzw. rlpr) zu senden - ganz ohne CUPS dazwischen, sofern das PDF
keinen höheren Standard hat.
Genauso kannst Du mit pdf2ps versuchen, eine PostScript-Datei aus dem
PDF zu erzeugen, und diese dann mit nc bzw. rlpr an den Drucker senden.
Auch da wäre dann wieder interessant, ob sich die Druckdauer ändert.
Und für alle Dateien kannst Du Dir natürlich auch noch mit
ls -lah dateiname
anzeigen lassen, wie groß sie sind.
Eventuell bläht CUPS ja den Druckjob unnötig auf, und deswegen dauert
die Übertragung so lange.
Gruß
Stefan
Reply to: