While publishing my book Get Your Head Around Aperture 1.5 I figured out how to create high-quality page thumbnails like the one above. It is almost possible to read the body text, and the small blue title is certainly readable: Importing Images From A Single Folder, even though the characters are tiny. The word Images is only 5 by 19 pixels.

I first tried taking screen shots and reducing the images in Photoshop, but that resulted in a horrible loss of detail and a very fuzzy look. The page size reduction was being carried out as though it were a photograph, not a page of text. I needed a way of maintaining the character information through the size reduction.

To create the high quality page thumbnails I printed the pages I needed to a PDF file:

Then viewing the generated page in Preview, reduced the page size until it was what I needed:

Since the PDF was being rendered at the reduced size, the detail was still present. Last, I took a screenshot with SnapzPro2 and added a thin border and drop shadow with the media inspector in RapidWeaver:

This also gives me an image with the drop shadow rendered in: I just click and drag the image from the published web page to my desktop.

Tags: Thumbnails, PDF, Get Your Head Around Aperture, Books, Documentation, RapidWeaver, Screen Shots, Photoshop

Clamshell Bucket: 1/800s f/4.0 ISO100 170mm -0.3ev, Canon 30D, Canon EF 70-200 f/2.7L IS, adjusted

RapidWeaver, the application I use to create this site, now has the option to generate the sidebar using PHP. I plan on taking advantage of this feature so that sidebar modifications (which includes adding new pages) don't affect all the HTML on the site and require a complete upload, 1000+ files in my case.

But switching to PHP creates a problem. Although the links I publish, such as http://www.bagelturf.com, don't specify the file extension and so will be automatically redirected to the appropriate index file, there are many links out there on the web that specify .html and those files will no longer exist. An example is: http://www.bagelturf.com/aparticles/index.html. When I replace this file with http://www.bagelturf.com/aparticles/index.php, all the links to the index.html file will be broken.

The fix to this is to use the mod_rewrite facilities of Apache. mod_rewrite allows rules to be set up that can generate new URLs from those that match patterns. The goal here is to convert all requests for .html into requests to .php. I found a couple of good sites to help me with this, here and here.

I want to experiment with PHP and mod_rewrite on my computer before making any changes on my hosting service. As it ships, Tiger has PHP disabled. I'm still running Tiger, note. The changes are slightly different for Leopard. To turn on PHP, I fired up TextWrangler and selected File > Open File By Name... This lets me type in the Apache configuration file name I need to change: /etc/httpd/httpd.conf. This file needs root access to edit, so as soon as I start to edit it, TextWrangler asks me if I really mean to do this. When I save the file it requests my password. I prefer using TextWrangler since I don't need to mess with the terminal or sudo.

To enable PHP I remove the # from the following two lines in httpd.conf:

# LoadModule php4_module libexec/httpd/libphp4.so
# AddModule mod_php4.c

Then I start Apache. This is done from the Sharing preference pane by turning on Personal Web Sharing:

If I already had Apache running, then I would have had to stop it and restart it by unchecking and then checking the checkbox.

I can check that PHP is active this by creating a simple PHP file and accessing it in my Sites folder in my home folder. The file is called index.php and looks like this:

To access it I load the URL http://127.0.0.1/~steve/index.php in a browser and expect to see a page with Hello World appear. It does, so now PHP is working.

To use mod-rewrite I create rules and put them into a .htaccess file in my Sites folder. To create the file, I again use TextWrangler and type in the following:

Options +FollowSymlinks is needed or else the rule does not work. The RewriteBase line tells Apache that my web pages live in my home folder. Without this line the access will go to the default web page for the system, which is not what I want. The RewriteRule line matches all URLs that end with .html and replaces the extension with .php. The Item as the end of the line tells Apache to give a response code of 301 (Moved Permanently) and to reload the page. This reload replaces the URL in the browser with the actual one I am using, the one ending with .php. This will tell search engines where my .html pages have gone.

There is one more step to getting this work. As set up so far, Apache will not parse .htaccess files in my Sites folder because that feature is turned off. As well as processing the global httpd.conf file when started up, Apache also parses a file users/steve.conf and by default that is set to deny access to .htaccess files.

To fix this I use TextWrangler to edit the file /etc/httpd/users/steve.conf so that it looks like this:

The edit needed is to change AllowOverride from None to All. This file applies specifically to my Sites folder and to everything in subfolders below that.

I'm done. Now I can experiment with my site by enabling PHP sidebar generation and viewing the pages locally. That's turned on in the Page Inspector:

Tags: PHP, Apache, Leopard, RapidWeaver

Roadster: 1/25s f/6.3 ISO400 55mm, Canon 30D, EF-S 17-55mm f/2.8

It's been a week since I went to the Los Gatos Apple store and picked up my copy of Leopard. But I'm not running it yet. I'm waiting for three things: an update to SuperDuper, some fixes for RapidWeaver, and an update to Aperture. All have some issues, or at least the potential of issues, when running under Leopard and since these are critical applications for me, I have to wait until they are ready.

The Apple discussions have reports of some odd problems with Aperture running on Leopard. Some people cannot launch the application beyond the splash screen. Others get crashes at the same point. Some can see their images, but get a crash as soon as they try to do anything with them. I've seen some problems fixed by turning off Time Machine, but others not. It's hard to distinguish one cause from another because the hardware configurations are so different. My suspicion is that graphics drivers are at least partly involved, but people have been able to fix some problems by ignoring ownership on firewire volumes. Suggestions are that Prokit and corrupted images are to blame as well.

The menu bar can vanish too. Some people have found that font duplicates were the cause. Others find that Leopard is thinking their video card is unsupported and once they get past that the menus come back. Spaces causes some odd interactions with Full screen in Aperture, but this is not specifically an Aperture issue. It interacts strangely with a number of applications. One person had problems with a color picker preventing Aperture preferences appearing. There are clearly many ways that all manner of easily forgotten additions cause problems under Leopard.

Meanwhile I've been booting into a copy of Leopard installed on another partition and playing with it there. I've already made a snapshot of my Tiger drive that I will keep for at least six months: that's my insurance in case of corruption or my own stupidity. When I do move over, I'll do all the requisite back ups and checks, clean out my fonts, remove all the non-standard preference panes and start-up items, unplug all the peripherals, etc. and then do an update install. The next step will be to test everything that's critical to make sure I don't need to revert and go forward with my fingers crossed.

Tags: Leopard, Early Adopters, Aperture, SuperDuper, Time Machine, RapidWeaver

RapidWeaver 3.6.2 released today includes support for Aperture. RapidWeaver's iMedia browser can access previews created in Aperture just like Apple's iLife applications are able to. An additional great feature is the ability to generate the sidebar with PHP: this makes for much short upload times on large sites like mine because fewer pages are affected by sidebar changes (in my case almost 900!).

Tags: Aperture, RapidWeaver, Blogging

Once I added tags to my articles following the release of RapidWeaver 3.6.1, I found that I had so many that I could not fit them into the sidebar in any sensible way. Another big problem was that any new article uploaded 780 pages because all the sidebars on all the pages and sub-pages changed. So I created a separate page for them that I update manually once in a while. It's a good place to scan for topics and find some of the more obscure items on the site.

Tags: Tags, RapidWeaver

Screencasts Online have a nice overview of the new features available in RapidWeaver 3.6.

Tags: Video, RapidWeaver, Blogging

Realmac Software released RapidWeaver 3.6.0 today. RapidWeaver is just as it sounds: a quick way to make great web sites. I've been beta testing it for a while, and publishing this site with it for as long as it has been stable.

For a quick look at what it does and how it does it, see the intro video and quick-start guide on the tour page. The quick-start shows how to create a blog in five minutes. It really is that quick. Customization is possible both through the RapidWeaver interface and by adding and editing HTML, PHP, and CSS. But there is no need to get embroiled in the details if you don't want to. There are plenty of low-cost themes and plug-ins available.

Tags: RapidWeaver, Blogging, Web Tools, Software, Interesting Stuff

Since you are reading this, you have made it to the new site: http://www.bagelturf.com. All new content will be posted here, so please update your links, feeds, and bookmarks.

At the old http://homepage.mac.com/bagelturf/ site all the existing material is still available, but nothing will be updated.

The layout and content links are all exactly the same, so if you want to globally update your links, just replace "homepage.mac.com/bagelturf" with "www.bagelturf.com" and you should be good to go.

One difference between the sites is that I am now publishing with a beta copy of RapidWeaver 3.6. This results in the permalinks being the title of the post, not listed separately. You will also find that the archive and category links have meaningful names now.

Tags: Hosting, Migration, RapidWeaver

The application that I use to create and publish this site is called RapidWeaver, currently at 3.5.1; but there is a new version on the way. I have been testing a beta of RapidWeaver 3.6 and it is looking pretty good. It's stable enough that I use it to publish now. My site is large, and I am running into problems with the current version because of its wasteful use of memory during export. 3.6 fixes that, so my workflow is to create in 3.5.1, save, and then publish using the 3.6 beta.

I use RapidWeaver because it is just so darn easy to use. I only have to touch HTML and CSS if I want to. Site templates are plentiful and low cost and available from a number of third parties. And there is a developer SDK that lets third parties write plug-ins. The only problems I have are self-imposed: my site has 130 pages or so -- and those are actual pages, not the automatically-generated ones line the permalinks. My home page has more than 450 articles. There are at least 500 images in the Aperture section alone, so probably close to 1000 in total now.

But RapidWeaver is keeping up. Not bad for a piece of software that costs $40 and has had free updates for at least a year and a half. I'm eagerly awaiting the release of 3.6. I know what is in it, but you'll have to wait to find out.

[Update: The Realmac Software blog page is now (2007-05-02) starting to reveal some of the new features]

Tags: RapidWeaver, Blogging, Web Tools, Interesting Stuff

While making this blog using RapidWeaver 3.2.1, I have found that the site document gets large very quickly as I add images. This is because RapidWeaver stores all the text and all the images in one large site document rather than externally in pieces in a file structure.

So if I drag in a 3MB TIFF image and scale it in RapidWeaver to 30% of its size, the site document stores the whole 3MB, while creating a much smaller JPEG to upload. To reduce storage requirement this without any extra tools I have found that I can use RapidWeaver itself to do the image conversion. It works like this:

1. Create a blog entry and drag in images

2. Use the image inspector to scale each of them

3. Preview the blog entry and tweak until it is OK

4. For each image, drag it out of the blog Preview and onto the desk top

5. Delete each image in the blog, replacing it with the desktop version by dragging

6. Delete the desktop images

So now the blog has just the JPGs. They are just the right size, and take up minimum space.

RapidWeaver should have a right-click menu that gives the option of doing all of this in one.

Tags: RapidWeaver, Performance, Interesting Stuff