[cups.general] RAW queue en 9100 printing

[Helge Blischke]

Dennis Leeuw wrote:

> 
> 
> On 02/28/2013 01:50 PM, Helge Blischke wrote:
>> Dennis Leeuw wrote:
>>
>>> On 02/28/2013 12:47 PM, Helge Blischke wrote:
>>>> Dennis Leeuw wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> For all our windows printer queues we used to use IPP to the printer
>>>>> and a RAW queue on CUPS and that worked fine, till a couple of weeks
>>>>> ago we received a Xerox WC7556 printer. After a lot of tweaking and
>>>>> testing I found that the only solution to make it work is to use port
>>>>> 9100 + RAW printing.
>>>>>
>>>>> When we use IPP and RAW and we send a job that has to print 2 copies,
>>>>> only one is printed.
>>>>> When we use 9100 and RAW then all works fine.
>>>>>
>>>>> That fact that we found a solution is great, but I also would like to
>>>>> know why. Can someone explain to me what the difference is and how
>>>>> this works? Or can someone point me to the direction how to find out
>>>>> what goes on?
>>>>>
>>>>> We are using Windows XP, CUPS 1.4.3 on Ubuntu.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Dennis Leeuw
>>>> I guess the IPP issue is due to the fact that in this case IPP job
>>>> attributes take precedence over the respective settings of the
>>>> PostScript job itself (an issue I already detected some time ago when
>>>> using the java based IPP implementation in Xerox DocuTech printers).
>>>> CUPS inserts a copies value of 1 in the printing IPP requests (as this
>>>> is the default) which corresponds to the command line options for the
>>>> filters and backends.
>>>> I then hacked the IPP backend (starting with 1.3.5) to discard the
>>>> copies attribute from the IPP request unless explicitely specified, so
>>>> that the copies spec in the PS job got activated again.
>>>> If you are interested, I could send you this (brute force) hack which
>>>> could easily adapted to the 1.4.3 backend, but you then need to get the
>>>> cups 1.4.3 sources, compile from the sources, and replace the original
>>>> ipp backen.
>>>>
>>>> Helge
>>>>
>>>
>>> Thank you for your explantion this sounds exactly like what might be
>>> going on. For now the 9100 printing solution is workable.
>>>
>>> I am going to put wireshark on the wire, to see if I can find the
>>> command where it says 1 copy instead of two. Sounds like another mistery
>>> solved.
>>>
>>> Thanks,
>>>
>>> Dennis
>>
>> You only need to inspect the /var/spool/cups/cnnnnn files, where nnnnn is
>> the respective job ID with leading zeros and look for "copies" and the
>> following binary integer value.
>> On the other hand, within the PS job, there will be a PostScript
>> statement like
>> #copies 2 def
>> or
>> /NumCopies 2 def
>> specifying your 2 copies, but CUPS doew not know about that.
>>
>> Helge
> 
> Cool!
> I ran the cnnnnn file through hexdump and after "copies" I get:
> 00 04 00 00 00 02 21 00
> 
> The 02 is the amount of copies, and the "prefix" is always 00 04 00 00
> 00". Is that always true or is there a deeper meaning?
> 
> Thanks for the help. I am learning a lot today.
> 
> Greetings,
> 
> Dennis

The  04 is the length of the following value field, i. e. 4 bytes. As the 
value is 2, the printer *should* print 2 copies. Thus there must be some 
other reason why the printer only prints 1 copy when used through the IPP 
interface. Could you post (an URL to) toe PS file which exhibits the issue?
If you set the cups queue to a stop, you'll see the file to print in
/var/spool/cups/dnnnnn-001
where again nnnnn is the job ID.

Helge