About macgrunt

publishing industry production grunt : interested in workflow automation and optimisation : particularly applescript

renaming finder items III

Posted on October 13, 2012 by macgrunt

renaming finder items introduced a couple of ways to batch-rename files in the finder — using automator or applescript — by replacing characters or removing parts of the file name. renaming finder items II showed how to map a bunch of files to a completely different set of file names.

Applescript Icon this post will show another way to rename files — based on their creation date — using applescript. this workflow came about due to the diabolical way that digital cameras name their files. here’s a screen grab of a typical bunch of images :

for this workflow, we’d like the order of the filenames to match the date the photo was taken — to make sorting, selecting, archiving, etc. just a little easier. the current naming is made more problematic because files are coming from more than one camera. well, we don’t have to put up with that crap — let’s just rename them.

set mgFolder to choose folder
tell application "Finder"
  set mgFiles to items of mgFolder
end tell
repeat with mgFile in mgFiles
  set mgPath to POSIX path of (mgFile as string)
  set mgCreation to creation date of mgFile
  set mgDate to short date string of mgCreation
  set mgTime to time string of mgCreation
  
  -- rest of script here
end repeat

first we get the user to select a folder of images to process, then we get references to the files in that folder, then we start a repeat loop to process each file in turn. we capture the following information :
mgCreation – for example “Thursday, 4 October 2012 17:13:18 ” – from which we extract :
mgDate – “04/10/12″ (that’s dd/mm/yy) and
mgTime – “17:13:18 ” (that’s hh/mm/ss)

if you find that mgDate or mgTime give you the data in a different format, you will need to update the next part of the script accordingly or, if you prefer, change your language and text system preferences :

we’re going to use mgDate and mgTime to create a file name like this “yymmdd_hhmmss” — so, we need to strip out the slashes and colons, reverse the order of the date, and introduce an underscore :

  set text item delimiters of AppleScript to ":"
  set mgTime to text items of mgTime --gives {"17", "13", "18 "}
  set text item delimiters of AppleScript to "/"
  set mgDate to reverse of text items of mgDate --gives {"12", "10", "04"}
  set text item delimiters of AppleScript to ""
  set mgDate to mgDate as string --gives "121004"
  set mgTime to mgTime as string --gives "171318 "
  set mgTime to text items 1 thru 6 of mgTime as string
  
  set mgNewName to mgDate & "_" & mgTime

this uses the handy “reverse of” command — taking a list of items and rearranging them in reverse order. also notice the second last line — we need that because mgTime has a trailing space we need to get rid of. this method works no matter how many trailing spaces there are because we’re saying “just give me the first six characters and ditch the rest”.

now, that’s the bulk of the script done — we also need to capture the extension of the file (mgExtension), create a filepath for the renamed file (mgFinalPath), and then do the renaming with a shell script. the shell script basically says — move this file, without any prompts, from this filepath to that filepath (you could also use this method to move the file to a completely different location — but we’re just renaming the file and leaving it in the same location) :
danger : do not run this next script — it is for demonstration purposes only – you’ve been warned!

set mgFolder to choose folder
tell application "Finder"
  set mgFiles to items of mgFolder
end tell

repeat with mgFile in mgFiles
  set mgPath to POSIX path of (mgFile as string)
  set mgCreation to creation date of mgFile
  set mgDate to short date string of mgCreation
  set mgTime to time string of mgCreation
  
  set text item delimiters of AppleScript to ":"
  set mgTime to text items of mgTime
  set text item delimiters of AppleScript to "/"
  set mgDate to reverse of text items of mgDate
  set text item delimiters of AppleScript to "."
  set mgExtension to text item -1 of (mgFile as string)
  set text item delimiters of AppleScript to ""
  set mgDate to mgDate as string
  set mgTime to mgTime as string
  set mgTime to text items 1 thru 6 of mgTime as string
  
  set mgNewName to mgDate & "_" & mgTime

  set mgFinalPath to mgFolder & mgNewName & "." & mgExtension as string

  do shell script "mv -f " & quoted form of POSIX path of mgPath & space & quoted form of POSIX path of mgFinalPath
end repeat

if we run this script on that original folder of images we’ll get this :

well, that looks pretty good at first glance — all the files have been renamed successfully … except … the very observant will notice that this folder has only 81 items, whereas the original folder had 103. wtf?

the problem is that it’s quite possible to have more than one file with a creation date of “04/10/12 17:13:18″ — digital cameras can flick off quite a few images in a second. the script in its current form will simply write over a file with a duplicate filename. so we need to build in some method to check if a file with a particular name already exists and, if so, create a different name. here’s one way :

  set mgFinalPath to mgFolder & mgNewName & "_1" & "." & mgExtension as string
  tell application "Finder"
    set x to 2
    repeat
      set mgExists to exists file mgFinalPath
      if mgExists is true then
        set mgFinalPath to mgFolder & mgNewName & "_" & x & "." & mgExtension as string
        set x to x + 1
      else
        exit repeat
      end if
    end repeat
  end tell

this time we’re appending “_1″ to each filename. then the script enters a repeat loop to check if a file with that name already exists. if so, it will change the end to “_2″ and then check that, incrementing by one on each pass through the loop. once it reaches a name that has not already been used it exits the repeat loop. this way we don’t lose any files :

this is the final form of the script. it’s always a good idea to test new scripts on duplicate files before implementing them into your workflow — just to make sure they do what you expect (and don’t do what you don’t expect) — you’ve been warned again :

set mgFolder to choose folder
tell application "Finder"
  set mgFiles to items of mgFolder
end tell

repeat with mgFile in mgFiles
  set mgPath to POSIX path of (mgFile as string)
  set mgCreation to creation date of mgFile
  set mgDate to short date string of mgCreation
  set mgTime to time string of mgCreation
  
  set text item delimiters of AppleScript to ":"
  set mgTime to text items of mgTime
  set text item delimiters of AppleScript to "/"
  set mgDate to reverse of text items of mgDate
  set text item delimiters of AppleScript to "."
  set mgExtension to text item -1 of (mgFile as string)
  set text item delimiters of AppleScript to ""
  set mgDate to mgDate as string
  set mgTime to mgTime as string
  set mgTime to text items 1 thru 6 of mgTime as string
  set mgNewName to mgDate & "_" & mgTime
  
  set mgFinalPath to mgFolder & mgNewName & "_1" & "." & mgExtension as string
  tell application "Finder"
    set x to 2
    repeat
      set mgExists to exists file mgFinalPath
      if mgExists is true then
        set mgFinalPath to mgFolder & mgNewName & "_" & x & "." & mgExtension as string
        set x to x + 1
      else
        exit repeat
      end if
    end repeat
  end tell
  
  do shell script "mv -f " & quoted form of POSIX path of mgPath & space & quoted form of POSIX path of mgFinalPath
end repeat

now, of course, you can run this script for any kind of file, not just images. but in its current form it has no error handling for if it encounters a folder. we’ve fixed it so it won’t have a hassle with duplicate files, but if it hits a folder you’ll get something like this :

dammit you say. but the fix is actually very simple — just change the line “set mgFiles to items of mgFolder” to “set mgFiles to files of mgFolder” and the folders will be skipped — no drama.

but that’s not all …
just to be safe, or because your workflow calls for it — you could change the script so that it makes a copy of the file — giving the new name to the copy and leaving the original untouched.

and again, the solution is very simple — change the shell script from move (mv) to copy (cp) :

do shell script "cp -f " & quoted form of POSIX path of mgPath & space & quoted form of POSIX path of mgFinalPath

you can get a copy of the RenameByDate app here

keep grunting

macgrunt icon

InDesign tip : #27

Posted on October 7, 2012 by macgrunt

ok, so, here’s the deal with ruler guides … there’s probably handy stuff you don’t know yet …

let’s start with the basics. you click-drag a guide from a ruler (if your rulers aren’t showing, hit cmnd-r). if you want a horizontal guide, drag from the top ruler. if you want a vertical guide, drag from the left ruler. BUT if you accidentally drag from the wrong ruler, just hold your option key before you let that button go and your guide will change orientation. cool.

if you want your guide to only traverse the page, you drop it on the page. if you want it to extend across a complete spread or across the pasteboard, drop it on the pasteboard. simple.

you can also drag a horizontal and vertical guide at the same time — hold your cmnd key and click-drag from your origin (these guides always traverse the spread/pasteboard) :

to select a guide, just click on it. to select a bunch of guides, click-drag over them. to lock your guides so they can’t be selected (and moved or deleted) go view > grids & guides > lock guides. to lock individual guides (rather than the whole lot) just select and lock them the same as you would an object — object > lock — or cmnd-L.

and you can lock all the guides on a particular layer by double-clicking the layer in the layers panel and then checking the lock guides box in the layer options window that appears (notice you can show/hide guides on a particular layer here too) :

an active (selected) guide is the same colour as the active layer. so, if you’re having difficulty seeing a guide as you drag it because the guide is the same colour as the background, just change the colour of the layer or choose a different layer to drag the guide on to.

the colour of a placed (deselected) guide is determined by your ruler guides settings. find this under your layout menu. setting the colour here only affects the guides you create from here-on-in. already existing guides maintain their original colour. change an existing guide by selecting it and then choosing ruler guides (which you can also access with a right-click once a guide is selected). go crazy.

this is also the place to set the view threshold of a guide — that is, the magnification level below which the guide will no longer be visible (unfortunately this isn’t terribly accurate — eg. in CS6, guides with a view threshold of 100% don’t disappear until 55% — you just have to get over it). if you want the guide to be visible at every magnification level — set the view threshold to 5% (the minimum magnification in InDesign) :

to quickly hide or show all guides use cmnd-; (also see the difference when you just hit ‘w’ — making sure your text cursor isn’t active at the time, of course — this is called preview mode).

to delete all guides on a spread right-click (or cntrl-click) a ruler and choose that command from the dropdown. this can also be accessed through view > grids & guides (this does not affect locked guides) :

but you might prefer to do it entirely from the keyboard — select all non-locked guides with cmnd-opt-g and then just hit delete.

to delete all guides throughout an entire document you need a tiny little script which you’ll find all the way back in InDesign scripting : lesson 01

if you just love precision (and don’t we all) you can use your control panel to place and distribute guides exactly where you want them. this screen grab shows what the control panel might look like with four vertical guides selected :

and now for tricky guides …
if you double-click the top ruler you’ll get a vertical guide in that position (left ruler gives you a horizontal guide, of course) — this is a great way to get a bunch of guides on the page quickly, before dragging them into exact position.

but the tricky guides are the ones you get if you use this method with the option key selected. they are partially protected guides. you can’t select them with the cmnd-opt-g method and they won’t be deleted when you choose delete all guides on spread. but these guides can still be selected and moved with your mouse and they can be deleted once they are selected. tricky — and handy.

note that the default view threshold of the tricky guides is the same as the magnification level at which they were placed. to change it, simply select the guides and right-click to access the ruler guides window.

but wait, there’s more …
if you want to place a whole bunch of guides in a regular pattern you can use create guides under the layout menu. this not only lets you create the familiar looking columns but also the less common but still-quite-functional-really rows :

rock on

and there’s still even more …
if you like to work by placing items on a page and then dragging guides to match the edges or centres of your placed items then you really should play around with the AddGuides scripts (both applescript and javascript) that come with InDesign. select your item/s and double-click the script in the scripts panel (window > automation > scripts OR window > utilities > scripts) and you’ll get a dialog box something like this (the javascript version is a little different) :

automatically placing as many guides for as many objects as you want :

and we haven’t even started on guide preferences, snap to guides and smart guides — but you probably already know all about that stuff.

keep grunting

macgrunt icon

InDesign scripting : lesson 25

Posted on October 2, 2012 by macgrunt

a slug form is a brilliant way to attach proofing data to an InDesign file — especially when you’re trying to keep track of which version of a job a client is signing off on.

there are many variations on the slug form, but all of them need to be filled out at some stage and many of them need to be updated with each new proof. here’s one that can be updated entirely automatically each time a pdf is exported — using applescript (click to enlarge) :

code and job are details pulled from the filename ;
client will be pulled from the document’s filepath ;
size and page are pulled from data for each page ;
proof is incremented by 1 each time the script is run ; and
proof date is gathered using a shell script.

for this example we’ll be using this document in this folder structure :

the first part of the script starts capturing the data we need :

set mgDate to do shell script "date '+%d/%m/%y'"

tell application id "com.adobe.InDesign"
  tell active document
    set mgPath to file path as string
    set mgName to name
    
  end tell
end tell

the shell script grabs the current date and pulls the elements we want into a text string (mgDate) like this “31/09/12″. that’s the australian date format, if you wanted that weird month-day-year format you’d change it to :

set mgDate to do shell script "date '+%m/%d/%y'"

if you wanted to add the time as well, you could do it like this :

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

which would make mgDate something like “13:45 31/09/12″

we’ve also captured mgPath —
“Macintosh HD:macgrunt:clients:macgrizzle:mg34567_stationery:”
and mgName —
“mg34567_letterhead.indd”
which now have to be broken up to get at their bits. this is done with text item delimiters. a text item delimiter specifies which character is used to separate elements in a text string. in a sentence, the space character is used to separate words. in the file path above, the colon character is used to separate the folder names. so, here’s how we get the bits we need :

    set mgPath to file path as string
    set mgName to name
    set text item delimiters of AppleScript to ":"
    set mgClient to text item 4 of mgPath
    set text item delimiters of AppleScript to "."
    set mgShortName to text item 1 of mgName
    set text item delimiters of AppleScript to "_"
    set mgCode to text item 1 of mgShortName
    set mgJob to text item 2 of mgShortName
    set text item delimiters of AppleScript to default

this gives us three elements : mgClient = “macgrizzle”, mgCode = “mg34567″, and mgJob = “letterhead” (we’ve also captured mgShortName “mg34567_letterhead” which we could use when we export the PDF).

now, this workflow was created for InDesign files that could have different page sizes throughout and needed a separate slug for each page. so the next part gets placed within a repeat loop to address each page in turn :

    repeat with mgPage from 1 to count pages
      set mgWidth to item 4 of bounds of page mgPage
      set mgWidth to mgWidth as integer
      set mgHeight to item 3 of bounds of page mgPage
      set mgHeight to mgHeight as integer
      set mgDimensions to ((mgWidth as string) & "x" & mgHeight as string) & "mm"

      set active page of layout window 1 to page mgPage
      tell active page of layout window 1
        try -- check to see that correct SLUG is on the page
          set mgFrame to ((text frame 1 of group 1) whose label is "SLUG")
        on error
          try
            set mgFrame to (text frame 1 whose label is "SLUG")
          on error
            display dialog "Your SLUG should be in place on every page." & return & return & "(Note : the correct SLUG has been given a script label to help with automation)"
          end try
        end try
      --bits to enter data into slug table here
      end tell
    end repeat

the first part captures the page number (mgPage) and the page size (mgDimensions). notice that a page does not have a ‘size’, it has bounds and we have to get the dimensions from that. bounds are expressed as a list of four numbers which define, in order, the top, left, bottom and right edges of the page. for an A4 page with mm as the measurement unit, the bounds will be approximately {0.0, 0.0, 297.0, 210.0}. if you’re in the habit of moving your origin, you’ll need to change the way you capture the dimensions which may then be something like {-100.0, -50.0, 197, 160} for example.

the next part checks if there’s a slug on the page (mgFrame). the easiest way to do this is to give the text frame in InDesign a script label. you select the text frame and then choose window > utilities > script label (in CS6 — it might be in a different place in other versions of InDesign) and then type in whatever label you are planning to use. DO NOT hit return/enter, as this will become part of your script label — simply click outside the window instead. script labels are case sensitive :

we check for mgFrame twice — first to see if it’s part of a group (the way the slug was originally set up) and then again in case someone inadvertently ungrouped the slug. this is called error handling — we don’t want the whole script to fail just because the slug is ungrouped.

o … k … now we’ve got all the bits of data we need and we just need to plug them all into the slug. to understand the next bit it helps to know how the slug frame has been created — it’s actually a table with three rows — six cells in the first row, eight cells in the second row and one cell in the third row (again, click to enlarge) :

we captured the text frame (mgFrame) now we need to address the table within that frame :

        tell table 1 of mgFrame
          set contents of cell 2 of row 1 to mgCode
          set contents of cell 4 of row 1 to mgJob
          set contents of cell 6 of row 1 to mgClient
          set contents of cell 2 of row 2 to mgDimensions
          set contents of cell 4 of row 2 to mgPage as string
          if contents of cell 6 of row 2 is "#" then
            set contents of cell 6 of row 2 to "1"
          else
            set contents of cell 6 of row 2 to (contents of cell 6 of row 2) + 1 as string
          end if
          set contents of cell 8 of row 2 to mgDate
        end tell

hopefully that all makes sense. if not, flick a question through. when it’s done its thing the slug will look something like this :

bonza.

once that process has been repeated for all the pages it’s time to export the pdf proof. we’re not going to go into all that here — you can see how to export pdfs in lesson 08, lesson 11 and lesson 18

when you’re done cobbling all those bits together you’ll have a script that looks something like this :

rippa rita

macgrunt icon

adobe cs — colour #03

Posted on September 27, 2012 by macgrunt

adobe cs — colour #01 and colour #02 started an explication of the excruciating world of colour management. excruciating, not because it is immeasurably difficult, but because so many seem to avoid it altogether — this is unnecessary.

colour management can be extraordinarily complex if you get into the nitty gritty — but most of us don’t need to delve that deep. so, do yourself a favour and get a basic working knowledge of colour management to give your files the best chance once they hit the press.

unfortunately, there’s no definitive solution to the problem. no one can say “here are the settings to set and the buttons to push” because, well, it depends. let’s see why — here’s a pretty standard choice for colour settings in InDesign (under edit > color settings…):

now that’s probably fine if you’re a general purpose kind of person working in north america. but if you’re a prepress kind of person in australia it’s pretty shitty. one of the key rules of colour management is give yourself the widest practicable colour gamut as your starting point. hover your mouse over where it says “sRGB…” and you’ll see this description pop up at the bottom of the window :

see how InDesign gives you clues about what settings to use — “not recommended for prepress work (because of its limited color gamut)“. if you change to the north america prepess settings you’ll see the rgb profile change to adobe rgb (1998) — a better choice for prepress work, because it has a wider gamut which also, conveniently, more closely resembles the cmyk gamut — as its description explains :

but for aussie prepress dudes, we’re still not there. swop stands for “Specifications for Web Offset Publications” (for those who don’t realise, “web” is the term for printing from a paper roll). in australia, most commercial printing (apart from newspapers, magazines and catalogues) is done through sheet offset.

in adobe cs — colour #01 we saw that swop restricts the total ink coverage to 300% with a maximum black of 90%. but sheet offset can tolerate more ink and this is exactly why aussies are often disappointed by flat images when their shit hits the press — they are restricting their images to an unnecessarily narrow gamut by using swop — which they do either because it’s the default or because it’s what is recommended on all the (mostly north american) forums.

a decent sheet offset press/operator under good conditions can handle a tic (or tac if you prefer) of about 350% so let’s look at some colour spaces whose descriptions match that :

judging by the descriptions, these should all give similar results but, unfortunately, although InDesign did a good job of pointing us at a good rgb profile, it’s not quite so helpful when it comes to cmyk. remember, the image from colour #01 and colour #02 had a black background of r0g0b0. here’s how those three cmyk profiles will render that colour :

u.s.sc and fogra27 do indeed give us a tic of 350% — but look at the difference in the separations. that 85% total black is diabolical. you’re just about guaranteed to get shitty detail in your shadow areas using u.s.sc because it’s relying so heavily on all four plates to create the dark colours — whereas fogra27 loads as much achromatic data as possible onto the black plate which will almost certainly result in a crisper result.

looking at the data for fogra39 we can see that the description was incorrect — it only allows for a tic of 330% (not 350%) but we can probably put this down to a typo — it’s very likely the fogra39 description was just copied from fogra27, which has been with us for longer.

so, is fogra27 better than fogra39? again, it depends. as mentioned above, 350% tic is easily achievable under ideal conditions but very much of our printing is done in a subideal reality. if you’re a prepress dude in australia sending high quality work to an excellent printer who has plenty of time (and budget) to do a high quality job, fogra27 is a good choice. if you’re sending stuff to a decent printer who’s been screwed down on the delivery deadline, then fogra39 will give you and them less grief.

having said all that … in an ideal world we would always get to speak directly with the printer’s production dude for explicit instructions on the best protocol to use for each job — but this isn’t always possible or practical — so we have to get better at best-guess scenarios.

• related post : InDesign tip : #24 : checking the black plate in separations preview.
• related post : adobe cs — colour #01 : you don’t need to convert images to cmyk.
• related post : adobe cs — colour #02 : you really need to get your shit together.

macgrunt icon

adobe cs — colour #02

Posted on September 23, 2012 by macgrunt

adobe cs — colour #01 started looking at colour management in adobe creative suite — specifically, how images no longer need to be converted to cmyk in photoshop. this post continues the indoctrination — colour management can be left to InDesign.

HOWEVER, you really need to get (and keep) your shit together.

let’s continue by following two documents converted to two different common colour profiles — fogra 27 and web swop. again, we are using the exact same rgb psd file in those two documents :

the separations preview panels show the breakdowns for the red and the background black for both documents (as indicated by the white circles).

now, when you export to PDF you get a few different options for colour conversion — no colour conversion, convert to destination, and convert to destination (preserve numbers) :

if you choose no colour conversion for either of those documents you’ll get exactly the same numbers in the PDFs as are shown in the separations preview panels above. what does this mean? it means that if you want to control your output you need to make a decision about which profile to use for your InDesign files. because images will produce significantly different results under different export conditions and unless you take control, you’ve got no idea what’s going to happen to your imported images once it’s time to export for print.

if you take either of those documents and export it to the opposite profile using convert to destination (preserve numbers). you’ll get exactly the numbers of the opposite profile. that is, if you take the fogra document and export it to swop using “preserve numbers” you’ll get the swop numbers in your pdf. however, if you use convert to destination without the preserve numbers option you’ll get a different set of numbers entirely — neither the swop nor the fogra ones.

what does THAT mean? it means, again, the choices you make (or fail to make) have an impact on your final output — both your indesign profiles and your export protocol will affect the finished product and if they don’t match, the effect is going to be unpredictable. or, more simply, if you don’t take control of your workflow you’re going to get unexpected results.

so, you have to get your shit together when it comes to colour management — don’t get pushed around by the software — you have to be the one doing the pushing.

ok, so that’s a demonstration of the problem. next up we’ll start looking at the solution.

• related post : InDesign tip : #24 : checking the black plate in separations preview.
• related post : adobe cs — colour #01 : you don’t need to convert images to cmyk.

macgrunt icon

macgrunt

mac automation and other stuff

Author Archives: macgrunt

About macgrunt

renaming finder items III

InDesign tip : #27

InDesign scripting : lesson 25

adobe cs — colour #03

adobe cs — colour #02

Follow “macgrunt”

About macgrunt

Share this:

Share this:

Share this:

Share this:

Share this:

Follow “macgrunt”