OS X Printer driver problems with 10.5 (Leopard) - the HP 1012

I'm having just so much fun upgrading my mother's vanilla Mac Mini to 10.5. First it was the buggy Mail.app update, now I find her Apple's 10.5.7 (Leopard) HP 1012 printer driver doesn't work. The printer worked perfectly with 10.4 (Tiger) - of course.

Print jobs pause for a time, then there's a printer response, then they hang, then they just ... stop.

Of course I have lots of company:

• Apple - Support - Discussions - HP 1012 printer & Leopard ...
• Can't print to HP 1012 with Leopard

I've tried a few fixes, such as resetting the print system (right click on printer in print and fax preference display, choose reset). I also found that the printer was shared by default but that there was a "Printer Sharing is turned off" message; I turned off sharing.

I seem to have fixed the problem for the Administrator account, but not for a regular user account. I may try promoting the user to Administrator, seeing if I can fix it, then trying them again as a regular user.

Power cycling the printer, or clicking on hold/resume a few times, will restart printing. Neither is a good option for my mother of course.

This 10.5 update has helped me think differently about 10.6. I'll take a look at that one in 2011. Of course that means I'll need to buy my new machine while they're still shipping with 10.5 ...

I'll update this post if I'm able to fix the problem ...

Update 5/29/09: At the moment things are working. It is a weird situation, however.

To recap, I was able to print successfully from my admin account using the installed printer drivers, perhaps because (from my Software Update Preference Pane Installed Update history) Apple released an HP Printer driver update in September 2008. I couldn't, however, print from my primary non-admin account.

Here's where it gets tricky. In order to print from my admin account I'd had to reset the printing system.

Even after I did that though, I couldn't print from my mother's non-admin account on the same machine. My hunch is that with the 1.1.1 update if I'd also reset the printing system from my mother's account it might have worked.

Yes, reset from the separate accounts.

Why do I think that might have worked?

Because, instead of doing that I installed the Gutenprint drivers (per Apple). Hint: Don't waste time trying to figure out the install directions, reading the manual, etc. The current version has an installer that does all the work for you, and, for you Gimp veterans, there's no longer any need for Ghostscript, web configuration, etc. All the directions and tips you need are in the installer documentation folder (DO read the readme file).

After installing the Admin account worked fine -- but the user account still didn't. I reset the admin account (again), but still only the Admin account worked.

That's when I did a reset from the user account as well as the admin account. Then I could print from the user account and the admin account. (Interestingly other accounts I created on the machine were also able to print, without a reset).

I'll update this post again after I've had some more experience -- and to see if it still works post reboot.

To recap -- before you try the Gutenprint be sure you have the September 2008 Apple update and try resetting the printer on EVERY account that has trouble -- which means adding back the printer definitions multiple times.

If you still can't get the Gutenprint drivers to work, this post may help though it didn't apply to me.

My hunch is gunk in the queue -- like maybe permissions gunk.

PS. Early in this process I even "repaired permissions". As usual it did nothing but suck time. I think the OS X "repair permissions" utility is some sort of sick Apple joke.

Update 5/30/09: It's not really fixed, after a day or so I got only the infamous "PCL: Unsupported Personality" atop all printed pages. This time adding and removing printer while using Gutenprint had no effect. So I tried it with the Sept 2008 Apple HP drivers and they worked. I also turned on printer sharing, just for kicks.

Clearly we need a new printer. This won't work for long.

I'll probably buy the Brother HL 2140 for my mother. Neither Canon nor HP can produce OS X device drivers to save their shriveled little souls.

Update 9/3/09: Unsurprisingly, it stopped printing a week or so after I left my mothers. I replaced it with the Brother. Weirdly, this printer is showing as supported in 10.6 (CUPS)! I don't believe it, but if you have 10.6 and test it out please let me know in comments. I ended up buying the Brother HL-2170W for my mother -- the 2140 Amazon comments weren't that encouraging.

A well done tutorial on swapping out a Mac Mini drive

There are a lot of these, but this one is particularly nice: DIY: Replace your intel mac mini's hard disk drive.

Is being unserviceable a part of Apple's design rules for some machines?

Unable to delete messages - a Mail.app 3.0 bug

There's a bug (surprise!) that hits a few Mail.app users when they upgrade from OS X 10.4 to 10.5.

I just ran into it upgrading my mother's ultra-plain Mac Mini from 10.4.11 to 10.5.2 and then directly to 10.5.7.

I did an update in place, not an archive and install. I didn't run Mail until the machine was at 10.5.7 and had gone through a post-update "safe boot" cycle to clean out old caches and debris. So I was surprised to find a very significant bug!

When I tried to delete an email from Mail.app 3.0 I got this error message:

The destination mailbox “Deleted Messages ... " does not allow messages to be moved to it.

I found several posts on this topic, but they were all IMAP configurations. The associated fixes in those posts didn't work.

My mother's mail uses POP against her Gmail account, this 2008 post by "Davl" had the fix:

In finder I opened the folder containing the mailbox folders of my POP account. It was located at:

My User Home Folder --> Library --> Mail --> POP/account name --> additional POP folder

In this folder were the mailboxes folders with .mbox extensions.

• Deleted Messages --> empty
• Drafts.mbox --> Messages
• INBOX.mbox --> Messages
• Sent Messages.mbox --> Messages

Note my Deleted Messages doesn't have a .mbox extension like the others do...

This is what I found  in icon view. Clearly there's something wrong with Deleted Message!

Yech.

This is what I did after confirming my Gmail POP settings were correct.

• In Mail.app I saw some "child" trash items. I deleted those and emptied the Trash.
• I quite Mail.app and moved the "Deleted Messages" folder to the desktop
• I restarted Mail. app and then deleted a message. The Deleted Messages folder was recreated

This bug goes back over a year, so it's disappointing that even in 10.5.7 Apple hasn't fixed it.

OS X internet bridging is WEP only

My parents don't have a wireless LAN at the moment, so I turned on Mac OS X 10.5 Internet connection sharing on my mother's Mac Mini. This is a bridging connection; it links my wireless clients with the household wired cable modem connection.

It works pretty well in their house -- I can work with my laptop and iPhone as needed. If you want to do mail, etc though you either have to turn off the firewall on the Mini or mess with ports.

There's one oddity -- unchanged from 10.4. When you set up "connection sharing" (bridging) the only available encryption is WEP (!). This is slightly better than nothing, but not much better; it's now trivial to hack WEP encryption. WEP also a pain to configure on a PC.

So why just WEP? Seems out of place, esp in 10.5.

Update 5/29/09: It's not only old-fashioned, it's also flaky -- like a LOT of things in 10.5. I find I have to periodically toggle it off and on again on the Mac Mini to get it working.

OS X 10.5.7 has a wireless problem?

We're on the latest round of OS X (10.5.7) and Airport Extreme (old, flying saucer model) fixes and something's gone downhill

No real mention on Google, so it's probably something with our older setup (Airport Extreme saucer station, Airport Express WiFi extender, 802.11g/b).

What we see is my MacBook on awake from sleep takes a while to get a connection, then it loses it, then it gets a lower power connection (maybe one of the stations) then it gets a full power connection.

Not lethal, but very annoying.

Update 6/7/09: I think I've found the problem.

Blank an iMac display - instantly (Leopard only?)

For years I've wanted to be able to turn my iMac display off on demand. There's no on/off switch of course, that would hurt the vibe.

It's a common desire. I need my iMac running at night so it gets backed up, but I don't want the photo show ("screensaver") running all night. On the other hand, I do like to have it run when I'm around. Problem is, nobody knew how to do this two years ago.

The best solution I found then was one of the elegant "dockables", which have been recently revived and updated (get the whole set!). The screen off dockable was quite good, but it had a few drawbacks. It couldn't be activated when the screen was locked, but when activated it left the screen unlocked. That's a problem with my kids.

Tonight, on a whim, I looked for current solution, and found How to turn off the iMac display | eHow.com.

Control-Shift-Eject. Presto, the screen is dark. It even works on a locked screen running my slideshow. (Control-Eject brings up the shutdown menu.)

WTF?! Why couldn't I turn this up two years ago? It's trivial to discover today. Was it some secret addition to an OS release? Was it always there, but only discovered a year or two ago?

The answer appears to be Yes and No. It's new to 10.5 (Leopard) and it's never been officially documented by Apple.

It doesn't appear in this 2006 article on similar shortcuts and it doesn't work on my old 10.3.9 iBook. It really only gets mentioned after Leopard is out.

Sigh.

On the one hand, a great feature. On the other hand, would it kill Apple to document it? It doesn't appear on Apple's recently updated screen shortcut kb article.

For me it justifies almost 10% of Leopard's purchase price. Hell of a way to run a company!

Following the trail leads to some other obscure Mac tips:

• Ctrl-K and Ctrl-Y will cut and copy text -- independently of Cmd-X and Cmd-Y. A separate clipboard.
• Option - Command - Eject: sleep computer (I knew that one)
• Many obscure Leopard tips

See also: Command-Option-Control-8 for reading in a dark room.

Why are all my Windows 2003 server folders read-only with a gray checkbox?

In the midst of a Kafkaesque episode of IT torture, I realized that all of my Windows 2003 server folders on every drive had a grayed-out (greyed-out) checkbox in the read-only attribute. The value of the checkbox could not be changed. (That is, it appears that it can be cleared, but on review it's set again. This is true even if one requests that changes propagate down the tree.)

In theory this means that somewhere in the tree of child folders there exists a read-only folder.

Was this related to the mind-crumbling miseries of my past week of IT hell?

Probably not, but the truth is dark enough. Microsoft has a kb article on this. I've cleaned it up, the original is poorly written. Emphases mine ...

You cannot view or change the Read-only or the System attributes of folders in Windows Server 2003, in Windows XP, or in Windows Vista

... Unlike the Read-only attribute for a file, the Read-only attribute for a folder is typically ignored by Windows ... you can delete, rename, and change a folder with the Read-only attribute by using Windows Explorer.

The Read-only and System attributes are only used by Windows Explorer to determine whether the folder is a special folder, such as a system folder that has its view customized by Windows (for example, My Documents, Favorites, Fonts, Downloaded Program Files), or a folder that you customized by using the Customize tab of the folder's Properties dialog box.

As a result, Windows Explorer does not allow you to view or change the Read-only or System attributes of folders.

When a folder has the Read-Only attribute set it causes Explorer to request the Desktop.ini of that folder to see if any special folder settings need to be set.

... if a network share that has a large amount of folders set to Read-only, it can cause Explorer to take longer than expected to render the contents of that share while it waits on the retrieval of the Desktop.ini files. The slower the network connectivity to the share the longer this process can take to the point where Explorer may timeout waiting for the data and render nothing or appear to hang.

Let's walk backwards to appreciate the horror of what Microsoft did here.

Suppose you want to display NTFS metadata like a file's name or comments in an Explorer view. This is a handy way to do what, millennia ago, we did using things like PC Magazine's dirnotes.com utility. Well, it's easy to enter that data, but how does Windows know to display it.

Ahh, here's where the horror of the hack sets in.

The metadata directions are stored in Desktop.ini files for each folder. It would be slow, however, for Windows to check that file every time an Explorer view is to be shown. So Windows 2003 needs to know when to check.

Cue dramatic music.

Some poor benighted soul realized that Windows (95? 98? NT? 2000?) doesn't use the read-only attribute for much. So he (must have been) had a brilliant idea. He'd hijack that attribute, and use it as a way to tell Windows that it needed to check the Desktop.ini file.

We know how the play unfolds now. Once this data value had been used this way the meaning changed. The text says "read-only" but the meaning is "look at the desktop.ini file".

We call that semantic drift.

Of course there's no reason for an attribute that really means "look at desktop.ini" to change the UI for a parent folder attribute of the same name, but that was inherited from the original use of the folder "read-only" attribute. It's a hack side-effect.

Finally, since "read-only" now meant "look at desktop.ini" it had to be reserved for system use, so Windows Explorer can no longer change that attribute. Of course attrib. exe can still change it, but probably you don't want to -- you're really telling Windows then to "ignore desktop.ini".

The Horror, The Horror.