Sonntag, September 13, 2009
Druckaufträge von der Kommandozeile aus verwalten
Gerade würgt sich mein HP Laserjet 1300 - immerhin ein Postscript-Drucker mit einem RAM-Upgrade - durch einen Druckauftrag, den ich aus Adobe Acrobat 9 ausgelöst habe. Da für den Druck einer Seite etwa 10 Minuten vergehen (!), wurde mir die Sache zu blöd und ich suchte nach Möglichkeiten, den Druckauftrag zu löschen.
Da er unter Mac OS X bereits an den Druckerserver raus ist, muss ich Linux und lprng bemühen. Wie es sich herausgestellt hat, ist die Verwaltung von Druckjobs äusserst simpel - wenn man denn weiss, wie:
Druckerwarteschlange anzeigen
# lpq -Plaserdrucker Printer: Laserdrucker@ALPHA 'HP Laserjet 1300' Queue: 2 printable jobs Server: pid 26486 active Unspooler: pid 26487 active Status: waiting for subserver to exit at 00:51:43.257 Rank Owner/ID Pr/Class Job Files Size Time stalled(672sec) mario@beta+327 A 327 657247.pdf 19804211 00:41:08 2 mario@beta+514 A 514 657247.pdf 8249902 00:47:05 done mario@beta+970 A 970 studium:glossar-fra 326256 16:17:30
19804211 Bytes? 19 MB sind viel, kommen aber offensichtlich hin, denn ich drucke einen 18-seitigen Scan eines Artikels, den ich auf JSTOR gefunden habe.
Druckauftrag löschen
Um einen Druckauftrag in der Warteschlange zu löschen, muss man sich die Zahl unter Job merken und gibt anschliessend auf der Kommandozeile folgendes ein:
lprm -Plaserdrucker 327 Printer Laserdrucker@ALPHA: checking perms 'mario@beta+327' dequeued 'mario@beta+327'
Quelle: In Unix, how do I print files and list or remove print jobs?
Donnerstag, Juli 30, 2009
Kreativ mit HP Tintenstrahldruckern
HP - invent from Tom and Matt on Vimeo.
Geniales Video. Aber garantiert nur bis zu dem Zeitpunkt, als die Jungs die Rechnung für die Tintenpatronen gekriegt haben ...
Nachtrag: ... und Scannern!
Donnerstag, Juli 02, 2009
lprng debuggen
Gerade habe ich eine Stunde mit debuggen von LPRng verbracht, bis ich schlussendlich feststellen musste, dass das angebliche Druckerproblem mit einem Kaltstart des Druckers (!) gelöst werden konnte.
Dennoch ist es für die Nachwelt sicherlich von Interesse, wie man LPRng im speziellen und Druckerprobleme unter Linux im allgemeinen debuggt.
lprng ausschalten
Damit man ungestörten Zugriff auf den Parallelport hat, schaltet man kurzerhand den von Debian automatisch geladenen Druckserver aus:
# /etc/init.d/lprng stop
Module überprüfen
Anschliessend überprüfen wir grundlegend, ob die Parallelporttreiber geladen wurden:
$ lsmod | grep lp lp 11076 0 parport 34280 2 lp,parport_pc
Berechtigungen des Parallelports
$ ls -l /dev/lp0 crw-rw---- 1 root lp 6, 0 2009-07-02 13:07 /dev/lp0
Sieht gut aus. Falls der Port nicht existiert, legt man in anhand einer anderen auf diesem Blog publizierten Anleitung an.
Auf Parallelport drucken
# cat sample.ps > /dev/lp0
ACHTUNG: Drucker, die kein Postscript sprechen (würde ich nie mehr in meinem Leben anschaffen!), werden seitenweise kryptische Codes ausdrucken. Eine Beispieldatei im Postscript-Format findet sich unter samplec.ps
In meinem Fall beendete sich dieser Befehl auch nach 20 Sekunden nicht, weshalb ich ihn mit Ctrl+C von Hand abbrechen musste (ansonsten hat man nach 1-2 Sekunden wieder freie Hand, sofern die Postscript-Datei nicht gerade 50 MB gross ist ...). Hier ging mir plötzlich ein Lichtlein auf, dass das Problem wohl nicht am Druckserver selber zu suchen war, sondern irgendwo an oder zwischen dem Drucker und dem Server lag.
lprng debuggen
Wenn bis hierhin alles geklappt hat, muss das Problem wirklich an lprng liegen. Deshalb starten wir den Druckserver im Debug-Modus:
# lpd -F -D1 >&/tmp/lprng.debug &
Ich habe Werte für D von 1, 2 und 9 ausprobiert, hat alles geklappt. In /tmp/lprng.debug werden alle Statusmeldungen akribisch aufgelistet. Anhand dieser ist es im Zusammenspiel mit Google möglich, andere Leidensgenossen zu finden und eventuell sogar die Lösung des Problems präsentiert zu erhalten.
Samstag, Februar 28, 2009
HP Laserjet 1300 im Alltagsgebrauch (2)
Aus aktuellem Anlass (Toner leer) habe ich mir die Mühe genommen, die Kenndaten über meinen getreuen Schwarzweiss-Laserdrucker HP Laserjet 1300 zu aktualisieren. Die ersten Findings wurden im Dezember 2006 veröffentlicht.
Chronologisches
- Kaufdatum: 19. April 2004
- In meinem Besitz: 58 Monate
Druckvolumen
- Total 13'861 Seiten gedruckt
- 238 Seiten/Monat
- 8 Seiten/Tag
Kosten
- Gerät: 412.00 SFr.
- Toner 1: 118.00 SFr. (31. März 2005)
- Toner 2: 119.00 SFr. (27. Dezember 2006 - Druckvolumen: 3072 Seiten in 235 Jobs)
- Toner 3: 113.90 SFr. (29. Dezember 2008)
- Total: 763.00 SFr.
- Seitenpreis: 5.50 Rappen (ohne Blattkosten)
Wichtige Artikelnummern
- Q2613A - Toner für 2'500 Seiten
- Q2613X - Toner für 4'000 Seiten
- Q1887A - 64MB SDRAM DIMM
- Q2485A - Papierschacht für 250 Blatt
Donnerstag, Februar 26, 2009
Xerox Phaser 6300DN druckt nicht unter Mac OS X 10.4.11
Auf der Arbeit ging nach der Installation der neuesten Druckertreiber für einen Xerox Phaser 6300DN unter Mac OS X 10.4.11 gar nichts mehr: Druckaufträge wurden zwar CUPS übergeben und das Druckericon verschwand auch prompt wieder aus dem Dock. Doch der Netzwerkdrucker spuckte nichts aus!
Nachdem ich das Problem auf einem dritten Mac mit demselben Betriebssystem reproduziert hatte, begann das Debugging. Von einem Mitarbeiter wusste ich bereits, dass Druckaufträge a) von Mac OS X 10.5-Computern und diesem Treiber problemlos gedruckt wurden sowie b) Druckaufträge mit dem Generic Postscript Driver unter Mac OS X 10.4.11 auch funktionierten. Das Problem konnte also schlüssig auf einen fehlerhaften Treiber von Xerox, der Mutter aller Kopierer und Drucker, eingeschränkt werden.
Nachdem ich in /etc/cupsd.conf
LogLevel debug
gesetzt und den Mac-Druckserver neu gestartet hatte, fanden sich in Console.app in der Datei /var/log/cups/error_log weiterführende Informationen:
I [23/Feb/2009:14:48:26 +0100] Adding start banner page "none" to job 519. I [23/Feb/2009:14:48:26 +0100] Adding end banner page "none" to job 519. I [23/Feb/2009:14:48:26 +0100] Job 519 queued on 'Xerox_Phaser_6300' by 'mario'. I [23/Feb/2009:14:48:26 +0100] Started filter /usr/libexec/cups/filter/cgpdftops (PID 1322) for job 519. I [23/Feb/2009:14:48:26 +0100] Started filter /usr/libexec/cups/filter/pstops (PID 1323) for job 519. I [23/Feb/2009:14:48:26 +0100] Started filter /Library/Printers/Xerox/PDEs/pstophaserps (PID 1324) for job 519. I [23/Feb/2009:14:48:26 +0100] Started backend /usr/libexec/cups/backend/socket (PID 1325) for job 519. E [23/Feb/2009:14:48:26 +0100] PID 1324 stopped with status 2! I [23/Feb/2009:14:48:26 +0100] Hint: Try setting the LogLevel to "debug" to find out more.
Als ich mich zusätzlich an localhost:631/printers/ wandte und auf den entsprechenden Drucker klickte, sah ich auch dort die ähnliche Meldung
Description: Xerox Phaser 6300 Location: Printer State: idle, accepting jobs. "The process "pstophaserps" stopped unexpectedly with status 2" Device URI: socket://10.0.0.1/?bidi
Hmmm, was zum Teufel?
Xerox Hotline: Da werden sie nicht geholfen
Mit dieser konkreten Fehlermeldung bewaffnet meldete ich mich bei der Xerox-Supporthotline. Nachdem ich wie ein depperter mit der dort eingesetzten Spracherkennung gewrestelt hatte (der Begriff "Technische Hilfe" sowie die Seriennummer mussten klar und deutlich ausgesprochen werden, damit sie die Spracherkennungssoftware entschlüsseln konnte), wurde ich von einer Person "beraten", die ich leider sehr schlecht verstand. Xerox sollte unverzüglich eine genügende Menge Geld in die Headsets und Telefonleitungen ihres Callcenters investieren ... Zu allem Unglück nuschelte die Person am anderen Ende auch noch.
Ich erklärte dem "1st Level Supporter" mein Problem und wies auf die klare Fehlermeldung hin. Leider interessierte er sich nicht sonderlich dafür. Wichtiger fand er, dass mein Arbeitgeber keinen Wartungsvertrag mit Xerox besässe (seit wann hat ein Wartungsvertrag Einfluss auf einen korrekt funktionierenden Treiber!? Dieses Problem trifft alle Kunden, weshalb der Hersteller bedacht sein sollte, solche Hinweise dankbar entgegenzunehmen). Immerhin war er so freundlich und hielt Rücksprache mit seinen "Kollegen". Leider schienen die 2nd Leveller bereits beim Feierabendbier zu sein, weshalb er mich bat, am nächsten Tag erneut anzurufen. Bis dann hätte er sich bei ihnen über die Fehlerursache erkundigt.
Zweiter Anruf
Heute nun, einen Tag später als geplant, fand ich Zeit, den Support anzurufen. Ich hatte zwar eine andere Person am Draht, musste mich aber wieder mit der vorgeschalteten Spracherkennung messen. Der darauf freundlich grüssende Hotline-Mitarbeiter sprach komisches Deutsch in ein Headset, das höchstens für ein Drittweltland getaugt hätte.
Diesem Herr durfte ich erneut die ganze Geschichte erzählen - und auch dieser Herr schien sich stur an sein Script zu halten, anstelle sich dankend auf meine superbe Fehlermeldung einzugehen. Wieder bemerkte er den fehlenden Wartungsvertrag, doch auch er hielt dann Rücksprache mit den "Software-Leuten".
Da er mir immerhin aufmerksam zugehört hatte, als ich ihm erzählte, dass der Generic Poscript Driver funktionierte, kam er schlussendlich mit einem für Xerox klar unwürdigen Vorschlag zurück: Ich solle doch einfach die Xerox-PPD benutzen, um den Generic Postscript Driver damit zu überschreiben ... Kopfschüttelnd bedankte ich mich für die ausserordentliche Hilfe und hängte den Hörer auf die Gabel.
Die Lösung
Auf mich allein gestellt tauchte ich tiefer in die Dateistruktur von Mac OS X ab auf der Suche nach den PPDs. Hilfreich war How Mac OS X Searches for and Chooses PPD Files, welches die von Mac OS X verwendeten Ordner für Druckertreiber explizit angab:
- /Library/Printers/PPDs/Contents/Resources/
- /System/Library/Printers/PPDs/Contents/Resources/
Ein
$ find . -name pstophaserps
in diesen Ordnern führte kein Binary pstophaserps zutage, das - gemäss meiner Übersetzung des Dateinamens - Postscript zu Phaser-tauglichen Postscript umwandelt.
Immerhin fand ich das PPD des Xerox Phaser 6300DN, öffnete dieses in einem Text-Editor und fand rasch die Zeile
*cupsFilter: "application/vnd.cups-postscript 0 /Library/Printers/Xerox/PDEs/pstophaserps"
Dieses olle Binary hätte als in /Library/Printers/Xerox/PDEs/ liegen müssen - tat es aber nicht. Ein Augenschein vor Ort liess mir ein Lichtlein aufgehen: Im Ordner fand sich ein Binary namens pstoxeroxps! Waren die Treiberentwickler wirklich so unfähig ...
... ja! Nachdem ich einen symbolischen Link erstellt hatte
$ cd /Library/Printers/Xerox/PDEs/ $ sudo ln -s pstoxeroxps pstophaserps
und einen weiteren Druckauftrag ausführte, ratterte es endlich im Drucker, und mein Dokument wurde gedruckt.
Danke, Xerox, für die gute Arbeit!
Labels: Druck, IT, PC-Support
Dienstag, Dezember 23, 2008
Seitenumbruch in der Druckversion von Safari
Heute habe ich mir an Safari 3.2 die Zähne ausgebissen: Der Browser wollte partout keinen Seitenumbruch vor einem div drucken, obwohl ich diesem den CSS-Stil page-break-before:always; zugewiesen hatte.
Safari unterstützt dieses CSS-Attribut eigentlich seit Version 1.2. Doch was zum Teufel? ... Unter Firefox wurde der Seitenumbruch vor dem Element tadellos gedruckt und div ist auch wie von W3C gefordert ein Block-Element, weshalb es sich hier offensichtlich um ein Browser-Problem handeln musste.
Nach einigem Pröbeln realisierte ich dann, dass das Eltern-div im CSS, welches für die Druckausgabe verwendet wurde (media="print" für Kenner), gefloated war. Nachdem ich diese Eigenschaft entfernte, wurde der Seitenumbruch problemlos gedruckt.
Abonnieren
