interleaving pages of jobs
John Beamon
jbeamon at trap.franklinamerican.com
Thu Sep 23 09:08:08 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
>
Please help me understand. What does the updated pstops utility have to
do with me printing multi-page TIFF files? My CUPS package provided my
pstops binary, and I've been unable to build the updated pstops on the
website. What change could I expect in my own problem situation with an
updated pstops?
--
-j
More information about the cups
mailing list