InDesign tip : #34

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 :
two version of the Finder's Go menu.

once inside the library folder, navigate to and delete these two files (after making a backup copy somewhere) :
> Preferences > Adobe InDesign > [version number] > [language] > InDesign Defaults
> Caches > Adobe InDesign > [version number] > [language] > InDesign SavedData

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] >

if even THAT doesn’t work then … well … you’re on your own. sorry.

macgrunt icon

InDesign tip : #33

this post may become a bit of a hodge-podge of a couple of different things, but the main message for today is …

if you have not already ‘upgraded’ to InDesign CC
— DON’T DO IT.

the CC version of InDesign is proving to be a real dog — it sporadically suffers from serious time lags for even the most mundane tasks (eg. selecting text) and is clunky in a bunch of other ways (the UI is simply grotesque — quite windows-like — click to enlarge) :
dialogs comparison between CS6 and CC

we’ve already looked at solving one speed issue that’s been with us since CS4 — the live preflight ‘feature’ — way back in InDesign tip : #09.

upgrading your operating system to OS X 10.9 does help the CC time lag issue significantly, but does not completely resolve the problem. so, you need a couple of other workarounds to help speed things up. these are NOT optimum solutions because they take away some handy functionality which many of us have come to rely upon — but they will help to save you from punching yourself in your own head.

with CC, the speed issue seems to become noticeable once you’ve imported a bunch of high res images (anything more than about half a dozen appears to unsettle the poor blossom). so here are two things to change to get things rolling again (somewhat).

the Pages panel generally looks something like this (screen grabs have been taken from CS6, but most versions are similar) :
pages panel with thumbnails

click on the little icon in the top right corner and you’ll get a dropdown menu — select Panel Options … :
pages panel dropdown

then you can uncheck the thumbnails checkbox :
pages panel options dialog

and all you get is blank page previews :
pages panel without thumbnails

then do the same with the Links panel :
links panel with thumbnails

links panel dropdown

links panel options dialog

links panel without thumbnails

while you’re in the links panel options dialog, you may want to have a bit of a look at the other things you can display in the columns (top section of links panel) and the link info (bottom section). you may find there’s stuff here which is specific for your workflow :
links panel with additional rows
the columns of the links panel can be resized (click and drag the little black line between column headings) and rearranged (click and drag the column heading itself).

you may even find it helpful to set up different versions of the links panel for different workspaces (see tip #08 if you have not yet discovered the benefits of workspaces). for example, some people find it handy to have a basic setup (similar to above) for standard work, but a more extensive set of choices for a separate prepress workspace :
links panel extended

as mentioned, this is not an ideal workaround, but if you’re stuck with InDesign CC and you find the time-lag issue excruciating, then give this a go, at least until Adobe get their act together and restore InDesign to its former glory.

macgrunt icon

InDesign tip : #32

it’s amazing the stuff you’ll find sometimes just by poking around in a program. it seems that if you hold the command key while selecting InDesign > about InDesign you’ll get this panel :
InDesign Component Information Panel

it contains all kinds of gobbledegook — the top section of the panel relates to the InDesign application, the bottom section is about the current document.

no doubt this stuff is useful to professionals who know what’s what, but the bit that’s probably most informative to us amateurs is the document history in the bottom left corner. if you scroll down in that panel you find a blow-by-blow rundown of what’s happened to the document since it was first created in InDesign :
Indesign Document History 01
this one shows a document that was originally converted from a QuarkXpress file back in 2009, has been ‘saved as’ several times, and went through a conversion this morning when it was opened on a different machine in a different version of InDesign.

the listed dates may well help you track down earlier versions of a document but it’s particularly good at letting you know when a file might be getting a little tired (before it finally falls over and refuses to budge).

there are two ways to quickly build a fresh version of a failing file. the first way is the ‘authorised’ technique : save or export your file to the idml format, then open and save. the advantage of this method is that you get an exact duplicate of the old file (with ALL styles, swatches, etc.). the new document history will look something like this :
Indesign Document History 02

but way back in tip #05 we looked at a different method. it basically involves moving pages to a new document :
Move Pages dialog

this is a superior method in several respects : it’s faster, especially as documents get bigger (‘converting’ an idml file can often take some time) ; it also strips out all unused styles, swatches, master pages, etc. so you basically end up with a cleaner file. and the new document history will look something like this :
Indesign Document History 03

have a look and add a comment if you find another cool use for the Adobe InDesign Component Information panel.

macgrunt icon

renaming finder items IV — part 3

the last two posts looked at using applescript to develop an app to make batch renaming finder items even easier than automator, or bridge, or whatever. first, we created the basic functionality, then we improved the script to make it more user friendly. this post will be the final instalment — the final revision to optimise usability.

to understand this post you’ll first need to review renaming finder items IV and renaming finder items IV — part 2.

the app has been created as a droplet — drop files on the app’s icon and they are processed by the script. pretty simple. but the app would be better still if it could be activated in a number of ways. so, we’re going to alter it so that, as well as accepting dropped files, it can accept a dropped folder of files, or just run when it is double-clicked.

it would also be better if it ran faster.

making it faster is easy. in its current form the script will rename 1000 files in a bit over a minute — not bad. but if you take every instance of this line :

tell application "Finder"

and replace it with :

tell application "System Events"

you’ll find that renaming 1000 files will take about a second. that’s even more not bad.

“System Events is an agent (or faceless background application) that supplies the terminology for using a number of features in AppleScript scripts. … Provides terminology to access disks, files, and folders without targeting the Finder. This can be more efficient than using the Finder …”
Mac Developer Library

ok, so much for speed, now for the varied functionality. the original script started with an on open command and assumed that the user would be dropping a bunch of files on the droplet.

here’s how to change that on open command so that it could accept either a bunch of files or a folder :

on open (mgDropped)
  tell application "System Events"
    if (count of mgDropped) = 1 then
      if (mgDropped as string) ends with ":" then
        set mgFiles to files of item 1 of mgDropped
      else
        display dialog "You're really using a script to rename one file?" & return & return & "OK ... whatever."
        set mgFiles to mgDropped
      end if
    else
      set mgFiles to mgDropped
    end if
  end tell
  my mgProcess(mgFiles)
end open

the files to be renamed are now defined by the variable mgFiles before being passed to the subhandler mgProcess. the reason we are now using a subhandler for the renaming is that the on open command is not the only script initiator — we’ll also be including an on run command.

the on run command is what allows the app to run by just double-clicking it. when the app is double-clicked it will ask the user to choose a folder of files to rename — again passing those files to the mgProcess subhandler. so the full start of the script now looks like this :

-- thanks to Yvan Koenig for the on run/on open clue :
-- http://macscripter.net/viewtopic.php?id=41214
on run
  set mgFolder to choose folder
  tell application "System Events"
    set mgFiles to files of mgFolder
  end tell
  my mgProcess(mgFiles)
end run

on open (mgDropped)
  tell application "System Events"
    if (count of mgDropped) = 1 then
      if (mgDropped as string) ends with ":" then
        set mgFiles to files of item 1 of mgDropped
      else
        display dialog "You're really using a script to rename one file?" & return & return & "OK ... whatever."
        set mgFiles to mgDropped
      end if
    else
      set mgFiles to mgDropped
    end if
  end tell
  my mgProcess(mgFiles)
end open
---------------------------------------------

so, to reiterate, having both the on run and on open commands allows this script to behave both as a standard app and as a droplet.

there are a bunch of other minor revisions that need to be made to the original script to accommodate this new functionality — not least the encapsulating of the basic script within a subhandler. the new completed script would look like this :
screen grab of finished EasyRenaming script

but you can get the complete EasyRenaming app here.

have fun improving this script for even greater functionality.


• related post : renaming finder items : renaming using automator or applescript.
• related post : renaming finder items II : renaming by list.
• related post : renaming finder items III : renaming by creation date.

macgrunt icon

renaming finder items IV — part 2

today we’re going to look at revising the script from the last post to make it more user friendly and robust. here was what we finished with last time :
screen grab of finished script

you may need to review how that script functions before proceeding : renaming finder items IV

refining a script for optimal usability is largely a matter of asking a bunch of “what if …?” questions. what if the user does this? what if the user does that? what if the user is a thicky? etc.

we’re going to do some simple refinements :

  • what if the user enters nothing in the first dialog? — we’ll give them the option to append something to the start of the filename.
  • what if the user enters nothing in the second dialog? — we’ll give them the option to simply delete the ‘change from’ text from the filename.
  • what if the user doesn’t fully understand what the script is going to do? — we’ll give them a confirmation message before proceeding.
  • how will we know how successful the script was? — we’ll include some extra reporting at the end of the process.

first we’ll add three variables right after the first line of the script :

set mgAppend to "NUP"
set mgChanged to {}
set mgUnChanged to {}

the first is a simple switch we’ll use for an if/then statement when it comes time to actually change the filenames. the other two are empty lists that will get populated as the script processes the files. these will be the basis for the end reporting.

the next part goes straight after presenting the change from dialog. it creates another window to check what to do if the user enters nothing in the change from dialog. this is where the mgAppend variable gets switched if required :

set mgChangeFrom to text returned of mgChangeFromDialog
if mgChangeFrom is "" then
  set mgJustChecking to display dialog "So, do you want to append the new text to the front of the filename?" buttons {"No — Cancel", "Yes — Append"} default button 2
  if button returned of mgJustChecking is "No — Cancel" then
    error number -128
  else
    set mgAppend to "YEP"
  end if
end if

screen grab of append check dialog window

does that all make sense so far?

now after collecting the change from and change to data from the user and running the considering case check, we’ll have three possible scenarios (apart from the script having been cancelled) :

  1. we have nothing for change from and a text string for change to (append)
  2. we have a text string for both change from and change to (replace)
  3. we have a text string for change from but nothing for change to (delete)

we can use those possible scenarios to build one of three possible confirmation dialogs like this :

if mgChangeTO is not "" then
  if mgAppend is "YEP" then
    set mgConfirmationText to "JUST CONFIRMING." & return & return & "Filenames will be changed so that :" & return & "      '" & mgChangeTO & "'." & return & "is appended to the front of each filename." & return & return & "IS THAT CORRECT?"
  else
    set mgConfirmationText to "JUST CONFIRMING." & return & return & "Filenames will be changed so that :" & return & "      '" & mgChangeFrom & "'" & return & "becomes" & return & "      '" & mgChangeTO & "'." & return & return & "IS THAT CORRECT?"
  end if
else
  set mgConfirmationText to "JUST CONFIRMING." & return & return & "Filenames will be changed so that :" & return & "      '" & mgChangeFrom & "'" & return & "is deleted." & return & return & "IS THAT CORRECT?" & return & return & return & "{WARNING : this change cannot be undone}"
end if

set mgConfirmation to display alert mgConfirmationText buttons {"HELL NO! STOP", "YES! Go do that thing"} default button "HELL NO! STOP" as critical
if button returned of mgConfirmation is "HELL NO! STOP" then
  error number -128
end if

screen grab of three confirmation dialog windows

the portion of the script that does the actual name changing is a bit more complicated now. it needs to allow for appending (as required) and for populating those two lists we need for reporting purposes :

tell application "Finder"
  repeat with mgitem in mgSelection
    set mgOriginalName to name of mgitem
    if mgAppend is "YEP" then
      set mgNewName to (mgChangeTO & mgOriginalName) as string
      set name of mgitem to mgNewName
      set end of mgChanged to mgOriginalName
    else
      set text item delimiters of AppleScript to mgChangeFrom
      set mgNameItems to text items of mgOriginalName
      set text item delimiters of AppleScript to ""
      set mgItemCount to count mgNameItems
      if mgItemCount is not 1 then
        set text item delimiters of AppleScript to mgChangeTO
        set mgNewName to mgNameItems as string
        set text item delimiters of AppleScript to "."
        set mgNameCheck to text item 1 of mgNewName
        set text item delimiters of AppleScript to ""
        if mgNameCheck is "" then
          display dialog "Sorry, You cannot have a file with no name at all" buttons "dammit" default button 1
          error number -128
        end if
        set name of mgitem to mgNewName
        set end of mgChanged to mgOriginalName
      else
        set end of mgUnChanged to mgOriginalName
      end if
    end if
  end repeat
end tell

and, finally, we have the reporting process. the original script simply popped up a window saying “All Done”. this version will give the user some helpful feedback :

set mgCountSelection to count mgSelection
set mgCountChanged to count mgChanged
set mgCountUnChanged to count mgUnChanged

if mgUnChanged is not {} then
  if mgCountUnChanged is less than 12 then
    set mgUnChangedList to "They are: " & return & "    "
    repeat with mgUnChangedItem in items of mgUnChanged
      set mgUnChangedList to mgUnChangedList & mgUnChangedItem & return & "    "
    end repeat
  else
    set mgUnChangedList to "Here are some of them: " & return & "    "
    repeat with x from 1 to 10
      set mgUnChangedItem to item x of mgUnChanged
      set mgUnChangedList to mgUnChangedList & mgUnChangedItem & return & "    "
    end repeat
  end if
end if

if mgCountSelection = mgCountChanged then
  set mgMessage to "All " & mgCountSelection & " files were successfully renamed."
else if mgCountSelection = mgCountUnChanged then
  set mgMessage to "Sorry, none of the " & mgCountSelection & " files were successfully renamed." & return & return & "You probably stuffed something up."
else
  set mgMessage to (mgCountChanged & " filenames were successfully renamed." & return & return & (count mgUnChanged) & " filenames were NOT changed because " & return & "they do not contain '" & mgChangeFrom & "'." & return & return & mgUnChangedList) as string
end if

display dialog mgMessage

the dialog will list the names of the unchanged files. if there are too many it will just list the first 10 :
screen grab of the final reporting dialog window

the finished script would look something like this.
screen grab of the finished script

there’s a bunch of different ways to improve this script. the next post will look at changing it so that it can be activated in a number of ways (rather than only by dropping files) and how to make the finished app run MUCH faster.

til then, keep grunting.


• related post : renaming finder items : renaming using automator or applescript.
• related post : renaming finder items II : renaming by list.
• related post : renaming finder items III : renaming by creation date.

macgrunt icon