From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 Description of problem: I have a PostScript printer (Lexmark Optra S 1855) set up as a Samba share. When Windows clients use their PostScript printer drivers to print, the job flows through all the queues, the printer warms up, but nothing prints. Local printing on my RHEL machine works fine, and Windows clients using their PCL printer drivers also work fine. After looking into this at some length, there seem to be two problems in the cupsomatic filter that are causing the failure. First, if the filter is passed an input file as a name on the command line, rather than a stream of data on standard input, it simply won't read the input file. (See the warning "inputfile handling is broken!!!" around line 166.) Unfortunately, when a PostScript file is spooled by Samba, this is exactly the case that arises. Second, if the input file contains printer job control options at the top (as it always will if the file comes from a Windows printer driver), then the test for the PostScript marker "%!" near line 485 will fail. I suspect this problem has been around since RH9, but I've been using LPRng instead of CUPS, so I didn't notice it until I upgraded to RHEL and was forced to move to CUPS. I've worked around this problem crudely for now by wrapping cupsomatic with a script that filters the input file and presents it to cupsomatic on stdin. (Mind you I knew nothing about the printing system to start with, so it took several hours to figure out what was wrong and how to work around it.) But this is clearly a bad answer in the long run because it mucks up the PJL options passed in by clients. So, is there a "real" fix? Or is cupsomatic going to get replaced by foomatic-rip sometime soon? Version-Release number of selected component (if applicable): foomatic-2.0.2-15.1.1 How reproducible: Always Steps to Reproduce: 1. Install a Lexmark Optra S 1855 PostScript printer. 2. Make the printer available as a Samba share. 3. Print to the printer from a Windows application using the Lexmark PostScript printer driver. Actual Results: Printer warms up but nothing prints. Expected Results: Material from Windows client should be printed. Additional info:
The move from cupsomatic to foomatic-rip will happen in a future release, but is too big a change for doing in an update. Just to clarify the situation: you have a Windows machine sending PJL-wrapped PostScript to the samba share on the Linux machine, but the Linux machine is trying to munge the PostScript? I think you need to set the queue up as a raw print queue for that situation. In other words, you should only need to tell one of the computers what type of printer it is.
About the clarification: There are two problems. The first one is that cupsomatic can't handle a filename passed to it on the command line. As far as I can tell that's exactly what happens with it's used with Samba, and the result is that cupsomatic simply fails (producing the error message "inputfile handling is broken!!!"). Without a workaround for that, you never run into the second problem. As for the second problem, yes, the Windows machine is sending PJL-wrapped PostScript to the samba share on the Linux machine. Here's what happens after that. CUPS decides that the file is of MIME type application/vnd.cups-postscript because it passes the tests around line 134 of /etc/cups/mime.types. Note that those tests specifically allow for PJL wrapping. application/vnd.cups-postscript files get filtered by cupsomatic because that's what the printer's PPD defines in its "cupsFilter" attribute. However, cupsomatic chokes because the very first characters in the file aren't the PostScript magic string "%!". (They're actually the PJL magic string "<0x1B>%-12345X".) cupsomatic seems to have code for parsing the PJL options, but it never gets invoked because the test for detecting PostScript is wrong. About the raw print queue: Yeah, I tried that before writing the wrapper for cupsomatic. The problem is that the raw queue passes *everything* sent by the Windows machine directly to the printer. The printer doesn't understand the PJL options that the Windows drivers prepend to the PostScript file, so it just generates PostScript errors and prints nothing. I certainly could be misunderstanding something about how the system is supposed to work, but it looks to me like things are basically OK with the exception of the two problems in cupsomatic itself.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.