Stacking in FPImposer

[esmith]

I have a recurring job in which the number of records change month to month. I used to have an imposition which I would edit for each recurrence to change the stack amount to equal total records divided by number of pages per sheet. I recently discovered that I could instead check the "Infinite Stack" checkbox to allow FP to determine the correct number of sheets based on input data.

 

I like that I can now re-use the same template each time I link to new data with differing number of records, but now I find myself wondering "Why would I want to ever enter a specific number instead of checking 'Infinite Stack'?"

 

P.S. "Horizontal" is missing the "t" in all three drop down boxes of the Layout tab.

[mhilger]

Hi Eric,

 

Good question.

 

We see customers using a defined depth for their stack for workflows where the customer wants to output sets that contain a specific number of sheets such as 200 sheets. This is often because of the the post-press workflow where the cutter might only be able to take a max of 200 sheets at a time. With a stack of 200 specified then, (and slip sheets to easily determine the breaks between sets), the post-press team can take that set, cut, and stack that set after it's cut into a single bin. Repeating this for the next set and placing in the finished bin with the other items keeps the sort order in place.

 

With stack set to infinite, we will automatically figure out the depth of a single-set stack as you have found. That might be a couple thousand pages of a complete job, let's say at 4-up. Finishing then requires that after some number of sheets are cut (the person working the cutter can just take a number of sheets off the stack of output w/out needing to look for a slip-sheet), each of the 4 little stacks of items would each need to go into their own bin. Not until the entire job is cut will the 4 bins of items actually be in consecutive order.

 

From what I can tell, our users prefer one of these methods or the other. It really comes down to preference in post-press and sometimes is based on finishing equipment capabilities (or lack thereof).

 

Make sense?

[esmith]

So if I have 800 records and have a 4-up imposition with a finite stack count set at 100, will my 101st page of my output file contain records 401, 501, 601 and 701?

 

Alternatively, if I took the same 800 records and used a 4-up imposition with a stack count of 400, would the output generate 400 pages with two "blank" stacks, or would FP treat it like an infinite stack by recognizing that the record set only required 200 sheets?

[mhilger]

So if I have 800 records and have a 4-up imposition with a finite stack count set at 100, will my 101st page of my output file contain records 401, 501, 601 and 701?

 

That's right - unless you also have a slip sheet enabled which will be your 101st page then (the records 401, 501, 601, and 701 would then be on the 102nd sheet).

 

Alternatively, if I took the same 800 records and used a 4-up imposition with a stack count of 400, would the output generate 400 pages with two "blank" stacks, or would FP treat it like an infinite stack by recognizing that the record set only required 200 sheets?

 

In this case, FusionPro will optimize the imposition and perform the stack that makes the best use of the sheets to minimize waste. So in this example, the first sheet will have records 1, 201, 401, 601 on it (stack is reset to 200 automatically). And yes - this is the same behavior as infinite stack.

 

The "minimize waste" optimization is most helpful when you have a larger set of records and the last set of those records isn't enough for a complete set.

 

Consider a job with 7000 records and a 4-up impo w/ stack at 800. So that's 2 sets at 3,200 records and 800 sheets each and then 1 set w/ 600 records. This last set would take 150 sheets vs. 800.

 

hth.

[esmith]

Thanks Mark. Now I just need to decide if I want to share this additional option with my bindery department, or keep my job easier by only offering one choice . Edited May 13, 2009 by esmith

[mhilger]

Heh. Consider a barter-and-trade with them. Or rather, tell them how you were instrumental in getting Printable to add this "new" functionality into the product to make the Bindery team's job easier. Cash that chip in when you need it.

[cmwirish]

Hi everyone,

 

(FP 601.f, PC XP) I am using a sequential numbering rule (for 1000 records) and want it to stack, but it keeps going across the page instead of stacking. I have set it up 4 across horizontal and then tell it to stack to 250. Is it because of the rule that it is not stacking? Sorry - rules confuse the heck out of me.

 

Any help would be appreciated!

 

Sincerely,

 

Chrissy

[ehazzard]

Chrissy,

 

Be sure to always select "stack" in the first column, then set the horizontal and vertical imposition. Without knowing more, this is where I would start.

[cmwirish]

Hi Eric,

 

No, they are still going across the page. I am going to try and email the file with the imposition file as well. (Probably quicker than me trying to explain)

 

Thank you,

 

Chrissy

671743 Raffle Ticket.fpi

671743 Raffle Ticket.pdf

[david]

Chrissy,

 

Stack must be the first setting in the imposition file. You had the horizontal as the first setting. I switched the two and it composed properly.

[cmwirish]

Hi David,

 

Thank you! It is what Eric said to do but I misunderstood what I needed to change (Just a duh moment I think!) I was afraid I was going to have to wait 4 hours until they woke up!

 

Thank you so much for your help.

 

Have a great day.

 

Sincerely,

 

Chrissy

[david]

Glad I could help!

[ehazzard]

Me too, glad I could be of assistance.

[cmwirish]

Thank you too, Eric! I was excited that it worked. Rules confuse but they are very cool when they work properly!

 

Have a great Friday.

 

Sincerely,

 

Chrissy

[Jeff Foster]

In this case, FusionPro will optimize the imposition and perform the stack that makes the best use of the sheets to minimize waste. So in this example, the first sheet will have records 1, 201, 401, 601 on it (stack is reset to 200 automatically). And yes - this is the same behavior as infinite stack.

 

The "minimize waste" optimization is most helpful when you have a larger set of records and the last set of those records isn't enough for a complete set.

 

Apologies for resurrecting an old thread. Is it possible to turn off this "optimization," so that the full stack size is used and empty spaces are left in the imposition when there aren't enough records for a complete set? Or is adding blank records to the data source the best way?

[Dan Korn]

Apologies for resurrecting an old thread. Is it possible to turn off this "optimization," so that the full stack size is used and empty spaces are left in the imposition when there aren't enough records for a complete set? Or is adding blank records to the data source the best way?

So you want to have empty sheets printed out?

[Jeff Foster]

Thanks for your reply Dan. I don't want empty sheets; I want empty positions. If the stack size is 500 and I have 15 positions on the sheet—which could hold 7500 records—but I have only 5000 records, I want the first ten positions to fill up (to a depth of 500), leaving five position stacks blank.

 

Currently, whether I have "Infinite Stack" checked or not, if I have 5000 records, it fills up all 15 positions and gives me a stack depth of 334 or whatever. Which is to say, it doesn't honor the stack size in this situation. It seems to me like there ought to be a Honor Stack Size/Efficiently Use Sheet toggle somewhere.

[Dan Korn]

Thanks for your reply Dan. I don't want empty sheets; I want empty positions. If the stack size is 500 and I have 15 positions on the sheet—which could hold 7500 records—but I have only 5000 records, I want the first ten positions to fill up (to a depth of 500), leaving five position stacks blank.

 

Currently, whether I have "Infinite Stack" checked or not, if I have 5000 records, it fills up all 15 positions and gives me a stack depth of 334 or whatever. Which is to say, it doesn't honor the stack size in this situation. It seems to me like there ought to be a Honor Stack Size/Efficiently Use Sheet toggle somewhere.

The imposition system was purposefully designed so that the the last stack always contains the fewest number of sheets possible, to avoid wasting paper by outputting a series of partially-filled sheets. I frankly don't see how leaving a bunch of empty spaces on more printed sheets could possibly be considered more "efficient."

[Jeff Foster]

I frankly don't see how leaving a bunch of empty spaces on more printed sheets could possibly be considered more "efficient."

 

It wasn't my contention that leaving empty positions on the sheet would be more efficient. It was my hope that one could choose between efficiency and strictly honoring the stack size for all forms. I take from your replies that one cannot, and that we have no choice but to continue padding the data source with empty records. Thank you for the clarification.

 

(This recurring job presents a situation where wasting paper is preferable to wasting time—and introducing more opportunity for error—restacking smaller stacks into the stack size we need. When software wants to intelligently save me from my own bad decisions—think automatic spelling correction—I appreciate the ability to turn the intelligence off from time to time when I'm sure of the rightness of my bad decision. )