[reportlab-users] HexColor()

[Lalo Martins]

On Tue, Feb 18, 2003 at 03:29:37PM +0100, Magnus Lycka wrote:
> At 03:33 2003-02-18 -0500, reportlab-users-request@reportlab.com wrote:
> >Ok, this is broken :-) Magnus pointed out that the current implementation
> >divides by 256 and not 0x100
> 
> No, it's not your day today Lalo. Last time I counted 256 == 0x100! ;)

I hope today I'm better :-)

> But I wonder... have you really tested this properly?

Yes, this is in actual use at a customer.  (Of course before your fix they
were getting their colors slightly off...)

> >            w = l/4
> 
> Unless you use "from __future__ import division" this will mean
> that w == 0 since len returns an int. int/int => int.

Yes.  This pretty much renders the whole thing unusable :-P my code uses
"from __future__ import division" - I must have forgot to paste it.

> But if we want to use 16 bits per colour, it will be 12 characters
> long, as in #AAAABBBBCCCC, and it will be interpreted as a 12 bit
> CMYK colour (AAA, ABB, BBC, CCC). See above. :(

I pointed that out in the introduction to my original email.  For this
customer, this is not a discussion - they need the possibility to type
either rgb or cmyk, and the current function solves their problem.  In real
life, 16 bits *per color* is much, much more than you need - the human eye
can't perceive that much, and I don't believe any printer or monitor in
existence can display it.

One way to disambiguate I pondered is to alow commas and/or whitespace...
but that would make the implementation a lot more complicated.  IMHO it's
not worth it.

(Of course the fact that this works for my customer doesn't mean it's
generally useful enough to go into reportlab - this is, remember, an offer,
not an imposition.)

> I don't think you can allow variable width if you want to accept
> both CMYK and RGB colors without a flag.

That is generalizing a special case too far.

> Personally, the only time I write colors like #something, it's 256 bit RGB
> color...

Allow me to emphasize the word "personally".  People in the publishing
business (which is the case of my customers) are much more comfortable with
cmyk.

> which is what the original function did...

It also accepted integers which is IMO way out of the application domain
implied by the function's name.

> Also, import this and think about
> "In the face of ambiguity, refuse the temptation to guess." and
> "Explicit is better than implicit.".

I see no ambiguity.  At least as far as real-life use goes.  Perhaps it
would feel safer if we constrained the "width" to 24 bits?

> It's probably better to make this into two functions, one to
> interpret HexCMYKColor strings, and another for HexRGBColor
> strings, but I don't feel a need for anything beyond what is
> currently available.

I'm not forcing you to use it.  I, on the other hand, have a real-life use
case for a single function that can handle both.

[]s,
                                               |alo
                                               +----
--
            Those who trade freedom for security
               lose both and deserve neither.
--
http://www.laranja.org/                mailto:lalo@laranja.org
         pgp key: http://www.laranja.org/pessoal/pgp

Eu jogo RPG! (I play RPG)         http://www.eujogorpg.com.br/
GNU: never give up freedom                 http://www.gnu.org/