Counting overflow pages

[LMC]

Is there any way to get a list of all the overflow pages in a document and insert the results into the XML log file when composing? For example a CSV string of the page numbers?

 

I've just taken a handover of the FusionPro development from another dev who left suddenly, so I'm still finding my way around the product - this was one of the undeveloped features, but is it even possible?

[Dan Korn]

The XML Log File will automatically report the total number of pages in each output record. However, it doesn't tell you which Overflow pages were invoked. I don't think there's a reliable way to report that. What are you trying to do with this data?

[LMC]

Thanks Dan. We're trying to identify which are the overflow pages so we can send them to a different printer. The printing process is automated by in-house software, and since the overflow pages are printed on one type of paper and the rest of the document is on another, we need to send the overflow pages to a different tray and/or printer.

 

At the moment the operators have to sight the document manually - since there can be thousands of pages in the document and maybe only a few overflow pages, it's a time consuming process for them to weed out the overflows.

 

If we can't determine which are the overflow pages, how hard would it be to make a change to the software to allow it?

[Dan Korn]

Thanks Dan. We're trying to identify which are the overflow pages so we can send them to a different printer. The printing process is automated by in-house software, and since the overflow pages are printed on one type of paper and the rest of the document is on another, we need to send the overflow pages to a different tray and/or printer.

 

At the moment the operators have to sight the document manually - since there can be thousands of pages in the document and maybe only a few overflow pages, it's a time consuming process for them to weed out the overflows.

Okay, now I see what you're really trying to accomplish. Instead of having to sort through a metafile to figure out what pages need to be printed on what paper, FusionPro can embed that information directly into the output so that the press handles tray switching automatically.

 

What output format are you using, and what version of FusionPro? If it's a PostScript-based output, and you're using FusionPro 7.0 or later, you can use the PPD Settings to insert a tray switch command in the output. If it's VDX, you can use the Page Media settings. The upcoming 7.2 release will offer JDF-based subset finishing for all output formats.

[LMC]

We're outputting PDF and the version of FusionPro is 5.8.

 

The problem with the postscript injection is that the mail is merged overnight server side and sent to the mail room as plain PDF - the printers then just print the document to any printer they like (there's 4 different makes of printers) so the tray selection command would have to be inserted as it is sent to the printer since that's chosen at print time. I managed to send the PDF to the printer driver by converting it to postscript and then injecting the relevant commands in the page setup section, but unfortunately the postscript drivers for some printers don't have all the features of the PCL ones (or RPCS in the case of the Ricoh printers), so postscript is out.

 

The metafile is preferred because the software we're developing allows the print operator to select any printer they like for a specific job - the config files contain all the data necessary to identify which pages need to be grouped. For example, the original document is four sides; pages 1/2 are duplex on one type of paper and 3/4 is another type of paper. Both pages are often the same size, just printed on different artwork (we have the artwork on our paper preprinted, and the PDF we print just has the variable data).

 

So a config file is sent along with the PDFs identifying which pages are grouped, so the operator just selects 'group 1' to be sent to tray 1 of printer A and 'group 2' to tray 2 of printer A (they're collated on the fly).

 

The problem is the overflow pages get in the way and mess up the sequence; there might only be one or two overflow pages in a file of 10000 pages but that's enough to cause grief. If we could identify which ones are the overflow pages we could then pull that page from tray 3 (or another printer since some of the printers only have two usable trays, and then insert them manually).

 

Btw, we're using a third party library to send the PDFs to the printer, so we have the option of setting a specific tray for each page without relying on postscript.

[Dan Korn]

I think that the JDF-based subset finishing, in the upcoming FusionPro 7.2 release, will meet your needs. JDF is designed to be independent of the output format, so it works just as well with PDF-based output as with PostScript-based output. And it abstracts out concepts like tray selection (really media selection), so that you don't have to know the exact commands for a specific device as with PPD files.

 

However, it obviously depends on how JDF-aware your printer, or printer cluster manager, is. But the JDF standard is the way of the future for this kind of subset finishing in the digital printing industry, so I think you will be well-served to adopt a JDF-enabled workflow.

 

Back to your original question, the answer is still No, the XML log file can't be set up to report which output pages are from Overflow pages and which are from Body pages in your template. As to how hard it would be to enhance FusionPro to do that, I'm not really sure. But I still think the right way to approach this problem is to leverage JDF instead of coming up with your own standard.