Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling Take Control ebooks.

 

 

Pick an apple! 
 
iMovie '09: Speed Clips up to 2,000%

iMovie '09 brings back the capability to speed up or slow down clips, which went missing in iMovie '08. Select a clip and bring up the Clip Inspector by double-clicking the clip, clicking the Inspector button on the toolbar, or pressing the I key. Just as with its last appearance in iMovie HD 6, you can move a slider to make the video play back slower or faster (indicated by a turtle or hare icon).

You can also enter a value into the text field to the right of the slider, and this is where things get interesting. You're not limited to the tick mark values on the slider, so you can set the speed to be 118% of normal if you want. The field below that tells you the clip's changed duration.

But you can also exceed the boundaries of the speed slider. Enter any number between 5% and 2000%, then click Done.

Visit iMovie '09 Visual QuickStart Guide

 

 

Related Articles

 

 

Cause of Font Cache Bug Revealed?

Send Article to a Friend

The other day I was using TextMate to run a simple Ruby script and an odd thing happened: the script suddenly started producing nonsense. There was nothing really wrong with the script itself, but TextMate appeared to have lost its mind; instead of showing me the actual string resulting from the script, like "ogopogo," it was omitting some of the letters, like "gpg." I restarted the computer and everything was fine after that. But I was left wondering what the heck had just happened.

I posted a query to the TextMate users newsgroup, and someone responded: "WebKit is used to render the HTML output window, and it has been known to behave strangely from time to time. Another possibility is that your font caches had become corrupted. Either of these problem could have been corrected by a reboot." Oh, yes, the font cache bug. I'd forgotten all about it, and I certainly had not connected it with TextMate's output. But I did know about the font cache bug. Indeed, I had referred to it implicitly, years before, in my review of Smasher (see "Insider Smashes Suitcases," 2005-09-26).

The Mac OS X font cache bug is an intermittent misbehavior of fonts on Mac OS X, typically affecting any application that displays Web pages with the built-in WebKit engine (Safari, OmniWeb, TextMate, BBEdit, and CSSEdit are examples). The bug can also mar the display of PDFs, I believe. A quick Google search turns up some pages that talk about it, including this one which provides some images of a corrupted Web page display, and a YouTube video showing characters randomly disappearing and reappearing (much like what I was experiencing myself). Rob Griffiths mentions the bug in a recent Macworld article. And, going back further in time, John Gruber had an extensive series of articles about it in 2005.

The occurrence of the font cache corruption bug on my machine has been less frequent in recent years; indeed, I'm not certain I've ever seen it on Leopard (I was using TextMate on Tiger when the bug struck me). Still, the question remains as to what actually triggers the bug.

Now it appears there's an answer. The problem seems to be caused, as one might expect, by a combination of two things: badly behaved fonts, and Apple's font caching mechanism. But in what way are the fonts badly behaved, and what's wrong with the font caching mechanism? The details come from an unexpected quarter of the Mac OS X world: the users of TeX.

TeX (pronounced "tech"), for those who don't know, is a typesetting program by the venerable Donald Knuth. It's often used for the production of scientific and mathematical books and papers. There are various Mac OS X TeX implementations, and it was while I was glancing over some Web pages connected with these, reading about TeXShop and MacTeX, that I noticed a link to a page about the font cache bug. I read the page, and my jaw dropped. Brilliant and determined detective work by some TeX power users has recently laid the blame for font cache corruption at the door of a TeX utility called pdftex, which lies at the heart of TeX implementations because it is used to pipe the TeX output directly to a PDF. If you receive and open a PDF that was created with pdftex, you run the risk of triggering the font cache bug on your machine.

Here's why (and now I am basically just quoting from the explanation by Richard Koch, the creator of TeXShop). A PDF file contains embedded copies of the fonts that it uses. Those copies consist of mathematical instructions for drawing the font's characters (that's what PDF is all about). These mathematical instructions are often expressed, in part, as PostScript subroutines for drawing partial shapes used by multiple characters, like this:

dup 372 {
    11 5 div
    6 38 5 div
    41 5 div
    0 61 5 div
    rrcurveto
    closepath
    endchar
}

Now, you may not be able to read that (how many of us are fluent in PostScript?), but it turns out that there's a bug in that subroutine. After the "endchar" line, the routine is supposed to have a "return" statement, and it doesn't. These subroutines were being incorrectly formed by the then-current version of pdftex.

However, the incorrectly formed subroutines had no obvious manifestation in the resulting PDF file, because pdftex was forming them incorrectly only in the case of characters which, while part of the font, were never used in that particular PDF. For characters that were being used in that PDF, pdftex was forming the subroutines correctly. Thus, the issue could never be directly detected.

But here's the problem: When such a PDF was opened on Mac OS X, Apple's font caching mechanism came along and stored these subroutines anyway - that's why it's called font caching! - so it would know how to draw those characters of that font if it encountered them later. So if it did encounter those characters of that font later, these subroutines would be called, and since the subroutines were corrupt, the font's drawing procedures would be wrong.

So the bug was being triggered by opening a "bad PDF," but it had no effect on the "bad PDF" itself; it was only later, if other characters of the same font happened to be used anywhere in the system where the font caches were called upon (such as through Preview or a WebKit-reliant application), that the corruption would manifest itself. And you know something? Sure enough, when I saw the problem in TextMate, I had been reading a TeX-generated PDF file earlier that same day.

What's the upshot for you, the end user? First, you may acquire, or may already have on your machine, the occasional "bad PDF" file, and if you open it, this might trigger the font cache bug, which will manifest itself as character corruption later on until you restart the computer or otherwise rebuild the font caches. You may be able to identify these by doing a Spotlight contents search for "pdfTeX" (if you sort the results by Kind, remember that a PDF can be listed either as an "Adobe PDF Document" or as "Portable Document Format"). A more specific search, avoiding PDFs that merely mention pdftex, would be "Encoding software contains pdftex." (On accessing the "Encoding software" search criterion through the "Other" pop-up menu item, see my "Spotlight Strikes Back: In Leopard, It Works Great," 2007-11-01.) You can't fix a "bad PDF," but at least you'll have some notion of which PDF files might trigger the bug.

Second, it's perfectly possible that there are other causes of font cache corruption besides PDF files generated with TeX, so let's not heap all the blame on the TeX users - after all, they're the ones who found the source of the problem in pdftex.

Third, newer PDF files generated with TeX are unlikely to cause the problem, because the TeX folks have also fixed the problem in pdftex.

Fourth, Apple changed the font caching mechanism in Leopard, but it looks like the problem can still occur (though it seems to me that it occurs less often). In any case it is ultimately up to Apple to rewrite its routines to deal more robustly with bad fonts; now that the TeX power users have been able to show Apple exactly how the bug is triggered, perhaps Apple will be able to correct it.

 

Make friends and influence people by sponsoring TidBITS!
Put your company and products in front of tens of thousands of
savvy, committed Apple users who actually buy stuff.
More information: <http://tidbits.com/advertising.html>
 

Comments about Cause of Font Cache Bug Revealed?
(Comments are closed.)

www.themacgroove.co.uk  2009-07-27 10:07
Camino is not WebKit, it's Gecko
Adam Engst  An apple icon for a TidBITS Staffer 2009-07-27 10:08
Correct, and I've edited the article to remove Camino from the list. Even if it might rely on WebKit somewhere, there are better examples, which I've added.
Kris Arnold  An apple icon for a TidBITS Supporter 2009-07-27 07:36
Interesting article.
One point - I'm pretty sure Camino uses Gecko, not WebKit, to render HTML.
Matthew Schinckel  2009-07-26 18:31
Yeah, but what about the PDF rendering? That is done by a plugin, which may use WebKit.
Jeff Porten  An apple icon for a Friend of TidBITS 2009-07-27 02:46
Sheer brilliance. I can confirm that I've recently seen a temporarily corrupted PDF in Leopard, and I'm glad to know that a reboot can fix it.

Also, have had unexplained problems with kerning Lucida Grande in Mail.app; possibly unrelated, but it makes sense to me that WebKit could be involved here as well.
Lindsey Thomas Martin  2009-08-03 15:44
I've been noticing the poor kerning of Lucida Grande in Mail.app (3.6; OS 10.5.7) as well; seems to have started in the last month and occur on line after quoted passages.
Michael M.  2009-07-27 05:52
Spotlight searches PDF infos, so you may be able to find PDFs with pdfTeX as the creator. I found a 2003 invoice from my telecom provider which was generated with pdfTeX-0.13d (today they are using another tool)
Adam Engst  An apple icon for a TidBITS Staffer 2009-07-27 10:18
Clever! I've updated the article to note this fact.
Bradley Dichter  2009-07-27 17:20
Use FontNuke to clean the cached fonts.
Matt Neuburg  An apple icon for a TidBITS Staffer 2009-07-27 18:31
Just found a screen shot of the bug in action from Feb 2008, says it's generated with Mac OS 10.5.2, so clearly the bug can still happen in Leopard.
ChristophT  2009-07-28 09:35
I work in Pre-media and we often deal with fonts that are quite legacy and quite crusty. I've noticed that a restart does not always clear the font cache. But there is a command line application in 10.5 that will forcibly remove/reset the font caches. This is an alternative to something like FontNuke. It's rare, but we have found them useful:

For current user (log out or reboot afterwards):
atsutil databases -removeUser

For all users and system font cache (reboot afterwards):
atsutil databases -remove
Adam Engst  An apple icon for a TidBITS Staffer 2009-07-28 15:36
Thanks, Christoph! Comments like yours really add to the utility of our articles, which warms the cockles of my publisher heart.
Steven Fisher  2009-07-28 15:37
Wow! Thanks for finding this explanation. Like all software problems I assumed it was a specific cause, but I had no idea what it was.
Lorenzaccio  2009-07-29 09:55
For me the problem appears only with preview not adobe reader on pdf files. Until 10.5.6 I could heal it with :
atsutil databases -removeUser
atsutil server -shutdown
atsutil server -ping

which avoids to reboot!!! :-)
But, last week I moved to 10.5.7 and it does not work anymore. The pdf file character set becomes totally erratic now. Adobe still works fine!
Matt Neuburg  An apple icon for a TidBITS Staffer 2009-07-30 11:33
Adobe reader works fine because it doesn't use the system font cache. That's why I was careful in the article to refer only to Preview and WebKit PDF viewing being affected...!
FubarGuy  2009-08-03 15:00
I've had a utility call Font Finagler for a few years to cure this exact issue. It's probably similar to FontNuke and the Terminal commands mentioned earlier but it's critical in prepress (pre-media?) work. Great article, hope it shines some light on this miserable problem.