Multi Page Document to Saddle Stitch Imposition

[Mattcooper]

Greeting all,

 

After many years of working with Fusion Pro I finally ran into a problem I can't seem to find a solution for.

 

I have a document setup with 10 pages each page is different. The first column in my data set tells me what page should be used and I have written a script that turns on the correct page based on this field.

 

All that works, but the problem is that this data set is building 1000 different saddle stitch books of varying sizes all with custom information. The books can be anywhere from 4 pages to 32 pages in size. I know where they break based on the first field all books start with a letter and end with a back. The problem is I can't impose the document the way it is since every page is seen as a new record the imposition will only impose a single page and not the full range. I can not seem to find anything that lets me define a range of records to impose.

 

I can get the file to compose single PDFs of each book, but this is not the best way because than I have 1000 PDFs to print instead of 1 PDF or 1 VDX file. Speaking of VDX files that as the same problem as the imposition it sees every page as a single record so I can not impose it on press ether.

 

Here is how the merge file is setup

 

Letter

Report

QA

FF

rFiller

ProFund

ProFiller

Filler1

Filler2

Back

 

The OnRecordStart Code

 

if (Field("PageType") == "Letter") {
FusionPro.Composition.OpenNewOutputFile(Field("Donor ID") + "-" + Field("Donor Name") + "-Qty" + Field("Quantity") + "." + FusionPro.Composition.outputFormatExtension);
}

if (Field("PageType") == "Letter") {
FusionPro.Composition.SetBodyPageUsage("Letter",true);
}
else if (Field("PageType") == "Report") {
FusionPro.Composition.SetBodyPageUsage("Report",true);
}
else if (Field("PageType") == "QA") {
FusionPro.Composition.SetBodyPageUsage("QA",true);
}
else if (Field("PageType") == "FF") {
FusionPro.Composition.SetBodyPageUsage("FF",true);
}
else if (Field("PageType") == "OUFiller") {
FusionPro.Composition.SetBodyPageUsage("rFiller",true);
}
else if (Field("PageType") == "ProFund") {
FusionPro.Composition.SetBodyPageUsage("ProFund",true);
}
else if (Field("PageType") == "ProFiller") {
FusionPro.Composition.SetBodyPageUsage("ProFiller",true);
}
else if (Field("PageType") == "Filler1") {
FusionPro.Composition.SetBodyPageUsage("Filler1",true);
}
else if (Field("PageType") == "Filler2") {
FusionPro.Composition.SetBodyPageUsage("Filler2",true);
}
else if (Field("PageType") == "Back") {
FusionPro.Composition.SetBodyPageUsage("Back",true);
}
else {
FusionPro.Composition.SetBodyPageUsage("Letter",false);
FusionPro.Composition.SetBodyPageUsage("Report",false);
FusionPro.Composition.SetBodyPageUsage("QA",false);
FusionPro.Composition.SetBodyPageUsage("FF",false);
FusionPro.Composition.SetBodyPageUsage("rFiller",false);
FusionPro.Composition.SetBodyPageUsage("ProFund",false);
FusionPro.Composition.SetBodyPageUsage("ProFiller",false);
FusionPro.Composition.SetBodyPageUsage("Filler1",false);
FusionPro.Composition.SetBodyPageUsage("Filler2",false);
FusionPro.Composition.SetBodyPageUsage("Back",false);
}

 

Here is how a report may look when generated.

 

Letter

Report

Report

QA

Report

FF

Report

rFiller

ProFund

ProFiller

Filler1

Back

 

 

So my goal is to be able to impose the varying page counts into a saddle stitch template and or create a VDX file that sees the correct number of pages per record. Ether would solve my problem.

 

If I need to clear anything up please let me know I can do everything, but share the data since it is sensitive data.

Edited October 13, 2015 by Mattcooper

[step]

First of all, welcome to the forum! For future posts, it would be helpful if you'd include the version of FusionPro, Acrobat, OS, etc in your signature. That way someone won't offer a solution that works in one version of FP but not your particular version.

 

Anyway, as you've discovered, impositions in FusionPro are setup per record. So you need keep in mind how many pages each record will produce when creating your imposition file. For example: if you want your job to duplex, you need to make sure that each record is producing 2 pages. And in your case: since you want each record to produce a signature, you need to make sure that each record produces a minimum of 4 pages.

 

You might be able to get by with importing your data as an external data file and determining which pages a particular signature needs to be enabled before composing each record but that honestly seems like a huge headache.

 

My suggestion would be to rework you data so that each record produces a signature rather than a page or as you mentioned in your original post: impose the PDF outside of FP.

 

But without seeing the template and some sample data, it's hard to really give you a more concrete suggestion.

[Mattcooper]

Thanks for the reply Step.

 

I have added that information to my signature for the future.

 

I have stripped my document of all the sensitive information and I am attaching it to this reply.

 

We have thought about reworking the data, but we have found that we could end up with over 400 columns per row to handle all the different reports. On top of that we would have to have multiple pages for each report if we say have 20 reports we would have report1, report2, report3 etc columns meaning we would have to create different pages for each one inside the merge file instead of just one report page like we have now. On top of that we would need a much larger OnRecordStart to figure out what pages to turn on and off for each row plus more variables inside the data to help figure out all that.

 

Anyway if you get a chance look over the attachment I think at this point we are stuck without a way to generate the pages than impose them based on a field.

Report.zip

Edited October 13, 2015 by Mattcooper

[Dan Korn]

For future posts, it would be helpful if you'd include the version of FusionPro, Acrobat, OS, etc in your signature. That way someone won't offer a solution that works in one version of FP but not your particular version.

Yes, this. A thousand times this.

Anyway, as you've discovered, impositions in FusionPro are setup per record. So you need keep in mind how many pages each record will produce when creating your imposition file. For example: if you want your job to duplex, you need to make sure that each record is producing 2 pages. And in your case: since you want each record to produce a signature, you need to make sure that each record produces a minimum of 4 pages.

Step is correct that imposition almost always requires that each record output the same number of pages, to match the imposition signature. However, the one exception is saddle stitch. Or at least, that's supposed to be the one exception. But, there's another wrinkle, which is that there's a bug in the version of FusionPro you're using which prevents saddle stitched imposition from being able to handle records with different numbers of pages. This is fixed in the 9.3.21 and 9.3.22 builds, which are available to download. So I think all you need to do is update to the latest version of FusionPro. (Though that's still hard to say even from the files you attached. Even though your question is about imposition, you seem to have inexplicably forgotten to include the .fpi Imposition Definition file.)

 

That said, let's talk about this:

The OnRecordStart Code

 

if (Field("PageType") == "Letter") {
FusionPro.Composition.OpenNewOutputFile(Field("Donor ID") + "-" + Field("Donor Name") + "-Qty" + Field("Quantity") + "." + FusionPro.Composition.outputFormatExtension);
}

if (Field("PageType") == "Letter") {
FusionPro.Composition.SetBodyPageUsage("Letter",true);
}
else if (Field("PageType") == "Report") {
FusionPro.Composition.SetBodyPageUsage("Report",true);
}
else if (Field("PageType") == "QA") {
FusionPro.Composition.SetBodyPageUsage("QA",true);
}
else if (Field("PageType") == "FF") {
FusionPro.Composition.SetBodyPageUsage("FF",true);
}
else if (Field("PageType") == "OUFiller") {
FusionPro.Composition.SetBodyPageUsage("rFiller",true);
}
else if (Field("PageType") == "ProFund") {
FusionPro.Composition.SetBodyPageUsage("ProFund",true);
}
else if (Field("PageType") == "ProFiller") {
FusionPro.Composition.SetBodyPageUsage("ProFiller",true);
}
else if (Field("PageType") == "Filler1") {
FusionPro.Composition.SetBodyPageUsage("Filler1",true);
}
else if (Field("PageType") == "Filler2") {
FusionPro.Composition.SetBodyPageUsage("Filler2",true);
}
else if (Field("PageType") == "Back") {
FusionPro.Composition.SetBodyPageUsage("Back",true);
}
else {
FusionPro.Composition.SetBodyPageUsage("Letter",false);
FusionPro.Composition.SetBodyPageUsage("Report",false);
FusionPro.Composition.SetBodyPageUsage("QA",false);
FusionPro.Composition.SetBodyPageUsage("FF",false);
FusionPro.Composition.SetBodyPageUsage("rFiller",false);
FusionPro.Composition.SetBodyPageUsage("ProFund",false);
FusionPro.Composition.SetBodyPageUsage("ProFiller",false);
FusionPro.Composition.SetBodyPageUsage("Filler1",false);
FusionPro.Composition.SetBodyPageUsage("Filler2",false);
FusionPro.Composition.SetBodyPageUsage("Back",false);
}

That's a lot of repetition. Believe it or not, if you set all of those pages to be Unused initially in the Page Usage dialog, then all your rule needs is this:

if (Field("PageType") == "Letter")
 FusionPro.Composition.OpenNewOutputFile(Field("Donor ID") + "-" + Field("Donor Name") + "-Qty" + Field("Quantity") + "." + FusionPro.Composition.outputFormatExtension);

FusionPro.Composition.SetBodyPageUsage(Field("PageType"), true);

[Mattcooper]

Thanks for the reply Dan Korn,

 

I have downloaded 9.3.21 to see if that would change anything sadly it doesn't. The problem is Fusion Pro is doing what it should be doing because each record really is only 1 page because of the way the data is setup. The data is setup so each record is a different page. If we where to make a single record contain all the pages for that record the record would have 400+ columns of data and we would need special pages to handle each different page.

 

For example instead of having a 10 page file like we have now to handle all the different types of books we would need a 70-100 page file which we would have to setup the variables for each different page.

 

This makes upkeep of the document a nightmare say you have to update the header information on the report pages instead of just updating the single report page in the 10 page file you have to update 40 different reports in the 70-100 page file.

 

Sorry about not including the FPI I thought I did I am attaching it to this post.

 

Thanks for the shortened code sometimes I over think simple things. Maybe I am over thinking this whole problem.

impo.fpi

[Dan Korn]

The problem is Fusion Pro is doing what it should be doing because each record really is only 1 page because of the way the data is setup. The data is setup so each record is a different page.

That's not really how Imposition works. It wants to impose multi-page output records, not multiple single-page output records.

If we where to make a single record contain all the pages for that record the record would have 400+ columns of data and we would need special pages to handle each different page.

You already have a massive data file with 76 fields. Perhaps some of that data could go into external data files, especially if it's repetitive. For instance, maybe the main data file should have an ID number for each fund, which can be used to look up that fund by ID in a separate data file. But it's hard to tell just from the dummied-out data how best to organize your real data.

For example instead of having a 10 page file like we have now to handle all the different types of books we would need a 70-100 page file which we would have to setup the variables for each different page.

Huh? Why would you need to do that? Just pull the pages you want from the 10-page file. You can activate more than one Body page at a time. Perhaps the data just needs to have a set of fields with the same names as the Body pages, where each has a value like Yes or No specifying whether to include it in that record. The OnRecordStart logic could look something like this:

var pages = ["Letter","Report","QA","FF","rFiller","ProFund","ProFiller","Filler1","Filler2","Back"];
for (var p in pages)
   FusionPro.Composition.SetBodyPageUsage(pages[p], ToUpper(Field(pages[p]))[0] == "Y");

This makes upkeep of the document a nightmare say you have to update the header information on the report pages instead of just updating the single report page in the 10 page file you have to update 40 different reports in the 70-100 page file.

Yes, that would be a nightmare. Don't do that. Generally, if you find yourself repeating the same thing over an over again, whether it's duplicating pages in the PDF template, or copying a set of lines in a JavaScript rule, where each one only changes one thing, you should be able to use a loop or some similar construct to avoid such brute force repetition.

Thanks for the shortened code sometimes I over think simple things. Maybe I am over thinking this whole problem.

Perhaps. Often jobs like this can be done in more efficient ways. Although, again, it's hard to tell just from the dummy data what would be the optimal way to set up this particular job.

[Mattcooper]

Thanks again Dan,

 

You have sparked my thought process.

 

I have not used multiple data files in a job before I was reading a bit on it and it seems like this could help.

 

So if I am following how this would work I would split data sort of like the image below.

 

http://s29.postimg.org/me0e4asvr/mockup.png

 

Than is my merge file I would check each report for a Y/N answer if Y than read the ID for that report and search the Report File for that ID than pull the fields for that ID for the Report Pages text boxes.

 

Only thing I am not fully understanding is how will I tell it to duplicate the report page, but use a different set of fields from the Report File.

 

Thanks so much Dan I am going to read more on this.

[step]

We have thought about reworking the data, but we have found that we could end up with over 400 columns per row to handle all the different reports.

I'm not sure I understand why that is but, regardless, I'm not sure why that matters. Personally, I think it's better to get the data in a format that will give you the output you want before it gets to FusionPro because you'll either have to re-format the data within FusionPro (as I mentioned previously by importing as an External Data file) or you won't be able to impose out of FusionPro. What it boils down to is: FusionPro can not impose the job the way you want when each record produces a single page.

 

On top of that we would have to have multiple pages for each report if we say have 20 reports we would have report1, report2, report3 etc columns meaning we would have to create different pages for each one inside the merge file instead of just one report page like we have now.

Again, I'm not sure I understand what you mean by that. But if you're saying you'd have to make a separate body page for each data column you add, that's not true. You'd probably want to look into making use of a Repeatable Component (or Template page).

 

On top of that we would need a much larger OnRecordStart to figure out what pages to turn on and off for each row plus more variables inside the data to help figure out all that.

If you're adding a bunch of 'else if' statements, then yes you'd need a much larger OnRecordStart rule but if all of your pages are turned off by default, your OnRecordStart rule could simply be made:

if (Field("PageType") == "Letter") {
   FusionPro.Composition.OpenNewOutputFile(Field("Donor ID") + "-" + Field("Donor Name") + "-Qty" + Field("Quantity") + "." + FusionPro.Composition.outputFormatExtension);
}

FusionPro.Composition.SetBodyPageUsage(Field("PageType"), true);

[Mattcooper]

Thank you Step,

 

You and Dan have given me much to think about on the best way to handle this job.

 

I am going to do some reading and see what comes of it.

[Dan Korn]

I have not used multiple data files in a job before I was reading a bit on it and it seems like this could help.

It's worth knowing about, at any rate.

So if I am following how this would work I would split data sort of like the image below.

http://s29.postimg.org/me0e4asvr/mockup.png

Yeah, probably something like that.

Than is my merge file I would check each report for a Y/N answer if Y than read the ID for that report and search the Report File for that ID than pull the fields for that ID for the Report Pages text boxes.

Sure. Or you could just see if each section field references an ID from another data file, and activate a page for it. Otherwise, if there's no ID in that field, then the corresponding page would be left unused. There are probably lots of ways you could slice this.

Only thing I am not fully understanding is how will I tell it to duplicate the report page, but use a different set of fields from the Report File.

I'm not sure what you mean. Do you mean the page called "Report" in the job you attached? I don't know why you would need to duplicate it. But I'm not quite seeing the whole big picture here.

 

As for using "a different set of fields from the Report File," perhaps there would be multiple report files, with different fields. Again, though, without seeing the real data, and how it all fits together, it's hard to make specific suggestions.

[Mattcooper]

Let me see if I can make it more clear.

 

So the merge file looks like this

 

Letter

Report

QA

FF

OUFiller

ProFund

ProFiller

Filler1

Filler2

Back

 

When a book is composed we would get something like this

 

Letter

Report1

Report2

QA2

Report3

FF3

Report4

Report5

OUFiller5

Filler1

Filler2

Back

 

So each report has different data based on the FundID so what I meant by duplicate the report page is how will it know I need to use the Report page 5 times.

 

Which I think Step answered with the templete thing which I am about to read up on.

 

Another thing is these pages have to be in a exact order so that is something else that has to be controlled for.

 

Thanks so much Dan I am learning a lot and taking all this to heart.