I have this working draft of a post explaining how badly broken Applescript is from purely an Apple-owned technology perspective, and imploring Apple to do something about it. It’s a bit long. But, since Adobe’s Creative Cloud has been released and I got my grubby little hands on a copy, I decided to look at the state of Applescript support in my most-used applications. It’s not that I have high hopes of anything improving given support since Creative Suite 5, but this is my bread and butter so it’s worth a look to see what I have to workaround in future upgrades of scripts, if upgrading a script is even worth the time.
Currently, my Applescript “support” of in-house that utilize Adobe applications has been relegated to using one call—
Here is what we have to work with.
- Photoshop: Line 1280.
- InDesign: Does not exist in the header.
- Illustrator: No header could be generated because the sdef (scripting dictionary) file does not exist.
I took a look at some other apps, like Bridge, and things go generally downhill from there. Essentially, any Applescript-related support is rendered useless in Creative Cloud. This is infuriating, back-stabbing bullshit. I would also like to say this is also unacceptable but that would ring hollow since the state of publishing technology is such that I have no choice but to use Adobe software. Nowhere on their site do they formally announce the drop in support in Illustrator, and given the dodgy performance of their Applescript API.
I wish Adobe would do three things:
- Formally announce that Applescript, if not OSA support in general, is going away.
- Pick a date well in advance (like a year) for developers to prepare.
- Turn it off all at once so I can stop having to hunt for the state of their API.
This unannounced erosion in API support by inconsistency is poor form, though I expect nothing less from Adobe these days, and reflects their general customer support as well.
Slant.com: What are the best programming fonts?. (via Hacker News)
The actual voting is likely not very scientific, but this is a really great collection. I’m a bit surprised to see that (a) Source Code Pro is at the top (by a thin margin) and (b) there is no italic form of the font. That latter point is a glaring and non-starter omission for me as I change all my comments to italics to help with reading context, and doubly so since this an Adobe font, a world leader in font development.
I had forgotten about Anonymous Pro, which I liked for a while, but I thought the glyphs were too wide.
I am currently using Menlo and really like it, particularly at 11 pt. Most of my editors default to Monaco, which I never liked. Monaco always just seemed a bit too clunky for my taste.
Subject says (most of) it all. I have been working with the command line more lately, partially out of need, largely out of preference, and am starting to collect a bunch of little snippets I have modified from other or created out of whole cloth to get me through my day.
The section has a germinal collection of command line snippets, but the real work lies in the shell scripting cheat sheet and info on creating a command line application with Xcode using Foundation classes.
Friends don’t let friends drink and drive.
Friends don’t let friends drink and drill.1
Friends don’t let friends drink and Photoshop.
Friends don’t let friends drink and review code.
Apologies to Matt Groening, but this has always been one of my favorites.
Working with Excel files in Excel via Scripting Bridge is non-obvious, even when the bulk of the work done is extracting information from Excel like I do. Exporting content from Excel into CSV or a tab-delimited file isn’t an option since oftentimes I need to capture styles applied to text that is simply lost upon export. I have to work in Excel, and over time I have learned that in order to work with an Excel file with Scripting Bridge, the file must meet these conditions:
- Saved in
.XSLX format and not
- Have more than one worksheet (tab).
- Not have any data connections.
The first condition was simple to troubleshoot and check because the file will not open. There is no visible error, but the returned value is
nil. Bam. Done.
The second condition was not as obvious. I discovered the condition through the
getItemCountInColumn:removeHeaderRow:inSheet: function in my
OCScriptingBridgeExcelController class. The problem was that the function would never stop counting. Columns with 1,000 items would be in the tens of thousands before I figured out what was going on and stopped the application. I don’t know what other issues may arise by having only one tab—finding those would be all but impossible to test given the sheer volume functions available in Excel—but at least I know the issue is there and the condition is easy to test. As to why the number of worksheets would interfere with such a seemingly simple function is buried somewhere in Microsoft.
The third test—no data connections—is proving to be much more difficult and had the same problems as the second. The problem testing for this arises when trying to decipher what Excel means by a data connection. Is this a connection in a pivot table or is this a named item, and what can be done about the connection if one is found? Connections, in general, are pretty well scattered throughout the API. Connections are managed (so far as I have found) in two places: the
pivotCache class, accessed through the
workbook class, and the
namedItem class, accessed through the
worksheet class. Documentation on both is just as scattered (and non-existent on the Mac). In my case, it appears the
namedItems array is where my found connections are held. In Applescript, there is no way to remove one once it has been created, and I haven’t gotten around to figuring out how to handle the existence of a named item. I am left with the same question as I do for the second condition: What does the existence of a named item have to do with getting information from an Excel spreadsheet? This is just weird.