Bug 113424 - cupsomatic filter causes samba PostScript printing to fail
cupsomatic filter causes samba PostScript printing to fail
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: foomatic (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-13 14:29 EST by Allen Akin
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:31:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Allen Akin 2004-01-13 14:29:23 EST
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:
Comment 1 Tim Waugh 2004-01-21 05:30:07 EST
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.
Comment 2 Allen Akin 2004-01-21 12:43:48 EST
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.
Comment 3 RHEL Product and Program Management 2007-10-19 15:31:24 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.