Blog

Gamma Control 3.0

A recent donation convinced me to correct some bugs found in Gamma Control, my freeware gamma adjustement application for Mac OS X, and release a new version. I also made user interface improvements based on the comments I’ve been receiving in the last years. If you’re in need of a simple, well-done, and easy to use gamma correction tool for your monitor, you should check the new version of Gamma Control.

Beside a nice US$100 donation, the other motivation factor was that I now have a spare monitor I can plug on my iBook to test dual-screen mode. This allowed me to find out why some users have been telling me that Gamma Control didn’t work on their second monitor while it worked fine for others.

Turns out that the option “Affected Screens: Screen touching control window” was working only when screens where side-by-side and had the same vertical size (in pixel). The problem comes from the fact that Cocoa’s NSScreen class and CoreGraphic’s CGGetDisplayBounds function use different coordinate systems. The first use the bottom-left corner of the main screen as origin with an Y-up coordinates, while the second use the top-left corner of the main screen as origin with Y-down corrdinates.

To know on which monitor the control window is, Gamma Control compares screen coordinates, and thus must apply the right transformation to have releavant results. This transform was buggy in Gamma Control 2.x.

Finally, having solved this and mysterious problem, I decided to fix other annoyances of the application, update the icon and improve the user interface.

Annoyances as when the gamma settings are lost after a screen saver or for other reasons. While Gamma Control does its best to detect such situations and reapply the gamma curves, it may fail to do so at some times. If this is a problem for you, I’ve added an option in the preferences to make Gamma Control reapply its settings continously (each 8 seconds).

I think all this qualifies for a major update to version 3.0. Gamma Control is still free, but donations are appreciated, especially if you’re using it for lucrative purpuses.

Halloween!… and stereo balance

Today, I watched TV, saw many pumpkins, people in costumes, and George Bush — and all this convinced me it was Halloween. Since today is a good day for weird things, here is another. For no apparent reason, the stereo balance of the sound output on my iBook regularly goes to the left. Not by much: just enough for me to notice after a while.

And while I just said “regularly”, I haven’t been able to find any regularity into this unexplained phenomenon. My guess is that there is a bug in Mac OS X Tiger that does this. It could be linked to me often plugging and unplugging external speakers, but I’ve never been able to link the problem to a single thing yet.

Since the difference is hardly noticeable without music playing, and the only way to confirm things are unbalanced is to open the sound system preference pane and look at the balance slider, and since I seldom goes there, I never notice immediately, and thus never found the cause. Maybe someone has a solution.

PHP Markdown & Text Encoding

Replacing characters outside ASCII range by their HTML entity equivalent is pretty common on the web. I’m talking about the process of changing characters (like é) to a named entity (é) or a numbered one (decimal é or hexadecimal é). From time to time, I get in my email a request asking for converting characters to their HTML entity in PHP Markdown. Here is an explanation of why this won’t happen.

The reason Markdown doesn’t convert any character (except for <>'"& where appropriate) is that you shouldn’t have to convert them. PHP Markdown will work with any character encoding which is a superset of ASCII, including ISO-Latin-1 and UTF-8, and will leave characters as they are. If your input text is UTF-8, the result will be UTF-8 and will be displayed correctly on a web page, provided you specify the UTF-8 charset in the mime-type (either in the server header or in a meta tag).

If you want to convert such characters to entities, feel free to do so: it should be performed after Markdown has finished processing the text. But replacing characters by entities does not belongs in Markdown. Correctly converting characters to entities require the knowledge of what the input charset is, and PHP Markdown doesn’t know about this — it simply assume any superset of ASCII.

Sim Daltonism 1.0.1

This small update to Sim Daltonism solve a problem that prevented the application from running on some G3 processors. While I had tested the application on two G3 computers prior releasing version 1.0, it looks like some G3 iBooks and PowerBooks didn’t like it. So here it is, this new version should now work correctly on your computer.

So what was the problem? What I did is deactivate autovectorisation that seemed to create binary code uncompatible with the G3. I previously thought autovectorization creates a not-vectorized path for the G3s; I’m not so sure anymore. Anyway, after some inspection it seems the vectorizing compiler isn’t able to optimize any of the critical parts of the code, which render autovectorization useless for Sim Daltonism.

I’ve added on Sim Daltonism page some requirements and a version history which you can read. You will find that Sim Daltonism works on Mac OS X 10.2.8; this is based solely on the fact that it compiles well using the 10.2.8 SDK in Xcode. I haven’t found a computer running that system to test on.