> From: Thomas DeWeese [mailto:[EMAIL PROTECTED] > > > Jihai Qiu wrote: > > The CCS engine for the document is set in > > BridgeContext.initializeDocument(), which is called by > > org.apache.batik.bridge.GVTBuilder.build(). But it seems there is no way > > to set CCS engine from FOP classes(such as BatikElement). (I do > not want to > > modify Batik source code). > > > > > >>It also appears that you are trying to map just the flowText element. > > > > For the svg elements, FOP extension maps <svg> to SVGElement > and all other > > tags to SVGObj. I am using the same approach for batik extensions: > > <flowText> to BatikElement and all other tags to BatikObj. BatikElement > > creates the root document for batik namespace. > > You can't really render an SVG document as a bunch of > disconnected pieces. >
If this *is* related to the 'absolute positioned block-container' issue, I think the SVG approach, in this case, might be complicating matters unnecessarily (though I must admit, it might seem the only viable alternative right now, apart from somehow 'preprocessing' your fo to make it contain 'exact' coordinates where needed...) > >> The SVG specification is pretty clear that SVG elements must have a > >> parent SVG element > > It seems Batik requires each child of SVG element must be SVG > element( or > > belongs to same document). > > <svg> Batik DOM element is created through SVGDOMImplmentation, while > > <flowText> Batik DOM element is created through > > ExtensibleSVGOMImplementation. I have to have a different root document > > for all the batik extension elements, otherwise the system uses > > SVGDOMImplementation to create generic DOM element. > > It sounds like you want to make a small change so FOP uses the > ExensibleSVGDOMImplementation instead of SVGDOMImplementation for all > the elements. > > >>I think you really want to try and "fix" the existing SVG element > >> mapping stuff in FOP. > > How to do this? I stuck in this problem now and do not know > what to do the > > next. Can someone please help me implement this batik extension in FOP? > > I don't think you can really fix this without making changes in FOP. > It looks like you might be able to just change the init method in > SVGElement. > Just to be on the safe side: in the meantime, we still don't know which version(s) of batik/fop are being used here... ;) but apart from that, if the ExtensibleSVGDOMImplementation behaves completely the same way... this might be worth a little patch. The svg-embedding example coming with FOP works if you make this change. ( to FOP 0.20.5 release ) Greetz, Andreas Delmelle --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
