Description of problem: From any application that can print (i.e Firefox, LibreOffice, Document Viewer, etc) I am unable to print from a printer drawer/tray other than "Paper Source: Auto Select". If I choose a different paper drawer, the printer will receive the job, but then it vanishes with no error on either end. I have three multi drawer/tray printers available and it happens on all three: HP LaserJet 4050, Savin c4540, and a Ricoh-Aficio-3228c Version-Release number of selected component (if applicable): Cups - 1:1.5.2-6.fc16 kernel - 3.3.0-4.fc16.x86_64 Gnome How reproducible: Every time Steps to Reproduce: 1. Open a file/document to print 2. Select multi drawer printer (i.e Savin c4540) 3. Click on Page Setup Tab and select a Paper Source other than Auto Select 4. Click Print Actual results: Printer warms up and "receiving data" light blinks but nothing is printed Expected results: Print job to be printed from the expected drawer/tray Additional info: This feature used to work on this laptop when I was running Fedora 13(x86), I did a fresh install (on a new drive) of Fedora 16(x86_64) so I am not sure if it a Fedora 16/cups issue or a 64 bit issue.
Please attach the PPD for each queue you are seeing this problem with, from the /etc/cups/ppd/ directory.
Created attachment 573397 [details] Ricoh 3328C ppd file
Created attachment 573398 [details] Savin C4540 PPD File
Created attachment 573400 [details] HP LaserJet 4050
OK, let's concentrate on the HP LaserJet 4050 one first. This is a straight PPD file for a printer that speaks PostScript natively, with no other filters involved. The PPD in comment #4 has all of the installable options for trays set to off: Tray 3 Tray 4 Envelope Feeder So the remaining input slot choices available are: Automatic Tray 1 Tray 2
Created attachment 573619 [details] upper.ps Please try printing the attached file as follows: lp -oraw -dHP-LaserJet-4050 upper.ps What, if any, output do you get from the printer? (Are there any messages on the display?)
I must have forgotten to recheck the Tray 3 option as I was playing around with settings trying to get it to work. When I ran the command above it prints a CUPS test page and pulls from the manual feed (tray 1). Which gave me hope so I tried printing normally and the HP seems to be working correctly now (even after adding back in tray 3). As far as I know I have not changed any settings on the HP (or in the driver) since I filed the bug report, so not sure why it would start working. The hope was short lived though, because the Savin & Ricoh still exhibit the same behaviour.
Since the HP now seems to work, I have update the title to reflect this only happening on my Ricoh & Savin copier/printers. I have also done a bit more troubleshooting on it and it seems not only can I not change the paper source, if I make any other changes on the page setup screen (i.e two-sided, paper type, etc) it will not print (even if leave the paper source set to Auto Select). If I leave all of the items on the Page Setup screen set to the default settings, I am able to change items on other tabs and it will still print (color, finishing, etc) I have everything up to date from the latest Fedora stable repos: kernel: 3.3.1-3.fc16.x86_64 cups: 1:1.5.2-6.fc16
OK. Let's try to fix them one by one. Taking the Ricoh one first. This is a foomatic driver, meaning that the PPD contains instructions for building a command line to run, based on running gs (ghostscript). The command line the PPD builds includes some PJL injection as well as some PCL tweaking based on changing specific bytes in the output stream. In this case, the command for tweaking the PCL so that Tray 1 is used is this: sed -e "s/\xf8\x25\xc0[\x00\x01]\xf8\x26/\xf8\x25\xc0\x04\xf8\x26/g" But it does not behave as expected. The input stream has these bytes: f8 25 c0 01 f8 26 followed by c0 00 f8 34 ... We expect that to be changed to: f8 25 c0 04 f8 26 followed by c0 00 f8 34 ... but instead it's getting changed to: f8 25 c0 04 f8 f8 25 c0 01 f8 26 followed by c0 00 f8 34 Instead of the final replacement byte, the entire original string of bytes is present. The reason is that "\x26" is the character "&", which is treated specially by sed. However, I don't think \x26 ought to be treated specially. I've filed bug #812067 to track it. From a quick glance at the Savin case, it might be the same issue there.
I have been following bug #812067 and saw it was updated with a new version of sed. I downloaded & updated my version to sed-4.2.1-8.fc16.x86_64 and now printing on the savin works as expected. Testing to the Ricoh will have to wait a week or two (waiting on parts to come in) Thank you so much for your help!
That's great! Let me know how the testing on the remaining printers goes. Thanks.
Since there's been no response for 5 months I guess all remaining problems have been resolved with fixing of bug #812067. Brianna, feel free to reopen this bug if I'm wrong.