Hi Jeremias, Would such a ColorConverter interface be useful as part of xmlgraphics commons? I think there may be other color related classes that could be re-housed like ColorExt.
Pete On Thu, Nov 26, 2009 at 8:20 PM, Jeremias Maerki <[email protected]>wrote: > Hi Peter > > On 26.11.2009 21:06:42 Peter Hancock wrote: > > Hi Jeremias, > > > > I think I see what you have in mind - the interface could simply expose > > methods like > > *Color convertXtoY(Color)*. Or did you have in mind the methods > returning > > output type-specific color representaions? > > Pretty much just one very simple "Color convert(Color)" method. Not sure, > yet, if it's too simple. ;-) But at least this wouldn't make any > assumption what kind of color conversion happens. The setup is done > elsewhere. Having a simple interface has the advantage that a converter > can be used in different places. > > > Should AbstractPaintingState be responsible holding the ColorConverter > and > > exposing it as a property e.g for the utility of AFPGraphics2D before > > calling setColor() on the GraphicsObject instance? > > I haven't really thought that far, but that sounds about right. The > original color should be preserved as long as possible IMO, and only be > changed where it makes sense. And that would most probably be at the > point where it is set on the AFP graphics object. > > > Cheers, > > > > Pete > > > > > > On Wed, Nov 25, 2009 at 8:26 PM, Jeremias Maerki <[email protected] > >wrote: > > > > > Hi Peter > > > > > > See my question I attached to bug 48237. But of course, the ideal case > > > is to have the color converted properly if possible. > > > > > > On 24.11.2009 15:30:30 Peter Hancock wrote: > > > > At present FOP does not respect an image color setting of 'b+w' when > > > > rendering svg to afp (see Bug 48237) > > > > > > > > According to the AFP spec ( > > > > > > > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HA3N1M00/7.47.1?SHELF=APSBK320&DT=20001002123303 > > > ) > > > > it does not seem possible to specify a grayscale color space, and so > my > > > > question is how should colour be controlled? > > > > > > I think there are two general approached besides just using RGB: > > > - CMYK with only the K component (that is a clear indication that we > > > want a fully black color or shades of that) > > > - using a Highlight color space (assuming black as a highlight/spot > > > color) > > > > > > But I have no experience with highlight colors on AFP, so I can't tell > > > if it would work. > > > > > > > Since AFPGraphics2D is responsible for setting the color on the MODCA > > > > GraphicsObject prior to calling drawing methods, would a sensible > fix > > > to > > > > the problem be to convert the awt.Color before calling this setter? > > > > > > Probably. I have some tentative need to have a general color conversion > > > facility for FOP (not just AFP). For example, at some point we may want > > > to have color conversion from sRGB to CMYK. Another use case for a > color > > > converter would be a detector which would convert any grayscale color > (R, > > > G, B or C, M, Y with equal values) to a CMYK value (with only K) which > > > might in certain situations improve output quality because otherwise a > > > RIP might be inclined to mix black by mixing CMY. I can imagine that a > > > general interface could be defined for which there could be multiple > > > implementations depending on the use case and configuration. For the > > > present case, one implementation of that interface per color setting > > > could be written for AFP. Not sure, just brainstorming. > > > > > > > Any thoughts would be most welcome, > > > > > > > > Pete > > > > > > > > > > > > > > > Jeremias Maerki > > > > > > > > > > > Jeremias Maerki > >
