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]
