[cups.general] RAW queue en 9100 printing

[Dennis Leeuw]

On 02/28/2013 06:11 PM, Helge Blischke wrote:
> 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.

Sorry, my mistake, this was a test from a GNU/Linux machine to figure 
out what the meaning is of the different fields, since I know for sure 
it works from GNU/Linux.

2 tests from a Windows machine reveals that the control file belonging 
to a job from a Windows XP machine that prints using the HTTP protocol 
doesn't have a "copies" field.