On Saturday 2012-06-09 00:42 +0200, Simon Sapin wrote:
> Le 08/06/2012 22:20, Tab Atkins Jr. a écrit :
> >Could we make the rgb components of rgb/a() be <number> rather than
> ><integer> in level 4?
>
> I’m in favor; I don’t see a downside in allowing it.
>
>
> >I suggest we cast the components to integers in the same way we did
> >for Transitions - normal round, .5 goes toward positive infinity.
>
> I’m not sure what rounding this is. I understand that as "n + 0.5 is
> rounded to n + 1" (with n an integer). What about n + 0.1 ? In the
> current Transitions ED I read "The interpolation happens in real
> number space and is converted to an integer using floor().", I think
> so n+0.5 would be rounded to n, not n+1
>
> In any case, the spec should define how to round (in what
> direction), but maybe not at which resolution. If an implementation
> can support more than 8bits per color channel the spec’ed rounding
> should not limit that.
So I think any definition of rounding behavior should be general to
colors, not specific to rgb(<integer>, <integer>, <integer>). We
already allow arbitrary precision colors with rgb(<percent>,
<percent>, <percent>).
I'd be inclined to say there might be advantages to not defining
rounding behavior here. The experience I've seen with color
management on different platforms has been that they round
differently, but being off by one color component doesn't sound all
that serious. Being able to benefit from hardware acceleration may
outweigh being able to define every result exactly.
-David
--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂