interleaving pages of jobs

John Beamon jbeamon at trap.franklinamerican.com
Mon Sep 13 11:52:50 PDT 2004


Helge Blischke wrote:
> John Beamon wrote:
> 
>>Helge Blischke wrote:
>>
>>>John Beamon wrote:
>>>
>>>
>>>>cups 1.1.19 on departmental print server and workstation, both RHL9.
>>>>Canon iR-3300 printer near the server.
>>>>
>>>>1.  If I set up the Canon as a local queue on the workstation, so that
>>>>the workstation talks directly to the Canon without the department cups
>>>>server, I have no problem.  I can submit job1 and job2 and job3 almost
>>>>simultaneously, and they spool into the printer and come out collated
>>>>into separate jobs.
>>>>
>>>>2.  If I set up the Canon as a print queue on the department cups server
>>>>and have the workstation browse the cups server for its printcap, I have
>>>>a problem.  I can submit job1 and job2 and job3 almost simultaneously,
>>>>and they spool into the printer and come out as if someone had taken two
>>>>new decks of cards and shuffled them together.  The pages come out like so.
>>>>
>>>>job1-1
>>>>job1-2
>>>>job2-1
>>>>job1-3
>>>>job2-2
>>>>job2-3
>>>>job1-4
>>>>job1-5
>>>>job2-4
>>>>job1-6
>>>>
>>>>The correct word for this is "interleaving", but there are no Google
>>>>results for "cups interleav" that have anything to do with printing in Unix.
>>>>
>>>>Any suggestions?
>>>>
>>>
>>>
>>>Are you using banner pages (option job-sheets=...)?
>>>Or are you printing each page as a separate file?
>>>
>>>Helge
>>>
>>
>>On that particular printer, we were using job-sheets=standard.  However,
>>  printing each page as a separate file is a separate issue.  In brief,
>>when we first installed CUPS, our particular documents were splitting
>>4-page docs into 4 separate one-page jobs, each with a cover sheet and a
>>different job ID.  We uncommented the two "application/octet-stream"
>>definitions in /etc/cups/mime.*, and that problem went away.  We now
>>print those same docs as cover + lots of pages in order.  However, when
>>we send two docs within a near time frame, job 2 will filter its pages
>>in during the output of job 1.
>>
>>This might be a CUPS issue, or it might be a Canon iR-3300 issue.  We
>>ONLY observe it when we queue from the workstation to the CUPS server,
>>not when we queue from the workstation to the Canon.
>>
> 
> 
> Yes, that is the problem. CUPS 1.1.x *does* process every file of a job 
> indifidually, and there are no precautions against interspearsing these
> files if the job come from different sources. THis *will* be fixed in
> CUPS 1.2
> as Michael Sweet stated more than once.
> For that very reason, I recently updated the alternate pstops filter to 
> provide user defined (by PostScript procedures) job sheets that are part
> of the
> file to be printed (option banner-pages=...), but cover handling is
> still
> not settled (some vendor's production printers support the cover-xxx
> collection
> attribute via IPP (or a similar option via their legacy interface), but
> as 
> "normal" bureau printers usually don't support things like this, I think
> of
> enhancing the alternate pstops filter to produce cover pages as well,
> but
> that will take some time, still).
> 
> Helge
> 

Pardon me for not noticing Michael Sweet's comments, but I haven't found 
any of the "more than once" references to this problem.  It might be a 
language issue, getting the use of "interleave" or "interspearse" or 
"shuffle" just right.

Just so I understand clearly, by "every file of a job", do you mean 
"every PAGE of a job"?  It's important to me.  Our jobs only contain one 
file each.  Simultaneous jobs will come out of the printer mixed 
together in a big stack of paper.  I will get the alternate pstops 
filter and start testing this week.  Thanks for your contribution.

-j




More information about the cups mailing list