interleaving pages of jobs

Helge Blischke H.Blischke at srz-berlin.de
Sat Sep 11 10:09:30 PDT 2004


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

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




More information about the cups mailing list