interleaving pages of jobs

[Helge Blischke]

John Beamon wrote:
> 
> 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

Just to clarify things:
If you look into CUPS' spool directory, you'll see files like
	dxxxxx-yyy
where xxxxx is the job id created by CUPS and yyy is the file number
within 
the job. As far as CUPS is concerned, the contents of every such file is
passed to the printer as a single job. That means, if a CUPS job
consists
of more than one file, each file is fed into the printer as a job of its
own (in PostScript terminology). 
As far as PostScript printers are concerned, a PostScript job is sort of
an
"atomic" entity.

Helge

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