in-postscript media-type request stripped by pstops?

[blinkety bill]

Hi,

I have a problem trying to print to transparency using Xerox print driver via CUPS.

I suspect the relevent code is tripped out by pstops.

The code is I think this:

featurebegin{
%%BeginFeature: *MediaType Transparency

 xerox$pagedevice /TraySwitch get {xerox$pagedevice /MediaClass (Transparency) put} if

%%EndFeature

Is this a bug?

Is there a way to make CUPS behave in a sensible fashion without hacking mime types/convs in insensible ways or without resorting to a 'raw' queue which would prevent being able to set up the same print queue to handle non-postscript automagically?

It seems I'm stuck with either

(a) cups will pass raw print jobs, so postscript will be handled

(b) cups will strip back to 'sanitised', target-neutral postscript

or

(c) have two print queues, one used by windows which is raw, other used by linux, which will automagically handle non-postscript.

In fact, I want (d) cups strips stuff that is known useless, and leaves stuff that is postscript-compliant and may be telling the printer to do something.

This seems reasonable, I'm not sure what the stuff that cups does need to strip does, I've only read about it and heard that it chokes if its not stripped. That seems kind of amateur to me. Postscript is a language, that poses challenges, but to me, stripping ALL vendor code is throwing the baby out with the bath water.

(b) seems to be what I would want when printing to file for distribution, not what I want when printing to network print server for hardcopy output on a specific device.

Am I misunderstanding? If not, I'm sure that this particular mechanism is the root cause of 99.9999999999999999 recurring percent of all CUPS admin headaches. Am I right, or am I right?

blinkety bill