Update: At some point, probably with iTunes 8 though I didn’t notice at the time, iTunes added support for batch changing video format, making the script featured in this post obsolete… as it should be.

Original post follows.

We usually keep our home movies in iPhoto, but recently I’ve started moving some select clips into iTunes. Unfortunately, the list of Movies quickly becomes unmanageable. These kinds of videos are much easier to work with when grouped as TV shows, but unfortunately iTunes won’t batch convert Video Kind.

So I wrote a script. In addition to defining selected movies as a show, it also tags their season with the current year and sets the Show Title. Here’s the script: (Open in Script Editor)

set showTitle to display dialog “Enter TV Show Title” default answer “Family Videos” buttons {“Cancel”, “Ok”} default button 2

set theYear to year of (current date) as integer

tell application “iTunes”

copy selection to tracklist

repeat with theTrack in tracklist

set show of theTrack to text returned of showTitle

set season number of theTrack to theYear

set video kind of theTrack to TV show

end repeat

end tell

To use that, just select some movies in iTunes and run the script. Whatever’s selected will be tagged and grouped under the title you entered.

Now our home movies are all grouped together and easily synced to iPhones or other iTunes fed products like iPods and Apple TVs. To view videos on any of those devices, the movies will need to be converted to iPod compatible format. QuickTime can do it, but iSquint/VisualHub can do it much faster.

This could have been done with AtomicParsley, but AppleScript is easier and pre-installed on every Mac.

What would be really great is if iTunes and iPhoto could talk to one another and pull video content out. iPhoto has supported movies for years now, why can’t they talk to each other? (because neither was designed for handling video formats?)

There’s plenty of room to improve this, if you do please post a link in the comments.

I recently came across an absolute disaster of a Palm Desktop data file while helping someone setup a new iPhone. It had 13,572 contacts, mostly duplicates. Judging from the number of obvious duplicate entries, my guess is the actual number will be somewhere around 2500 (it was).

Here is the process I used to automatically remove a lot of those duplicates and import the remainder into the Mac’s Address Book.

The first step is to get out of Palm Desktop as soon as possible. Select all contacts and export to a group VCard. This one was 3.4 MB.

Most of this will happen in Terminal, but a quick stop in BBEdit or TextWrangler will save a few steps later on. (TextMate tends to choke on big, non-UTF files.) The Palm export file is encoded in MacRoman. It’s 2008, pretty much any text that isn’t Unicode should be. I used TextWrangler to convert the encoding to UTF-8 no BOM (byte order marker).

VCards require Windows style CRLF line endings. While we could deal with those in Sed, we might as well just switch the file to Unix style LF endings in TextWrangler too. The TextWrangler bottom bar should switch from this:

To this:

Now comes the magic.

While this could be done as an impossible-to-read one-line sed command, it’s easier to digest and debug as separate command files.

Here are the steps:

1. Use Sed to join each individual VCard into a single line using a token to replace line feeds, output to intermediate file
2. Sort and Uniq the result to remove obvious duplicates.
3. Replace the tokens with line feeds

Below are the two sed command files I used. I ran these individually but they could easily be piped together into a one-line command.

vcard_oneline.sed:

# define the range we'll be working with
/BEGIN:VCARD/,/END:VCARD/ {

# define the loopback
:loop

# add the next line to the pattern buffer
N

# if pattern is not found, loopback and add more lines
/\nEND:VCARD$/! b loop

# replace newlines in multi-line pattern
s/\n/   %%%     /g
}

Run that like this:

sed -f vcard_oneline.sed palm_dump.vcf > vcards_oneline.txt

Then run that file through sort and uniq:

sort vcards_oneline.txt | uniq > vcards_clean.txt 

vcard_restore.sed:

# replace tokens with DOS style CRLF line endings
s/      %%%     /^M\
/g

# add the <CR> before the LF at the end of the line
s/$/^M/

Run that with something like this:

sed -f vcard_restore.sed vcards_clean.txt > vcards_clean.vcf

After that last step, you should be able to drag the vcards_clean.vcf file into Address Book to import your vcards.

Suggestions for improvement are always welcomed.

Notes:

In VIM, type the tab character as control-v-i (hold control while pressing v then i), type the line break by typing control-v-enter.

iconv could be used to convert from MacRoman to UTF-8. TextWrangler just seemed easier at the time.

Palm Desktop appears to dump group VCards in input order, so duplicate entries were not grouped together. Running the output through sort visually reveals a ton of duplicates and makes it possible to use uniq to remove consecutive duplicates.

I had to quit and re-open Address Book once or twice before it would import the files.

John Gruber of Daring Fireball (thanks for the link!) knows a lot about font-rendering, however in a recent post discussing screen-rotation and sub-pixel text rendering he let this slip:

“I tested it on my Cinema Display with the screen rotated 90°, and, to my eyes, sub-pixel anti-aliasing still looked good.”

That is just preposterous. Aside from his observation being completely wrong, he also revealed a bug in OS X: The current system doesn’t recognize rotated pixel orientations, sub-pixel rendering on rotated screens should probably be disabled automatically. (rdar://problem/5627732)

Here are two screenshots of my browser’s address bar as displayed on my Cinema Display, which clearly shows the difference. The top image is Leopard’s default sub-pixel rendering. The second image is the same bar photographed with my display rotated 90°, the photo was then rotated back in Photoshop for better comparison.

The text was apparently calculated against the presumed horizontal LCD primary orientation. But because the pixels were rotated, several of the letterform stems (verticals) are drawing as full-pixel-width colored lines. The first “h” is especially glaring, its stem and stroke are drawn as a pair of dark red and light blue lines.

Sub-pixel rendering takes advantage of a known horizontal alignment of the three color primaries that make up each physical pixel. The algorithm seems to render text at 3x the horizontal resolution, ignoring the color information and treating each third-pixel as a valid light source to use for drawing letterforms. That 3x width is then striped with red, green and blue to match screen’s component primary ordering. (That was an educated guess)

As Steve Weller stated in the post John linked, the human eye has “pathetic color-resolution”. This fact is exploited all over the place in video, with many formats sampling color only once for every four luminance pixels.

Several things are at play here:

1. Human vision is the bifocal product of horizontally arranged eyes.
2. Most written human language uses letterforms which are vertically oriented and horizontally distinguished. Especially Latin-derived languages.
3. Most human languages read horizontally.
4. Human vision tends to be less color sensitive for motion, or when scanning information (like reading)

It all just kind of worked out perfectly. Digital color reproduction combined our horizontal predisposition with our soft and slow perception of color, and then arranged color primaries horizontally. Text also reads horizontally, and since the viewer is rapidly moving their eyes, we perceive shape and contrast before color. Additionally, Latinate languages evolved letterforms which utilize horizontal variations against a largely regular vertical syncopation. Presto: sub-pixel rendering just seems fantastically obvious.

Regarding John’s closing supposition,

“I’m not sure the iPhones rotating display is reason enough to rule out sub-pixel rendering.”

Based on everything leading up to sub-pixel rendering in the first place, most of the benefits would be lost if the underlying pixel grid was vertically oriented. The sensitivity of computer text falls across the horizontal axis. Adding resolution to the vertical axis isn’t worth the effort.

Sub-pixel rendering is ultimately a transitional technology anyway, a half-step that improves the now while waiting for a better and inevitable future to arrive. Once we start seeing iPhone level pixel-densities all over the place, sub-pixel rendering will began its transition to technology footnote.

Digital displays will someday reach a point where every physical pixel is capable of producing every color of visible light. (And someone will doubtlessly push into near infrared and ultra-violet, claiming increased realism and fidelity). Future displays will also be operating at a density where anti-aliasing may not be necessary at all.

I still think Apple’s decision to use standard anti-aliasing for the Leopard menu bar was a mistake. Unless they’ve got some spiffy high-pixel-density cinema displays ready for MacWorld and enable system-wide resolution independence in 10.5.x, switching to standard anti-aliased text rendering in the menu bar was a change that should have been postponed. The necessary hardware pool just isn’t here yet and the result is an interface that looks markedly worse than it did under previous releases.

Amazing how times change:

Originals found here, via Shawn King on Twitter

I’ve been seeing an issue with Apple Mail affecting several iPhone users on a several different of hosts:

• With a POP account, Apple’s Mail.app will ask for the password repeatedly, refuse the correct password and fail to collect any mail.
• With IMAP, the account seems to stall and does not necessarily update state or download new messages. Desktop IMAP behavior is particularly erratic.

In both cases, the iPhone continues to work just fine. The problems mostly affects users who’ve set their iPhone to Auto-Check for mail to something other than Manual. The following lines appear in the Desktop’s console.log almost immediately after setting the iPhone to auto-check for mail:

2007-07-05 15:33:17.190 Mail[21242] Unhandled response to command SELECT: * NO  Trying to get mailbox lock from process 28292
2007-07-05 15:34:24.098 Mail[21242] Unhandled response to command SELECT: * NO  Trying to get mailbox lock from process 29790
2007-07-05 15:36:14.917 Mail[21242] Unhandled response to command SELECT: * NO  Trying to get mailbox lock from process 31080

Those entries seem to indicate that the IMAP server is sending a response that Apple Mail doesn’t know what to do with.

A thread on the MacRumors forums claimed this was a multiple connections issue with the mail server, but I think I’ve conclusively debunked that, at least for IMAP.

To test the multiple connection theory, I set up Thunderbird on two other physical machines, one Mac and a Dell running Ubuntu, then set up my account using the default IMAP settings. I also opened my account in Horde webmail and hit reload a lot. Despite those simultaneous connections, Apple Mail seemed to be fine and messages were getting delivered. The little progress indicator was, however, still sitting there next to the account name, not spinning.

So now I can break Apple Mail just by turning on Auto-Check in iPhone’s Settings->Mail. Manual checking from the iPhone doesn’t cause any problems. So far I’m only seeing this on shared hosts running the Courier mail server.

IMAP is inconsistent about when it breaks, maybe relating related to server load issue. POP will break every time: If I check my email on a POP account with the iPhone, Apple Mail will immediately ask for and then refuse the password for that account.

An IMAP workaround

Installing IMAP-IDLE, pretty much fixes the problems with IMAP. I’ve had this running for several hours and the iPhone checking every 15 minutes, and things seem to be working smoothly. IMAP errors still appear in console.log but mail is getting through. I’m going to install this on a few other machines tomorrow and see what happens.

Not sure what to do about POP, but then we’re migrating everyone over to IMAP anyway.

Setting up icon placement and window sizes on a disk image isn’t as easy as it should be. Here’s part of my solution for automating a designed disk image with AppleScript.

Fixing Window Size

According to this thread on Apple’s Installer-dev list, window size isn’t written until there is some user interaction, specifically clicking either the green zoom button or the little resizing thingie in the lower right corner. I was unable to get UI Scripting to dependably click the resizing corner, but I did notice that two clicks on the zoom button, after setting a window’s size, toggles between the set size and the zoomed size. So I specified my desired window size, then had System Events click the zoom button (button 2) twice:

set bounds of window 1 to {50, 75, 580, 680}
tell application "System Events" to tell process "Finder" to click button 2 of window 1
tell application "System Events" to tell process "Finder" to click button 2 of window 1

Forcing .DS_STORE to Record Icon Positions

The Finder’s .DS_STORE files are a bit of a mystery. The binary format is closed and there is no programatic way of forcing these files to update. Some smart people have suggested some harebrained workarounds for dealing with this problem, but I wanted something cleaner and more flexible.

My solution was to start fresh by obliterating any .DS_STORE files that might be on the disk image; this appears in the window-layout script before doing anything else:

do shell script "rm " & quoted form of POSIX path of dmgPath & ".DS_STORE"

Next the window is sized, icons are positioned and background image is assigned. Then the script waits to eject the disk* until the .DS_STORE file has been created (open in Script Editor):

set waitTime to 0
set ejectMe to false
repeat while ejectMe is false
    delay 1
    set waitTime to waitTime + 1
    if (do shell script "[ -f " & quoted form of POSIX path of dmgPath & ".DS_STORE ]; echo $?") = "0" then set ejectMe to true
end repeat
log "waited " & waitTime & " seconds for .DS_STORE to be created."
eject dmgPath

On my MacBook Pro, it usually takes 4 seconds for the file to appear. First deleting the file makes sure that the resulting file contains all the new placement information.

Next the disk image gets run through DropDMG and is ready for uploading. I’m ejecting the disk image before converting because I’m getting filesystem errors when I try converting while the source DMG is still mounted. I don’t remember that happening in the past, but it’s probably a good idea to eject first anyway.

Or, How I reclaimed 1.25 gigabytes of my hard drive.

When 10.4 imported mail from the old 10.3 mbox files, it broke each message into an individual file so Spotlight could index them. The old mbox files, rightly, were left on the drive. For most people this wouldn’t take up a noticeable amount of space, however those of us with a ton of mail saw a significant hit to our disk space.

The following commands will remove the unused mbox files from the drive, recovering a potentially large amount of disk space:

    cd ~/Library/Mail
    find . -name "mbox" -ls

Make sure the only thing listed are mbox files in your mail directory (they should be). To delete all those files, change the last “-ls” of the above command to “-delete“. (I didn’t include the full command on purpose since it deletes files and I wanted to strongly encourage everyone doing this to check the file list before deleting.) Just to be doubly safe, backup before doing this.

Total size of my mail folder went from 3.07 GB (3,206,511,328 bytes) to 1.84 GB (1,884,864,581). A savings of almost 1.25 GB. At $229.00 for a 93.2 GB formatted notebook drive, that’s an actual cost savings of $3.02.

Note there was/is a bug with Mail importing under 10.4 where very large mbox files don’t read correctly. Make sure all your messages really did import correctly before deleting your mbox files.