Category Archives: indesign

Post navigation

throughout this site (and others) you’ll find lots of applescripts which are direct responses to real-world workflows. but, chances are, you’ll need to do some cut-pasting, and additional code writing to create a script which does exactly what you want in your workflow.

this can be a bit intimidating and not a little frustrating as you try to get the bloody thing to work.

so here’s a post (and there may be more to follow) which gets back to basics and addresses a common beginner question :

When I’m cutting and pasting sections of a script, how many ‘end tells’ do I need to include?

new scripters will often be confronted with errors like these when trying to compile or run a script in development :

one of the main problems with this kind of error, as compared with many other types of errors, is that Applescript Editor may not highlight the exact line where the problem needs to be fixed.

the important thing to remember is that the number of ‘end tells’ will be exactly the same as the number of ‘tells’.

when writing code from scratch, it’s best practice to write the ‘tell’ and ‘end tell’ first — then go back and fill in the rest of the code :

you can have tells within tells (or nested tells) — these get closed off in the reverse order that they were opened — but notice, still, the number of ‘end tells’ is the same as the number of ‘tells’ :

other commands
this is also the case with other commands that need an ‘end’ statement. for example, if you have an ‘if’ command within a ‘tell’ command, the ‘if’ needs to end before the ‘tell’ ends :

tell application id "com.adobe.InDesign"
if x = y then
-- some more code
end if
end tell

when writing code you can also close off with just ‘end’ and the editor will work out which end goes with which command when the script is compiled. so you can write it out like this :

tell application id "com.adobe.InDesign"
tell active document
if x = y then
repeat 5 times
-- some more code
end
end
end
end

… and, when compiled, it will become this :

tell application id "com.adobe.InDesign"
tell active document
if x = y then
repeat 5 times
-- some more code
end repeat
end if
end tell
end tell

but you can see that even here — all the commands get closed down in the reverse order that they were opened. the ‘repeat’ is closed first, then the ‘if’, then the second ‘tell’ and lastly the first ‘tell’.

… and another thing
whenever possible, it’s best to avoid one application ‘telling’ another application :

tell application id "com.adobe.InDesign"
set mgFolder to file path of active document
tell application "Finder"
set mgOLDFolder to (mgJobFolder & "OLD:" as string) as alias
end tell
end tell

… is better writen as :

tell application id "com.adobe.InDesign"
set mgFolder to file path of active document
end tell
tell application "Finder"
set mgOLDFolder to (mgJobFolder & "OLD:" as string) as alias
end tell

macgrunt has now received at least two undeniable confirmations of the medicinal properties of applescript : the first was from a generous commenter on one of the earlier lessons which you can read here ; and the second was from a user who asked for assistance with a different exporting problem (which is what this post will be about, eventually). to quote :

The joy also helped ease my sciatic nerve pain I have been suffering for more than a month now.

now, the cynical among you may think that these people are exaggerating or just being flippant — but do you really have a good and verifiable reason to doubt the written testimony of fellow mac users? not likely.

here’s the brief for the sciatica-easing workflow : export the active document to 300ppi CMYK jpegs and 150ppi RGB pngs.

the first part of the script is pretty similar to all the other exporting scripts on this site — get the filename and path of the active document, shorten the filename so that the names of the exported images won’t be too long, create some folders to hold the exported images :

-- developed by macgrunt for use with InDesign
-- last updated April 2014
-- macgrunt.com
-- export jpgs and pngs from active InDesign document
tell application id "com.adobe.InDesign"
set mgFolder to file path of active document
set mgDocName to name of active document
end tell
----------------------------------
-- this bit shortens filename to first space
set text item delimiters of AppleScript to {" "}
set mgDocName to text item 1 of mgDocName
set text item delimiters of AppleScript to ""
----------------------------------
----------------------------------
-- this bit creates subfolders in the same location as the InDesign file
tell application "Finder"
if (exists folder "JPGs" of folder mgFolder) is false then
set mgJPGfolder to make new folder at mgFolder with properties {name:"JPGs"}
else
set mgJPGfolder to (mgFolder & "JPGs") as string
end if
set mgJPGfolder to mgJPGfolder as alias
if (exists folder "PNGs" of folder mgFolder) is false then
set mgPNGFolder to make new folder at mgFolder with properties {name:"PNGs"}
else
set mgPNGFolder to (mgFolder & "PNGs") as string
end if
set mgPNGFolder to mgPNGFolder as alias
end tell
----------------------------------

hopefully it’s clear that mgFolder is where the InDesign file is saved, so the new JPGs and PNGs folders are created in that same folder. these new folders are created using an if/then/else routine — if you just tried to create the new folder when there was already one there, the script would throw an error — and that’s tedious.

the second half of the script sets the export parameters and does the actual exporting — pretty simple :

this block of code highlights one of the frustrating things about trying to write applescript — the inconsistency of syntax. notice how ‘jpeg color space’ is not capitalised like all the other export preference properties? that’s not really a big deal because the script editor will correct that automatically if you accidentally type it in caps.

but notice the two export commands : ‘export format JPG’ vs ‘export format PNG format’ — why do they have different structures? who knows — adobe are just weird. it’s even weirder when you include the two PDF export commands : ‘export format PDF type’ vs ‘export format interactive PDF’. best not to think about it.

that repeat loop at the end is purely to get consistency of filenaming. if we just export a document “mgThis_file.indd” to jpegs, the filenames would be “mgThis_file.jpg”, “mgThis_file2.jpg”, “mgThis_file3.jpg”, etc. again with the inconsistency … why doesn’t InDesign add ‘1’ to that first jpg? — adobe really do have some serious explaining to do.

anyway, as we were adding a repeat loop to include ‘1’ on the first image, we took the opportunity to add an undescore as well. so these files would now come out as “mgThis_file_1.jpg”, “mgThis_file_2.jpg”, “mgThis_file_3.jpg”, etc.

obviously, this is a very basic script which exports a single document at a time, using one set of export preferences. but like all the PDF export scripts on this site, it doesn’t take much to adapt it to export all open documents, or give the user the chance to choose export preferences.

ever since Adobe launched their Creative Suite back in 2003 there has been ongoing speculation about when the various elements would be combined into a single application. the obvious contenders right from the start were InDesign and Illustrator since their functionality overlapped in many respects.

the problem has always been, however, that the fundamental architecture of the two products is completely different, even though the user experience is quite similar. the main reason for this is that Illustrator was developed from the ground up by Adobe, but InDesign is basically an expansion of Pagemaker — originally developed by Aldus.

well it appears that the merger is now well and truly in the pipeline with beta testing in full swing. if you’re not yet involved, you can apply to take part in Adobe’s Prerelease Program here

as with most beta versions there is still a lot of clunkiness to sort out, but the developers have also come up with some quite reasonable solutions to the inevitable problems. one example is the tool panel which, by default, is a monster hybrid of the two panels we are already familiar with. but there are also panel presets for just-InDesign and just-Illustrator panels. and now you can also specify your own custom tool panel, just as you’ve been able to do with menus since CS4 :

it looks like Adobe are planning to ease users into this new way of working because the new document window will now let you choose ‘artboards‘ or ‘pages‘ as the intent (the rest of the window changes depending on which intent you choose) — effectively keeping the two working styles independent, at least for the time being :

as with all change there are many who are not happy. generally speaking, it looks like the mainly-InDesign users aren’t too concerned, whereas the Illustrator aficionados are not at all happy (probably because Adobe is attempting to integrate the Illustrator functionality into InDesign, rather than the other way around) — some uncharitable testers have taken to calling the new application IllDesign.

there are also those who, perhaps not without reason, have questioned the timing — suggesting that Adobe had plenty of opportunity during the ten years of the Creative Suite to get this hybrid up and running but that they kept it under wraps to enable them to continue selling the two separately. obviously that is no longer a concern now that everything is integrated into Creative Cloud.

sometimes your InDesign files may get a little feral and tracking down rogue colours can be a bit tedious. obviously deleting unused swatches is pretty easy, but this doesn’t always get rid of all ‘unexpected’ colours.

here’s the easy way to find those buggers …

first change that random colour into a spot swatch :

then set up a preflight profile that treats spot colours as ‘not allowed’ :

this will pinpoint exactly where the problem swatch is being used in your document. then you can decide how to proceed with those elements :

if the preflight check doesn’t show anything up, then the swatch is probably being used by a style (paragraph, character or object). delete all your unused styles, and if that swatch still won’t budge then the style attached to the swatch is probably the base for another style — get it?

you can go ahead and delete the swatch, replacing it with whatever other swatch you choose — or not bother, if it’s not being used, it’s not being a problem.

sometimes things go awry with InDesign and it behaves abominably. sometimes things go even more awry and you can no longer open the application at all. these are the times to trash your preferences. but sometimes even this doesn’t work — and that’s what we’re going to cover in this post.

but first — trashing preferences. the best way to do this is to manually remove two files (if it’s running, quit InDesign to do this). both of these can be found in the user ‘Library’ which is, in recent versions of OSX, a hidden folder which does not normally show up in the Finder’s Go menu. but if you click Go and then hold down the option key — you’ll see Library get added to the list :

unfortunately, deleting those two files will also delete handy things like print and document presets and whatnot (luckily, things like workspaces, customised keyboard shortcuts, and PDF presets are not lost) BUT it will fix InDesign in the overwhelming majority of cases.

sometimes however this DOES NOT work and InDesign will continue to crash when attempting to start up. this may be caused by some recalcitrant recovery data. so the next thing to try is deleting this folder — also in the caches folder (again, after making a handy backup copy somewhere) :> Caches > Adobe InDesign > [version number] > [language] > InDesign Recovery >

but once in a purple-polka-dotted moon you may find that EVEN THIS DOES NOT WORK. then it’s time to get radical and delete everything else inside that last level of the caches folder (again, after … you know the score):> Caches > Adobe InDesign > [version number] > [language] >