Using Photos to Enhance Video

This is awesome technology:

Font Smoothing in Firefox 3 on XP


I have noticed an issue with font smoothing on Firefox 3 ever since I upgraded my home WinXP machine last week. Namely, my fonts seem to be "ghosted" by red borders. My guess is that this is some kind of sub-pixel smoothing gone awry. As a matter of comparison, I am showing Habari's admin menu in Firefox 3 and Safari 3.1.1 (I am comparing with Safari because I no longer have Firefox 2 on my machine). In most circumstances, I would say that Safari goes overboard with the anti-aliasing/sub-pixel smoothing, at least with small fonts. However, in this case it clearly looks better. In fact, it looks very much like the menu used to look on Firefox 2.

Is anyone else seeing this? I am curious if this is a Cairo graphics problem (newly integrated in Firefox 3) or a WinXP problem.

Debugging PHP on Windows with XDebug and VIM

Habari is a sufficiently complex PHP application that sometimes the only way to figure out what is going on is to fire up a debugger. Following a suggestion on #habari and some google searching, I found an article on the blog on using XDebug with vim. The instructions were for a linux box, and I initially struggled to get things working on Windows (XAMPP). But, I finally got it through digging through the comments on the article and Vim documentation. I thought it would be useful to gather the required steps in one place, so here are my instructions:

  • Read the article.
  • Download XDebug and put it in xampplite\php\ext
  • Edit xampplite\apache\bin\php.ini. Add these lines:
    xdebug.remote_enable = 1
    xdebug.remote_port = 9000
    xdebug.remote_host = localhost
  • Restart Apache. Check that xdebug appears on your phpinfo() page.
  • Download the xdebug plugin for Vim and put it in: C:\Program Files\Vim\vim71\plugin
  • Download and install Python 2.4 (not 2.5). You can see which version of Python your copy of gVim is looking for by looking for the 'python' string in the gVim binary (dirty, but it works!)
  • Now you need to modify to work with windows paths, so open in gVim
    • Change the session file to something reasonable. XAMPP has a directory that already serves this purpose, so you might change self.sessfile to
      self.sessfile = "C:\\xampplite\\tmp\\debugger_vim_saved_session." + str(os.getpid())
    • Now change every occurance of getAttribute['filename'][7:] to getAttribute['filename'][8:]. Do the same with getAttribute['fileuri'][7:]
  • Open up a browser and append ?XDEBUG_SESSION_START=1 to the end of an address on your local webserver.
  • Open gVim. Hit F5, then refresh your browser page. You should now be debugging!

Fixing CRLF issues when applying patches in a multi-platform environment

In my role as a Habari developer, I have been increasing butting heads with the same issue. I do some development on my windows machine at home, create a patch file with TortoiseSVN and upload it to trac. Then, I arrive at my iBook at work and download my patch. When I go to apply it though, I get messages such as this:

physics-2004-19:~/Sites/habari bjohnson$ patch -p0 --dry-run < timelineSearch.patch (Stripping trailing CRs from patch.) patching file system/admin/comments.php (Stripping trailing CRs from patch.) patching file system/admin/entries.php (Stripping trailing CRs from patch.) patching file system/admin/js/admin.js Hunk #1 FAILED at 190. Hunk #2 FAILED at 230. Hunk #3 FAILED at 277. Hunk #4 FAILED at 385. 4 out of 4 hunks FAILED -- saving rejects to file system/admin/js/admin.js.rej

Patch is failing because it is not appropriately dealing with the way that Windows machines and Unix-based machines (including OS X) signify an end of line. On Windows, a newline is specified by a carriage return (CR) followed by a line feed (LF). On Unix, however, a newline is just a LF. The 'patch' command is somewhat intelligent in dealing with patch files created on a Windows machine, in that it converts all CRLFs in the diff file to LFs before applying the patch. The problem, however, is that the target file might also have CRLFs in it. This is frequently the case when working in a multi-platform development environment like so many open source projects. The fix: remove all CRLFs from the target files before applying the patch. An easy way to do so is with the 'tr' command. For example:

tr -d '\r' < admin.js > temp; rm admin.js; mv temp admin.js

Now apply your patch. Problem solved!

Upgraded to Wordpress 2.5

I upgraded to Wordpress 2.5 this evening. I am not really sure why I went to the trouble of doing this, since I am now a contributor to the Habari project, and would like to get my blog on that new platform soon. However, I wanted to see what all the fuss was with the new admin interface for Wordpress. I guess I am not as offended by the blue tones of the admin as other designers seem to be. In fact, I find it quite soothing. Still, I don't like that category selection is now "below the fold". And the tagging interface seems to be begging for tag clutter, since it doesn't list any previously used tags.

The reason I did not immediately jump to Habari is that I am still rather fond of K2's advanced search and navigation features, and these have not made their way to Habari yet. Ironically, these features now seem to be broken after upgrading to WP 2.5. This may mean that I am going to change over to Habari sooner rather than later.

UPDATE: I got the search and nav features to work again by following the suggestion in this thread.

 1 2 3  10 Next →