Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

I had a handy script I wrote on a plane years ago that let me block off my Entourage calendar at specific times each weekday for a given week. The times for these events were created by concatenating some strings and converting the result into an AppleScript date object. I mention that merely for background, and because it was an incredibly geeky way to automate the tedious process of blocking off lunch on my calendar (without resorting to recurring events).

I found that my script didn’t work in Snow Leopard — despite flawless operation across several successive major versions of Mac OS X. The dates themselves remained correct, but the times were all coming up as 12:00 a.m. instead of what was expected.

For example, here’s a simplified reproduction scenario you can try on Snow Leopard:

It turns out that the fix is easy if not exactly obvious: remove the periods from “a.m.” and “p.m.” before converting strings to date objects. (I use the periods because I follow the Associated Press Stylebook!)

So, there is a workaround in the unlikely event you encounter the same problem with your scripts.

A question came up on the AppleScript-Users mailing list and I wanted to make note if it, because I came up with a quick Python-based way to answer it. Here, I reiterate that answer on how to get the number of pages from a PDF.

This Python 2.5 sequence (shown as run interactively from the Terminal on Leopard — not as a script) works for me using both a local file and a file from an AFP-mounted volume. It uses the Quartz 2D bindings for Python, which are part of the Python install on Mac OS X (since 10.3?), so it is not pure Python.

Substitute your own path for the pdf_filename variable’s contents, and you can try it yourself. (Above, $ is the shell prompt, and >>> is the Python interpreter’s command prompt, so don’t copy/paste those.)

Since I was doing this in Terminal, I could also type “pdf_filename = ‘” then drag and drop a file from the Finder into Terminal window to insert its path, complete the quoting, and pressed Return. (Saves some time and potential for mistyping.)

You could wrap this sequence into one longish command line and run it from AppleScript with “do shell script.” Or you could save it as a Python script file and again run it with “do shell script.” Or, you could skip AppleScript and just use Python, which I prefer over AppleScript. (Python seemed very natural to me with my minor AppleScript background, and I’m pretty sure I’ve written more of it than AppleScript by this point.)

This is derived from “Example 2: Splitting a PDF File” in the Using Python with Quartz 2D on Mac OS X document at the Apple Developer Connection.

That ADC example also shows how you could specify a PDF file’s path at the command line (with sys.argv), rather than hardcoding it as I did for my example.

There may be a shorter way to do this since I’m no expert on Quartz 2D. (I just appreciate that the bindings are there for a scripting language I happen to like a lot.) I honestly don’t know what’s happening when the provider and pdf objects are being set, but I really don’t need to know for this.

I wanted to find a way to do syntax highlighting of code snippets on my Drupal blog. I came across the GeSHi Filter module, which lets Drupal sites take advantage of the apparently well-regarded GeSHi Generic Syntax Highlighter library that’s meant for just this purpose.

However, I ran into some roadblocks implementing it on my site. Here’s the short story of what I settled on after some trial and error.

My existing code snippets are in <code> blocks, and the initial GeSHi Filter settings applied badly to them. I made the decision to only use GeSHi on <blockcode> blocks, since I wasn’t using that tag yet and it wouldn’t conflict with the snippets already posted.

I most commonly write Bash/Zsh, Python, and AppleScript snippets on my blog. However, the Bash code I was using as part of my trial and error simply wasn’t highlighting; it was coming through as the default (and boring) plain text — but was at least boxed off from the rest of the blog post.

I thought that GeSHi wasn’t correctly discovering that the code was written in UNIX shell syntax. I couldn’t find a way to specify the language for that blockcode tag, until I did some searching on the ’net. To change my blockquotes to choose a certain language — at least for the purposes of this Drupal module, if not for GeSHI in general — I needed to add the “lang=lang” style to the tag. For Bash, I could use “lang=bash,” for Python, “lang=python,” and for AppleScript, “lang=applescript.” That made sense.

However, my code was still not being syntax highlighted. I discovered that the Drupal module came with an initial set of languages enabled. The others were all turned off, but that could be changed in the module settings. Without turning them on, even properly-tagged <blockcode> sections did not get the benefit of syntax highlighting.

I changed the GeSHi Filter options to enable some of the languages that were initially disabled, and then disabled the ones I didn’t anticipate using. This allowed me to add Bash and AppleScript syntax highlighting support, as both had been turned off by default. After that, I saw the results I’d hoped for: a syntax-highlighted code snippet.

It took some work, but now that it’s done, I should be all set.

I am happy about a solution I just came up with to the problem of not being able to define an arbitrary set of dates as the recurrence pattern for an event in Microsoft Entourage 2008.

I wanted to enter an event that was split across two days, and wouldn’t have obviously fit any type of “every Wednesday” or “every second Thursday” pattern. The ideal way to handle this, I think, was available in the Steltor CorporateTime calendar I used to use: create an event and add arbitrary dates to it, so that each recurrence appeared as part of the series. You can’t do that in Entourage — or I’ve never found any trickery to allow it.

Luckily, however, the event’s start time and duration was the same on each of the two days, so I realized I didn’t need to make two different events for it. And, I only had two recurrences to deal with — if there’d been more, it’s unlikely they would have been evenly spaced.

I used my “Compare dates” AppleScript to determine how many days apart the two instances of this particular event were. I came up with 20. I entered that as the number of days between recurrences. I set the recurrence to end on the date after the last event.

The result? I got two events (and two events only), both on the days I intended, and they were linked as part of a recurrence pattern. Sweet. It’s the little victories, you know?

According to the AppleScript Overview which was freshly revised for Leopard, the AppleScript Utility is scriptable and now lets you enable GUI Scripting. I think this means — although I haven’t confirmed it personally yet — that this is the first scriptable way to enable GUI Scripting.

I’ve spent a small amount of time trying to enable it other ways in the past — including the use of the `defaults` tool — and been stymied. I’m not sure when the last time I tried was, or which version of Mac OS X. Nonetheless, a scriptable way to enable GUI Scripting is welcome.

Despite my concerns that GUI Scripting could be a source of security problems — from the perspective of a social engineering attack — there are already many other potential ways to script or automate applications for social engineering mischief. On the plus side, systems administrators and others who need GUI Scripting on or off, even for just a short time, should have an easier time enabling or disabling it on computers thanks to this change.

Hm. They actually tell you what’s new in Leopard — from a Mac OS X developer perspective, anyway — in the release notes section of the ADC Reference Library.

Who would have guessed? I think I missed this for Tiger. And, AFAIK, it wasn’t available at all for any previous version of Mac OS X. ’Twas a shame, quite a shame.

(I’ve always missed John Montbriand’s old overviews of the Mac OS classic releases; they were a treasure trove, relatively speaking, of information. Even for sys admins.)

It struck me today that when running Entourage, I have two script menus. One is specific to Entourage, the other is for the optional — but handy — system-wide Script menu. Yet both have the same icon — the stylized black and white paper-rolled-into-an-S icon — in my menu bar.

The app-specific script menu was probably more common in classic Mac OS days than it is under Mac OS X. (But yet, as I type this, I noticed that MarsEdit has its own script menu, too. I think that just shows how wired into classic’s scripting Brent Simmons was — I mean, he worked on UserLand Frontier, the original scripting environment for the Mac.)

Ah, I just wish the two menus could be one and the same. If Entourage (or any other application) detected that you had the system’s Script menu enabled, it ought to just turn its own off in favor of the system menu. Or maybe the system-wide menu could show the app-specific scripts first, so that they are always in a known location (top of list, right side of menu bar), and take over the function of the application’s scripting menu. Or, they could just have two different icons, or one could be an icon while the other was text, or whatever.

In reviewing Jesper’s list of requirements for The Email Client That Doesn’t Suck, I was somewhat surprised how many of his points are already handled by Microsoft Entourage 2004.

I’d give it 19 out of 26 points. There are some places where I’m being charitable towards Entourage, partly because it can support the requirement with a little work (which does not always mean scripting — and it should be noted that Entourage is very scriptable) or I didn’t understand what Jesper meant by the requirement.

Many Mac users discount Entourage. There are a couple of reasons that may be cited:

• Microsoft bundles it with Office 2004, so you have to buy it along with a lot of other software in order to get it. That costs more than a standalone client, even if you’re eligible for the $149 Student and Teacher Edition (which is often discounted even more).
• It’s not Universal yet, so it works natively only on PowerPC Macs. It requires Rosetta on Intel Macs today. (But Microsoft has announced that the next version of Office will be Universal.)
• It comes from Microsoft, so it must be evil somehow.
• It has a custom monolithic database for its backend. This predates any of Apple’s Core Data-type development. It can be a completely valid issue for some — such as those with network or portable home directories, or those performing regular client backups.
• It doesn’t look like a Mac OS X application. Rather, you might say it looks more like an application from classic Mac OS … and I’d agree, but there are some quick things you can do to spruce things up. (I had some on my old blog, but I still haven’t ported the old content over. Suffice it to say that changing a lot of the font choices to “Lucida Grande” in the preferences makes a big difference.)

That said, there are many valid concerns about Entourage. I voice many through the Microsoft feedback channels available to me.

However, I think there is a huge impediment to creating a new e-mail client today, simply because of how connected this kind of product is to your whole computing experience. Any developer should take that into consideration, and realize that it’s probably an unending effort.

I just upgraded Salling Clicker from version 3 to 3.5, and promptly discovered that it no longer lets me control Keynote 2. Only when I tried to using the Clicker application on my Palm Treo 650 to control Keynote did I get a message that Keynote 3.0.2 or later was required.

Needless to say, I have not yet upgraded to Keynote 3. It has been out more than a year, and the rumors peg an update that was aligned with Leopard. Apple offers no upgrade price break; you’re always buying a full copy. It makes little sense to update to the newer version of it in iWork ‘06 now, unless I really want a universal version or compatibility with this new Clicker.

Compatibility that I had, mind you, yesterday on the old version. Sigh. If they’d just put this in the system requirements on the Clicker Web site, I wouldn’t have upgraded.

Update: Salling swiftly responded to my tech support request and suggested using the script for the older Keynote 2 that is now posted.