OS X WYSIWYG HTML Editor: RapidWeaver

Realmac Software - Reviews

This gets quite good reviews, but despite my intereste in the domain this is the first I've heard of it. Odd.

Gordon's Tech: OS X 10.4.2 and iPhoto 5.0.3 together fix some of Tiger's problems with Color profiles (ColorSync)

Whew. This is complex. I've made enought updates to a prior blog posting that I think it's worth drawing attention to: Gordon's Tech: OS X 10.4.2 does not fix Tiger's problems with Color profiles (ColorSync).

The bug may be interesting from a design perspective -- Apple might have been trying to improve color management for non-experts, but they ended up messing up their solution. The bug fix requires patches to both 10.4 and iPhoto together.

The power of open source: G5 build for Firefox

Only open source can handle this. A single contributor distributes builds of Firefox optimized for the G5 CPU: BeatnikPad Journal: G5-optimized Firefox 1.0.5 released

iSync: really not ready

Mac OS X 10.4, .Mac: Put URLs in the Notes field for Address Book syncing

Any information in an Address Book contact's URL field will not be synced between Address Book and .Mac, but data in the Notes field will be.

This is really embarassing - for Apple. Sync is hard (indeed, sync between data models may be impossible), but it seems like iSync development has been rather underfunded.

OS X 10.4 hotfile clustering bug lockup - using hfsdebug

Macintouch - Mac OS X 10.4.2 (Part 26)

I've a hunch this bug may be fixed in drives formatted with 10.4.2, but I wonder if there's any other real fix.

Increasing Free Disk Space Improves Performance

Robert Mohns

Jason Mark writes: "Crashes appeared to happen at random [...] One clue I did find was within minutes of restarting a process called "update" would take up to 97% of my processor, and the hard drive would spin like crazy. [...] I did some housecleaning, and now have 11gigs of free drive space, and Tiger is just humming along. Crashes went away. Speed is great. I've been up for 6 days now (for a while my record was 3 hours)."

I strongly suspect that free disk space is a red herring. What Mr. Mark is seeing appears to be the same issue I and others have experienced, in which the update daemon fails to relocate a small file as part of hotfile clustering, retries intensively, spiking both itself and syslog, causing disk IO to peak and the system to eventually reach an unresponsive state. The only way out is to reboot by key sequence or reset button. For more, see my notes in the May 16th MacInTouch Tiger Report:

Low disk space may exacerbate this issue, but It is wildly unlikely that it is the cause. Something is causing update to fail -- perhaps bad sectors on the disk? -- and it handles that failure badly, eventually taking down the system. You can use the (non-Apple) hfsdebug utility and your system log to find the offending file, then delete it manually. I have found that the same file will cause this time and time again; removing the offending file puts the problem at bay ... for a while. The problem goes away ... until some other file causes update to lose its mind. The only solution that really works may be to erase the drive and reinstall...

In "housecleaning" his drive, Mr. Mark may have accidentally deleted the offending file, or he may have cleared space needed for hotfile clustering .... or something else entirely, since so far, nobody really knows what's going on. Apple may, but they aren't talking. He may not encounter the problem again ... or, like me, he may have a month or so of grace, then start experiencing the same old problems.

Unfortunately, this does not appear to be a simple file system damage problem; DiskWarrior and Apple's own Disk Repair don't seem to have any effect on it. I haven't yet experienced it under the just- released 10.4.2; when I do, I intend to fsck -y in single user mode to see if it makes a difference. I expect to run into it eventually, as I've left intact update's current "problem child" file for this reason.

OS X 10.4.2 does not fix Tiger's problems with Color profiles (ColorSync)

Update: The fix has probably been released. Looks like the fix had to be made both to the OS and separately to iPhoto. Below are two interesting commentaries.

iPhoto Color Shift Bug, identified?

This is the best summary of the problem I've seen, and the first to suggest installing QT 7 could produce the problem on 10.3.x.

At this point I’m comfortable pointing to the underlying ColorSync foundations updated in 10.4 as the culprit. (These are used by SIPS and presumably by iPhoto too, despite iPhoto’s unique EXIF parsing engine, the foundations are meant to be used throughout the system.) My only hesitation is whether or not this problem appears on 10.3.x after installing QT7.

This bug is most obvious in two settings:

• fast user switching messes up color profiles -- monitors that need them look awful after the switch
• iPhoto mangles image color on edits

If it's a QuickTime bug I wonder if the fix will come with the next iteration of QT.


Update 7/14:

This bug may have been fixed in both 10.4.2 and iPhoto, but I find this description quite interesting nonetheless. It may be a more subtle bug than some might think ....

John Fieber (Macintouch)

Everyone out there trying to fuss with the Generic RGB profile to fix the iPhoto color shift is barking up the wrong tree. The problem is with the display profile.

The problem is that when you edit in iPhoto it CONVERTS the RGB data to the DISPLAY profile to use as a working space for the edit. [1] Then on save it ASSIGNS the display profile RGB data as Generic RGB. This is the bug.

The color data is in the display profile space, not Generic RGB. The color should have been converted. Profile aware applications, like iPhoto itself, reading the image interpret the color data incorrectly because of the incorrect profile.

The reason why some people notice it and others don't and why manipulating the Generic RGB profile appears to "solve" the problem for some is because the magnitude of the color shift is a function of the difference between the display profile and Generic RGB. If you change your display profile to Generic RGB, the color shift goes away. If you change Generic RGB to match your display profile, the color shift goes away.

Folks with CRTs will generally notice less of a shift than folks with LCDs, particularly bad ones like in the iBook and 12" PowerBook, because a CRT's native color behavior is much closer to Generic RGB than an LCD's.

If you edit in iPhoto, you can mitigate the damage by ASSIGNING the display profile to the image. (You can do this with Preview, ColorSync Utility, the sips command line tool, AppleScript, Automater, Photoshop, etc.) This will allow profile-aware applications to correctly interpret the color data. You might then CONVERT to another profile, such as sRGB, depending on the intended use of the image.

(But note that the damage control must be done after EVERY edit as the color shift bug is cumulative otherwise.)

[1] This could be considered a bug, but isn't the cause of dramatic color shifts. The display profile is a lousy working space and conversions through it can be very lossy indeed. However, this was a design choice of the iPhoto team.

I think the iPhoto team was trying to improve color workflow for non-experts, but they took the wrong road. I use sRGB for everything: I attach it to images during import using raphic Converter nad I use it for my monitor profile. I was told this was a reasonable compromise for a non-expert, particularly since I edit using an iBook (lousy LCD color!).

Apple needs some help with their color profile development!

Macintouch Safari 1.3 (Part 7)

This seems fairly dumb:Sigh.

Update 7/14: The original comments and my post title were unfair to Apple. IE doesn't support color profiles, Safari does. The problem is that Safari assumes untagged files are Standard RGB, a better guess would have been sRGB.