Package: foomatic-filters
Version: 3.0.2-20080211-3.2
Severity: normal
Hello,
When used with CUPS and Samba, foomatic-rip overrides the printing
options, ignoring the user's choice and setting them to their default
values instead. This is a different problem than bug #497671, that I
already handled.
Use case: a Windows user sends a printing job with an option
'ColorMode=Color', on a raster printer which PPD's default is
'ColorMode=Monochrome'.
Result: a monochrome print.
Process breakdown:
1. The Windows printing driver (CUPS, Adobe or Microsoft PostScript with
the printer's PPD) processes the options, embedding them into the
PostScript file.
2. The Windows SMB client sends the processed PostScript to the printing
server, without any external option, as the SMB protocol does not
support printing options.
(bug #497671, if not worked around: CUPS receives the job, passes it to
pstops, that overrides somes options)
3. CUPS receives the job, and passes it to foomatic-rip.
4. foomatic-rip identifies that it was called by CUPS, and:
4.1 l. 2879, notes that the options were given in the PostScript and
on the command line (which is wrong), but that their values are
different,
4.2 inside the 'if' bloc, replaces the PostScript value the “command
line value”, in fact the default PPD value,
4.3 l. 2977, logs the replacement.
To fix that, I simply disabled all the remplacement code between lines
2879 and 2983, but it may have broken other features.
-- System Information:
Debian Release: 5.0.2
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i586)
Kernel: Linux 2.6.26-2-486
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
