Thomas, Thanks for your answers (and time)
> > Hi Peter, > > "Peter" <[EMAIL PROTECTED]> wrote on 10/13/2006 04:55:00 AM: > > > I have been prototyping a bit and it does look fairly doable to get the > > orginal icc-color values into the PDF renderer by wrapping them inside a > > Color object that is returned from the PaintServer#convertRGBICCColor > > function. > > Yes, this is where you would attach the additional information that > you need. In fact it probably would be good to store a reference to > the ICC profile and the values in all cases so that any destinations that > could/wanted to make use of it could. > > > The wrapping Color class delegates all calls to the wrapped converted > RGB > > color so the behavior inside batik should not be influenced. > > There is no need to truly 'wrap' the java.awt.Color class. You just > need to subclass it and attach your information in the subclass. > Agreed. So I have been merging the Color extension I needed for FOP and what I would need for SVG. I am however somewhat confused where it belongs. I have put it in fop's util package and changed build.xml to include it in the transcoder.jar but I am not very confident that is the best place for it. Is there any doc explaining how the dependencies between fop and svg should be handled? > > I am assuming, but have not tested this, that whenever SVG manipulates > > color data the Color object returned from the convertRGBICCColor > > function will not make into the PDF library. > > Essentially correct (it depends a little on the definition of > 'manipulates'). Change I guess. But given Color's interface that does not seem to make sense, so I guess this is not an issue > > > Next would be to try and get cmyk in. I understand that this is not svg > spec > > compliant and might therefore not make it in the source tree but I can > > always use it locally in that case I guess. > > So to be honest I tried to track down the reference on icc-color and > while it talks about how you can use them I couldn't find the definitive > reference. I wanted to read this to get clues on the CSS extension. > Do you have that reference handy? Probably the answer is no. I am really very new to all these things so the chances I have something available you don't are really very small. But I am also not sure I understand what exactly you are looking for. Are you saying the svg spec is unclear on what the icc-color function should do and that you expect some other spec to explain that? > > > First would be to decide how it actually should look like from a user > > perspective. > > > > There are a few options I guess > > Except for your second proposal one the big problem is that you > would have to go in and make serious changes to the CSS DOM for > colors which is already one of the hairiest parts of the CSS DOM. > Yeah...I ran into that as well. So what I have done is build a prototype using the 2nd approach, but I slightly changed it. In what I have implemented the icc-color 1st argument is still a name of color space defined in a color-profile element but there the href needs to be "#CMYK". That way the parsing of the icc-color function did not have to change. > One thing that confuses me is that especially when talking about CMYK > there are a large number of potential color spaces in common usage. > I'm not sure how useful it is to say 'use this CMYK color' don't you > really need to define the CMYK? Are you always implying processes CMYK? > Or SWAP? Or one of the other common CMYK colorspaces? What I have been trying to get to work (actually it seems to work) is that the CMYK values the user specifies in the icc-color function call end up in the pdf using the /DeviceCMYK 'color space'. The idea is that while one has no control on how the color will look (being uncalibrated) when printed, the user can nevertheless be sure that if he has pdf material generated outside svg using /DeviceCMYK values, the color svg generates will look the same when printed. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
