[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: color.el
From: |
Miles Bader |
Subject: |
Re: color.el |
Date: |
Sun, 20 Feb 2011 13:07:12 +0900 |
"Drew Adams" <address@hidden> writes:
>> Radians seem cleaner; an argument range of 0-360 only seems
>> useful if an interface is primarily user-level (e.g. a spec
>> in a web page or something).
>
> Cleaner than what? than [0,360]? than [0,1]? than both?
> And why? In particular, why would [0,2*pi] be cleaner than [0,1]?
Actually I was just comparing to 0-360; I agree that 0-1 is probably the
best of them all.
[A possible exception might be if you're trying very hard to avoid
consing; then maybe any use of floats is undesirable. It doesn't seem
that's considered an issue with this API tho...]
> I agree (if you are saying this) that the input and return values of these
> functions should not assume only or even primarily user-level use cases (e.g.
> web-page color spec). They should be general functions. This is essentially
> a
> utility library of building-block functions.
Agree.
> IMO, the values should be of the same type (a) for all components
> (r,g,b,h,s,v),
> and (b) for both input and return values. We should not be sometimes passing
> in
> [0,1] for RGB and other times passing in [0,255] for RGB. Similarly for
> return
> values. And we should not use [0,360] for H but [0,1] for S and V.
I agree.
I'd rather not ever use 0-255 in the interface though. _If_ it's
sometimes desirable to use integers instead of floats for color
components, 0-65535 gives higher resolution, is already in use by Emacs
color functions (`color-values'), and can be efficiently (without
division) converted to 0-255 internally when that range is desirable
(for backends or whatever).
-Miles
--
Dinanzi a me non fuor cose create
se non etterne, e io etterno duro.
Lasciate ogne speranza, voi ch'intrate.