I previously wrote about and praised John Gruber’s Word Count script, which uses Jesper’s ThisService to add a systemwide service to Mac OS X.

I have one minor quibble with it, however. While a word count is invaluable for prose, there times in computer-related writing when you actually might want a character count as well or instead, which the script doesn’t provide. Such was the case when I wrote the UCSD redesign post, where I wanted to character counts of the URLs.

Fortunately, AppleScript is pretty easy to hack, and even though I have no idea how to write AppleScripts, hacking John’s script to include a character count proved painless. The new script is:

on process(_str)
    tell application "System Events"
        set _appname to name of first process whose frontmost is true
    end tell
    tell application _appname
        display alert "Word count: " & (count words of _str) & "
Character count: " & (count characters of _str)
    end tell
end process

Seriously, count characters of _str counts the characters in the string. I have to hand it to AppleScript, that’s cool beans.

Just reload the script into ThisService and you’ll have a slightly better systemwide word count service.

Counting Paragraphs

Coming off of the god-like high of manipulating the code to do my bidding, my mind naturally gravitated towards giving the script even more power. Counting paragraphs seemed like something the script could use, even though, really, I can’t think of a reason why I would want to ever count paragraphs. But, hey, that sort of thinking never stopped Microsoft from dumping features into it’s products, so I added a count paragraphs in _str part to the code and tested it.

Turns out, no, I’m not a god, and apparently AppleScript becomes retarded when you ask it to count paragraphs. It works fine for counting the paragraphs in a single paragraph block, but anything more than that and it overestimates the number. Again, I don’t know AppleScript — or even paragraphs — well enough to troubleshoot this, and I don’t really care enough to try writing a Ruby or Perl script to add a feature I don’t actually want. If, however, you do, knock yourself out.

John Gruber explained how to set this up a year ago:

Back in October my friend Jesper wrote a nifty little utility called ThisService. You give ThisService a script — either AppleScript or any Unix scripting language such as Perl, Python, or Ruby — and it generates a system-wide service based on that script, right there in the Services menu, available in any app. No Xcode or Cocoa required. You just write the script… …This one is about as simple as it gets, but I use it quite often. It takes as input the currently selected text in the frontmost app, and then displays an alert showing the number of words in the selection.

I installed it and it works spectacularly well. This is particularly useful for applications that don’t have their own word counters (Safari), or for ones that have word counters with stupid keyboard shortcuts (TextMate).

Just one thing to note, finding the right keyboard shortcut proved somewhat difficult for me. The one Gruber uses, shift-command-K, will interfere with Safari’s “Block Pop-Up Windows” menu item (which I don’t think needs a friggin’ shortcut to begin with). I opted for shift-command-End, as that isn’t likely to conflict with any app’s built-in shortcuts.

In Mac OS X Tiger:

1. Open a Finder window and navigate to a folder of your choice.
2. Change the view of the folder from Icon to List (assuming default is Icon view).
3. Close the window, open a new Finder window, then navigate to the folder you changed.
4. Notice that the Finder opened in the default Icon view, but the folder you changed is still in List view, as it remembers the change you made.

In Mac OS X Leopard:

1. Open a Finder window and navigate to a folder of your choice.
2. Change the view of the folder from Icon to List (assuming default is Icon view).
3. Close the window, open a new Finder window.
4. Note that the fucking Finder is now been set to List view as default!

This is painfully annoying. In order to set a folder to be in a specific view you have to open up the folder’s view options (View->Show View Options) and check the box at the top that locks the folder in a specific view.

I don’t have an advanced degree in user interface design or nuthin’, but doesn’t the Tiger behavior, you know, make sense? Cause the Leopard way seems totally moronic.

You know who frequently breaks functionality in new OS versions? Microsoft. Apparently superfluous use of transparency in inappropriate places is not the only thing Apple’s ripped-off adopted from Windows Vista.

If you’re viewing this site outside of a feed reader than you’ve undoubtedly noticed that things look a bit different here. That’s because I decided to redo my site design, flipping the contrast from light (text) on dark (background) to dark-on-light. The reason isn’t so much for aesthetics (which I think are served by the switch anyway) but more so due to OS X’s extremely poor handling of light-on-dark text.

A Quick Overview of OS X Text Rendering

The days of blocky, pixelated fonts are generally behind us¹. OS X’s Quartz graphic system improves text display by utilizing subpixel rendering, a technique which uses the natural RGB pattern of an LCD screen to improve the quality of on-screen text. Quartz’s subpixel rendering is interesting in that its results differ significantly from Microsoft’s ClearType system (included in Windows XP and turned on by default in Vista). For an anal-retentive switcher — like me — the difference between text on Windows and OS X is immediately noticeable. With the release of Safari 3 beta on Windows, which mimics OS X’s text rendering instead of the usual ClearType, the general computing community has taken note of this difference as well. Joel Spolsky wrote a good piece comparing the two methods, for those that are interested.

Ultimately, I’m a fan of Apple’s implementation, as it does an exquisite job of replicating on screen what text will look like when printed out. If I had to choose between Windows or OS X to write a book on, for example, I would go with OS X hands down, for that reason alone².

Light vs Dark

One thing Spolsky doesn’t mention is that OS X’s rendering method is optimized for dark-on-light, and reversing that has a very noticeable impact on text quality. Below is an example of OS X rendered text both light-on-dark and dark-on-light (I’ve included a Windows XP CleartType version for comparison):

OS X’s light-on-dark text appears blurrier than the dark-on-light text, whereas there appears no visible difference in quality on Windows XP. This effect on OS X can be seen more clearly by zooming in on the text.

It’s important to note that for any given letter the number of pixels in both lines is exactly the same, but the light-on-dark line shows outer pixels — like the three pixels off the bottom of the letter “o” — much more so than the dark-on-light letters do. The color fringing for OS X’s light-on-dark text is clearly much more severe than it’s dark-on-light.

While the details of the actual algorithm OS X uses are unknown to me (and let’s be honest, I probably wouldn’t be able to understand it even if it was known to me) it does appear that both the text color and the background color play a role in how OS X does its subpixel rendering. The following image shows two lines of text — the top is black and the bottom white — against grayscale backgrounds (given in HTML hex).

The dark-on-light text holds up extremely well regardless of background color. Unfortunately the same cannot be said of the light-on-dark text. The white text gets cleaner (and clearer) as the background gets lighter (until it disappears, that is). This is made even more clear upon zooming into the image (data not shown).

Some Fun with OS X

There is one final thing you can do to fully see the difference at hand, though only Mac users will be able to do this. On OS X you can invert the screen by pressing Cmd-Ctrl-Option-8 ³. Do this and then refer back the first screenshot. Note that the previous light-on-dark OS X text, while now dark-on-light in color, still looks the blurrier of the two. The pixels in the light-on-dark text do not invert the same as the pixels in the dark-on-light text, suggesting quite strongly that the algorithm OS X uses favors dark-on-light text.

So?

The take home message here is that if you’re going to use light-on-dark text that’s to be viewed on OS X you need to be extra careful in choosing your colors. While you can just pick whatever colors you want and run with them on Windows, the color combinations need to be optimized for OS X viewers. For light-on-dark text it appears that lowering the contrast between text and background colors will improve legibility within a certain range.

In my case, I was really happy with the background color I’d chosen, which seems too dark to get a good light colored text against on OS X. Rather than lighten the background to a gray I opted to just switch to black text on a white background. We’ll see how long this lasts.

Of course, none of this is a problem for Windows, as all text basically looks equally sorta-OK regardless of colors. Hurray for Windows, I guess.

1. Well, I agree with John Gruber that sometimes you want a blocky, pixelated font↩
2. I should point out that there are numerous other reasons to choose OS X for writing, to the point that it’s ridiculous to not to choose OS X. I’ll probably go into more detail on that at a later date.↩
3. This effect cannot be captured via OS X’s screencapture utility, otherwise I’d show you myself.↩