adding automatic page numbering to your InDesign document is easy. just create a text frame on your master page and then hit cmnd-opt-shift-N or choose this from your Type menu :

you can style the page number the same way as you would any other text. if you type in “page ” before the page number, your master page will look like this :

and your document page looks like this :

but you probably already knew that.

you’ll notice that in the insert special character flyout menu there are a few other markers including one called ‘section marker’ which we’ll talk about in a moment. but there’s no marker for ‘total pages’ — so how do we get automatic numbering in this format? :

well, it’s a bit of a mystery why adobe decided to put that particular functionality in a different place. but here’s where you’ll find that second special character from the Type menu :

ok, now, you can also add a ‘section marker’ from the insert special character flyout menu. on the master page it looks like this :

just to make things clear, that’s : {section marker}+” ~ page “+{current page number marker}+” of “+{last page number text variable}

then you need to specify what you want the section marker to say — under your numbering and section options :

which will render your document page thus :

so far so good.

unfortunately…
the last page number text variable is just a tad clunky — even in CS6. so far we’ve been looking at page two of this document :

six pages with a two-page section followed by a four-page section. and the text variable has been used with these options :

notice that the scope is set to ‘section’. so we get ’2 of 2′ because there are only two pages in the section.

but, if we change the scope to ‘document’ we don’t get ’2 of 6′ :

why? because the text variable is for ‘last page number’ (4) not ‘total page count’ (6). your challenge is to come up with even one scenario where you’d want to number your pages in that fashion.

you’d have to agree that that’s pretty crap. at the very least, InDesign should offer the option to use absolute page numbering for that text variable — maybe one day.

the original version of this script was created, like so many scripts, in response to a problem. a necessary third-party export plugin was changing InDesign’s colour settings to a default custom set whenever it was used.

obviously, this is not an ideal situation for a colour-managed workflow and required each user to manually change the settings back every time the plug-in was run. needless to say, sometimes a user forgot to do this.

ordinarily, a script is not going to be of much use in this situation, because the user still needs to remember to run it. but this one takes advantage of yet another handy scripting feature supported by InDesign — the startup script. as you can probably guess, a startup script runs automatically whenever InDesign starts up — not an absolutely perfect solution to this problem, but at least a useful safeguard.

the structure of the script itself is quite simple :

tell application id "com.adobe.InDesign"
  
  set CMS settings of color settings to "macgrunt colour settings"
  
end tell

well, having gone that far, why not also reset a couple of other things, that might be periodically changed during the day, back to your preferred defaults at the start of the next day? this version of the script also resets some display preferences and the workspace :

tell application id "com.adobe.InDesign"
  
  set CMS settings of color settings to "macgrunt colour settings"
  set properties of display settings to {raster:proxy, vector:high resolution, transparency:medium quality}
  
  -----------------------------
  -- thanks to milligramme — adobe forums
  -- http://forums.adobe.com/message/3822734
  do script "app.applyWorkspace('macgrunt');" language javascript
  -----------------------------
  
end tell

that last command is an interesting one. if you look at the scripting dictionary for InDesign, you’ll see there’s an apply workspace command specified for applescript. problem is, it doesn’t work. but, as shown above, it’s possible to call the equivalent javascript using the do script command.

the finished compiled script looks like this :

of course, you would need to substitute your own colour settings and workspace names.

well, that’s all very interesting, but how do you make this thing run every time InDesign starts up? rather than the scripts panel folder — just save it using the script file format into this folder :
Applications > Adobe InDesign CS6 > Scripts > startup scripts

what other things could you use a startup script for to help make your day a little easier?

adobe’s prerelease program is a brilliant way to contribute to the development of future software releases. this is what adobe has to say about the program :

“The goal of a Prerelease Program at Adobe is to solicit early feedback on new features and bugs in order to produce a unique and a bug free product that can deliver maximum results.”

it’s not something you can just sign up for — you have to apply, giving your areas of expertise, years of experience, etc. and if adobe think you may have something to contribute you’re in. you can apply to be part of adobe’s prerelease program here

if you get accepted into the program you get a sneak-preview of some of the cool stuff currently in development — some of it is just tweaks to existing tools — some of it doesn’t make the cut because it just doesn’t work, or whatever — but some of it is truly awesome — like this new menu that’s in the very early stages of development :

(apologies, the conditions of the prerelease program forbid showing screen grabs of the actual functionality)

the top few menu items are pretty clunky at this early stage and will probably only be useful to talentless desktop publishers in the first few incarnations of this menu. but the basic concept is sound and there’s already quite a bit of evidence from the beta-testing that one day these will be really powerful features of InDesign.

the last two menu items are the ones with immediate application for designers. as you can probably guess, these allow for quickly testing different colour sets and font sets throughout a document. these rely on the user correctly assigning swatches and type styles onto which the test colours and fonts can be temporarily mapped. if you’re happy with the results, just confirm your choice and all your swatches and/or type styles are updated accordingly. a cool thing about this functionality is the capability to switch between up to three different colour sets and font sets — giving you all the experimental scope you need.

adobe keep things pretty tight, so it’s hard to know if this menu will make the cut for CS7. there is a positive vibe on the review forums, but there’s also a lot of concern about some of the more obvious bugginess — so it might be a bit longer before we see this menu released for real.

if you’re excited by this kind of future functionality, then you’re exactly the kind of person that adobe needs to help with testing and reviewing. so apply for the prerelease program and have your say.

keep grunting

we’ve already looked a fair bit at how to export pdfs from InDesign using applescript. see lessons 08, 09, 10, 11, and 12 plus InDesign scripting : bringing it together. but these scripts have relied on pdf export presets and, as it turns out, there’s a really good reason NOT to use an export preset when creating a pdf.

presets invariably export a ‘print’ pdf, but these often have tiny white lines criscrossing the screen. this is an unfortunate side effect of transparency flattening and is quite off-putting to clients, who incessantly ask “is it going to print like that?”. but if you export an ‘interactive’ pdf, you don’t get the dreaded white criscrossy lines (strange but true — who knows why?).

now, at this stage, you can’t save interactive pdf settings as export presets. but that don’t matter none — cause we got applescript.

this script is a stripped back version of a much larger one — with additional export options and email generation. this post will focus mainly on the syntax for exporting interactive pdfs — so refer back to the posts listed above if any of the other bits are confusing.

the first part of the script generates a dialog like this :

  set mgDialog to make dialog with properties {name:"How you want this exported then?"}
  tell mgDialog
    tell (make dialog column)
      tell (make border panel)
        tell (make dialog column)
          make static text with properties {static label:"PDF export setting : ", min width:140}
        end tell
        tell (make dialog column)
          set mgResolutionButtons to make radiobutton group
          tell mgResolutionButtons
            make radiobutton control with properties {static label:"72ppi layout", checked state:true}
            make radiobutton control with properties {static label:"96ppi layout", min width:180}
            make radiobutton control with properties {static label:"144ppi layout"}
          end tell
        end tell
      end tell
      tell (make border panel)
        tell (make dialog column)
          make static text with properties {static label:"Document option : ", min width:140}
        end tell
        tell (make dialog column)
          set mgDocumentsButtons to make radiobutton group
          tell mgDocumentsButtons
            make radiobutton control with properties {static label:"active document only", checked state:true}
            make radiobutton control with properties {static label:"all open documents", min width:180}
          end tell
        end tell
      end tell
      
      set mgResult to show mgDialog
      if mgResult is true then
        set mgResolution to selected button of mgResolutionButtons
        set mgDocuments to selected button of mgDocumentsButtons
        destroy mgDialog
      else
        error number -128
      end if
    end tell
  end tell

that gives you a dialog that looks something like this :

and captures the results into two variables : mgResolution and mgDocuments

it’s important to remember that a radiobutton group returns an integer – starting at 0 – not the label assigned to the selected button. for example, if you select the second option in the top radio button group you will get ’1′ as the result (not “96ppi layout”)

so, the next thing we need to do is assign variables depending on the choices made in the dialog :

  if mgDocuments is 0 then
    set mgDocList to name of active document as list
  else if mgDocuments is 1 then
    set mgDocList to name of every document
  end if
  if mgResolution is 0 then
    set mgResolution to seventy two ppi
  else if mgResolution is 1 then
    set mgResolution to ninety six ppi
  else if mgResolution is 2 then
    set mgResolution to one hundred forty four ppi
  end if
  
  my mgExportInteractive(mgResolution, mgDocList)

you’ll notice here that when re-specifying the variable mgResolution we don’t use quotation marks (it’s seventy two ppi not “seventy two ppi”). this is because the three options shown above are constants defined by the developers. if you want a different resolution you can use an integer between 72 and 300 (eg. set mgResolution to 200).

that last line passes the two final variables (mgResolution and mgDocList) to the subroutine that does the actual work (mgExportInteractive).

now, it’s not really necessary to use subroutines, but they are a great way to make scripts modular. it makes it easy to cut and paste whole chunks of reusable functionality into a future script (and you WILL do this as you get more and more into scripting).

there are two subroutines in this script, the second one is called from within the first one :

on mgExportInteractive(mgResolution, mgDocList)
  tell application id "com.adobe.InDesign"
    set properties of interactive PDF export preferences to {interactive PDF interactive elements option:include all media, generate thumbnails:true, pdf magnification:fit page, pdf page layout:single page, flip pages:false, PDF JPEG quality:maximum, open in full screen:false, page transition override:from document, PDF raster compression:JPEG compression, include structure:false, page range:all pages, export layers:false, export reader spreads:false, view PDF:false}
    set raster resolution of interactive PDF export preferences to mgResolution
    repeat with i from 1 to (count of mgDocList)
      set active document to (every document whose name is item i of mgDocList)
      my mgProcess()
      tell active document
        export format interactive PDF to mgFilePath without showing options
      end tell
    end repeat
  end tell
end mgExportInteractive

on mgProcess()
  tell application id "com.adobe.InDesign"
    set mgFolder to file path of active document
    set mgDocName to name of active document
    set text item delimiters of AppleScript to {"."}
    set mgDocName to text item 1 of mgDocName
    set text item delimiters of AppleScript to ""
    set mgFilePath to mgFolder & mgDocName & ".pdf" as string
  end tell
end mgProcess

now, if you scroll all the way out to the right, you’ll see an interesting thing. oh, all right, you don’t have to scroll all the way out — I’ll tell you — there’s a piece of code there that says “… export reader spreads:false …”. why is this interesting? because, in CS5 (the version this script was written for), exporting reader spreads in an interactive pdf is the default and there’s no option to change it in the standard export dialog box (this has been rectified by CS6). but you CAN change it through applescript — a rare case of something you can do with applescript which cannot be done with the native program. running a script containing that piece of code will change all future exports as well — so you may want to add another line to your final script to reset it back to the default “true” — it’s up to you.

so, that’s the basic syntax for exporting ‘interactive’ pdfs rather than ‘print’ pdfs. check the dictionary for all the other settings you can adjust through applescript.

to download the complete functioning script, you can go here.

have a good one

a little while ago we had a look at how to use applescript and sips to scale image files without the hassle of going through photoshop – see image processing with applescript II. open the terminal application, type in “man sips” and you’ll find there’s a whole bunch stuff you can do with images without ever opening photoshop — pretty cool :

… but you can play around with all that another time. today we’re focussing on extending the functionality of the image resize script from that post to make it a little more user friendly. rather than a have script that’s hard-wired to scale images to 500px high, we’ll create one that can accept user input, so that the pixel dimensions can be changed each time the script is run.

to do that we need to first create a dialog. unfortunately the dialog possibilities with standard applescript are pretty crap — particularly when compared to all the options available to applescript dialogs in InDesign – border panels, columns, rows, checkbox controls, dropdowns, enabling groups, event listeners, comboboxes, editboxes, radiobuttons, etc.

here is all you get with standard dialogs :

well, although that’s pretty diabolical, it’s still enough for what we need. here’s the first part of the script :

display dialog "enter the pixel ratio you want these scaled to" with title "resize images" default answer "800" buttons {"cancel", "wide", "high"} default button 1
set mgResult to result
set mgText to text returned of mgResult
set mgButton to button returned of mgResult

that’ll give us a dialog something like this :

… which gives us two pieces of information — the text entered and the button clicked – both captured into variables. if you want to make the script fool-proof, you’ll need to add some error handling to ensure that the text entered is an integer. but in its current form, the script assumes that the user is not an idiot.

the next part of the script creates a subfolder in the finder to save the transformed images into (this script creates duplicates of the original images rather than overwriting the originals with the resized versions) – then creates a reference to that folder for use later in the script :

set mgFolder to (mgText & "px") as string

tell application "Finder"
  set mgItems to selection
  set mgContainer to container of item 1 of mgItems
  set mgContainer to mgContainer as alias
  if (exists folder mgFolder of folder mgContainer) is false then
    make folder at mgContainer with properties {name:mgFolder}
  end if
end tell

set mgFinalFolder to mgContainer & mgFolder & ":" as string

then comes the key to the adaptability of this script — altering the final sips command based on the user’s choices in the dialog. we capture this into a variable called mgScriptString :

if mgButton is "high" then
  set mgScriptString to "sips --resampleHeight '" & mgText & "' "
else
  if mgButton is "wide" then
    set mgScriptString to "sips --resampleWidth '" & mgText & "' "
  end if
end if

the rest of the script is pretty much as per the previous post except that we insert the mgScriptString variable into the do shell script command :

repeat with mgItem in mgItems
  set mgName to name of mgItem
  set mgFinalpath to mgFinalFolder & mgName
  set mgPath to POSIX path of (mgItem as text)
  
  --convert mgFinalpath to POSIX form
  set text item delimiters to ":"
  set mgFinalpath to text items 2 thru -1 of mgFinalpath
  set text item delimiters to "/"
  set mgFinalpath to mgFinalpath as string
  set text item delimiters to ""
  
  set mgFinalpath to quoted form of mgFinalpath
  
  try
    do shell script mgScriptString & quoted form of POSIX path of mgPath & " --out " & mgFinalpath
    do shell script "sips -m '/System/Library/ColorSync/Profiles/sRGB Profile.icc' -i " & mgFinalpath
  end try
end repeat

wrap all that in an open handler (and delete the line “set mgItems to selection”) and you’ll have a script that looks like this :

save that as an application and whack it in your sidebar. drag and drop as many images as you like onto the app — they’ll all be scaled quicker than you could do it through photoshop. don’t worry about accidentally dropping non-image files — these just get skipped.

you can also go here to get the complete image processing script.

have a good one

someone once said — something along the lines of — “if you ever want to invade australia, do it in january, because there’s no-one doing a goddamn thing.” — which goes some way to explaining why there have been no posts this month.

so we’re going to finish this slack month with a slack post — but one which demonstrates a handy little applescript trick — the say command. and we’re going to make it a bit aussie-themed on this important anniversary because, well, why the hell not?

to date, the scripts on this site give feedback to users through dialogs — little windows that pop up with appropriate messages. but there’s no reason why you can’t use apple’s text-to-speech technology to give verbal feedback to users when tasks are complete, or whatever.

… and it really is as simple as this :

say "something"

that will give you something in whatever the default voice is set to. there are a bunch of different voices to choose from in the speech panel of your system preferences :

specifying a particular voice for your feedback is also simple :

say "aussie, aussie, aussie" using "Alex"
say "oy, oy, oy" using "Alex"

or you might prefer to use a random voice :

set mgVoices to {"Kathy", "Vicki", "Victoria", "Alex", "Bruce", "Fred"}
set mgTheVoice to some item of mgVoices
say "aussie, aussie, aussie" using mgTheVoice
say "oy, oy, oy" using mgTheVoice

and now you can also download additional voices to play around with — just click on the customise option in the system voice dropdown :

you can find samples of some of the voices over at NextUp

but …
you have to be a little careful with your voice choice. here’s a little homage to monty python :

say "strailya, strailya, strailya, we love you" using "Bruce"

now bruce doesn’t do a bad job (alex is better) but how would it sound with an australian voice? well the results are disappointing — karen (who pronounces her name more like ‘corinne’) doesn’t know how to speak australian. i reckon she’s a ring-in. when asked to say ‘strailya’ — a very basic aussie term — she instead says ‘stray liar’ — very odd behaviour for an aussie sheila.

the closest you’ll get with poor old kazza is this :

say "strail yuh, strail yuh, strail yuh, we love you" using "Karen"

… and the same goes for that un-australian “Lee” too — flamin’ wowser.

there are a few other things you can play around with when using the say command (rate, pitch modulation, volume, etc). check out the standard additions dictionary. unfortunately, not all properties work with all voices (eg. pitch and modulation do not affect the australian voices) :

say "chuckus a tinny would you darlin?" using "Lee" speaking rate 200
delay 0.2
say "no worries love" using "Karen" speaking rate 130

have a bonza aussie day — and keep grunting

applescript can be immensely frustrating at times — trying to get the syntax and structure to work just right is often a torturous process for us novices. but sometimes an applescript solution turns out to be astonishingly easy …

this script is the result of simple paranoia : there are a lot of online services offering to generate randomised passwords for you. now, it seems rational to expect at least some of these services may be malignant — they generate a password for you, then follow your digital trail to where that password is used. again, this may simply be paranoia and have absolutely no bearing at all on reality — or maybe not.

this is a simple script to generate passwords, on your own machine, of whatever length you like ^*

* yes, whatever length you like, but you may find the script bogs down a bit when generating passwords of more than 50,000 characters — apologies.

a good password is a random collection of upper case letters, lower case letters and digits (even better passwords also include punctuation, but many, many sites do not allow punctuated passwords) — so the first thing we do is create a bunch of lists (see below for an explanation of why we don’t use just one list) :

set mgList1 to {"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z"}
set mgList2 to {"a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z"}
set mgList3 to {"1", "2", "3", "4", "5", "6", "7", "8", "9", "0"}
set mgList4 to {mgList1, mgList2, mgList3}

that last list is a list of lists — things will become clearer in a moment.

next we ask the user to specify the length of the password. this uses the handy display dialog command which is standard issue with applescript :

set mgAnswer to display dialog "How long should this password be?" with title "password generator" default answer "8"
set x to text returned of mgAnswer

… and will generate a dialog something like this :

usually the result of a dialog is only button returned — but because we used the default answer property, we can also retrieve the text returned. in this case, the text returned is captured by the variable ‘x’.

the next part is the creation of the password :

set mgPassword to ""
repeat x times
  set mgThisList to some item of mgList4
  set mgPassword to mgPassword & some item of mgThisList
end repeat

first we create an empty variable (mgPassword) then run that variable through a repeat loop ‘x’ number of times — each time adding another randomly chosen letter or digit. this is achieved through the “some item of…” trick. first we randomly choose one of the three lists, then we randomly choose one of the items from that list.

finally, we present the password back to the user :

display dialog "Here you go …" with title "password generator" default answer mgPassword buttons "bonza" default button 1

wrap all that in an on run statement and you’ll have a neat little script that looks like this :

save that out as an application somewhere then just double-click to run.

or, if you’re really lazy, you can download the completed app here : password generator

so, why not use just one list?
you could combine all those lists at the start into one like this :

set mgList1 to {"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", 
"L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", 
"Z", "a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", 
"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", "1", 
"2", "3", "4", "5", "6", "7", "8", "9", "0"}

… but your passwords will be less likely to contain digits. with three lists you have a 1 in 3 chance that a digit will be chosen on each pass through the repeat loop. with only one list that chance is reduced to 1 in 6.2.

yeah, sure, but why not just do it like this? …

set mgList1 to {"A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", 
"L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", 
"Z", "a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k", "l", "m", 
"n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y", "z", "1", 
"2", "3", "4", "5", "6", "7", "8", "9", "0", "1", "2", "3", "4", "5", 
"6", "7", "8", "9", "0"}

because i didn’t bloody think of that when i first wrote the script — now shut up!
… but also because, with the three list version, you have the opportunity to extend the script to ensure that, for example, you don’t get three capitals in a row (so there).

now for your homework : how would you alter the script so that it generates five passwords at a time :

hoping you all have yourselves a grunting great christmas.

if you find this script handy, feel free to spread a little christmas cheer by hitting the donate button — thanks

here is a variation on the slug form script from lesson 25. this version does not use a pre-existing form on the page — it creates a simple text frame holding information similar to the ‘page information’ you can add to your printouts, with three important improvements : it’s more readable ; it includes the page dimensions and ; it includes the user name.

the full version of the script prints the document and exports a pdf to an email attachment — functionality that you can find lessons for elsewhere on this site. today we’ll just focus on the core problem of creating the slug info which will look something like this :

the first part of the script demonstrates a handy little scripting trick — the script property :

property mgUser : ""

if mgUser is "" then
  --bit to collect new user name
  tell application id "com.adobe.InDesign"
    activate
    set mgDialog to make dialog
    tell mgDialog
      tell (make dialog column)
        tell (make dialog row)
          make static text with properties {static label:"Enter the name you'd like to be known by."}
        end tell
        tell (make dialog row)
          set mgTextField to make text editbox with properties {edit contents:"Who you then?", min width:250}
        end tell
        tell (make dialog row)
          make static text with properties {static label:"(you won't be hassled with this again)"}
        end tell
      end tell
    end tell
    
    set mgResult to show mgDialog
    if mgResult is true then
      set mgUser to edit contents of mgTextField as string
      destroy mgDialog
    else
      error number -128
      destroy mgDialog
    end if
  end tell
  mgRunThisSucker()
else
  mgRunThisSucker()
end if

you’ll notice that we set the property mgUser to “” right at the start, and then go on to ask if mgUser is “”… — now that might seem nonsensical, but it’s not — because script properties have persistent data. the first time we run the script mgUser starts off as “” but is given a different value by the user when they enter their name in the dialog that’s generated (eg. ‘macgrunt’). that new value gets saved as an integral part of the script so that the next time it is run mgUser is “macgrunt”, not “”. by wrapping that whole script in an if/then statement, we ensure that the user only has to enter their name the first time the script is run. every subsequent run skips everything down to the second last line — mgRunThisSucker().

the user will be presented with a dialog something like this :

of course, you can change the various text elements in that dialog to read however you like.

the next part of the script captures a bunch of data we need :

on mgRunThisSucker()
  with timeout of 36000 seconds
    set mgHour to do shell script "date '+%H'"
    set mgMinute to do shell script "date '+%M'"
    if mgHour is less than 12 then
      set mgAmPm to "am"
    else
      set mgAmPm to "pm"
    end if
    if mgHour is more than 12 then
      set mgHour to mgHour - 12
    end if
    set mgDate to do shell script "date '+%d/%m/%y'"
    set mgDate to mgDate & "  :  " & mgHour & ":" & mgMinute & mgAmPm
    
    tell application id "com.adobe.InDesign"
      tell active document
        set mgName to name
        set mgFolder to file path
        set text item delimiters of AppleScript to "."
        set mgShortName to text item 1 of mgName
        set text item delimiters of AppleScript to ":"
        set mgClient to text item -4 of (mgFolder as string)
        set text item delimiters of AppleScript to default

we’re capturing both the date and time for this version of the slug form. notice that …”date ‘+%H’” captures the hours in 24-hour time — but we want our time to appear as “2:00pm” rather than “14:00″ — hence the bit of extra mucking around. if you’re happy with 24-hour time you could capture mgDate like this :

do shell script "date '+%d/%m/%y  :  %H:%M'"

note also that the way you capture mgClient depends on where the InDesign file sits in your folder hierarchy — text item -2 of (mgFolder as string) is the folder containing the InDesign file — text item -3 of (mgFolder as string) is the next folder up, etc.

next we create a layer and paragraph style for the slug information (if they don’t already exist) and the slug offset at the bottom of the page :

        try
          set mgLayer to layer "SLUG"
          set locked of layer "SLUG" to false
          delete every text frame of layer "SLUG"
        on error
          set mgLayer to make layer with properties {name:"SLUG"}
        end try
        try
          set mgPara to paragraph style "SLUG"
        on error
          set mgPara to make paragraph style with properties {name:"SLUG", justification:left align, point size:7, applied font:"Minion Pro  Regular", fill color:"Black"}
        end try
        
        set mgBleed to document bleed bottom offset of document preferences
        set mgSlug to mgBleed + 5
        
        if slug bottom offset of document preferences is less than mgSlug then
          set properties of document preferences to {document slug uniform size:false}
          set properties of document preferences to {slug bottom offset:mgSlug}
        end if

the first part has a couple of try blocks — the first time the script is run on a particular file it will create a new layer and para style — but on subsequent runs the layer and style will already exist and trying to create them again will cause an error. so, instead, we cover off all eventualities with the try blocks. notice that the first try block deletes all the text frames on the slug layer — new frames are created with fresh content on each run. the rest of that part of the script is dedicated to setting the slug offset to 5mm outside the bleed (unless it’s already bigger than that).

the next part captures the rest of the data we need and puts all the elements together into one long text string (mgContents) :

        repeat with mgspread from 1 to count spreads
          set active spread of layout window 1 to spread mgspread
          tell active spread of layout window 1
            set mgPage to name of page 1
            set mgWidth to item 4 of bounds of page 1
            set mgWidth to mgWidth as integer
            set mgHeight to item 3 of bounds of page 1
            set mgHeight to mgHeight as integer
            set mgDimensions to ((mgHeight as string) & "x" & mgWidth as string) & "mm"
          end tell
          
          set mgContents to mgShortName & "  :  " & mgClient & "  :  page " & mgPage & "  :  " & mgDimensions & "  :  " & mgUser & "  :  " & mgDate

notice that we’ve opened a repeat loop here — because we want to add a separate slug to each spread (this script was created for a workflow where it is possible that a single file could have pages of varying sizes).

and finally the last bit — create the text frame, fill it with text, style the text, move the frame to the right layer and, when all frames are done, lock the layer so it can’t be inadvertently used for other content :

          set mgBounds1 to mgHeight + mgBleed
          set mgBounds3 to mgBounds1 + 4
          set mgFrameBounds to {mgBounds1, "0", mgBounds3, mgWidth}
          set mgSlug to make text frame in page mgPage with properties {geometric bounds:mgFrameBounds, fill color:swatch 1}
          set properties of text frame preferences of mgSlug to {inset spacing:{0, 2, 0, 2}}
          set vertical justification of text frame preferences of mgSlug to bottom align
          set contents of mgSlug to mgContents
          set applied paragraph style of parent story of mgSlug to "SLUG"
          move mgSlug to layer "SLUG"
        end repeat
        set locked of layer "SLUG" to true
      end tell
    end tell
  end timeout
end mgRunThisSucker

cobble all that together and you’ll have a script that looks something like this :

save that as a script (.scpt) into your scripts panel folder. as discussed in the previous post, lesson 26, if you save it in text format (.applescript) the property mgUser will not be saved as persistent data and will have to be entered every time the script is run — and that would be tedious.

if you can’t be bothered compiling this yourself, you can go here to get the complete slug script

keep grunting

you learn something new every day — well, at least you should, if you’re paying sufficient attention.

way back in lesson 04 you’ll find this statement :

the first scripting lesson – lesson 01 – suggested you save your InDesign applescripts in script file format (.scpt). but there’s a very good reason why you should ignore such nonsensical advice and save them in text file format (.applescript) instead…

well, it turns out that there’s also a very good reason to ignore THAT and go on and save your scripts in .scpt format — the marvellous script property.

a script property is an immensely handy little scripting trick. it allows you to save data into a variable, within the script, so that it is still available the next time the script is run, and the next time. The data is persistent.

one example of the use of a script property is in the finder cleanup app. on the first run, this script captures the way finder windows are set so that, the next time the script is run, and every time after, those same finder windows can be opened in exactly the same place and pointing to exactly the same folders. so, the data is captured, then used over and over again.

but, if your InDesign script is saved in text format (.applescript) the data captured in the script property is not persistent. it works fine while the script is running, but the data is lost once the script ends and has to be reinstated the next time the script is run.

so, if you’re going to take advantage of a persistent script property you need to save your work in the .scpt format.

the next scripting lesson will show how a script property is used in a variation of the slug form script from lesson 25.

with a little bit of effort you can turn poor typography into ok typography in your body copy. unfortunately, InDesign doesn’t really allow for great typography — but that’s something we’ll touch on in a moment. this post is about automatic kerning, justification and hyphenation.

the first thing to check when you’re working with a particular font is what result you get with each of the automatic kerning options — metrics and optical. which one of those is best for a particular font depends on how good the type designers were at doing their job.

when you choose metrics you are using the mathematical settings created by the typographer. a well created font will have metrics for all the most common character pairs — specifying, for example, the amount of space that should appear between ‘AB’, which will (at least, should) be different from the amount of space that appears between ‘AV’. these metrics are generally known as kerning tables.

when you choose optical you are asking InDesign to override the typographer’s kerning tables and space the characters more or less visually based on the shapes of the characters.

here are a couple of screen grabs showing the same portion of text using the two different automatic kerning methods :

as you can see, neither of these methods is perfect. ‘his’ and ‘and’ are undoubtedly better using metrics kerning, but ‘winston’ and ‘musing’ are better when using optical kerning — the metrics don’t come up to scratch. and this for a font called Adobe Garamond Pro — you would think we should expect better from the metrics.

and here’s why InDesign doesn’t allow for great typography and why, in at least this one aspect, Quark shits all over InDesign. with Quark you have the option to correct dodgy metrics by editing the kerning tables. so, with Quark we could get in there and fix that diabolical ‘mu’ combination in the kerning table and then it would be corrected for every instance throughout the entire document. InDesign allows no such finessing — we are stuck with the shitty kern-pairs that come with the font or we take our chances with optical kerning.

so, when working with a new font, always check both automatic kerning methods to see which will give you the least disappointing results.

ok, now on to justification. the default justification settings that come with InDesign are simply insane and lead to this kind of abomination :

this is because the default justification settings look something like this :

those numbers are invariably going to lead to shit results. all the adjustments to a line of text happen between the words — none between the individual characters — and those adjustments range from 133% word spacing (big gaps) down to 80% (words running together).

settings which make just a little more sense look something like this :

… and will lead to better results — not perfect, but better :

right, last we have hyphenation and, again, the defaults are ludicrous :

just the fact that automatic hyphenation is turned on by default is silly enough — because InDesign is not that great at deciding where a hyphen should appear within a word. but the rest of those settings will, AGAIN, invariably lead to shit results — like this :

four hyphens in the first seven lines and the very first word on the page is the second half of a word from the previous page — just atrocious.

most jobs do not require automatic hyphenation — you should add your own (discretionary) hyphens, where appropriate, as you set the text. if you really must use automatic hyphenation (eg. you’re laying out vast tracts of text like a novel) then you should uncheck all those check boxes and adjust the other settings to something more like this :

the improvement to the type is simply indisputable :

but wait, there’s more …
once you come up with a bunch of settings which suit your sensibilities you can make them your very own defaults — just the same as you can change so many of InDesign’s default settings. just make sure you have no documents open then adjust the justification and hyphenation settings through the paragraph panel (under the type menu) :

those will be your new defaults for every new document from now on.

keep grunting