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.
The wrapping Color class delegates all calls to the wrapped
converted RGB
color so the behavior inside batik should not be influenced.
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.
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.
First would be to decide how it actually should look like
from a user
perspective.
There are a few options I guess
1/ Something like stroke="cmyk(c,m,y,k)". This
would mirror who it would
work in fop when the patch gets accepted. RGB values, when
needed in svg,
would come from the "normal" cmyk to rgb
conversion.
2/ Something like stroke="rgb(r,g,b)
icc-color(#CMYK,c,m,y,k)"
I am guessing from an implementation point of view, this
would be the least
intrusive
3/ Or perhaps stroke="rgb(r,g,b) cmyk(c,m,y,k)"
As a product feature 1/ makes most sense I think, but if it
would not make
it in the source tree anyway I'd rather try 2 (that is
actually how e.g. XEP
exposes it as well)
Any guidance or thoughts would be warmly welcomed!
Thanks,
Peter
> -----Original Message-----
> From: Peter [mailto:pc.subscriptions gmail.com]
> Sent: Thursday, October 12, 2006 2:48 PM
> To: 'batik-devxmlgraphics.apache.org'
> Subject: RE: fop - svg - icc (and cmyk color)
>
> Thomas,
>
> Just exploring the grounds.....
>
> From my side, cmyk and/or multiple unconverted icc
profiles within one
> rendered svg image would only be needed for simple
fills (no filters or
> other more advanced svg features) and only for PDF
rendering (not sure
> whether that matters). Basically I would like to use
svg to add
> "decoration" to existing (cmyk or icc based)
art work using a separate
> layer which is imposed on the original information
later during the
> workflow. In that context it is important that the
added decoration and
> original art work have matching colors when printed but
it is perfectly
> acceptable that when the user decides to use more
advanced svg features he
> is on his own wrt color mgmt.
>
> I have the impression from what you replied lower that
that is something
> that is potentially doable in Batik without turning
everything upside down
> or having to stretch the svg spec. Did I understand
that correctly?
>
> If so, and assuming the Batik community would be
interested in seeing
> something like this integrated, do you think someone
could write out a
> high level roadmap of what would have to be done
(something like
> http://www.nabble.com/Including-an-sRGB-color-profile--
> tf1373500.html#a6455273)? I could give it a try
assuming the effort stays
> manageable, but I think without some initial tutoring
this would take far
> more time for me than what I can afford to spend.
>
> Thanks,
>
> Peter
>
>
> > -----Original Message-----
> > From: thomas.deweesekodak.com
[mailto:thomas.deweesekodak.com]
> > Sent: Thursday, October 12, 2006 2:15 PM
> > To: batik-devxmlgraphics.apache.org
> > Cc: batik-devxmlgraphics.apache.org
> > Subject: RE: fop - svg - icc (and cmyk color)
> >
> > Hi Peter,
> >
> > "Peter" <pc.subscriptionsgmail.com> wrote on 10/12/2006 06:56:21 AM:
> >
> > > Stretching my luck....and asking more
beginner type of
> questions...some
> > of
> > > which may be nonsense or not suited for this
list.
> > >
> > > Would you (or anyone else) have any idea when
your patch (27248) will
> > make
> > > in the source tree?
> >
> > I probably wouldn't commit it until it was
clearer if the feature
> will
> > in fact be part of SVG 1.2 Full. That might not
happen for a while...
> >
> > > With respect to your consideration that Batik
needs a rendering color
> > space,
> > > would that mean that it is impossible (even
with the patch) to mix
> > colors
> > > from different color spaces without seeing
them converted?
> >
> > This depends a lot on the structure of the SVG
content. If you are
> > just doing simple fills it might be possible to
hold and mix colors from
> > different color spaces in one document. But as
soon as you perform an
> > operation that requires 'rendering', examples
being filters, patterns,
> > masking(?), group opacity, etc. Then Batik will
need to render the
> > elements to a bitmap an do pixel manipulations at
this point all the
> > colors must be in the same color space.
> >
> > > The fact that cmyk is basically "not an
option" does that stem from
> the
> > fact
> > > that all color manipulation is done with 3
components and that
> changing
> > that
> > > would require turning everything upside down
or is there something
> else
> > > going on (as well)?
> >
> > The main problem with CMYK is that SVG is built
around sRGB, so a
> > number
> > of the filters in particular are defined in terms
of 3 color channels so
> > you simply can't add a fourth color channel
without playing significant
> > games with the SVG specification.
> >
> > Things are a bit better with respect to simple
fills. I think you
> > could potentially carry the CMYK color info
through to the PDFGraphics2D
> > as long as that part of the image was natively
representable in
> Graphics2D
> > terms.
> >
> > Trying to pass a CMYK images through might also
be a potential source
> > of trouble.
> >
> > > Do you have any idea (wrong list I guess, but
I am just looking for a
> > > solution for my problem) how other
(commercial) fo/svg implementations
> > deal
> > > or deal not with these issues (cmyk and/or
multiple not converted
> > profiles)?
> >
> > I don't really know. There was a proposal from
HP/Canon called SVG
> > Print
> > that tried to address some of these issues.
> >
> > > > -----Original Message-----
> > > > From: thomas.deweesekodak.com
[mailto:thomas.deweesekodak.com]
> > > > Sent: Thursday, October 12, 2006 12:07
PM
> > > > To: batik-devxmlgraphics.apache.org
> > > > Cc: batik-devxmlgraphics.apache.org
> > > > Subject: Re: fop - svg - icc (and cmyk
color)
> > > >
> > > > Hi Peter,
> > > >
> > > > "Peter"
<pc.subscriptionsgmail.com> wrote on 10/12/2006 05:29:55
> AM:
> > > >
> > > > > As a follow up on a recently
submitted fop color patch
> > > > > (http://issues.apache.org/bugzilla/show_bug.cgi?id=40729) I am now
> > > > looking
> > > > > into what it would take to support
icc/cmyk support for fo
> embedded
> > svg
> > > > > content.
> > > >
> > > > Batik already supports ICC color
profiles for colors (see the
> > > > example in the distribution;
samples/test/spec/color/colorProfile).
> > > >
> > > > However it is important to realize
that unlike FOP SVG has an
> > embedded
> > > > rendering color space (sRGB, in some
cases linear sRGB). This is
> > required
> > > >
> > > > because of operations like filters which
need to work with real
> pixel
> > > > values not abstract colors.
> > > >
> > > > In Bugzilla there is a patch that
adds support for a
> > > > rendering-color-space [Bug #27248].
This allows you to
> > > > adjust the color space that Batik does
it's rendering in
> > > > (all source colors are converted to that
color space before
> > > > rendering). However it is restricted to
3 bands as otherwise
> > > > all of the filter/gradient/masking/etc
code falls apart.
> > > >
> > > > > First, any higher level advice on
how to approach this in general
> > would
> > > > be
> > > > > warmly welcomed.
> > > >
> > > > Well aside from CMYK support you may
not have much to
> > > > do. It may be instructive to look at the
rendering-color-space patch
> > > > to see what needed to be done to support
alternate color spaces for
> > > > rendering.
> > > >
> > > > If you want to do CMYK then you have
a huge task ahead
> > > > of you.
> > > >
> > > > > Second, what I think I have learned
after 2 hours (first 2 hours
> > ever in
> > > > > Batik code, so I am probably
missing a lot) is that fop (in
> > > > > PDFSVGHandler#renderSVGDocument)
creates a bridge context and
> passes
> > > > that to
> > > > > Batik's GVTBuilder#build.
> > > >
> > > > Correct.
> > > >
> > > > > I have the impression (however?)
that the color-profile elements
> are
> > not
> > > > > added to the color profile bridge
during the build invocation (it
> > skips
> > > > over
> > > > > the defs element).
> > > >
> > > > The SVGColorProfileElementBridge uses
getElementsByTagNameNS to
> > track
> > > > down the color profile elements in the
document containing the
> element
> > > > when a paint using an icc-color is first
encountered (if it were
> done
> > > > as part of the normal build tree walk
then forward references
> wouldn't
> > > > work).
> > > >
> > > > > The result is that during
rendering, the fallback color is used as
> > the
> > > > color
> > > > > profile is not found in the bridge.
> > > >
> > > > I think this is due to a mistake in
your content.
> > > >
> > > > > Would this be expected behavior and
should fop figure out another
> > way to
> > > > get
> > > > > hold of the color-profile info?
Actually, I am not sure which
> > > > color-profile
> > > > > elements (those of fo or the
embedded svg ones) should be used.
> > > >
> > > > Batik will naturally only look for
color-profile elements in the
> > > > SVG namespace.
> > > >
> > > > In your example, I think you want to
change the 'name="icc"'
> > > > attribute to be
'name="changeColorAuto"'.
> > > >
> > > > > <fo:instream-foreign-object>
> > > > > <svg xmlns="http://www.w3.org/20
00/svg"
> > > > > xmlns link=
"http://www.w3.org/
1999/xlink" height="50"
> > width="50">
> > > > > <defs>
> > > > > <color-profile
name="icc" rendering-intent="auto"
> > > > >
xlink:href="changeColor.icm"></color-profile
>
> > > > > </defs>
> > > > > <g>
> > > > > <rect height="20"
width="20" x="15" y="15"
> > > > > fill="rgb(100, 100,
100) icc-color(changeColorAuto,
> > > > 0.1,0.1,1.0)"
> > > > > stroke="rgb(200, 200,
200)
> > > >
icc-color(changeColorAuto,0.2,0.2,0.2)"
> > > > >
stroke-width="10">
> > > > > </rect>
> > > > > </g>
> > > > > </svg>
> > > > > </fo:instream-foreign-object>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> >
------------------------------------------------------------
---------
> > > > > To unsubscribe, e-mail: batik-dev-
> unsubscribexmlgraphics.apache.org
> > > > > For additional commands, e-mail:
> > batik-dev-helpxmlgraphics.apache.org
> > > > >
> > > >
> > > >
> > > >
------------------------------------------------------------
--------
> -
> > > > To unsubscribe, e-mail:
batik-dev-unsubscribexmlgraphics.apache.org
> > > > For additional commands, e-mail:
batik-dev-
> helpxmlgraphics.apache.org
> > >
> > >
> > >
------------------------------------------------------------
---------
> > > To unsubscribe, e-mail:
batik-dev-unsubscribexmlgraphics.apache.org
> > > For additional commands, e-mail:
batik-dev-helpxmlgraphics.apache.org
> > >
> >
> >
> >
------------------------------------------------------------
---------
> > To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
> > For additional commands, e-mail:
batik-dev-helpxmlgraphics.apache.org
------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org
|