cups banners, scheduling and interoperability questions

[Helge Blischke]

Well, if the printer in question is serviced by one and only one CUPS
server and by
nothing else, the different files of different jobs should not
interleave (note,
the banner pages are treated much the same as a jopb consisting of
multiple files).

But, if there are other sources of print jobs than one single CUPS
server, 
interleaving may certainly happen. As a workaround you could try the
alternate
pstops filter which supports built-in banner pages (i.e. banner pages
prepended and
appended to the job files itself, not as separate files), though the
contents
and the layout of these pages must be programmed in PostScript.

Helge


David Decotigny wrote:
> 
> Hi,
> 
> 1st question
> ------------
> 
> We have the following configuration : 1 cups server, 1 printer (HP
> Postscript over ethernet), *2 queues* for this printer (1 for duplex, 1
> for single-side printing, for historical reasons), multiple unix clients
> (cups client). And, for each job we want to print *a banner*.
> 
> The question is : if 2 clients send their printing requests to the
> server "at the same time" on the 2 queues, could the jobs' banner and
> document pages interleave ?
> 
> I mean: client A sends a job on queue Q1 with the banner "A_banner" and
> the document contents "A_contents", and at the same time client B sends
> "B_banner" and "B_contents" on the other queue Q2: could it happen that
> the server schedules the 2 jobs (banner + contents) in the following order :
>    A_banner
>    B_banner
>    A_contents
>    B_contents
> ... so that the pages are interleaved on the printer ?
> 
> For what I understand, 1/ cups actually treats the banner and the
> document contents as 2 distinct tasks and 2/ cups sees 2 distinct queues
> and does not care whether these queues correspond to the same physical
> resource (the printer). So I think this can actually happen... please
> tell me I am wrong...
> 
> If I am unfortunately right, is there a way to change this behavior in
> the cups configuration ? Where to look at in the source code to make the
> change ?
> 
> Related question : and if there were only ONE queue for the printer, are
> we assured that the banner and document contents will never interleave ?
> ie that we'll allways have something like:
>    A_banner
>    A_contents
>    B_banner
>    B_contents
> In that case, a dirty hack would be to define 3 queues: 1 "top-level
> queue" for the physical printer (not available to the clients), and the
> 2 "client-level queues" available to the clients that simply redirect
> their jobs to the "top-level queue". But this raises another question:
> where should the banner be printed ?
>    - By the "top-level queue" only ? But what about the
> "job-originating-user-name" and "job-originating-host-name"
> substitutions in the banner ? will they be set to "root" and "localhost"
> (because the client-level queues sending the jobs to it are run by
> cupsd, ie by by root on localhost) ?
>    - By the "client-level queues" ? but in that case, is it sure that
> the banner and documents contents will NOT interleave ? Because it seems
> that it is equivalent to printing 2 distinct pairs of job
> (A_banner+A_contents and B_banner+B_contents), so that in the end we
> could still get the wrong schedule:
>    A_banner
>    B_banner
>    A_contents
>    B_contents
> (depending on the way the OS schedules the connections from the
> "client-level queues" to the "top-level queue" server socket) Am I wrong ?
> 
> I'd be happy if cups effectively schedules two queues targetting the
> same physical printer as one single physical resource ! I'd be equally
> happy if cups can send both the banner and the job contents over the
> same TCP connection !
> 
> 2nd question
> ------------
> 
> Now imagine we have windows machines. If the windows machines don't
> print through the cups server, obviously they can interleave their jobs
> between a cups banner and the associated document. Ie we can have (and
> we DO have) :
>    Unix_banner
>    Windows_job
>    Unix_contents
> Which is a bit annoying. The problem comes from the fact that the banner
> and the document's content are 2 distinct jobs from the printer's point
> of view. The 1st question was related to internal cups scheduling, this
> one is more independent on cups. Am I wrong ?
> 
> So, what is the best solution to make the windows machines print through
> the cups server, which would centralize the scheduling of the jobs ?
>    - setup a samba server on the cups server ? I tried it, with the cups
> server printing the banner. But the "job-originating-user-name" and
> "job-originating-host-name" always say "nobody"/"localhost" (which is
> normal since the smb stuff is run as nobody on the cups server). I also
> tried to make the windows client include the banner at the beginning of
> its job (windows printer "properties" wizard), but for a strange reason,
> the printer does not print it...
>    - Is there another way to do this ? IPP (how on windows clients ?) ?
> Will the "job-originating-user-name" and "job-originating-host-name"
> substitutions reflect the correct user/host name ?
> 
> (re) I'd be happy if cups can send both the banner and the job contents
> over the same TCP connection !
> 
> Thanks a lot in advance for your answers !
> 
> --
> David Decotigny -- LLR -- http://polywww.in2p3.fr

-- 
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de
tel: +49 30 75301-360