Exploration

Archive: 'Mac' Category

One of the things you discover as a speaker and, especially, a conference organizer is this: Keynote generates really frickin’ enormous PDFs. Seriously. Much like Miles O’Keefe, they’re huge. We had one speaker last year whose lovingly crafted and beautifully designed 151-slide deck resulted in a 175MB PDF.

Now, hard drives and bandwidth may be cheap, but when you have four hundred plus attendees all trying to download the same 175MB PDF at the same time, the venue’s conference manager will drop by to find out what the bleeding eyestalks your attendees are doing and why it’s taking down the entire outbound pipe. Not to mention the network will grind to a nearly complete halt. Whatever you personally may think of net access at conferences, at this point, not providing net access is roughly akin to not providing functioning bathrooms.

So what’s the answer? ShrinkIt is fine if the slides use lots of vectors and you’re running Snow Leopard. If the slides use lots of bitmapped images, or you’re not on Snow Leopard, ShrinkIt can’t help you.

If the slides are image-heavy, then you can always load the PDF into Preview and then do a “Save As…” where you select the “Reduce File Size” Quartz filter. That will indeed drastically shrink the file size—that 175MB PDF goes down to 13MB—but it can also make the slides look thoroughly awful. That’s because the filter achieves its file size reduction by scaling all the images down by at least 50% and to no more than 512 pixels on a side, plus it uses aggressive JPEG compression. So not only are the images infested with compression artifacts, they also tend to get that lovely up-scaling blur. Bleah.

I Googled around a bit and found “Quality reduced file size in Mac OS X Preview” from early 2006. There I discovered that anyone can create their own Quartz filters, which was the key I needed. Thus armed with knowledge, I set about creating a filter that struck, in my estimation, a reasonable balance between image quality and file size reduction. And I think I’ve found it. That 175MB PDF gets taken down to 34MB with what I created.

If you’d like to experience this size reduction for yourself (and how’s that for an inversion of common spam tropes?) it’s pretty simple:

Download and unzip Reduce File Size (75%). Note that the “75%” relates to settings in the filter, not the amount of reduction you’ll get by using it.

Drop the unzipped .qfilter file into ~/Library/Filters in Leopard/Snow Leopard or /Library/PDF Services in Lion. (Apparently no ~ in Lion.)

Done. The next time you need to reduce the size of a PDF, load it up in Preview, choose “Save As…”, and save it using the Quartz filter you just installed.

If you’re the hands-on type who’d rather set things up yourself, or you’re a paranoid type who doesn’t trust downloading zipped files from sites you don’t control (and I actually don’t blame you if you are), then you can manually create your own filter like so:

Go to /Applications/Utilities and launch ColorSync Utility.

Select the “Filters” icon in the application’s toolbar.

Find the “Reduce File Size” filter and click on the little downward-arrow-in-gray-circle icon to the right.

Choose “Duplicate Filter” in the menu.

Use the twisty arrow to open the duplicated filter, then open each of “Image Sampling” and “Image Compression”.

Under “Image Sampling”, set “Scale” to 75% and “Max” to 1280.

Under “Image Compression”, move the arrow so it’s halfway between the rightmost marks. You’ll have to eyeball it (unless you bust out xScope or a similar tool) but you should be able to get it fairly close to the halfway point.

Rename the filter to whatever will help you remember its purpose.

As you can see from the values, the “75%” part of the filter’s name comes from the fact that two of the filter’s values are 75%. In the original Reduce File Size filter, both are at 50%. The maximum size of images in my version is also quite a bit bigger than the original’s—1280 versus 512—which means that the file size reductions won’t be the same as the original.

Of course, you now have the knowledge needed to fiddle with the filter to create your own optimal balance of quality and compression, whether you downloaded and installed the zip or set it up manually—either way, ColorSync Utility has what you need. If anyone comes up with an even better combination of values, I’d love to hear about it in the comments. In the meantime, share and enjoy!

One of the things that I’ve found mind-bendingly annoying about Leopard (besides its complete refusal to allow classic window management) is the “this file was downloaded from the internet, are you sure you want to open it?” dialog box. Yes, damn it: I just downloaded the file with the express intent of opening it. Stop bothering me. Keep it up and I might mistake you for PC.

What’s even worse is that the dialog requires mouse input to get past. It would be just within the limits of acceptability if the dialog buttons responded to keyboard input; if I could hit command-O or something to invoke “Open”, then I’d probably keep the safeguard in place, because I could just charge past it with a quick twitch of the fingers. Since I can’t, I want it gone. And of course there’s no “don’t ask me again” checkbox to tick.

After a plea on Twitter, I got pointers to a couple of ways to disable this annoyance (as well as a ton of “oh God, I hate that too; let me know if you find an answer!” replies). The first way is done as a Folder Action. For a variety of reasons, I’m not that thrilled by folder actions, so I gave it a pass. The other approach is to write your own preference file. Ah, much better! (Why is this better? I don’t know. It just intuitively feel like the better approach to me.)

Now, one way is to just disable the warning for all public.item files—which is to say, every type of file. I was tempted, but it turns out there’s a finer grain that can be applied: listing specific file types to be ignored. Better still! That way I can switch this off for the file types that I download all the time, like HTML files, and keep the safeguard in place for file types I almost never download, like executable scripts.

Doing this means you need a list of OS X’s Uniform Type Identifiers, so I dug around to find that listing, which appears to have moved in the not-too-distant past. Here’s the preference file I’ve put together with that listing as a guide. This file lists all of the file types I don’t want to be nagged about.

I led with public.text because it encompasses not just regular text files, but HTML files as well; public.xml appears to cover XHTML, though I’m not 100% sure where those files fall. public.audiovisual-content covers all audio and video files, as you might guess. There are probably a few other types I’ll add over time, as I encounter enough resistance on certain types of files that I don’t need to be safeguarded. I’ll probably never add public.script or public.executable to the list; personally, I prefer to be warned about that sort of stuff.

To make the magic happen, save the above file (or your own variation) as ~/Library/Preferences/com.apple.DownloadAssessment.plist. Then log out of and back into your account. Finito.

So if you’d like to get your Mac to be less of a nag about opening downloaded files, there’s how. As the links above show, I’m standing on the shoulders of giants here, so my thanks to those who paved the way. I hope that you will be able to benefit from both their work and my small additions thereto.

Update [13 Mar 09]: Potentially very bad news, folks. I just tried this on my 10.5.6 machine and it failed utterly. As did the Folder Action approach. Older versions of Leopard apparently didn’t have this problem. Anyone else seeing the same kind of thing on their machines? If either way is still working for you under 10.5.6, can you tell us which one it is in the comments? Thanks.

Update [18 Mar 09]: Great news, folks. Ben Millett kindly sent me a copy of his working-under-10.5.6 file and I tried it out, and it worked! The difference seems to be that the version I was using was encoded as “Unicode™ (UTF-8, no BOM)” whereas the encoding of the file Ben sent me is “Western (Mac OS Roman)” (both according to BBEdit). So if your copy doesn’t work, check the file encoding. Next I’m going to experiment with adding file extensions, and will report back if I meet with success.

So I’ve been putting off upgrading from Panther to Tiger for quite some time now. My base reason is that I’ve been really, really busy, but the other reason is that I kept hearing that it wasn’t worth it. Now, I’m used to the 10.x.0 version of any major OS X release being unstable and the source of many complaints, but it’s up to 10.4.4 now. That seems like enough time to work out the kinks.

Plus, I have to use Tiger if I want to play with the Mac version of Google Earth. So there’s that.

Admittedly, I do have Tiger installed on a partition of an external drive, and I’ve played around with it a little bit. Still, that’s a very far cry from upgrading my laptop’s hard drive from Panther to Tiger. I know that any major OS upgrade will mean time and energy spent on managing the transition, including re-installing or upgrading some third-party software. That’s where the “I’ve been busy” thing comes back into play. It’s a lot easier to take the lazy route: the system I have now works, so why mess with it? Then again, that same attitude would have kept me in the Classic OS if I’d let it. At some point, you have to upgrade.

I recently wrote that the font Freight Micro had broken Unicode references. It turns out that I was basing my comments on a beta version of the font without realizing it. The designer of the Freight family was good enough to provide me with a copy of the final version of the font, which I tested, and I’m delighted to report that it does not suffer from the same problem.

So my deepest apologies for any misinformation I may have spread. If you see anyone referencing my previous post on this topic, please point them to this one. Thank you.

A followup to my previous post: thanks to the nearly impossible to find Character Palette (and thanks to Todd Dominey for instructions on how to enable and use it), I was able to determine the problem and restore my editing pencils. It turns out that a beta copy of the font “Freight” was what caused the problem. This beta copy of Freight was for some reason convinced that Unicode 9999 is the reference to a Z-caron instead of a pencil symbol. It didn’t do this for 9998 or 10000. Just 9999.

So I removed “beta Freight”, and the pencils returned. Thanks to everyone who helped me out!

Update:there’s more to the story, namely that the copy of Freight in question was a beta, and not the final release, and the final release doesn’t have the problem that bit me. I’ve edited this post to reflect that fact.

Pretty much nobody but me ever sees this, but when I’m logged into meyerweb’s copy of WordPress (basically, all the time) I see a little pencil icon next to entries and comments. It’s the “click here to edit this” link, and I generate it using the following markup:

<a href="[...]">&#9999;</a>

Ah, Unicode.

The problem is that at some point in the recent past, my OS X 10.3.9 laptop started rendering that character as a Z with a set of rabbit ears on top, whereas my OS X 10.3.9 desktop machine still shows the pencil. I can only assume this is due to a recent software installation on the laptop, possibly one that stuck in a badly structured font or something. Or else an update messed up the Unicode pointers.

Whatever the cause might be, does anyone out there know if there’s a way for me to figure out what font is being used to generate the funky Z, or how I might otherwise be able to track down and destroy it and get the pencils back? Because it’s driving me frickin’ crazy.

After a lovely Sunday morning breakfast at the Farmers Market in Los Angeles, Kat, Carolyn, and I strolled through The Grove to check the sights and pick up a gift card for some friends. As we neared the center of the main drag, Carolyn suddenly pointed and shrieked delightedly, “Daddy!”

She was pointing directly at the large white logo in the middle of the silver façade of the Apple Store.

I’m thinking that maybe I need to spend a little less time on my PowerBook.

John Gruber just posted a great article on how to take the Weather Dashboard widget in Tiger and hack it to add a “last updated” time. It’s not only useful, but it’s also a wonderful introduction to the simplicity of widgets. If you can hack on XHTML, CSS, and JavaScript—as I expect most visitors to this site can—then you can alter or create a Dashboard widget.

However, there was one thing I didn’t like about John’s hack: he converted the 24-hour time already stored by the widget into 12-hour AM/PM time. I prefer 24-hour time, as do most people outside the United States (which I am not, but never mind that now), and sticking to 24-hour time makes the script addition even simpler. So here’s my quick modification of John’s JavaScript to result in a time like “1450” instead of “2:50 pm” or “0307” instead of “3:07 am”.