1. This is an alternative way I try to solve the FOP absolute positoned block-container issue.
2. The FOP version is fop-0.20.5 with batik jar and tried with batik version 1.5. 3. As we have sent back and forth the question and answers so many times, can someone doing the SVG for FOP please take a look at my batik extension code and help me solve the problem? I hope someone know the details of both FOP and SVG may help me. I am affraid that FOP does not contain Batik extension because FOP developor did not feel it is easy to add. Thanks a lot. Jay > > 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] > > > ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
