0

I have to print big jobs (mixed parts lists as PDF and drawings as TIF) using different lp options. All these jobs should be printed without any other print job between. I figured out, I can use lp -H hold .... and at last lp -i plot_job -H resume, but not with more plot jobs together.

Has anybody an idea to handle such jobs ?

Example:

3 sets containing:
{
. 1 x start_page
. 2 x first_part_list
. 2 x first_drawing
. 2 x second_part_list
. .
. .
. .
. 1 x end_page
}

Horst
  • 67
  • 7
  • I think cups is the wrong place to address this; more appropriate would be a step that combines the various PDFs and TIFs into a single PDF file, which could be printed without interruption by other print jobs. – chepner Apr 16 '14 at 13:31
  • Yes, it seams to be the only possible way. – Horst Apr 18 '14 at 12:34
  • So I create postscript files in the right size and put them together in one file. And at last I use "lp -oraw ..." to print them. This works by just appand the files. – Horst Apr 18 '14 at 12:44

1 Answers1

0

I'd suggest you define a "special purpose print queue" for such tasks, addressing the same physical printer as the "normal" print queue. That way you can put the normal queue on hold, so the queues where "other" print jobs are pushed to, whilst processing your special print queue without interruptions. You can even script such sequence.

arkascha
  • 41,620
  • 7
  • 58
  • 90
  • With this solution, I would have to generate **a seperate print queue for each job.** That sounds very complicate. – Horst Apr 16 '14 at 13:20
  • Why that? Why can't you feed multiple jobs into the queue and print those? – arkascha Apr 16 '14 at 13:24
  • Because there are a lot of users printing such jobs. – Horst Apr 16 '14 at 13:29
  • As said: you can script that solution. Prepare a script accepting an arbitrary number of documents to print. The script pushes the documents in the "special queue", halts the "normal" queue, activates the "special queue", waits for the jobs to finish. Then it deactivates the "special" queue again and reactivates the "normal" queue. In addition the scripts implements a locking strategy: the script may be used multiple times in parallel, also by different users, but it takes care that only one instance can ba active at a given moment. All other instances are delayed. – arkascha Apr 16 '14 at 20:05
  • You are right, for small jobs this would be OK. But the problem on this solution is, these print jobs some times take up to 1 or 2 days, so the others would not be able to print during this time. – Horst Apr 17 '14 at 05:38
  • 1
    Well yes, but that is _exactly_ what you ask for, isn't it? That whilst one meta job is printed nothing else should interfere? Note that others might very well _start_ their print jobs. Just the _processing_ is delayed until prior jobs have finished. – arkascha Apr 17 '14 at 08:08
  • It would be a good improvement, if we could print more jobs together and not just stick them together in one file. – Horst Apr 22 '14 at 09:34