>I don't think this will go without changing some method signatures. >Given that not in every context (see AreaTreeParser example above) you >have the FO tree available. So it may make sense to define a >ColorContext interface which allows access to the available color >profiles for the document. There would be an implementation for the FO >tree context and one for the AreaTreeParser context, maybe some >additional implementation if necessary. But I can see that there will >need to be some extensive changes. I currently don't see a way around >that. But maybe someone else does. >
Trying to trim down the amount of code I will have to touch (this is my first attempt to contribute to an open source project and I'd rather start as small as possible) Perhaps the following could work? (*) I add a second rgb-icc function, rgb-icc-internal or whatever that does not take an NCNAME for its colorprofile parameter, but the src of the matching element from the declarations element. (*) The user specifies rgb-icc (of course) which will always, I hope, be parsed through a call to [EMAIL PROTECTED] -> ? -> ColorUtil#parseColorString. The result of this is a class derived from java.awt.Color which registers rgb replacement values, icc values, color profile ncname and also the color profile src (setting the src happens in the new ICCColorFunction#eval method which has access to the fo tree) (*) If later ColorUtil#colorTOsRGBString is called, the ColorUtil returns an rgb-icc-internal iso rgb-icc call where relevant (I guess the name should be changed) (*) Obviously parsing of rgb-icc-internal will also be added, but at this stage the map is no longer needed. Thoughts on (1) this could work (2) you guys would buy into this rather awkward approach? Thanks, Peter -- View this message in context: http://www.nabble.com/Including-an-sRGB-color-profile--tf1373500.html#a6716163 Sent from the FOP - Dev mailing list archive at Nabble.com.
