Red Hat Bugzilla – Bug 121547
Lexmark Optera S 1255 printer reports an PostScript error
Last modified: 2007-11-30 17:10:41 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 Description of problem: When I try to print certain documents on my Lexmark Optera S 1255 printer, it does not print at all. When I enabled PostScript error reporting, it came up with this error message: ERROR: configurationerror OFFENDING COMMAND: setpagedevice ERRORINFO: Key= --nostringval-- Value= --nostringval-- Stack: diettype I have been in contact with Lexmark support, but they where unable to tell me anything (exept mailing me a manual which mainly details how to install their drivers on AIX - exept one line of rpm -Uvh Lexmark_optera.rpm (about that)). They do have an rpm for RedHat 9 on their website, but I do not know how this work, as I want to use CUPS as my printing system for simplicity (fearing that this will install some sort of propietary printing system). But you may examine it, maybe you'l find a ppd file which could be used or something. I have also tried to use the Optera S 1250 ppd found on LinuxPrinting.org, installing it by installing the Optera S 1250 by the redhat-config-printer program, and then replacing the /etc/cups/ppd/Tynnklientserver.ppd file generated by the file downloaded from linuxprinting.org, but this gave the same error message from the printer. I have also sent this error message to lexmark support, hoping that they will figure it out. I will post and translate any interesting responses. The mail sent to them where (translated from norwegian into english): Think I at least found out something. Turned on postscript error messages on a Optera S 1255, and got this error message: (the error message I detailed) The printer was connected to the paralell port of a fedora-computer, and the printout was local (it came from a thin client conected to the machine, so it should be counted as local). The program I tried to print from was OpenOffice 1.1, through CUPS. I send you a copy of the failed document as soon as possible. Do you got an .ppd-file you may mail me? Tried that on linuxprinting.org but it yielded the same error as the one Fedora carried - thinking that it may be the same file... BTW I found this RPM on your site - what is it? http://downloads.lexmark.com/cgi-perl/downloads.cgi?ccs=229:1:0:166:0:0&emeaframe=&fileID=1190 Your homepage says that it should be RH9 compatible. I may test it on a test-computer and see what happens - your documentation is rather poor. BTW it says "deleting buffer" in the middle of the print: It starts, says "deleting buffer", stops, starts again - and if the postscript error thing is activated, it prints the error message. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1. Print SOME documents - either from the web, OO, or from some other source 2. Then, SOME documents fail each time - others do not. Actual Results: Nothing. Se Description for a more accurate description Expected Results: That the document shall print! It happens to about 25-50% of all prints, so its QUITE annoying Additional info:
Sent an example file to Tim Waugh (twaugh@redhat.com) - wasn't able to upload it as a attachment - 2 MB of size... Got a response from Lexmark this morning. They said: Use our PS/PCL driver kit for UNIX (which we linked to). If you do not want to use this driver, I will have to see the setup page for the printer, so we can see if it is possible to upgrade the codes in the printer.
(Your mail to me didn't have any attachment.) The problem might be something like trying to set duplex printing when it is not duplex-capable. So I'll need to know two things: 1. Please attach to this bug report the output of 'printconf-tui --Xexport', so that I can see the print queue settings -- make sure to remove any passwords it might contain. 2. Is the 2Mb file you tried to attach a PostScript file, and if so which application did you use to generate it?
I shall do that (when I get back to my shool where the problem-printers exists). The problem is definatly not the cable - as we are seeing the same problem at network-attached printers too (another Optera S 1255 and a Optera S 1850), even when trying to print over SMB (showing up as "raw data" or something at windows'es print-manager - but still nothing shows up at the printer(the network attached ones has not been set to print error messages)). After installing the RPM with their print-drivers (which integrates with CUPS), "everything" worked great. The printer connected to lp0 even showed up in redhat-config-printers. The 2 MB file i tried to attach is the .swx file i was trying to print (the same which I sent you on mail).
Created attachment 99900 [details] The output from one of the pc's without working printing
Created attachment 99901 [details] The output from the machine which has the properitary drivers
How about if you set the printer model to Generic PostScript?
What do you mean? Set it as a "raw" printer? How do I do that? Anyway I got it working now - added the printers via Lexmarks properitary drivers, shared them (Lexmark did'nt know how - their tool, that is, and redhat-config-printer only showed the one connected directly into the paralell port... (found out how to edit cupsd.conf and use lpadmin to give everybody (on the LAN) access - why isn't this included in the web interface, which btw is great!)), and disabling the wicked firewall on the client-computers. Then all was a silk ride, they automagically appeared on the clients. When we upgrade to FC2 soon, at least we know how to fix things!
In the 'Printer driver' tab, choose 'Generic' as the manufacturer and 'Raw Print Queue' as the model.
I am personally no longer able to debug this, as the printers have been decomissioned (replaced by better HP ones), and i have moved over to university - no longer having access. Anyway, for future reference: The lexmark supplied drivers acctually worked, but i had to install some xorg-compat (or somesuch) to get their config tools to work on fc3. Then the config was a chore, since we wanted to share them over CUPS IPP printer sharing - as their config tools did not make this possible, system-config-printer did not pick up anything setup by their tool, and the cups ipp config files... Well. They aren't that bad, acctually, when you get used to them. You may or may not close this bug.