On second thought, having the conversion based on the profile might be the
right thing to do after all. Either the renderer knows how to deal with
color profiles and will do the necessary, or it does not in which case it
will ask the color for its rgb values. The profile based converted values
might be the best bet then. 

Also the xsl spec says the replacement values are used when the color
profile is not available (not when the renderer does not know how to deal
with it). When the profile can not be loaded, an rgb Color based on the
replacement values can be created and returned.

Leaves the CMYK case....not sure what to do there. I guess converting
device/default cmyk to (device/default?) rgb is also easy so in that case
replacement values are not needed either. That would mean that the
cmyk(c,m,y,k) approach could work just as well as the perhaps more awkward
rgb-icc(r,g,b,#CMYK,c,m,y,k) hack. It does seem necessary to create a CMYK
color space class though (or complete the one in org.apache.fop.util).

Apologies for all the confusion and unclear questions...this is (obviously)
all very new for me and I am far from confident I grasp all the details or
consequences of possible decisions made

Jeremias Maerki-2 wrote:
> Uh yeah, right. I didn't think about that. No way around subclassing
> Color then.
> On 09.10.2006 09:54:31 Peter Coppens wrote:
>> >Do you really have to extend the Color class? I think it already
>> >provides methods to access the fallback sRGB value which is actually
>> >what the FO spec wants (getRed(), getGreen(), getBlue()).
>> Not sure....all pretty new for me, but would the get<RGB>() functions not
>> return the profile based converted values rather than the ones the user
>> specified as first arguments to the rgb-icc function?
> Jeremias Maerki

View this message in context: 
Sent from the FOP - Dev mailing list archive at Nabble.com.

Reply via email to