Your WF appears to obtain the same outcome.
Hi David
Sounds like the same idea I had...see image. Ill check your workflow as well...sounds similar
I think I have the solution for you (see below and attachments). I initially pad the input pages to a multiple of 4. The page numbering is for my debugging purposes. Then based on whether the job containing a multiple of 4 or 8, the job is routed. A multiple of 8 works well. A multiple of 4 only requires additional padding of pages to complete the signatures and then a deletion of pages. For either path the job is split into 4 equal segments (downside is the segments are named foo - 1, foo - 2, .. if the job name has a number within it the routing based on job name could "fail"). You'll probably want to change the imposition settings.
I also attached the results of using a 206 page job input.
Thanks David, We are almost there.
However when splitting the 164pps into half to impose it is now 82pps. The signature I believe needs to be divided by 4.
The resulting PDF puts pps "1 and 2" & "42 and 43" individually on an A3 sheet as opposed to a spread.
See screen grabs
Simon
OK. I believe the solution is to split into 4 segments -- equal page lengths. Route the 4 segments to 4 branches based on job name of the segment which gets appended by - "segment number". Join branches containing segments 1 and 4 (the outer pages for the booklet) and Join branches containing segments 2 and 3 (the inter pages for the booklet). Impose each Joined output with the required binding edge shift for the booklet. Then join the two booklets. This should give you the result you are looking for. Ignore the Save nodes, I used them for de-bugging.
Thanks for the help.
That will not work unfortunately as the file needs to be split into Printers pairs as you split it. Segments just splits in half, say 1-82 and the 83-164 for a 164pp.
In this example it needs to be split like so...(hence the conumndrum!)
164,1,2,163,162,3,4,161,160,5,6,159,158,7,8,157,156,9,10,155,154,11,12,153,152,13,14,151,150,15,16,149,148,17,18,147,146,19,20,145,144,21,22,143,142,23,24,141,140,25,26,139,138,27,28,137,136,29,30,135,134,31,32,133,132,33,34,131,130,35,36,129,128,37,38,127,126,39,40,125
and
124,41,42,123,122,43,44,121,120,45,46,119,118,47,48,117,116,49,50,115,114,51,52,113,112,53,54,111,110,55,56,109,108,57,58,107,106,59,60,105,104,61,62,103,102,63,64,101,100,65,66,99,98,67,68,97,96,69,70,95,94,71,72,93,92,73,74,91,90,75,76,89,88,77,78,87,86,79,80,85,84,81,82,83
thanks
Simon
Here is a proposal for your splitting issue set up the workflow in this order:
One can then apply the imposition required for the different branches and then rejoin the segments
Hello All,
We have 2 finishing lines for Saddle Stitching boklets. One is a conventional Horizon and the other a Watkiss SquareBack. Imposing booklets for Horizon with conventional creep is fine in Core but creep for Squarebacks is tricky, as the requirement is to create a "spine" on the outer spread. Essentially half the book is crept AWAY from spine and the other half is crept TOWARDS the spine.
The only way we can think of doing this is to "Split" and do 2 impose nodes (creep outwards and the other creep inwards) and re join. This does work but the issue then lies in the variables for the page range,.....there are upto 50 different page range splits needed to accomodate 8pps through to 196pps.
Our current system is doing this using Quite Imposing server and we pass the page count and creep amount , it then trims and shifts "to" and "from"..works beautifully with no intervention and simple params passed ie page count and creep amount.
Does anyone else have any experieince imposing for squarebacks?
Thanks
Simon
Solved! Go to Solution.