You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instead of the Color instance itself being in charge of the color space to render it to, this would ideally be the backend's job.
Otherwise, inconsistent Color instances could result in an inconsistent diagram, since the user may want to use color spaces other than sRGB.
The proposed solution would be to either parametrize toRGBA over the RGBSpace to use; or ideally, don't provide toRGBA at all and simply provide toColour :: a -> Colour Double and toAlpha :: a -> Double.
The text was updated successfully, but these errors were encountered:
haasn
pushed a commit
to haasn/diagrams-lib
that referenced
this issue
Nov 20, 2012
This addresses concerns raised in issue diagrams#66 by letting the backend
choose which color space to render Color instances to. Functions are
provided for backwards compatibility with the old semantics, which were
to always render out to companded sRGB space.
Instead of the Color instance itself being in charge of the color space to render it to, this would ideally be the backend's job.
Otherwise, inconsistent Color instances could result in an inconsistent diagram, since the user may want to use color spaces other than sRGB.
The proposed solution would be to either parametrize toRGBA over the RGBSpace to use; or ideally, don't provide toRGBA at all and simply provide toColour :: a -> Colour Double and toAlpha :: a -> Double.
The text was updated successfully, but these errors were encountered: