Hi Peter,
> > "Peter" <pc.subscriptions gmail.com> 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" <pc.subscriptionsgmail.com> 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: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org
|