Spacebar Magnifies Photos in iPhoto '08
In iPhoto '08, you can choose whether double-clicking on a photo will edit it or magnify it. I prefer my double-clicks to edit photos, but every now and then it's nice to magnify a photo. To do that, even when double-click is set to edit, just select the photo and press the Spacebar.
Written by
Adam C. Engst
Recent TidBITS Talk Discussions
- Alternatives to MobileMe for syncing calendars between iPad/Mac (1 message)
- Free anti-virus for the Mac (20 messages)
- iTunes 10 syncing iPod Touch 4.1 (2 messages)
- Thoughts about Ping (16 messages)
Related Articles
- Mac OS X 10.6.3 Update Delivers Range of Fixes (29 Mar 10)
- Mac OS X 10.6.2 Addresses Myriad Bugs and Security Issues (09 Nov 09)
- Tiny Mac OS X 10.6.1 Update Fixes Some Bugs (10 Sep 09)
Published in TidBITS 994.
Subscribe to our weekly email edition.
- Apple Mail Sending Issues in Snow Leopard
- Amazon Makes Orwell Buyers Right
- Missing Sync Helps Palm Users Connect with Snow Leopard
- Getting 1Password Working in Snow Leopard
- AirPort Menu Improves in Snow Leopard
- Vonage App Coming to iPhone
- eBay Sells Skype to Private Investors
- Phone Amego: the Macintosh/iPhone Mind Meld
- Snow Leopard Snubs Document Creator Codes
- TidBITS Watchlist: Notable Software Updates for 07-Sep-09
- ExtraBITS for 07-Sep-09
- Hot Topics in TidBITS Talk for 07-Sep-09
Two-Line URLs Broken in Snow Leopard's Preview
While going through final testing of the PDF of his "Take Control of Exploring & Customizing Snow Leopard," Matt Neuburg ran across a bug related to clicking long Web URLs. The problem is not related to any particular PDF; it's purely a bug in Preview, and one that could cause fairly significant confusion (and in our case, customer support headaches).
Here's the problem. Let's say you're using Snow Leopard and thus Preview 5.0 (501), and you open one of our Take Control ebooks - the 2.1 version of "Take Control of Mac OS X Backups" is a good example. At some point while reading, you'll run across a URL to a Web page that is too long to fit on a single line (search for "http" to find one quickly).
Now, click the bottom line of the URL, and your Web browser will load the proper destination page - whatever the full URL is. But click the top line of the URL, and Preview instead sends you to whatever visually appears on that top line, not the full URL.
We put some effort into making our split URLs look decent, so most of the time that top line will go somewhere (if an error page at the appropriate site), but if it were just "http://www.", Preview would happily send that fragment to your Web browser.
Again, there is nothing wrong with the PDF. Both lines of the URL contain PDF link boxes with the full URL in them. Clicking either line in Adobe Reader works fine. And of course, the versions of Preview in Leopard and other versions of Mac OS X work as expected.
We assume that the problem is that Preview is attempting to treat text that looks like a URL as a link, but it is unfortunately doing so in such a way that it ignores the actual PDF link box that sits on top of the text.
This is a new feature in Preview - the Leopard version sees all URLs as just text - and is actually one that has existed for some time in Adobe Acrobat Pro and Adobe Reader. The difference is that Adobe's programs honor the PDF link box in favor of the automatic URL recognition; they too can see only one line of a URL when faced with a split URL that lacks a true PDF link box.
The only workaround for users is to be sure to click the bottom line instead of the top one, or to use Adobe Reader (which has its own pluses and minuses). On our end, we could start using a URL shortening service, and we have in fact done that on a couple of particularly awkward URLs in recently released ebooks to avoid customer support questions, but we can't change all the ebooks we've already published. In general, though, we prefer to use actual URLs since they often convey useful information.
Although I don't have a large collection of PDFs from other publishers and other sources, it's entirely likely that there are other sources of PDFs that will run afoul of this bug too, so consider yourself forewarned.
I've reported this bug to Apple, so we can hope it will be fixed in a new version of Preview in Mac OS X 10.6.1. Historically, it's taken only about two weeks for Apple to release the first update to a major version of Mac OS X, so it's likely that we'll see 10.6.1 in the very near future.
![](/file/11593/db.tidbits.com.tar/db.tidbits.com/images/badges/SmileLogo2010-50x50.gif)
editing PDFs; TextExpander for saving time and keystrokes while you
type; DiscLabel for designing CD/DVD labels and inserts. Free demos,
fast and friendly customer support. <http://www.smilesoftware.com/>
Clicking the first line sends just that line to the browser. Clicking the second line sends the first and second lines (fortunately, a working URL in this instance, although one must then navigate to the desired page).
And the third line is not clickable.
It will be nice to get this fixed--I really don't want to suffer through Reader again.
--John
I'm wondering if a full-on electronic publisher such as TidBITS should be relying on someone else's URL-shortening service. It strikes me that, unlike a public service, a private service (a subdomain hosted on your own server) used just for ventures such as "Take Control" would have a limited universe of URL listings, short equivalents, and redirection.
The bonus would be that you could assign alias URLs that convey the useful information you see in the original without the alphanumeric soup found in the originals.
The Preview bug has exposed once again the problems inherent in publishing URLs in other media, but TidBITS could easily take control of those URLs in its own publishing process.
But, it would be nice to have short URLs in some situations, and particularly short URLs to which we could assign some useful alias information. Plus, when they broke (because they always do eventually), our server could provide some useful information about what was there at some previous point in time (a cached version of the page when the URL was created, for instance).
Of course, another downside is that it adds more work to making links.
I'll add this to our list of possible projects, but it's far below some other things we really want to get done in the near term.