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: [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]
