From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 Description of problem: Network Printers configured using the gnome printer configuration gui as (for example): Queue Type: UNIX Printer (lpd queue) Server: Canon Queue: print Printer: GP405 Printer Driver: Postscript a simple command such as: lp hello . will print out 5 pages of postscript commands. Version-Release number of selected component (if applicable): LPRng-3.8.9-6 How reproducible: Always Steps to Reproduce: 1.Define a UNIX network (postscript) printer (using default settings) 2.print a test page to it 3.collect a weeks supply of scrap paper Actual Results: the printer prints the Postscript commands Expected Results: It should print a test page Additional info: The same printer(s) works fine from RH7.1 & RH7.2 (and spooling from RH8.0 via a RH7.1 m/c works fine)
Which driver do you use in Red Hat Linux 7.2?
RH7.1 uses the Canon GP405/Postscript driver with LPRng-3.7.4-2 The only difference in configuration I can find is in the /var/spool/lpd/canon/mf.cfg file which has a '-d' switch in the PSfilter for RH7.1. I have tried adding this in RH8.0 but not got consistent results.
On the 8.0 machine please run 'printconf-tui --Xexport' and attach the result. Thanks.
Created attachment 90460 [details] printconf-tui --Xexport outoput as requested The printer definition I has set up for testing is softtest.
Are you printing the test page from the redhat-config-printer tool? I wonder if enabling the 'prerender PostScript' option would make a difference here.
Pre-rendering just prints out the postscript commands for the bitmap instead. If I switch the printer from 'PostScript' to 'Raw Printer Driver' I can print postscript files correctly (though no other file type will print). I therefore suspect the header that is being added to the postscript file by the postscript driver. What I see printed ahead of my postscript data is: %! <</HWResolution[600 600]>> setpagedevice <</Duplex false>>setpagedevice <</PageSize [595 842] /ImagingBBox null>> setpagedevice Then my own postscript data continues: %!PS-Adobe-3.0 ..... Is it possible that something else is being added before the %! (unprinted) that is confusing the printer? Is there a way of trapping the print file just before it gets sent to the printer?
You can set it up as a local printer and set the custom device to '/dev/lp0' (create that file and make 'lp' own it). Another thing you can try is to edit the /usr/sbin/lpdomatic script and change 'my $debug = 0;' to 'my $debug = 1;'. Then when you print you will end up with some useful output in /tmp.
That has tracked the problem down. The printer doesn't like the HWResolution command. I have trapped the output using /dev/lp0 and created a raw printer. Printing the trapped data prints the postscript commands. Commenting out the HWResolution line works OK. On further investigation this does just seem to be a problem wirh the Canon GP405. How can I stop lp adding in the HWResolution line?
Did you comment out *just* the HWResolution line? I've seen problems with the duplex line before (bug #82385). Could it possibly be that? Otherwise I'll need to add a 'do nothing' value to that resolution foomatic option, like I did for duplex.
It was just the HWResolution (probably a canon bug). The header that prints OK is: %% <</HWResolution[600 600]>>setpagedevice <</Duplex false>>setpagedevice <</PageSize[595 842]/ImagingBBox null>>setpagedevice %!PS-Adobe-2.0
I've mentioned this to the upstream foomatic maintainer.
Created attachment 90475 [details] Here's the patch I'm about to commit upstream. Apply with 'patch -i resolution.patch /usr/share/foomatic/db/source/opt/Postscript-Resolution.xml'.
Sorry, but you aren't going to like this. I have applied your patch but it still wouldn't work. Further investigation reveals that in order to work the commented out HWResolution line needed to be present. With the line deleted it fails to print again. An empty comment doesn't fix it either but any comment with text in it after the %! makes it all work. I will report this to Canon as well. THIS WORKS: %! %% %% <</HWResolution[600 600]>> setpagedevice <</Duplex false>>setpagedevice <</PageSize[595 842]/ImagingBBox null>>setpagedevice NEITHER OF THESE WORK: %! <</HWResolution[600 600]>> setpagedevice <</Duplex false>>setpagedevice <</PageSize[595 842]/ImagingBBox null>>setpagedevice %! %% <</HWResolution[600 600]>> setpagedevice <</Duplex false>>setpagedevice <</PageSize[595 842]/ImagingBBox null>>setpagedevice
Created attachment 90477 [details] comment.patch Here's a patch intended to add '%% %%' in the right place. What a weird Canon bug.
(I should mention that it applies to /usr/share/foomatic/db/source/driver/Postscript.xml this time.)
That patch didn't wouldn't apply to my Postscript.xml file but I have hand edited the change in and all seems to be well. Thanks for your help.
Great. This change is applied in upstream foomatic CVS.