I'm trying to use Core to impose documents coming out of XMPie. Note that they are NOT coming out of uStore, but rather they are PDF/VTs being generated in uProduce (unimposed) and then sent to Core. These specific documents are multipage personalized calenders. I want them imposed in a cut & stack fashion.
Currently Core is recognizing the records in the PDF/VT and imposing each calendar as a cut and stack unit (which is good), but it then lays the records out in a sequential order. In other words, if you are looking at the top page of the stack (assuming 10 up, 2 colums, 5 rows), you would see records like this:
What I want is each record stacked below the previous and the overall number of pages balanced out so all of the rows and columns are filled as much as possible (with padding if needed). So, let's say I have 100 records and the sheet is 10 up (2 columns, 5 rows), looking at the first page of the stack, I would see records like this:
I used this number of records for simplicity, but if you didn't have a number of records that cleanly divdied between the stacks, then the last stack would just have padding at the bottom.
This is the way the imposition inside XMPie works already, but I want to use Core for my impositions instead because of the other features it offers.
I really want to find a way to replicate this behavior in Core. I feel like it should be possible, but I'm just not finding the right combination of settings to do it. It seems to me this is how most people would want their variable documents imposed...for instance a stack of postcards that need to stay in ZIP code order, etc.
I hope what I'm asking for makes sense, it's hard to put it into words, so feel free to ask me for more clarification. We're on Core version 188.8.131.52 and we have Advanced PrePress/Routing and Advanced Output modules.
I am not sure that I completely understand the scenario but I think you can do what you want by using the Split component and Job Group imposition (which is part of the OM license).
One caveat, I know the following will work with the current version of FFCore (v.184.108.40.206). We have made some changes around job group imposition so please ensure you are running the latest version of FFCore.
In any case, I would use two imposition components and add a split in between them.
In the first imposition component I would do the cut & stack imposition for each record in the PDF/vt (aka each calendar).
Since this is working as required there's, presumably, no need to change anything.
After doing this imposition, FFCore will adjust the record boundaries on the imposed PDF so ensuer the record boundaries accurately reflect the contents of the PDF. Each record will be padded to ensure that only one record is present in each imposed press sheet.
Add a Split component after imposition. Configure it to:
After Split, FFCore will divide the PDF/vt records evenly between all 10 branches.
Merge all the Branches into an imposition node configured to impose 10up using Job Group imposition. Ensure the option to Apply to Each Variable Data Record is not enabled
Enabling Job Group Imposition also requires use of the Collect Job Documents option for the Imposition component
The above imposition will place each PDF file (at this point the fact that the file is a PDF/vt is immaterial) in a different location in the layout. This will create the required layout since Split ensured each PDF had N contiguous records with N being a tenths of the number of records in the original PDF/vt.
Note: If you leave the Apply to each Variable Data Record option enabled then the imposition component will impose each PDF/vt record separately pleacing records sequentially in the layouts. The Apply to Each Variable Data Record option was introduced in FFCore v220.127.116.11.
Hi Javier, I am working through your suggestion below. One question: do you know if something changed in how v.18.104.22.168 handles PDF/VTs in the imposition component? Since upgrading, it is no longer properly recognizing where the records break. Same workflow, only difference is the Core version.
If the PDF/vt is not a proper PDF/vt then FFCore will not recognize the records.
There's a config file option to loosen the PDF/vt compliance check. That option is undocumented and will be reverted back to the default value during upgrades.
I will email details privately.
I have been able to get this working based on your instructions, so thank you very much!
There are a few downsides to this approach:
1) The need to create a seperate component for every different N-up scenario we might have.
2) While I do mostly get the stack/cut layout I'm looking for, it doesn't handle an uneven amount of records all that well. Since it is doing everything in multiples of the predefined number of branches, I get a lot of blank/padded sheets in the stacks.
Hard to explain this, so I figure the best way is to show you how XMPie's internal imposition handles this versus how it is working in Core. Is there anyway I can upload files to you so you can see the difference between the two?