Global adjustment to text frames placed independently

[Typothalamus]

I have a 340-page coffee table–style book where all the main text frames must be narrowed <1 mm. Alongside these body text frames, which are always to one side of the page and randomnly alternating which side depending on image compositions, is, an independent second column for occasional editor sidenotes. Basically, the gutter between body and sidenotes is a hair too tight and needs a fraction more space between them. Body text and sidenote frames are both to be narrowed, but more so the body text.

Here's where it gets complex: Unfortunately, the book, labored on now for over a year, was not set up in a conventional manner. Not knowing how to variably control which side of the page that body text would appear on as needed by image compositions, body text frames were independetly placed on each spread, linked together for each chapter, and then shifted left or right as desired. The original text document frames (magenta by default) were never used.

So now a global adustement is hard. Furthermore, no script was learned and applied for the sidenotes. So everyting happens in a highly manual way. The sole upshot is the layout looks pleasing, but is arduous to deal with.

[Typothalamus]

That's correct — it needed about 10 pages for all the permutations. Here it is attached as an ID file, plus screenshots. Images of various sizes would appear roughly on every other page but I've removed them for simplicity. Apologies for the delay. It's revised for sharing.

[rob day]

The script seems to work fine—you have to change the g value from 2 to .39:

var g = .39;
app.doScript(moveAnchors, ScriptLanguage.JAVASCRIPT, undefined, UndoModes.ENTIRE_SCRIPT, 'Adjust text frames');

function moveAnchors(){
    app.scriptPreferences.measurementUnit = MeasurementUnits.MILLIMETERS;

    var api = app.activeDocument.allPageItems;
    
    var b, af, sf, xOff;
    for (var i = 0; i < api.length; i++){
        if (api[i].constructor.name == "TextFrame") {
            //get the anchored frames
            if (api[i].parent.constructor.name == "Character") {
                af = api[i];
                //the text frame holding the anchor
                sf = api[i].parent.parentTextFrames[0];
                xOff = af.anchoredObjectSettings.anchorXoffset
                //Check if the anchored frame is to the left or right of the body frame
                if (af.geometricBounds[3] < sf.geometricBounds[1]) {
                    b = sf.geometricBounds;
                    sf.geometricBounds = [b[0], b[1]+g, b[2], b[3]]
                    af.anchoredObjectSettings.anchorXoffset = xOff+g
                } else {
                    b = sf.geometricBounds;
                    sf.geometricBounds = [b[0], b[1], b[2], b[3]-g]
                    af.anchoredObjectSettings.anchorXoffset = xOff+g
                }
            } 
        } 
    };   

    app.scriptPreferences.measurementUnit = AutoEnum.AUTO_VALUE; 
}

Before and after

[rob day]

Also, is this going to be printed? If you think a .39mm change to the body/anchor space is optically meaningful, you will have problems with the small outside margins when the book is bound and finished. Binding and trimming isn’t that accurate and the small 1.1cm margins will appear visually uneven when the printer can’t exactly hit the trim in the bindery.

[Typothalamus]

I've tried the script — powerfully useful tool for these purposes. Feeling less a luddite. Noticing, however, it doesn't move all the anchored notes (see last page), but can manually adjust those.

Concerning binding, magins (1.1 cm at spine, outer edge, top) and trim size are based on a Taschen series, but as it's uncommon in the industry, I anticipated possible issues when the book block is cut, even if Taschen's printers have refined a process to pull it off. The Taipei printer here assures they can do it but until it's demonstrated, there's concern. And with a higher page count, it's a more difficult chop.

Question: A 3-column vertical grid is on a master and the two resulting gutters were ~4.5mm wide. If what we're doing is increasing gutter width 0.39mm, could that be applied in the master grid and be brought to affect  body and sidenotes frames? It means each gutter widens 0.195mm to the left and right and elements can realign to it. 

Very appreciative of this.


 

[rob day]

The Taipei printer here assures they can do it

If they can trim to a .39mm tolerance why do you need a 3mm bleed?

[Typothalamus]

I did see your point earlier, and perhaps it's just rephrased, but the printer isn't asserting they deal in tolerances down to ~0.4 mm, (though I can see how it seems I'm logically implying such). It's just an expansion of the gutter between body text and sidenotes by a fine increment, visually discernable, but not in the margins (margins 1.1 cm, top and sides — how Taschen achieves thus, one wonders). The 3-mm bleed is conventional, and not from a template or spec the printer supplied.

A coping strategy considered is to increase, if necessary, overall format size by a few mm, expanding margins making unevenenss less apparent — but that only works to a degree; a straight cut is still needed.

[Robert at ID-Tasker]

And here is some "inside info" about your document - after filetring out unnecessary information - sorted by Width and PageIndex:

The last two lines - yellow here and on the 1st screen - two TextFrames are 0.01cm / 1mm wider than the rest.

Top of the 2nd screenshot - those two lines - with appropriate values - would resize everything accordingly.

Then sorted by PosX and PageIndex:

Not all values are the same - you have:

1x 13.88 & 2x 13.89

4x 22.20 & 1x 22.21

5x 28.59 & 1x 28.60

Column PARENT TYPE - Page = TF is on the page / Main text, Character = Anchored TF.

[Typothalamus]

Yes, as mentioned, I do things very manually and by eye, and this example document both reflects that and is a bit worse as it was pulled and picked apart from the main document to show all the permutations. But I see the exactitude provided by the tool for analysis. Very neat/useful. More to learn. 

Would like to evaluate the entire document's 340+ pages in this manner, if it's not too hard, and pull any gross violations back into line.

[Robert at ID-Tasker]

Thanks. 

Yes, my tool is extremely versatile - it can be used as a 3rd helping hand - to work on a current selection, or process multiple objects/documents in BatchMode - or can be used as a Preflight tool - whatever you need. 

And you've instant access to anything in your document. 

Any functionality that is already in the InDesign - or can be achieved through scripting or even plugins - is on steroids. 

Unfortunately, there are few extra steps needed to get it up and running - but after that - it's plain sailing. 

[rob day]

Yes, as mentioned, I do things very manually and by eye

You might look at the Parent/Master Spread Primary Text Frames feature, which would allow you to make precise global changes from various master spreads.

Here’s an example where I have run your sample text through Primary Text Frames. I’ve made a Master Spread for the folios and guides, then based Inside and Outside spreads on the folio master.

Primary Text Frames have this icon:

Primary Text Frames can be shared between Masters and are ideal for your design. I can switch inside and outside pages via drag and drop:

Your anchored sidebars can be saved as Object Styles:

The masters would let you make uniform global changes in one move. More here:

https://community.adobe.com/t5/indesign-discussions/can-someone-help-demystify-how-primary-text-fram...

[Typothalamus]

Thanks so much @rob day. Among the prices paid for not being, or hiring , a dedicated ID professional at the start, I must add this, however, though my example had just one master page, there are three masters in the actual document I use, so I was getting part of the way there, but now I see how it should be done. 

The varriances also are due to another factor — the frames I drew or copied typically didn't snap exactly into place or the same place, along the guides though at one zoom level, say 100%, they appeared to have, then at 300%, they wouldn't, and at 600% they would (or something clearly counterintuitive like this).  And then once proceeding down that path, these things carried on and grew.

Also, the 47 chapters are one document. TOC , son's new foreword, new scholarly preface, original preface, new index, publisher's note, etc. are all separate ID docs.  No mastery over combining them, but will live with combining them into one pdf for the printer. 

[Typothalamus]

What would be the order of operations / how would you handle this, revising the one massive document:

A) Strictly standardizing the size of the text frame (perceptually not visible, but still, if doing it right, the text frame should not be a visual guess);

B) Increasing the gutters by the very slight amount (affecting the corresponding TFs and sidenotes);
C) Ensuring that the TFs' position snaps accurately into place (again, they all looked accurate until zooming in very close, or reviewing Robert's tool); 
D) Developing  Primary Text frames off of Masters and going back and applying them?

This is anything but starting from scratch — more so like coming to a year+ of labor, editing text and notes and designing other elements. Hence the question of how to approach revising ID fundamentals at this stage.

[Robert at ID-Tasker]

Looks like I really need to install CS6 and create a version of my tool for CS6...

All the steps you mention - plus re-numbering sidenotes - would be just few minutes of work for you...

Unless IDML from CC will re-import correctly at your side...

[rob day]

Your desire for precision is at odds with the document construction. Hard to know, but I’m guessing it might be faster to reconstruct the doc using Primary Text Frames along with Object Styles for the sidebar, see my attachment above. It certainly would make future adjustments easier.

[Robert at ID-Tasker]

@Typothalamus, @rob day is right, as you don't have too much graphic elements - at least looking at your example doc - and SideNotes are anchored - you could very quickly start from scratch.

[Typothalamus]

Many questions arise — intuitively, I'd guess that getting an understanding of how to reproduce this and executing it would take several days at best with support. There are ~100 photos to align (and ~100 more to come), hundreds of sidenotes to align, titles, subtitles, and details upon details. My familiarity and facility with executing this in the right way is far from anything at hand. Backing up, just to begin with, I still do not to know:

1. why the TFs for body text, sidenotes, or anything else, do not perfectly align on my guides. There is, I presume, a setting that governs how closely and precisely and within what range things snap to a guide/grid. As it is now, what looks perfectly aligned on a guide at one magnification shows it not to be on another. Repairing it by hand only reveals that it looks right at say 600x zoom but wrong at 100x zoom, and then again vice-versa;

2. I actually do not feel confident or trusting of a process to disassemble this and rebuild it. It's as if I've built something by hand in a considered way, thinking of every micro space and line, and now it's all going to be treated as one large data dump which may transfer some things correctly and others not. 

The desire for precision is certainly at odds with the document's bones. But as you see, if not viewing it through a precision analysis tool, there is a level of care, composition, and balance that more than deserves a proper treatment.

 

[Robert at ID-Tasker]

Quick question - do you have SNAP TO GUIDES on/checked?

And you won't have to use 600% zoom...

[Typothalamus]

That's corrected now. Lock Column Guides and Smart Guides were but not Snap to Guides. Such a basic step with critical impact. However, though it improves the situation, I still find that the main text frame is alternatingly showing as perfectly aligned at 100%, off at 125% and 150%, on at 175%, etc. Sidenotes are now perfectly aligned at all magnifications. 

[rob day]

It's as if I've built something by hand in a considered way, thinking of every micro space and line, and now it's all going to be treated as one large data dump which may transfer some things correctly and others not.

But all of your problems are coming from the hand work. If the body text was in a parent page’s Primary Text Frame flow there would be no inconsistencies to address, and as long as you don’t make changes to the page’s text frame positions, you would be able to globally make any kind of size, or x y position change from the Parent pages. Same goes for the anchored side bars—if an Object Style is applied any kind of global micro adjustment could be made from the style definition.

[Typothalamus]

Yes,  I concede/recognize all of that. At the same time, there's an intimidation factor before taking on this bit. Added to the above points, there's the fact that, depending on the printer's next evaluation, a plan B involving resizing margins and format slightly to accomodate the limits of the printer if they cannot manage this current design without issues, should be in place, ready to go. 

If I reconstruct this behemoth in order to have that flexibility, it's frankly a question of how best to even start… Would you copy the document and try to impose changes on it? Or start fresh, individually reconstructing, copying and replacing hundreds of notes, hundreds of images, and so on, and as the text was polished and revised in ID (not Word), the text that came from that ID doc. 

Also, I'd be more comfortable knowing how to undo a script; ctrl+Z isn't working.

[rob day]

The script I posted has an undo. You should see Undo Adjust text frames in the Edit menu

[Typothalamus]

Yes, it's there but goes away after continuing to work on the document. Is this how it's meant to be?

[rob day]

It is saved in the undo history, so you would have to undo all of the changes you make after running the script in order to get back to the state prior to running the script.