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.
> >
> > 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.
"Peter" <[EMAIL PROTECTED]> wrote on 10/16/2006 05:15:12 PM:
> 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?
Right now the dependencies are a bit of a mess. In general I would say
that FOP has deeper dependencies on Batik however Batik depends on FOP for
the PDFTranscoder (and PDFGraphics2D) implementation meaning that we have
an ugly nasty snarly mess. Our hope is to eventually straighten this out
by moving the PDFGraphics2D into the xmlgraphics subproject.
> > > 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?
Yes, in short the 'color' type comes from CSS. None of the CSS
specs (2, 2.1, 3) seem to mention an icc-color() function, I can't
find it in either of XSL-FO or the SVG specifications. I'm sure
it must be in one of them but I couldn't find it.
> > > 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.
I still want to track down what is going on with the definition of
the icc-color function. But I would suggest that the reference be
to '#Device-CMYK'.
> > 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.
I think this is the same as processes CMYK.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
