ForumCanon IP4200 und Turboprint
Marco W. – Samstag, 01. April 2006 21:02 Uhr

Hallo zusammen,

ich schaffe es irgendwie nicht meinen Drucker (Canon IP4200) unter SuSE 10.0 zum Drucken zu bewegen. Der Drucker wird aber gefunden, da ich mit Turboprint-Config ein Düsentestmuster ausdrucken kann. Aber weder das Drucken einer Testseite noch das Drucken aus anderen Anwendungen heraus funktioniert. Der Druckauftrag wird in die Warteschlange gestellt und dann tut sich nichts mehr. Im Turboprint-Setup-Programm erscheint unter Status ein grüner Punkt und es erscheint die Meldung “Druckt – Aufträge annehmen – 1 Aufträge”.

Ich bin für jeden Tip dankbar!

2 Antworten
Ottfried Meyer – Sonntag, 02. April 2006 11:54 Uhr

Hi,

Welche Linux-Distribution ?
Welche Kernelversion ?
Welches Druckersystem (cups oder lprng oder … ) ?
Welche Turboprint-Version ?
Was steht unter /var/log/turborprint/* ?
Was steht unter /var/log//* ?
Wie ist der Drucker angeschlossen (usb/parallel) ?
Existiert das zugehörige Devide unter /dev/* ?
Stimmen die Permissions des Devicefiles ?
Kann man als root drucken, als user jedoch nicht ?
Was meint die Admin-Oberfläche von cups (wenn dieser benutzt wird) ???

Die Vielfalt der Informationen ist proportional zu der
Nützlichkeit der Hilfe, die wir hier geben können.

Gruß,
mcc

Silvio Tusche – Sonntag, 02. April 2006 12:16 Uhr

Es steht ja SuSE 10 da. Also ist die Distribution und die Kernelversion (2.6.13) bekannt. Wobei die Kernelversion jedoch unerheblich ist. Aber ansonsten hast du recht. :-)

Silvio Tusche – Sonntag, 02. April 2006 12:25 Uhr

Wie hast du denn Turboprint installiert. Mit dem RPM-Paket oder Tarball? Ich halte den Weg mit dem Tarball für sicherer, da die Systemgegebenheit (z.B. bei mir 64-bit-Architektur) besser berücksichtigt werden. Bentzt du eine lizensierte Version von Turboprint oder die Freewareverison (mit Turboprint-Logo und niedrigerer Auflösung).

Ansonsten kann ich nur sagen, daß ich mit dieser Kombination – SuSE 10 / Turboprint / Canon iP 4200 mit lizensiertem Treiber hochzufrieden bin. Die Resultate sind das beste was ich je unter Linux gesehen habe.

Was passiert eigentlich, wenn du einen Druckauftrag in eine Postscriptdatei umleitest und anschießend mit

lp testdatei.ps

ausdruckst. Was sagen die Logs?

Marco W. – Sonntag, 02. April 2006 15:38 Uhr

Hallo,

also hier noch ein paar zusätzliche Informationen:
Ich benutze die Demo-Version von Turboprint 1.94 (mittels RPM-Paket installiert) und mein Drucker ist über USB angeschlossen. Die Verzeichnisse /dev/usb/lp0 und /dev/usblp0 existieren und die Rechte habe ich auf jeweils rwxrwxrwx gesetzt. Aber weder als root noch als Benutzer kann ich drucken (außer dem Düsentestmuster).

Auszug aus /var/log/cups/error_log:

I [02/Apr/2006:14:41:19 +0200] All jobs on ‘tp0’ were purged by ‘root’.
I [02/Apr/2006:14:41:19 +0200] Printer ‘tp0’ started by ‘root’.
I [02/Apr/2006:14:41:21 +0200] Saving printers.conf…
I [02/Apr/2006:14:41:21 +0200] Printer ‘tp0’ modified by ‘root’.
I [02/Apr/2006:14:41:21 +0200] Saving printers.conf…
I [02/Apr/2006:14:41:21 +0200] Printer ‘tp0’ modified by ‘root’.
I [02/Apr/2006:14:41:21 +0200] Setting tp0 device-uri to “usb:/dev/usb/lp0” (was “usb:/dev/usb/lp0”.)
I [02/Apr/2006:14:41:21 +0200] Saving printers.conf…
I [02/Apr/2006:14:41:21 +0200] Printer ‘tp0’ modified by ‘root’.
I [02/Apr/2006:14:41:21 +0200] Saving printers.conf…
I [02/Apr/2006:14:41:21 +0200] Saving classes.conf…
I [02/Apr/2006:14:41:21 +0200] Default destination set to ‘tp0’ by ‘root’.
I [02/Apr/2006:14:49:45 +0200] Adding start banner page “none” to job 3.
I [02/Apr/2006:14:49:45 +0200] Adding end banner page “none” to job 3.
I [02/Apr/2006:14:49:45 +0200] Job 3 queued on ‘tp0’ by ‘root’.
I [02/Apr/2006:14:49:45 +0200] Started filter /usr/lib/cups/filter/pstops (PID 10061) for job 3.
I [02/Apr/2006:14:49:45 +0200] Started filter /usr/lib/cups/filter/pstoturboprint (PID 10062) for job 3.
I [02/Apr/2006:14:49:45 +0200] Started backend /usr/lib/cups/backend/usb (PID 10063) for job 3.

Auszug aus /var/log/turboprint.log:

ERROR:
configfile_class::open_config_file: wrong file contents
ERROR:
configfile_class::open_config_file: wrong file contents
lp -d tp0 /tmp/tp9779_1.tmp
lp -d tp0 /tmp/tp9779_3.tmp
canon_class::get_ink_quantity: head: CL ink: NO newink: PBK=040,BK=040,Y=040,M=040,C=040
Report at end of pdrivecontrol_class::release_printer
29 inifile::open(buffer)
28 inifile::open(buffer)
5958 inifile::open(buffer)
29047 inifile::open(buffer)
64100 prefs::device_array (cups_device)
256000 spoolsystem::open: remember_buffer
29047 inifile::open(buffer)
Total memory usage=384209

Auszug aus /var/log/turboprint_cups.log:

#######################################################
New print job Sun Apr 2 14:49:45 CEST 2006 (pstoturboprint 1.94-2)
job-id 3
user root
title tp10059_1.tmp
copies 1
options cpi=10 lpi=6
file
/usr/bin/tpprint -v2 -l/var/log/turboprint_cups.log –ppdfile=/etc/cups/ppd/tp0.ppd –psfeatures /tmp/pstoturboprint10062.chunk /tmp/pstoturboprint10062.var
PPD file:
-rw-r–r– 1 lp lp 28435 Apr 2 14:41 /etc/cups/ppd/tp0.ppd
test directory access:
drwxr-xr-x 2 root root 144 Apr 2 14:49 /etc/turboprint
drwxr-xr-x 10 root root 240 Apr 2 14:39 /usr/share/turboprint
drwxr-xr-x 2 root root 9952 Apr 2 14:39 /usr/share/turboprint/printers
-rw-r–r– 1 root root 607 Apr 2 14:39 /etc/turboprint/system.cfg
chunk file:
-rw——- 1 lp lp 8428 Apr 2 14:49 /tmp/pstoturboprint10062.chunk
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib/tls/libm.so.6 (0x40036000)
libc.so.6 => /lib/tls/libc.so.6 (0x4005d000)
/lib/ld-linux.so.2 (0x40000000)
/usr/bin/tpprint -v2 -l/var/log/turboprint_cups.log –ppdfile=/etc/cups/ppd/tp0.ppd –psfeatures /tmp/pstoturboprint10062.chunk /tmp/pstoturboprint10062.var
Searching PPD file and postscript header for options…
———– Start of var file ———–
ZEDOPARM=”$ZEDOPARM zedoInputSlot=ButtonSelect”
ZEDOPARM=”$ZEDOPARM zedoMediaType=Plainpaper_4″
ZEDOPARM=”$ZEDOPARM zedoPageRegion=A4″
ZEDOPARM=”$ZEDOPARM zedoBrightness=0″
ZEDOPARM=”$ZEDOPARM zedoContrast=0″
ZEDOPARM=”$ZEDOPARM zedoIntensity=0″
ZEDOPARM=”$ZEDOPARM zedoGamut=0″
ZEDOPARM=”$ZEDOPARM zedoGamma=180″
ZEDOPARM=”$ZEDOPARM zedoColorK=0″
ZEDOPARM=”$ZEDOPARM zedoColorC=0″
ZEDOPARM=”$ZEDOPARM zedoColorM=0″
ZEDOPARM=”$ZEDOPARM zedoColorY=0″
ZEDOPARM=”$ZEDOPARM zedoColorCorrection=1″
ZEDOPARM=”$ZEDOPARM zedoUserColor=0″
ZEDOPARM=”$ZEDOPARM zedoColorModel=RGB”
ZEDOPARM=”$ZEDOPARM zedoDithering=ErrorDiffusion”
ZEDOPARM=”$ZEDOPARM zedoDuplexAdjust=0″
ZEDOPARM=”$ZEDOPARM zedoMirror=0″
ZEDOPARM=”$ZEDOPARM zedoDuplex=None”
ZEDOPARM=”$ZEDOPARM zedoPrinterDriver=Canon_PIXMA_iP4200″
ZEDOPARM=”$ZEDOPARM zedoResolution=600x600dpi”
GSPPDFOUND=1
GSCOLORMODE=2
GSXDPI=600
GSYDPI=600
GSWIDTH=4960
GSHEIGHT=7015
TPWIDTH=8268
TPHEIGHT=11693
TPXOFFSET=0
TPYOFFSET=0
———– End of var file ———–
GSCOMMANDLINE=gs -sDEVICE=pcx24b -r600x600 -g4960x7015 -dSAFER -dNOPAUSE -dBATCH
TPCOMMANDLINE=/usr/bin/tpprint -a0 -e1 -s8268x11693 -v2 -l/var/log/turboprint_cups.log —cpi=10 —lpi=6 –ppdfile=/etc/cups/ppd/tp0.ppd –psheader=/tmp/pstoturboprint10062.chunk
COMPLETEPIPE=/usr/share/turboprint/lib/tpstdin –paste /tmp/pstoturboprint10062.chunk | gs -sDEVICE=pcx24b -r600x600 -g4960x7015 -dSAFER -dNOPAUSE -dBATCH -sOutputFile=/tmp/pstoturboprint10062.fifo – >> /var/log/turboprint_cups.log
———– Start of print job ———–
———— End of print job ————

Auszug aus /var/log/cups/access_log:

localhost – root [02/Apr/2006:14:41:19 +0200] “POST /admin/ HTTP/1.1” 200 121
localhost – root [02/Apr/2006:14:41:19 +0200] “POST / HTTP/1.1” 200 290
localhost – root [02/Apr/2006:14:41:19 +0200] “POST / HTTP/1.1” 200 152
localhost – root [02/Apr/2006:14:41:20 +0200] “POST / HTTP/1.1” 200 290
localhost – root [02/Apr/2006:14:41:20 +0200] “POST / HTTP/1.1” 200 152
localhost – root [02/Apr/2006:14:41:21 +0200] “POST /admin/ HTTP/1.1” 200 177
localhost – root [02/Apr/2006:14:41:21 +0200] “POST /admin/ HTTP/1.1” 200 28677
localhost – root [02/Apr/2006:14:41:21 +0200] “POST /admin/ HTTP/1.1” 200 152
localhost – root [02/Apr/2006:14:41:21 +0200] “POST / HTTP/1.1” 200 290
localhost – – [02/Apr/2006:14:41:21 +0200] “POST / HTTP/1.1” 200 137
localhost – – [02/Apr/2006:14:41:21 +0200] “POST / HTTP/1.1” 200 137
localhost – – [02/Apr/2006:14:41:21 +0200] “POST / HTTP/1.1” 200 77
localhost – – [02/Apr/2006:14:41:21 +0200] “POST / HTTP/1.1” 200 137
localhost – – [02/Apr/2006:14:41:21 +0200] “POST / HTTP/1.1” 200 137
localhost – root [02/Apr/2006:14:41:21 +0200] “POST /admin/ HTTP/1.1” 200 121
localhost – – [02/Apr/2006:14:41:22 +0200] “POST /printers/ HTTP/1.1” 200 221
localhost – – [02/Apr/2006:14:41:22 +0200] “POST /classes/ HTTP/1.1” 200 221
localhost – – [02/Apr/2006:14:41:22 +0200] “POST /printers/ HTTP/1.1” 200 109
localhost – – [02/Apr/2006:14:41:22 +0200] “POST / HTTP/1.1” 200 365
localhost – – [02/Apr/2006:14:41:27 +0200] “POST /printers/ HTTP/1.1” 200 221
localhost – – [02/Apr/2006:14:41:27 +0200] “POST /classes/ HTTP/1.1” 200 221
localhost – – [02/Apr/2006:14:41:27 +0200] “POST /printers/ HTTP/1.1” 200 109
localhost – – [02/Apr/2006:14:41:27 +0200] “POST / HTTP/1.1” 200 365
localhost – – [02/Apr/2006:14:49:20 +0200] “POST / HTTP/1.1” 200 114
localhost – – [02/Apr/2006:14:49:20 +0200] “POST /printers/ HTTP/1.1” 200 206
localhost – – [02/Apr/2006:14:49:20 +0200] “POST /admin/ HTTP/1.1” 401 0
localhost – root [02/Apr/2006:14:49:20 +0200] “POST /admin/ HTTP/1.1” 200 77
localhost – – [02/Apr/2006:14:49:45 +0200] “POST / HTTP/1.1” 200 137
localhost – – [02/Apr/2006:14:49:45 +0200] “POST / HTTP/1.1” 200 137
localhost – – [02/Apr/2006:14:49:45 +0200] “POST / HTTP/1.1” 200 77
localhost – – [02/Apr/2006:14:49:45 +0200] “POST /printers/tp0 HTTP/1.1” 200 5342

Die Log-Files enthalten keine neuen Informationen, wenn ich einen Druckauftrag zuerst in eine Postscriptdatei umleite.
Die Druckaufträge bleiben immer so lange in der Warteschleife, bis ich sie manuell lösche.

Gruß,
NRIXS

Ottfried Meyer – Sonntag, 02. April 2006 18:43 Uhr

Hi,

da das Düsenttestmuster, welches vom Drucker selber erzeugt wird und
lediglich durch einen Befehl und nicht durch den zu druckenden Inhalt
über die USB-Schnittstelle ausgelöst wird, muss logischerweise die
Kommunikation über die USB-Schnittstelle zumindest auf unterster
Basis funktionieren.

Die Kernelversion spielt deswegen eine Rolle, da das “neueste” Turboprint
meines Wissens nach schon älter al ein Jahr ist. Veränderungen der IOCTLs
beim Übergang von 2.4.* nach 2.6.* können einem die ganze Schnittstellen-
kommunikation verderben und eine bestimmte SuSE-Version sagt noch nichts
darüber aus, ob der User/SysAdmin nicht den Kernel upgedated hat…

Aber egal…weiter mit den Logfiles…

Könnt es eventuell sein, dass das Spoolverzeichnis (/var/spool/lp oder
/var/spool/cups) nicht richtig in xtpconfig/xtpsetup eingesetzt wurde ?

Sieh doch einmal unter /etc/turboprint/*.cfg nach, ob die Einstellungen
dort mit denen Deiner “Systemrealität” :) übereinstimmen.

Randbemerkung:
Ich habe vor kurzem wegen eines Hardwareschadens einen neuen Rechner
bauen müssen udn dort ein Gentoo-Linux hochgezogen.
Auch hier bockt Turboprint: Bei mir meint Turbopront immer ein /dev/cups
ansprechen zu wollen mit den gelichen Effekten wie bei Dir. Allerdings
fehlt in Deinen Logfiles die entsprechende Fehlermeldung.

Herr Zeiler von Zedonet ist informiert … ich warte auf eine Antwort.

Die Einstellungen sind übrigens dieselben, die bei meinem alten System
funtionierten.

SIGH

Keep hacking!
mcc

Marco W. – Sonntag, 02. April 2006 21:32 Uhr

Hallo,

erstmal Danke für die ausführlichen Antworten. Das Spoolverzeichnis ist
richtig eingetragen, daran liegt’s leider auch nicht. Übrigens benutze ich die
Kernelversion 2.6.13-15.8.

Gruß,
NRIXS

Ottfried Meyer – Sonntag, 09. April 2006 13:21 Uhr

Hi,

so…nach einiger Forschungsarbeit ist hat sich folgendes
herauskristallisiert:

Zedonet stellt Turboprint als closed-Source Produkt her.

Damit darf ZedoNet nicht das Rasterformat bzw. die Rasterformat-
Library von Cups benutzen (GPL), muss also eine eigene in die Infrastruktur
mit einbringen.

Das hat bis Cups 1.1.23 (?) wohl auch noch geklappt. Mit neueren Versionen
von Cups geht dieses nicht mehr.

Ein Fix wird von der Cups-Entwicklungsmannschaft abgelehnt, da es ein
Turboprint-Problem ist.

Von Herrn Zeiler/Zedonet habe ich bis heute (2006-04-09) keine
Stellungsnahme erhalten, was nicht meinen bisherigen Erfahrungen
mit Supportfragen an ZedoNet entspricht.

Die Crux an der Geschichte ist, das entweder ZedoNet auf die Closed-Source-
Politik und damit auf den Verdienst verzichten muss, um das neue Rasterformat
zu unterstützen oder die Cups_Mannschaft wohl Lizenzen bezahlen muss, um das
propietäre Rasterformat von ZedoNet/Turboprint zu unterstützen.

Beides will man jedoch nicht.

(Angaben ohne Gewähr — siehe auch den Cups-Bugtracker (Suchwort “Turboprint”))

Eine weitere Kommentierung der aufgezeigten Sachlage erspare ich mir
hier.

Einziger Ausweg, den ich gerade versuche, ist die Entfernung von Cups und
die Installation von LPrng.

Seufz……

Fundamental entäuscht und frustriert,
mcc

Ottfried Meyer – Sonntag, 09. April 2006 15:20 Uhr

Nachtrag:

Ich habe jetzt cups-1.13 (!) installiert.
Nun kann ich mit tpprint direkt drucken…mal sehen.
was sich noch so ergibt…

still hacking,
mcc