cupsys doesn't process postscript features

I can't confirm this behavior with a HP Photosmart C6180. Changing color to greyscale works as expected.

I've tried this on several Systems including Dapper Drake with OOo 2.0.
Every tested version of OOo has this problem but neither KDE- nor Gnome-applications.

Normally the printer options should be forwarded to the cups filter (specified in the PPD file) as arg $5. But OOo doesn't do this. So this problem only affects printer who need a cups filter.
I'll attach one of the tested PPDs.

It's curious ...

OOo passes *some* arguments but not all. I tried it again using the driver for Brother MFC-885CW. I changed every of the 16 options I could change, but only 4 of them were passed. The log file says:
> arg5 = PageSize=A4 Resolution=Fine BRColorMediaType=BrotherGlossy MirrorPrint=ON job-uuid=urn:uuid:a6ab5bd6-e799-39cc-6e2c-f1fc9b58bc20
What's about the other 12 options?

I'll add the PPD file but I don't think it's a problem of some PPDs.

FriedChicken, check also whether some of the options get executed by OOo inserting their PostScript code into the PostScript data stream.

Yes, they are all inserted into the PS code:
%%BeginSetup
%
[{
%%IncludeFeature: *PageSize A4
} stopped cleartomark
[{
%%IncludeFeature: *Resolution Fine
} stopped cleartomark
[{
%%IncludeFeature: *BRMonoColor BrMono
} stopped cleartomark
[{
%%IncludeFeature: *BRColorMediaType BrotherGlossy
} stopped cleartomark
   [...]
%%IncludeFeature: *BRSlowDrying ON
} stopped cleartomark
%%EndSetup

But this is useless for cups filters (not only them from Brother), because they expect to get the options as arg $5. And every application (KDE and Gnome/GTK) does this as expected, but OOo not.

@ Chris Cheney

Are you really sure this is a problem of cupsys? I'm not ...
There should be no need for a cups filter to look into the PS file. And every application else than OOo handles this right by passing the correct options.

A workaround is it to use kprinter as pseudo-printer and set the options in the kprinter dialog. That's not really satisfying but shows that this is a bug in OOo and not CUPS.

FriedChicken,

As you yourself showed in the resulting postscript it set options that should have been parsed by cupsys. Now maybe you could argue that openoffice.org should also send those options directly to cupsys, but cupsys should also know how to print proper postscript documents sent to it.

Chris

No, cupsys has not to parse the PS file. PS printers should, but CUPS filters (that are used by non-PS printers) don't necessarily need to. So it's a OOo bug.

FriedChicken,

So does cupsys pass the postscript as generated by OpenOffice.org directly to the printer? OpenOffice.org sends postscript as its print format (will be changing to PDF soon) to cupsys which then converts the postscript into whatever format that the print can understand so yes cupsys probably should be intrepeting the options being sent to it in postscript.

Chris

Till,

Feel free to weigh in on this discussion, I am be no means a printing expert, but it seems cupsys should be processing these options?

Chris

I'm no printer expert, too, and weren't shure. But now I took a look into the CUPS documentation:
   filter - cups file conversion filter interface
   Synopsis
   <filter> job user title num-copies options [ filename ]
from: http://cups.org/documentation.php/man-lpadmin.html (or man filter)

So the options-argument is not optional and OOo has to pass this argument. If OOo uses lp or lpr each option hast to be passed as "-o=option1".

Till, please correct me, if I'm wrong.

Well even with the options passing as documented by cupsys to be used, it would be at least a wishlist bug if not more for cupsys to also properly parse options from postscript files sent to it, since it otherwise processes the postscript file before actually sending it to the printer.

Chris

Usually the CUPS filter which converts PostScript into another format (for most drivers pstoraster or foomatic-rip) is supposed to read out the option settings embedded in the PostScript data stream. For the HP Photosmart C6180 the foomatic-rip filter is used and therefore the problem does not occur. For the Brother printers Brother's proprietary drivers are used. The CUPS wrappers (/usr/lib/cups/filter/brlpd*) do not read option settings from the PostScript input stream. The filters /usr/Brother/lpd/filter* and /usr/Brother/lpd/psconvert* pass the PostScript inout directly into Ghostscript, without parsing option settings which are embedded. So all embedded options without active PostScript code to control Ghostscript get ignored. This is a bug in Brother's drivers.

There is definitely no CUPS bug.

Reassigning this bug to brother-cups-wrapper-common, not sure which Brother package it really belongs on.

Yes in brother-cups-wrapper-common there is the ppd file for this printer. Marking to confirmed.

FriedChicken, thank you for reporting this bug to Ubuntu. Dapper Desktop reached EOL on July 14, 2009.
See this document for currently supported Ubuntu releases: https://wiki.ubuntu.com/Releases

We were wondering if this is still an issue in a supported release? If so, could you please execute the following via a terminal as it will automatically gather and attach updated debug information to this report:

apport-collect -p brother-cups-wrapper-extra 222602