lichtkind

At the recent YAPC::EU (still running) I gave a talk about my latest CPAN module: Graphics::Toolkit::Color (in short GTC - v1.53). It went a little out of hand and even worse: some of the key thoughts I did not formulate as clear as wanted. That is why I use this channel to correct that. In this first part I outline the goal of the module and the next part will be about the design principles of the public API, moving than into implementation details and the general issues when dealing with colors.

At the beginning I did not plan to write GTC. I just factored out 6000 constants out of the main class of Chart and separate them into a nice submodule of its own. This was just step 2 of my mission to breathe some new life into a rusty staple of the CPAN.

The package got improved to cater to some needs of its mother module and as soon I discovered I could use these features in other projects - the CPAN distribution was born.

The original feature set was:

1. translate color names into RGB triplets (to define colors by name -- X11 and CSS)
1.1 added pantone colors to have designer colors that look actually good
2. translate HSL triplets into RGB (to define colors more intuitively)
3. compute complementary colors to have an optimal color set for graphs

Then I added a gradient function for my other projects and support for the syntax 'standard_name:color_name' to define a color, employing a set of colorname modules I took over in maintainership. At this point we surpassed any comparable module on cpan, since they do either complement or gradient and also lack any of the additiona arguments of these methods GTC provides. And there is at least one more planned method, so GTC can become your one stop shop to compute sets of interrelated colors. In order to achieve that GTC has to accept and output a lot of useful formats. Ignoring in the process the comprehensive list of color space converter modules such as Color::Convert is not ideal but the only choice to get three features I want to stick to.

1. No none core dependencies. (That takes care of over half of the distributions).
2. Being able to compute all operations in all supported color spaces. This would require helper functions some modules don't provide. It is just easier to have a set of uniformly written modules by myself than extending other people code, each package in a different way.
3. And borrowing and rewriting code is something I have to do anyway, since there is no module on CPAN that supports all spaces (like RGB, HSL, HSV, Lab and so on) I want to incorporate. Since most people scratch their itch and go on to different pastures.

To summarize: GTC creates color sets or even single colors procedurally whenever it is too much hassle to open photoshop or GIMP to figure out what you really need and then punch the numbers directly into your code. The module can also be also useful if you only know at runtime how many complementary colors you need to visualize your data set or if you have to respond to an at runtime given color (e.g.: give me an much darker variant of that color which has a minimal distance to black!). Sometimes its just enough to be able to read that a color is a mix between lime and mid green instead of #23AB44.