Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Cannot print to Epson Stylus Photo 1400 after replacing Fedora 8 withe Fedora 9. Version-Release number of selected component (if applicable): How reproducible: I actually tried to enter the printer to CUPS in two different ways. The first way was to let CUPS try to find a driver for Epson->Stylus Photo 1400. The second was to use the pipslite-cups package as described in my blog posting: http://opensource.org/node/332 I installed the printer using two different names so that I could compare one method of printing vs. the other. Neither worked (though both can print the test page from the CUPS admin screen). Steps to Reproduce: 1.Attach Epson Stylus Photo 1400 to USB port of Fedora 9 computer 2.Lauch firefox browser to point at http://fedoraproject.org/ 3.Attempt to print the home page Actual results: The document print status window pops up and says "There was a problem ..." Expected results: A printout of the Fedora Project's home page. Additional info: As I mentioned in my blog posting, this worked trivially under Fedora 8. It works Not At All in Fedora 9.
I meant to add that my version of CUPS is 1.3.7, release 2.fc9
This particular model does not have an entry in the openprinting.org database saying which driver might work. If it worked with Fedora 8, perhaps the method for guessing a likely driver has changed. First, I need to see the identification strings from the printer, so what does '/usr/sbin/lpinfo -l -v' say? The fact that you get a 'There was a problem ...' dialog means that the job stopped for some reason. You should have seen a 'Diagnose' button in that dialog. Did you try that?
Here's two bits of information you requested: [root@laptop ~]# /usr/sbin/lpinfo -l -v Device: uri = socket class = network info = AppSocket/HP JetDirect make-and-model = Unknown device-id = Device: uri = beh class = network info = Backend Error Handler make-and-model = Unknown device-id = Device: uri = hal:///org/freedesktop/Hal/devices/usb_device_4b8_7_HQ0250712290853470_if0_printer_noserial class = direct info = EPSON Stylus Photo 1400 make-and-model = EPSON Stylus Photo 1400 device-id = MFG:EPSON;MDL:Stylus Photo 1400;CLS:PRINTER; Device: uri = usb://EPSON/Stylus%20Photo%201400 class = direct info = EPSON Stylus Photo 1400 USB #1 make-and-model = EPSON Stylus Photo 1400 device-id = MFG:EPSON;CMD:ESCPL2,BDC,D4,D4PX,ESCPR1;MDL:Stylus Photo 1400;CLS:PRINTER;DES:EPSON Stylus Photo 1400; Device: uri = hpfax class = direct info = HP Fax (HPLIP) make-and-model = Unknown device-id = Device: uri = hp class = direct info = HP Printer (HPLIP) make-and-model = Unknown device-id = Device: uri = http class = network info = Internet Printing Protocol (http) make-and-model = Unknown device-id = Device: uri = ipp class = network info = Internet Printing Protocol (ipp) make-and-model = Unknown device-id = Device: uri = lpd class = network info = LPD/LPR Host or Printer make-and-model = Unknown device-id = Device: uri = scsi class = direct info = SCSI Printer make-and-model = Unknown device-id = Device: uri = smb class = network info = Windows Printer via SAMBA make-and-model = Unknown device-id = [root@laptop ~]# When I ran the Diagnose function, I learned that /usr/lib/cups/filter/rastertopips failed. [root@laptop ~]# file /usr/lib/cups/filter/rastertopips /usr/lib/cups/filter/rastertopips: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped [root@laptop ~]# rpm -qf !$ rpm -qf /usr/lib/cups/filter/rastertopips pipslite-cups-1.0.3-1.i386 [root@laptop ~]# I think when I installed Fedora 8 it was an i386 install; my Fedora 9 is an x86_64 install. Perhaps this 3rd-party program doesn't work for 64 bits...
I just tried installing pipslite-cups on an x86_64 machine here and found the same problem as you describe. Looking at the /var/log/cups/error_log file with debugging on showed this: /usr/lib/cups/filter/pipstoprinter : **** ERROR **** : /usr/share/pipslite/paper_list.csv : List file is broken Third-party software problem, so closing CANTFIX.