CUPS not printing via ipp: protocol

[Scott Sharkey]

Guys,

The fact is that this used to work, in Hoary, and in Breezy, and in 
almost every other version of Linux that I have tried.  And in most of 
those cases, it still works.  So, while we have found a workaround, it 
is genuinely a bug, unless someone can show me documentation that this 
is now the intended behaviour.

-Scott

gborzi wrote:
> Rich Lott;1381196 Wrote: 
>> Thank you gborzi!
> 
> 
>> I have TWO ways to get it working.
> 
> 
>> 1. as gborzi said, on the client machine use Raw Queue driver. This
>> works 
> 
>> fine, but it means the client has no control over the printer functions
>> (eg. 
> 
>> quality, media...)
> 
> 
>> 2. same principle, add the printer to the server, using the Raw Queue
>> driver. 
> 
>> Set the client up with the drivers, pointing to the raw queue. This way
>> the 
> 
>> client /can/ control the driver settings, and it works too.
> 
> 
> 
> 
> Thanks to you for solution 2). I didn't foresee this one.
> 
> 
> 
> 
>> I'm really happy to have found a solution. I still think this is a bug
>>
> 
>> though -- the cups server should be able to tell whether a data stream
>> is 
> 
>> postscript or whether it's in raw printer language and adjust
>> accordingly. 
> 
>> Clearly this is what the Windoze box feeds it, and it is correctly
>> identified 
> 
>> by the cups server and passed to the printer.
> 
> 
>> Anyone think it's worth raising it as a bug in Ubuntu?
> 
> 
> 
> 
> It can be also viewed as a "feature". Let's suppose that you want to
> enforce option for the print server (e.g. toner saving). With solution
> 1) this can be done. With 2) you leave driver option freedom to the
> clients. As for Windows box, I think they can still work with solution
> 1) by using a generic Postscript printer driver on the client for the
> network printer.
> 
> Rather than a bug I would speak about a lack of information, I wasn't
> able to find anything related to this change in cupsys changelog and
> other docs. Perhaps it was mentioned somewhere.
> 
> Such a change in behaviour should be clearly pointed to.
> 
> 
> 
> 
>> relieved, rich
> 
> 
> I'm relieved too. The client.conf solution was not ideal.
>