Bug #12163 for Graphics-ColorNames: Color names that don't appear in keys %tied

Wed Apr 06 10:05:26 2005 CFAERBER [...] cpan.org - Ticket created

Subject:

Color names that don't appear in keys %tied_var

It might be a good idea to have color names that are recognized but don't appear in the list of available color names. One example is "fuscia". It is not a valid color name but it should still be recognized. This is important when you want to use the maps to translate colors back to their names. Currently, there's no indication whether you should translate #FF00FF to "fuscia" or "fuchsia", so you can't simple use Graphics::ColorNames::HTML in order not to have to maintain your own list. Well, there's a patch attached, which implements the feature.

Nur in Graphics-ColorNames.new: blib. diff -ur Graphics-ColorNames-2.0_01/lib/Graphics/ColorNames/HTML.pm Graphics-ColorNames.new/lib/Graphics/ColorNames/HTML.pm --- Graphics-ColorNames-2.0_01/lib/Graphics/ColorNames/HTML.pm 2004-07-22 21:52:45.000000000 +0200 +++ Graphics-ColorNames.new/lib/Graphics/ColorNames/HTML.pm 2005-04-06 15:33:39.052949274 +0200 @@ -53,8 +53,7 @@ 'blue' => 0x0000ff, 'aqua' => 0x00ffff, 'lime' => 0x00ff00, - 'fuchsia' => 0xff00ff, # "fuscia" is incorrect but common - 'fuscia' => 0xff00ff, # mis-spelling... + 'fuchsia' => 0xff00ff, 'red' => 0xff0000, 'yellow' => 0xffff00, 'white' => 0xffffff, @@ -69,6 +68,14 @@ }; } +sub NamesRgbTableExtra() { + use integer; + return { + 'fuscia' => 0xff00ff, # "fuscia" is incorrect but common + # mis-spelling... + }; +} + 1; __END__ diff -ur Graphics-ColorNames-2.0_01/lib/Graphics/ColorNames.pm Graphics-ColorNames.new/lib/Graphics/ColorNames.pm --- Graphics-ColorNames-2.0_01/lib/Graphics/ColorNames.pm 2005-04-04 15:15:29.000000000 +0200 +++ Graphics-ColorNames.new/lib/Graphics/ColorNames.pm 2005-04-06 15:46:39.641545953 +0200 @@ -121,6 +121,12 @@ { no strict 'refs'; $self->load_scheme($module->NamesRgbTable); + + if(my $m = UNIVERSAL::can($module, 'NamesRgbTableExtra')) + { + local $self->{NAMES} = ($self->{NAMES_EXTRA} ||= {}); + $self->load_scheme($m->()); + } } } @@ -190,6 +196,9 @@ } else { my $value = $self->{NAMES}->{$key}; unless (defined $value) { + $value = $self->{NAMES_EXTRA}->{$key}; + } + unless (defined $value) { my @schemes = @{ $self->{SCHEMES} }; while ((!defined $value) && (my $scheme = shift @schemes)) { if ((ref $scheme) eq 'CODE') { Nur in Graphics-ColorNames.new: Makefile. Nur in Graphics-ColorNames.new: pm_to_blib. diff -ur Graphics-ColorNames-2.0_01/t/03-HTML.t Graphics-ColorNames.new/t/03-HTML.t --- Graphics-ColorNames-2.0_01/t/03-HTML.t 2005-03-30 01:44:44.000000000 +0200 +++ Graphics-ColorNames.new/t/03-HTML.t 2005-04-06 15:49:25.329616388 +0200 @@ -8,7 +8,7 @@ tie my %colors, 'Graphics::ColorNames', 'HTML'; ok(tied %colors); -ok(keys %colors == 17); +ok(keys %colors == 16); my $count = 0; foreach my $name (keys %colors)

Thu Apr 07 10:32:42 2005 rrwo [...] cpan.org - Correspondence added

I've had similar suggestions before, where people have wanted the ability to translate RGB codes into color names. But it's beyond the scope of this package, which is just to provide a translation of names to colors. If I add a lot of features that most people will consider extraneous, then there is the risk having many people not use the module because they only want a list of colornames. I am trying to clean up the module so that it is "lean and mean", and only does a few related things but does them well. Some systems have duplicate names due to mistakes, others have intentional duplicates because people have different names for the same thing. Note that one can have multiple color schemes. Indeed, if I query keys it's because I want a list of keys. It could break something to have a hidden key that didn't show up in 'each' but still returned a value in 'fetch' and 'exists'. It might even break somebody's code. And your patch would be problematic for multiple color schemes. "fuscia" may not belong in HTML but it might belong some another scheme Z. If Z had higher-priority than X, then why should I care if "fuscia" doesn't belong in HTML. Likewise, if HTML has higher-priority than Z, should Z's inclusion of "fuscia" invalidate HTML's exclusion? I'd recommend the following solutions: * Write a Graphics::ColorNames::StrictHTML module that eliminates the fuscia, and/or * Have your code which reverse-translates RGB codes return a list when multiple names have that value. In scalar context you could just return the first one. I do appreciate the interest and efford put into the patch, but I will have to turn down your request. Thanks, Rob

Thu Apr 07 10:32:43 2005 rrwo [...] cpan.org - Status changed from 'new' to 'resolved'

Thu Apr 07 11:20:42 2005 The RT System itself - Status changed from 'resolved' to 'open'

Thu Apr 07 11:20:42 2005 Guest - Correspondence added

[RRWO - Thu Apr 7 10:32:42 2005]: Show quoted text

> I've had similar suggestions before, where people have wanted the > ability to translate RGB codes into color names. But it's beyond the > scope of this package, which is just to provide a translation of names > to colors.

Maybe it could be another module -- e.g. Graphics::ColorNames::Reverse.. . Well, my main concern is to provide the information necessary to do reverse lookups without duplication of the data already present in Graphics::ColorNames's map modules. G::CN::HTML, for example, does not tell you whether "#ff0ff" should be translated to "fuscia" or "fuchsia". It might be good to include this information even if the behaviour of G::CN itsself is not changed. Actually, if I think about what you said about "intentional duplicates", there are not two types of color names (standard and non-standard) but three: * standard and preferred * standard but not preferred * non-standard Regarding compatibility, it might make sense not to change what NameRgbTable returns but to add new functions which returns the additional data (and is used by NameRgbTable, which could even be inherited from G::CN::BASE so that new modules only have to implement one of the two functions).

Thu Apr 07 21:22:07 2005 Guest - Correspondence added

[guest - Thu Apr 7 11:20:42 2005]: Show quoted text

> Maybe it could be another module -- e.g. Graphics::ColorNames::Reverse..

I'm wary of putting it in the Graphics::ColorNames::* namespace, since that's where the color schemes are (and there is an all_schemes method to query a list of schemes available in version 2.0). If I could do it over again, I'd write a Graphics::ColorNames::Plugins::* namespace, but there are already several modules using the existing system and several extensions. Show quoted text

> Actually, if I think about what you said about "intentional duplicates", > there are not two types of color names (standard and non-standard) but > three: > > * standard and preferred > * standard but not preferred > * non-standard

The point behind the module isn't about standard names or not. It's so that programmers (or users) can specify a color by name rather than RGB code. People can use whatever naming scheme they want: they can even use ones in other languages than English if they write them. Duplicates are not just in HTML. They are also in X. For instance, various shades of grey|gray, peru|tan3, olivedrab3|yellowgreen, and others. In the HTML case, it's a known issue. In X, which takes priority?

use strict; require Graphics::ColorNames::X; my $x = Graphics::ColorNames::X->NamesRgbTable(); my $y = { }; foreach my $name (keys %$x) { if ($name !~ /\s/) { my $rgb = sprintf('%06x', $x->{$name}); if (exists $y->{$rgb}) { push @{$y->{$rgb}}, $name; } else { $y->{$rgb} = [ $name ]; } } } foreach my $rgb (keys %$y) { if (@{$y->{$rgb}} > 1) { print join(" ", $rgb, map { "\"$_\""} @{$y->{$rgb}}), "\n"; } }

Mon Dec 17 20:10:38 2007 rrwo [...] cpan.org - Status changed from 'open' to 'rejected'

Bug #12163 for Graphics-ColorNames: Color names that don't appear in keys %tied_var