Inserting Multi-page PDF variable graphics

[Dan Korn]

Originally Posted by IndexxPrep

Using this rule to place 8.5 x 11 PDF files that may or may not have .125" bleed. I am getting mixed results as far as the art centering in the text box. I have been using alignh and alignv with mixed results. I also noticed that in the supplied code you use position="afterline". If I remove that the horizontal positioning works perfect, however the art is top aligned in the box. I do not see any documentation on 'position' in the tag reference or user's guide. Any way to just center without scaling regardless of bleed box dimensions? See section of code below.

    //This is the secondary loop for this script.
    //It will loop through and create markup for each page in the PDF.
    for (pageLoop = 1; pageLoop <= pagesInPDF; pageLoop++)
    {
        markupToReturn += '<graphic file="' + PDFresourceRef.name + '" pagenumber = "' + pageLoop + '" scale="off" alignh="center" alignv="center" />';

        markupToReturn += '<P>';
    }

You could try specifying a different bounding box, by adding an attribute such as pdfbboxtype="MediaBox". (Valid values are "CropBox" (the default), "MediaBox", "BleedBox", "TrimBox", and "ArtBox".) Without seeing the graphics, I'm not sure exactly what effect it will have, but you could play around with that.

Also, the attributes for scale, alignh, and alignv apply only to graphics in graphic frames, and have no effect on inline graphics in text frames, which is what these are.

If you know how many pages there are going to be ahead of time, or at least the maximum, then instead of using inline graphics in a text flow and overflow pages, you could specify multiple body pages with graphic frames, which would allow you to utilize all the graphic scaling and alignment options. You could use the FusionPro.Composition.SetBodyPageUsage function to suppress the extra pages in each record. This is a bit more work to set up, but it might be worth it for the scaling options.

[IndexxPrep]

Thanks for the info. After much trial and error, I have somewhat combined the two methods and now have a properly working product. Thanks so much for all you do Dan! You rescue us all when we're in a rut.

[Hadrian]

Anyone figure out the centering issue or glitch with this type of inline usage?

[IndexxPrep]

@Hadrian,
The only way I could get this to work for my situation was to use a graphic box method instead of the text overflow method. Because my situation had to handle files with bleed and files without bleed, this was my only option as I could not get the overflow method to center properly for all scenarios. I put the following rule in a text rule. I create a graphic box on page 1 called "Front" and another on page 2 called "Back" and I do not assign any rule or variable field to the graphic box, the rule will do that.

Here is my code:

FieldName = '';
PDFfileName = '';
pagesInPDF = 0;
markupToReturn = '';
pathToAllPDFs = 'Macintosh HD:Users:macuser01:Desktop:resources:'; /* change "pathToAllPDFs" value to the path where your local test files are located /*
pathToPDF = '';
PDFresourceRef = '';

var FrontFrame = FindGraphicFrame("Front");
var BackFrame = FindGraphicFrame("Back");

//This is the main loop that parses through all of the fields for a given record.

PDFfileName = Field("File");
pathToPDF = Field("File");  /* this one should be uncommented for marcom central */

/*pathToPDF = pathToAllPDFs;  //uncomment this and comment out the one above to preview on a local machine  */

//Create a new resource that references this
PDFresourceRef = CreateResource(pathToPDF ,'graphic' ,'no');

//Find out how many pages it has
pagesInPDF = PDFresourceRef.countPages;

//This is the secondary loop for this script.
//It will loop through and create markup for each page in the PDF.
if (Field("Sides")=="1"){
for (pageLoop = 1; pageLoop <= pagesInPDF; pageLoop++)
{
FrontFrame.SetGraphic('<graphic file="' + PDFresourceRef.name + '" pagenumber = "1" scale="off" />');
return pathToPDF;
}
}else if (Field("Sides")=="2"){
for (pageLoop = 1; pageLoop <= pagesInPDF; pageLoop++)
{
FrontFrame.SetGraphic('<graphic file="' + PDFresourceRef.name + '" pagenumber = "1" scale="off" />');
BackFrame.SetGraphic('<graphic file="' + PDFresourceRef.name + '" pagenumber = "2" scale="off" />');
return pathToPDF;
}
}
}
return pathToPDF;

return markupToReturn;�

Hope this helps you!

[Hadrian]

@IndexxPrep

Ok I got it. I am going to use a combo as well. I appreciate it.

[jreynolds]

I've used this script many times without an imposition, but am having trouble using an imposition template with an infinite stack.

In the attached sample, I'm trying to get the "AK" version with 14 pages to print 3 times, the "GTC1" version with 23 pages to print 4 times, then the "SSG" version with 22 pages to print 5 times. However, it seems that since the "AK" version is first record, it composes the last 2 records with only 14 pages too and I get the error message:

The number of pages in this record does not match the imposition signature: 9 pages will be truncated.

From another thread, I tried adding these lines in OnJobStart, but it sounds like that is uneccessary:

//FusionPro.Composition.chunksBreakStacks = true;

//FusionPro.Composition.forcePreprocessing = true;

So what's the trick for getting variable page PDFs to work with infinite stacking imposition?

[esmith]

I don't believe stacking works with projects where each record has a different number of pages output. When job begins to compose FP Imposer presumably calculates total number of records and multiplies that times number of pages in layout/first record to determine total pages which is used to determine where to break each stack (and thereby determine total number of sheets). This process does not take into account that each record might have different number of pages based on rules since they have not processed yet.

I have always had to output single pages in this scenario and use 3rd party imposition software for the stacking process.

I will be thrilled if I turn out to be wrong!

[jreynolds]

Thanks esmith. I think your solution of imposing after processing is the way to go for now. Hopefully a fix is in the works for using this great script with infinite stack imposition.

[Dan Korn]

Originally Posted by esmith

I don't believe stacking works with projects where each record has a different number of pages output.

I would make a more general statement: Imposition expects each record to output the same number of pages, whether you're doing stacking or not. There's a setting in FP Imposer where you enter the number of pages per record.

Originally Posted by esmith

When job begins to compose FP Imposer presumably calculates total number of records and multiplies that times number of pages in layout/first record to determine total pages which is used to determine where to break each stack (and thereby determine total number of sheets).

Yes, there's a preprocessing step which determines the number of records, and where the stacks and chunks will break.

Originally Posted by esmith

This process does not take into account that each record might have different number of pages based on rules since they have not processed yet.

Well, it's not so much that preprocessing doesn't expect records to have different numbers of pages; it's that the entire imposition system doesn't expect it.

Originally Posted by esmith

I have always had to output single pages in this scenario and use 3rd party imposition software for the stacking process.

I will be thrilled if I turn out to be wrong!

No, you're not wrong. Although it's not clear to me what the expectation is if you define a signature of, say, 2-up for a business card with a front and a back, and then you output three pages from a record.

[esmith]

Originally Posted by Dan Korn

Although it's not clear to me what the expectation is if you define a signature of, say, 2-up for a business card with a front and a back, and then you output three pages from a record.

It would be nice to have the option of creating business cards (using your example) for 500 employees while generating different quantities for each employee based on title (i.e. executives get 300 each; administrative/sales gets 500 each; everyone else gets 100 each). These would all be stacked by employee in one print-ready file.