Bug#712512: Problem remains
It seems that I was too quick to close the bug. My tests did not include
printing even and odd pages as in this following example.
$ lpr -P HL-1250-usb -o page-set=odd two_page_postscript_file.ps
( remove sheet and place in tray to print other side)
$ lpr -P HL-1250-usb -o page-set=even two_page_postscript_file.ps
The first side is printed correctly. But the next sheet has
JL SET MEDIATYPE=REGULAR
@PCL SET SOURCETRAY=AUTO
@PCL SET RESOLUTION=600
@PJL SE
as usual. This typically happens on repeated attempts to print the
second page. Obviously the above PCL commands have lost synchronisation
with the printer. It seems to be an "interjob" problem, since my
previous tests with the current cups-1.6.4-2 of a multipage document
seemed to work, which misled me into temporarily closing this bug.
The same bug shows up when printing in other ways, as for example
printing the odd pages from gv, and then doing the even pages.
/var/log/cups/error_log:-
E [13/Jan/2014:20:42:56 +0000] [CGI] Unable to scan "@LOCAL"!
/var/log/cups/access_log doesn't seem to include anything useful, just
entries like:
localhost - - [13/Jan/2014:21:01:28 +0000] "POST /printers/HL-1250-usb HTTP/1.1" 200 16429 Send-Document successful-ok
The status shown in the browser at http://localhost:631/printers/ is
HL-1250-usb Brother HL-1250 series usb Brother HL-1250 Foomatic/hl1250 (recommended) Idle - "Sending data to printer."
That Idle - "Sending data to printer" looks odd? Why is it still sending
data when it is 'Idle'? Perhaps that confirms again some sort of
handshake failure between cups and the printer?
# lpinfo -v
network socket
network http
network lpd
network ipp14
network https
network ipp
network ipps
network smb
direct usb://Brother/HL-1250%20series
I will capture the raw PCL and see if I can spot the problem and if not
add it to this bug tomorrow (I hope).
Meanwhile, I have the manufacturer's own (not quite free) PPD.
Where do I put that so cups can see it? /etc/local/cups/ppd/ perhaps?
That should eliminate a problem with the foomatic ppd.
This printer has worked for years with cups. And I see the problem using
different machines (all debian testing) using both the parallel and the
usb ports. I suspect the the problem may have been introduced with the
xml version of the ppd, but that is speculation. When I have captured
the pcl it will presumably indicate what is happening unless the
error about not scanning "@LOCAL" is enough.
ael
Reply to: