Mac Musings

Miscellaneous Updates

Daniel Knight - 2012.03.27 -

Sometime's there's just not enough to say about a topic to justify a full-fledged article. Below are some recent discoveries that deserve to be shared with Low End Mac's readers, yet none would really justify their own article.

Troubleshooting: Check Your Hard Drive First

I've been dealing with some stability problems on both of my production Mirrored Drive Door Power Macs (a dual 1.0 GHz model and a dual 1.25 GHz) over the past few days. As is so often the case, this was due to hard drive problems. In my many years using Macs, I have to say that more often than not, startup problems and lockup problems are due to hard drive corruption or a failing hard drive.

This is causing me to rethink my strategy of putting 2-3 hard drives in each of my Power Macs on the theory that backing up is faster over the internal drive bus than over FireWire, making me more likely to run SuperDuper!, and that it's also faster and more convenient to boot from an internal backup drive. However, if any internal drive is having problems, it can cause startup and stability problems.

I've also made it a habit to use an 80 GB hard drive as my main startup drive because my "backup" Power Macs are older models that don't support drives over 120 GB (see How Big a Hard Drive Can I Put in My iMac, eMac, Power Mac, PowerBook, or iBook?), so if I have to switch to one of them, the boot drive will be plug-and-play ready. (BTW, you can use higher capacity drives in Macs that don't support capacities over 128 GB, you just can't access more than 128 GB without special software or a third-party drive controller.)

In the end, Disk Utility was able to fix my hard drives, and then I used DiskWarrior to clean up their directories, which fixed some other issues.

Memory Surprise!

I picked up a second MDD Power Mac G4 from Advanced Technology Recycling few months back, a dual 1.25 GHz machine to replace the 1.0 GHz one I use to run OS X 10.4 Tiger and Classic Mode. It shipped with 2 GB of memory, but in a configuration I'd never seen before. It had two 1 GB modules instead of the more traditional four 512 MB sticks. Rather than deal with that, I just swapped the four 512 MB modules from my old MDD to the newly acquired one, setting the 1.0 GHz model aside as a backup.

When I started having problems with my Digital Audio Power Mac G4, a dual 1.6 GHz upgraded machine running OS X 10.5 Leopard, I swapped its drive to the 1.0 GHz MDD, booted, and discovered that it recognized that it had 2 GB of memory installed. Until then, I believed that it didn't support modules over 512 MB. Now I want to do some testing to see if I can go beyond 2 GB by adding a pair of 512 MB modules.

I began having problems with this machine, pulled the high capacity modules, and went back to using just a pair of 512 MB sticks for 1 GB total. In retrospect, it was the hard drive that was giving me problems (as it had in the Digital Audio Power Mac), not the memory.

Live and learn.

Claris Home Page and PNGs

Although it hasn't been updated since 1997, I continue to use Claris Home Page (CHP) in Classic Mode, the primary reason a Mac with OS X 10.4 remains in my production suite. I have found a program that can almost replace Home Page, which is a good thing, because CHP doesn't support HTML 4, Cascading Style Sheets, or even produce clean HTML 3.2 code. Still, it is a great writing and editing environment because it's fast - definitely more responsive than anything else I've tried.

I recently solved one problem with Claris Home Page: It doesn't work with PNG images. It's old software, and it works just fine with GIF and JPEG images, as well as HTML and TXT files, but it just won't work with PNG. That's a shame, because 8-bit PNG files can be quite a bit smaller than 8-bit GIF images.

I've tried to use PNGs with KompoZer and BlueGriffon, both of which support PNG. But when I use Home Page to upload site changes, the PNGs are not displayed. Last week I decided to try something different - after CHP updated the site on our server, I manually copied the PNGs to the server using Cyberduck to replace the ones CHP had uploaded.

Violá, the images were now displayed!

My best guess is that Home Page somehow corrupts those files when it uploads them.

The advantage: Smaller, faster loading images. For instance, the LEM logo at the top of the page is a 7,467 byte GIF. As a PNG, it drops to 6,359 bytes, a 15% reduction. Serve that image 10 million times, and you save 1.1 GB of bandwidth. But mostly you get a slightly faster loading page.

Replacing Home Page

Change can be difficult, especially when you have an old, comfortable, familiar, efficient way of doing things. Switching from the Classic Mac OS to OS X was a challenge made easier by Classic Mode, which has never been supported by Intel Macs and was dropped from PowerPC Macs with OS X 10.5 Leopard. I really want to find a replacement for Claris Home Page, but nothing I've found really replaces it. Many WYSIWYG HTML editors want to convert all my thousands of files, perhaps breaking HTML that has worked for years. Some insist on using a template. Some want to store everything in a database. And the ones that come closest to replacing CHP are expensive commercial solutions.

The closest I ever came on my PowerPC Macs was KompoZer (I prefer version 0.71 to 0.8), which I still use to apply Cascading Style Sheets (CSS) to articles written and edited with Home Page. I've found an even better solution on my Intel Mac mini - BlueGriffon takes KompoZer to the next level, and it's also freeware. It works differently from KompoZer and Home Page, but I'm learning its ins and outs.

For instance, Home Page lets me manually resize an image, while KompoZer will scale the image proportionally, so I don't have to specify both height and width. Both make it easy to apply a border to an image. BlueGriffon has a different way of resizing images - you click on the image, grab one of the control points, and adjust away. This is great for resizing an image to fit, but it's terrible if you want to do something specific like use a double-resolution image (see below). And there doesn't seem to be any way to apply a border short of switching to source code.

KompoZer makes it easy to use spans - simply highlight a block of text, apply a style sheet, and you're done. With BlueGriffon, you select a block of text, select Span from the Format menu, and then you can apply your style sheet. It's not nearly as elegant as KompoZer, and I may end up keeping KompoZer around for things like putting borders around images.

Curiously, BlueGriffon seems to lack a mechanism for uploading new files and changes to your server, so I still use Home Page for that, which works fine except for PNG images (see above).

Accomodating Retina Displays

Screen capture of reduced image.

Reduced and sharpened in Photoshop.

Double resolution image.

The new iPad and the iPhone 4S have Retina displays with double the resolution of their predecessors. If you've compared them with older models, you know how gorgeous text is. Problem is, images not optimized for the higher resolution aren't going to be as crisp as they could be.

Another consideration is that modern browsers support zooming in and out, which makes text and images larger or smaller. With a standard resolution image, things get fuzzier as you zoom in. With a higher resolution image, they don't get nearly as fuzzy. In recent weeks I've been using some double resolution GIFs in our news roundups.

On the right are three example images. The first is from a screen capture of the double resolution 468 x 354 pixel image using Safari 4.1.3 with OS X 10.4 Tiger. The second is the same image reduced to 234 x 177 in Photoshop with a bit of sharpening, the way I have traditionally done things. The third is the double resolution image, which should look remarkably crisp with a Retina display.

GIF image sizes are 12,701 bytes for the screen shot, 11,298 bytes for the sharpened image, and 16,896 bytes for the double resolution, 10,475 bytes, 8,004 bytes, and 11,904 bytes respectively for PNGs. The file size for the double resolution PNG is just the least bit larger (about 5%) than the sharpened GIF.

Granted, at standard resolution on a non-Retina display, it's not the sharpest of the three images, but as soon as you zoom your browser window, you'll see how much better it holds up as you enlarge things.

I haven't yet experimented with JPEG images, but I suspect that a medium sharpness JPEG double-resolution image would look better than a high sharpness standard resolution image without the quadrupling in file size you'd get from using the same level of sharpness.

Maximum Image Sizes for WebKit

Because of the immense resolution of the new iPad's Retina display - 2048 x 1536 pixels - some web designers have discovered limitations in the WebKit rendering engine that powers Safari and several other browsers. While the iPad has a 3 megapixel (MP) screen, WebKit has problems displaying JPEG images over 2 MP in size, so websites that need to display higher resolution images than that need to look at GIF and PNG images. Problem is, 24-bit PNG images are huge compared with 24-bit JPEG images, because PNG-24 doesn't use image compression.

This isn't an issue for Low End Mac, but if you're trying to display hugh JPEGs in a browser, it's something you should be aware of. (BTW, WebKit has a 3 MP limit on GIF and PNG images.)

ramBunctous Broken in OX 10.4 and Later

Here's a real blast from the past. Two weeks ago we linked to an article on Hardmac explaining that with system memory as cheap as it is today, RAM disks (virtual drives stored in system memory) are making a comeback. That got me thinking of ramBunctious, the best RAM disk program I've ever used - starting back in my Classic Mac OS days.

ramBunctious has a wonderful feature: It creates a disk image of your RAM disk on your hard drive, and every change you make to the RAM disk is automatically mirrored to the disk image. Brilliant, and in the early days of Low End Mac, this made it easy to copy the RAM disk file to a 100 MB Zip disk so I could transport it between home and work.

That version of ramBunctious doesn't work with Mac OS X, and in 2002 I published Why OS X Doesn't Need a RAM Disk, which explained that because OS X can use any free memory as a disk cache, the need for a hyperfast RAM disk was virtually eliminated - at least for most users. Still, a RAM disk is wicked fast, and ramBunctious 2 was eventually released, followed by version 2.0.1, which added support for OS X 10.3.x "and above".

Reading that, I contacted the developer of ramBunctious, obtained a registration code, and proceeded to test it on Mac OS X 10.4, 10.5, and 10.6. I had high hopes when the program launched, let me choose a RAM disk size, created a 40 MB image file, and gave me a 40 MB RAM disk. I copied a boatload of files to each RAM disk, used TextWrangler 2.3 to do a global search-and-replace on those files, and was stunned at the speed. On the dual 1.0 GHz Power Mac G4 running Leopard, it took about 30 seconds (vs. several minutes from the hard drive). On the dual 1.25 GHz machine, about 24-25 seconds. And on the 2.0 GHz Core 2 Duo 2007 Mac mini, somewhere around 7-8 seconds!

I verified that the time stamps on the files had been updated. Then I ejected the RAM disk and double-clicked the disk image. ramBunctious mounted a completely blank RAM disk. Nothing had been written to the disk image. Something about OS X 10.4 and later broke the most valuable feature in ramBunctious, which I reported to its developer.

I don't expect we'll ever see ramBunctious another version of ramBunctious, which is a shame. It's actually faster to create a RAM disk, copy files to it, make a bunch of global changes, and then sync things back to your hard drive than it is to do the same work from your hard drive. The problem is that you need some sort of smart sync system to only copy back the files that changed.

Playing with ramBunctious brought back good memories, and it would be wonderful to see someone develop a similar program for newer versions of Mac OS X.

Join us on Facebook, follow us on Twitter or Google+, or subscribe to our RSS news feed

Dan Knight has been using Macs since 1986, sold Macs for several years, supported them for many more years, and has been publishing Low End Mac since April 1997. If you find Dan's articles helpful, please consider making a donation to his tip jar.

Links for the Day

Recent Content