Scripting - moving around pages of a spread (Book cover made of 3 pages)

[Fred.L]

Hi guys,

I would like to create a script that helps me deal with Book covers files in a faster way.

One thing I've no idea how to handle it is to **move pages on the pasteboard** in Indesign, via script and more precisely, put them next to each other.

What do we have:

- I've got a spread made of 3 pages (Back Cover - Spine - Front Cover)
- The width of the spine always needs to be adjusted (upon printing house demand)

What do I need to do:

- Change the dimension of the Spine (this part is ok)

- Move apart the pages to help me deal with the new Spine dimension

- Get the pages stacked again to get a nice spread

For the sake of precisions:

I need to move apart the pages to get some space and deal with the designs, artworks, texts that need to be adjusted, shrink or expand, and fit better the new dimension of the spine

Any help would be nice

Thanks

PS: I've had a look at HurryCover from Indiscripts/ M.Autret but I'd like to keep the 3-pages Cover thing and share my script to our subcontractors so they can speed up their work too. So this can not be an option unfortunately

[Robert at ID-Tasker]

I can never understand why people want to work on 3x separate pages - instead of working on a single wide page? Same as when working on X-fold leaflets. 

Just add guides to mark the spine / fold lines. 

And if someone really needs all elements to automatically move when size changes -> Liquid Layout. 

[m1b]

Hi Robert, OP is looking for a way to adjust their design quickly once the spine thickness is known. - Mark

[Robert at ID-Tasker]

Hi Robert, OP is looking for a way to adjust their design quickly once the spine thickness is known. - Mark

By @m1b

I know - that's why I've suggested Liquid Layout. 

No need to adjust anything - when it's been done right in the 1st place. 

[James Gifford—NitroPress]

I once thought the three-page cover layout was fussy and complicated, having done many-many covers as a flat layout.

I was wrong. Properly set up, the three-page cover layout is the only sensible way to do any cover that might have to be adjusted from an original layout and spine thickness... which is pretty much all of them, given that sure as shootin', you will need to adjust it by some small amount to match (say) KDP's arbitrary changes.

All that said, I can't imagine a script really helping much unless you need to do this operation ten times a day.

With a properly set up file —

• Open existing file.
• Save as new iteration, if a good idea.
• Click spine page with Page tool.
• Set page to new spine width.
• Tweak rightmost page (front cover) to snap onto the new thickness.
• Adjust spine text box to either new width of spine page, or spine page margins.
  • Since the spine contents are set up to automatically align to 'vertical' center, with offsets as needed....

...done. I suppose a script could cut that from 30 seconds to five, but... I'd bet it always leaves one d*mn thing to touch up. Why bother?

And Liquid Layout... is one of those features that works better in the help text than on the screen.

[Robert at ID-Tasker]

@James Gifford—NitroPress

Won't Liquid Layout do this automatically in a split second?

You set objects on the left side - to stick to the left edge, you set objects on the right - to stick to the right - then you set objects on the spine to stick to the center of the "page". 

And that includes any background graphics. 

[James Gifford—NitroPress]

Maybe. But after years of managing flat layouts because it seemed to be the superior method, the 3-page spread is so easy, automatic and foolproof I don't have much interest in exploring the quirks of an ID feature that... has its quirks. Very few of the "E-Z-1-Button" features added in the last few years truly bring improvements to the workflow, IMVHO.

It took me far longer to type the above list than it did to execute it on a frequently revised book cover this week. I don't think I had the file open for a full minute to export the updated cover, and I didn't have to carefully screen the result to see what might have "flowed" sideways.

[Fred.L]

Hey,

Thanks for your interest ^^

I've been working in the Book industry (gaming) for many years and we deal  with about 300 books a year. I can now and then have to adjust 10-20 book spine adjustments in a single day. The move to 3p spread Cover has made a huge improvement in saving time, mainly because our cover files gather a lot of graphics. The use of Liquid layout may be interesting in itself but it requires something that can be time consuming, as you say it yourself, "when it's been done right in the 1st place" . At the end of the day, Liquid layout may well be of little benefit, if any.

Using Liquid Layout means that you have to take some time to think/set up the Front page + Back page + Spine, just for the sake of dealing with a spine width and the change of overall page dimension. Since books are all different, you have to set up the page again and again.

With a 3p spread, you only have to focus on the Spine part. Front and Back pages are left alone (assuming you didn't forget to tick the checkbox "move graphics with the page").

Liquid layout may be used still, but on the Spine page only. I've used it, when possible, but it doesn't always work fine. It depends of the conntent, the graphics, the illustrations, especially if you have things to edit in photoshop/ Illustrator. Indesign just cannot do the job alone.

I would just say that, in my opinion, there is no One way only to do Book covers efficiently. For us, 3p spread is way better, faster, logical, understandable, and works fine in our workflow.

That being said,

I agree that the script is not going to save me hours of cumbersome work. But, as many tools, they can just be handy, and help us make the workflow simpler, which is always a good thing, i believe. Besides, scripts help me set up new challenges and improve my knowledge in scripting.

At the moment, I do everything manually, and it works fine. Making it semi-automatic would be nice, that's all

So if anybody knows the method to move the pages on the pasteboard, I'm all ears ^^

Thanks

[Robert at ID-Tasker]

@Fred.L

I just don't understand your step / requirement "moving pages apart"?

[Fred.L]

Thanks for you answer,

I see

Let's try to make it clearer then

Find attached 3 screenshots that may better picture what I have in mind.
- Small UI that allows me to select the proper Master page for the dimension of the spine
- specify the new width in an EditText + button Apply
- 2 other buttons that help me handle the spread and the graphics inside

[Laubender · Accepted solution]

Hi @Fred.L ,

you said:

"What do I need to do:

- Change the dimension of the Spine (this part is ok)

- Move apart the pages to help me deal with the new Spine dimension

- Get the pages stacked again to get a nice spread

"

Well, change the dimension of the spine, move apart the pages surrounding the spine page horizontally.

That can be achieved automatically when using the option Facing Pages enabled in the document setup dialog.

All that without a script…

FWIW:

If Facing Pages is not enabled you have to move the back page and the cover page every time when you change the width of the spine page. For projects like yours I always use Facing Pages enabled and two spreads with 3 pages each for the cover of a book.

Regards,
Uwe Laubender
( Adobe Community Expert )

[Fred.L]

Hey,

Thanks for your answer
I didn't actually think about that way of doing it… 
Just tested second ago. Works fine indeed.
I think you just proposed something that may well be an easier solution than using a script…

We could work on the Master pages and the Spread could only be a way to gather/ exploit the datas then. Nice ^^

I think I'm actually going for it 😄

Thank you very much Uwe 😉

[Robert at ID-Tasker]

Hey,

Thanks for your answer
I didn't actually think about that way of doing it… 
Just tested second ago. Works fine indeed.
I think you just proposed something that may well be an easier solution than using a script…

We could work on the Master pages and the Spread could only be a way to gather/ exploit the datas then. Nice ^^

I think I'm actually going for it 😄

Thank you very much Uwe 😉

By @Fred.L

That's why I couldn't understand what you were doing - changing width of the spine page will automatically "move" back and front cover pages. 

[rob day]

Hi @Fred.L , As Uwe suggests the important part of the setup is to make sure Facing Pages is checked, otherwise when you transform page 2 (the spine), the front and back covers will not align to the new spine dimension:

With the Page tool selected you can transform the spine page without affecting the back and front covers:

[James Gifford—NitroPress]

Actually, some refinement to that is in order, as well as a simplification of my steps above. I simply recalled that some layouts didn't automatically move the front cover into position — making sure Facing Pages is checked takes care of that. (And if any great mind wants to explain the relevance/connection/machinery/reason for that seemingly disconnected setting... please do. 😛 )

But if the cover file is properly set up  — in purely flat-layout terms, no need to set up or accommodate liquid flow or any of those additional layers that might be very useful in other circumstances — and if Facing Pages is indeed checked, AND the spine contents are created as a self-aligning group (using a phantom horizontal element, if needed for an asymmetrical layout), then the steps boil down to:

• Open file, save new iteration if needed;
• Select spine page with Page tool;
• Set new width;
• Select spine content group;
  • Center to Page — or possibly Margins might work better; there's another place to add an offset value.
• Export.
• Go get some coffee.

AFAICT, Bob, your example assumes the centered spine content stays centered, but it seems that adjusting the spine page width changes the centering of that page and the front cover page, making it necessary to adjust that content as well. Or did I miss another secret format setting? 🙂

[Robert at ID-Tasker]

@James Gifford—NitroPress

But with a single page and Liquid Layout - it's just:

• Open
• Change Page width
• Export
• Save 

No need to select & re-center anything. 

And if needed - it can be easily automated even with a very simple JS script. 

[James Gifford—NitroPress]

...once you have a perfect layout created, and IIRC there are a number of restrictions.

For production work, the 3-page layout is pretty near a perfect solution, requiring no unique features or optimization. That there are five or six other ways to do it means five or six other designers can avoid posting here about how ID is a limited tool. 🙂

[Robert at ID-Tasker]

...once you have a perfect layout created

By @James Gifford—NitroPress

I prefer to do things "right" from the beginning - just in case.

Not that I'm trying to force my point on anyone - but in terms of number of operations required - Liquid Layout wins 😉

[James Gifford—NitroPress]

I understand all that. But "right" using more or less conventional tools and techniques is one thing, and the added layer of carefully setting up alternate layouts and tagging things for liquid layout is another.

And, IMVHO, unnecessary for production work given the very straightforward simplicity of the 3-page system and how it meshes with the reality of book production and update needs. Creating an update cover isn't always just tweaking the spine width; other changes like back cover info (or, say, 'New Edition" splashes on the cover) aren't uncommon, and having to stop and make sure they're liquid-conforming is... a step a commercial house might not have time to muck with.

Add in that some updates might need to be done years down the road... I'd bet that the whole Parent page system won't have changed at all, while with Alternate Layouts/Liquid Layouts... who knows?

in terms of number of operations required - Liquid Layout wins

Only in a single, very narrow sense that doing one, one-step update is the whole task... which it often is not. That's why I don't think a script would add anything here; doing the spine width change is probably only one step between start and finish anyway, and there's not much to be gained from speeding and streamlining the process much further.

[Robert at ID-Tasker]

@James Gifford—NitroPress

Yes, you are right - when there are many more operations / changes to perform 3x page layout might be beneficial ... but OP wanted to script just the spine width change ...

[rob day]

and if Facing Pages is indeed checked, AND the spine contents are created as a self-aligning group (using a phantom horizontal element, if needed for an asymmetrical layout), then the steps boil down to:

In my example the spine title and author are simply in a rotated text frame with the Text Frame Options Align set to Center. I’m using a Left Indent and Tab to position the text. The background color is at the bottom of the stack

When I select the Page in the pages panel, and Transform with the Ref Point set to Center, everything stays centered :

The only move i’m making here is changing the W field from 1 in to  .5 in:

[James Gifford—NitroPress]

When I select the Page in the pages panel, and Transform with the Ref Point set to Center, everything stays centered :

Ah.

Still a need to group the spine contents (with an alignment frame, if the layout isn't symmetrical or simple centered text). But that does save yet one more step.

[Robert at ID-Tasker]

When I select the Page in the pages panel, and Transform with the Ref Point set to Center, everything stays centered :

Ah.

By @James Gifford—NitroPress

Another thing to remember 😉 

[rob day]

(And if any great mind wants to explain the relevance/connection/machinery/reason for that seemingly disconnected setting... please do. 😛 )

I think the logic is, with a Facing Page document it is assumed the document will be bound—it has a spine, which shows in the Pages panel. With a bound book the spread pages could not be separated—they are always folded at the spine or a gatefold. The spine is indicated in the panel:

But you might be designing something that will not be bound or folded—maybe a window or trade display where there could be space between the "pages". In that case the Pages panel has no spine indicator

[Willi Adelberger]

If you set up the document as double sided, and not as single pages, the change of the width of the spine moves automatically the pages to their correct position. I never move them appart and move it back. I change the spine width and the other pages move correct to their new position.