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.
> 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').
> 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?
> 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.
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?
> 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:[EMAIL PROTECTED]
> > Sent: Thursday, October 12, 2006 2:48 PM
> > To: '[email protected]'
> > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, October 12, 2006 2:15 PM
> > > To: [email protected]
> > > Cc: [email protected]
> > > Subject: RE: fop - svg - icc (and cmyk color)
> > >
> > > Hi Peter,
> > >
> > > "Peter" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > > > Sent: Thursday, October 12, 2006 12:07 PM
> > > > > To: [email protected]
> > > > > Cc: [email protected]
> > > > > Subject: Re: fop - svg - icc (and cmyk color)
> > > > >
> > > > > Hi Peter,
> > > > >
> > > > > "Peter" <[EMAIL PROTECTED]> 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/2000/svg";
> > > > > > xmlns:xlink="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-
> > [EMAIL PROTECTED]
> > > > > > For additional commands, e-mail:
> > > [EMAIL PROTECTED]
> > > > > >
> > > > >
> > > > >
> > > > >
--------------------------------------------------------------------
> > -
> > > > > To unsubscribe, e-mail:
[EMAIL PROTECTED]
> > > > > For additional commands, e-mail: batik-dev-
> > [EMAIL PROTECTED]
> > > >
> > > >
> > > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
[EMAIL PROTECTED]
> > > > For additional commands, e-mail:
[EMAIL PROTECTED]
> > > >
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail:
[EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
