in lesson 30 we looked at an applescript to change rows of a particular height to a new height throughout an entire InDesign table. here’s an example of slightly more complex table formatting.
no doubt you would use table and cell styles when setting up your own tables — to assist with formatting changes further down the track. but sometimes you need to work on tables that other, less diligent InDesign users have set up. and if you’re doing that on a regular basis, or if the tables are extensive, it makes sense to automate the tedium.
but now we want the reversed row heights to be a little wider and the blank rows to be narrower. first we need to change all the rows to a specific height before working on the other rows. to do this we change the ‘at least’ specifier to ‘exactly’ by changing auto grow to false :
tell application id "com.adobe.InDesign" tell active document tell table 1 of selection set auto grow of every row to false set height of every row to 5 -- rest of script to go here end tell end tell end tell
then we can use the cell fill colour to address the reversed rows only :
set height of (every row whose name of fill color is "C=0 M=100 Y=100 K=50") to 6.5
we need to use a different tactic for the blank rows. here’s one way — address every row that comes before a reversed row :
repeat with x in (every row whose name of fill color is "C=0 M=100 Y=100 K=50") set mgName to name of x try set height of row (mgName - 1) to 2 end try end repeat
the ‘name’ of a row is its number — so the first row in a table is row 1. that’s why we need the try statement — the first reversed row is row 1 and there is no row 0 to change to a height of 2 — so the script would throw an error without that try.
the only remaining problem, as the observant will notice, is that there is at least one cell (and probably more) which is now too small and has overset text. an extra line in the script will fix that :
set height of every cell whose overflows is true to 9
this is just a taster for what can be done with table formatting through applescript. whether or not you end up using scripting with your own tables depends on your workflow, how big your tables are, how often you work with tables, etc, etc. sometimes table are just too small to justify the time it takes to write or edit a script. but table scripting could be another powerful tool in your production arsenal — anything to minimise the monkey-work.