esmith Posted November 15, 2012 Posted November 15, 2012 Is there a way to allow telescoping (stacking) of records on an FPI layout so that no range of records (i.e. store number with data sorted by same) would "wrap" to the next position on the layout? As an example, say I have records for items sold in each of 4 stores with data sorted by store number. Store #1 has 34 items; store #2 has 20 items; store #3 has 24 items; and store #4 has 22 items (for a total of 100 records). By default, if I created a 4-up imposition with stacking enabled, FP would create a 25-sheet file with store #1's records in the first position, wrapping around to place the final 9 records in the 2nd position. Store #2's items would begin on the 10th sheet in position 2 and wrap around to the 3rd position on sheet one, etc. I want to know if there is some way that I could force FP to scan through the data to determine at which records the store number changes and then determine the sheet count based off the result. So in the example above, FP would pre-determine that store 1 has the most records (34) and create a 34-sheet output file so that each store filled one position on the layout with "blank pages" as filler to finish the positions for each of the other 3 stores. The 4-store example is relatively "easy", but in a "real" scenario, there might be 2,496,300 records across 8,321 stores (an average of 300 records per store, but each store could have more or less) and FP would need to pre-determine how many stores's records could fit in each position and then compose without letting any store wrap from end of stack to beginning. In the latter example, it would also be necessary to chunk the output (our RIP might choke on a 625K sheet file!) while continuing the "stack" through all the chunks. So if we were generating 5K-sheet chunks and a store had 342 records beginning on sheet 4,085 in position 1, the remaining 326 records would continue in position 1 in the next chunk rather than wrapping to the first sheet of the same chunk. I'm having a deja vu moment where I think a similar issue has been posted before (I'll go back and check). It seems like the feedback was "that would just waste extra stock by having a bunch of scrap for the other positions on the latter pages." But in my case (at least), the idea is that the trimmed items could be collected coming off the bindery equipment and there would not be an issue of having to pull items from one position at the beginning of the run to be set aside until the rest of that stores' items could be collected from the previous position at the end of the run. Did I explain our conundrum well enough?
Dan Korn Posted November 15, 2012 Posted November 15, 2012 I'm not sure I'm visualizing the job completely just from the description. Posting an example might help. At any rate, I think that it should be possible. As I explained in the other thread, when you use stacked imposition, a preprocessing run is automatically invoked to count all the records and calculate which ones goes on which imposed sheets before composing. I think what you need to do is this: In FP Imposer, check the "Infinite Stack" box.In OnJobStart, tell FusionPro to break stacks at chunk boundaries:FusionPro.Composition.chunksBreakStacks = true;In OnRecordStart, set up dynamic chunking:if (FieldChanged("StoreNumber")) FusionPro.Composition.OpenNewOutputFile(); What will happen is that FusionPro will put each store into its own output file (chunk), and each output file will contain a single stack with the records for each store. In other words, each store gets one imposed stack, in one output file. If you also want to make sure that no output file (chunk) exceeds a particular number of records, you can also set up "static" chunking, in conjunction with the dynamic chunking, by checking the "Output to multiple files" box on the Output tab of the Composition Settings. Basically, this tells FusionPro to emit chunks no larger than that size, but they can still be broken up smaller than that based on dynamic chunking via calls to FusionPro.Composition.OpenNewOutputFile().
Recommended Posts
Archived
This topic is now archived and is closed to further replies.