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: http://www.nabble.com/Including-an-sRGB-color-profile--tf1373500.html#a6726105 Sent from the FOP - Dev mailing list archive at Nabble.com.
