Back in this post, AppleScript Identifying InDesign Hidden Characters, I outlined an issue with AppleScript picking up meta-characters from InDesign that were causing false results in string evaluations. Posting my problem to the Adobe forum resulted in a couple of less than helpful suggestions that revolved around calling in the robust JavaScript. Thanks for trying, guys, but JavaScript is not the sharpest chisel in my tool box. Also, I still feel this is a bug in the CS5 programming, but I'm not going to waste my time trying to push the issue with Adobe.
I did manage to generate a fix of my own though. I was trying to avoid re-writing the original script and how it was evaluating the content, but I was not left with many options, and I set about adding in a new handler.
Instead of comparing the contents of all of the text frames on a page that share a similar script label against a pre-set list of strings, this handler counts the number of text items in each string in the list. Because the application is recording data from the meta-character, it should have at least one and if any one string in that list contains more, it is considered not empty and returns a corresponding boolean value that is evaluated by the main body of the script. True, execute the contents of the block; false, do nothing. This worked pretty well until I started testing on other templates that are used. Some of the data merge remnants would return three or more text items in what was supposed to be an empty frame! I changed the text item delimiters that AppleScript uses to count those items, but I had to insert a couple of assumptions, the first being that one set of labeled frames would always receive a price containing a decimal, if anything, and the other would always receive a string of text two or more words in length, separated by a space. I dislike doing this because it opens the door for any number of exceptions, but the data sources supported the plan. By re-setting these parameters, the text item count for an empty frame would always return "1", regardless of the number of metacharacters, as they would have no decimals or spaces to separate them.
I also cleaned out the small army of redundant tell statements directed at the application, an assigned variable that was never used in the script, a number of blocks that no longer had a function because of the logic of the new handler, and inserted some detailed documentation regarding the revisions.
A successful update, and a working solution to a satisfying challenge. Now I'm off to script a process on a baleful application, Microsoft Excel.
Thursday, April 21, 2011
[Stratos Burst] Because the stratosphere is hella tits!
Obviously there are considerations to be made; equipment, FAA regulations, legalities, launch and landing planning, etc. I'll be blogging here as I develop what we shall title Project Stratos Burst.
Stay tuned!
Monday, April 11, 2011
AppleScript identifying InDesign hidden characters
This last week I have been updating a script that acts on Adobe InDesign; the update is to move the script from CS4 to CS5. Besides cleaning up the code to remove the small army of redundant tell statements in the original script, the only edits that it needs to function properly are revisions to the syntax in statements that address script labels. This is a common bug for us this time around and is usually one of the first things I look for, and solves 90% of our broken scripts. This particular script has presented greater difficulty and I am a little stumped. After the standard edits have been made, the script runs to completion, but fails to perform any of the intended actions, and I've narrowed it down to the result of an if statement that never returns true.
The script is intended to pull the content of all text frames on a page that are tagged with a given script label, and compares the result to a variable for a string match. In this case the control variable is
Prior to the running of this script, the page is generated by executing a data merge within InDesign onto a template document. The script then checks these particular frames for content because sometimes they receive empty strings of data in the merge. Even so, the hidden characters that InDesign uses to mark the beginning and end of a record entry remain.
Most functions typically ignore these, but it seems that InDesign is picking it up in the get contents command, even though in the context of the application, it has no idea what it is or how to address it. It's taken me a couple days to figure this out.
Here is the native AppleScript Editor event log showing it's script command and the return (lines 1-3):
And here is the results of the same command (lines 1-2 above), and the returned list as seen in Script Debugger's event log on AEPrint view:
To translate that into a string view it would look like
AEPrint picks up a bit of data in that string, although it has no idea how to display something that exists only in the context of InDesign as a virtual glyph representing an insertion point. As far as I can tell the character is selectable only through a shift-arrow selection. It can be copy/pasted into into a find/change field but does not return as a result in a text or GREP search.
It is possible to manually remove the record markers from the frame, but this defeats the purpose of using a script as it involves a user touching every affected frame every time a data merge is run. I'd rather not re-write how the script evaluates the content of the frame as the current method is probably the most accurate, but I could attempt to count the characters in the frame and hope that all future merged content is longer than two characters. I need to figure out how to coax AppleScript to allow me to manipulate these hidden-but-existing characters, or otherwise ignore them entirely. Is there an elementary solution here that I'm passing over, making this harder than it should be?
It seems to me, since this script ran well with InDesign CS4, so something might have changed in CS5. Is it possible that hidden characters that were beneath the view of InDesigns other functions are now being included? Or is this an overall bug in the machine?
The script is intended to pull the content of all text frames on a page that are tagged with a given script label, and compares the result to a variable for a string match. In this case the control variable is
{"","","",""}The content of the four text frames on the page is compared to this control in an if statement
if pageData is dataCheck thenso if all four frames are empty, the if statement should return true, and the contained actions will be executed, which it never does. The culprit appears to be a hidden character that is the remnant of a data merge, but I'm at a loss on how to deal with it.
 | |
| Record Marker (:) and End Of Story (#) |
Most functions typically ignore these, but it seems that InDesign is picking it up in the get contents command, even though in the context of the application, it has no idea what it is or how to address it. It's taken me a couple days to figure this out.
Here is the native AppleScript Editor event log showing it's script command and the return (lines 1-3):
And here is the results of the same command (lines 1-2 above), and the returned list as seen in Script Debugger's event log on AEPrint view:
To translate that into a string view it would look like
{"?","?","?","?"}
AEPrint picks up a bit of data in that string, although it has no idea how to display something that exists only in the context of InDesign as a virtual glyph representing an insertion point. As far as I can tell the character is selectable only through a shift-arrow selection. It can be copy/pasted into into a find/change field but does not return as a result in a text or GREP search.
It is possible to manually remove the record markers from the frame, but this defeats the purpose of using a script as it involves a user touching every affected frame every time a data merge is run. I'd rather not re-write how the script evaluates the content of the frame as the current method is probably the most accurate, but I could attempt to count the characters in the frame and hope that all future merged content is longer than two characters. I need to figure out how to coax AppleScript to allow me to manipulate these hidden-but-existing characters, or otherwise ignore them entirely. Is there an elementary solution here that I'm passing over, making this harder than it should be?
It seems to me, since this script ran well with InDesign CS4, so something might have changed in CS5. Is it possible that hidden characters that were beneath the view of InDesigns other functions are now being included? Or is this an overall bug in the machine?
Subscribe to:
Posts (Atom)