> From: Jay Chiu [mailto:[EMAIL PROTECTED] > > Attached please find a sample fo file with embedded svg object. > You may also take a look at the batik samples, > xml-batik/samples/extensions/flow/flowtext.svg > > FOP does support the base SVG 1.1 funcationality as Batik > supports. But SVG 1.1 does not support more flexible text > feature, such as text can not wrap onto multiple lines. Thus it > is impossible to put a text paragraph onto a SVG 1.1 charts. > Batik uses batik extensions <flowText>, <flowdiv>, <flowregion> > etc. to support the advanced text features. These new tags are > in the batik namespace, different than the svg namespace. The > current fop does not support the batik extensions.
Now see perfectly what you mean... Don't know if you have made the change yet that Thomas DeWeese suggested to make to FOP's SVGElement.init() - in fact, I replaced every SVGDOMImplementation with the ExtensibleSVGDOMImplementation, and after making this change the error becomes as follows: [ERROR] Unsupported element encountered: flowText (Namespace: http://xml.apache.org/batik/ext). Source context: file:/e:/temp/embedding_flowtext.fo (line: 43, col: 56) [ERROR] Expected XSL-FO (root, page-sequence, etc.), SVG (svg, rect, etc.) or elements from another supported language. and one more for every <batik:>-tag. ( That's the batik-extension not being supported... ) Checking the sources, I think you would like to make your code part of the org.apache.fop.svg-package ( unless the batik-extension could be used by itself, outside of the svg-context - after checking the flowText.svg example supplied with batik, my suspicion here seems correct. ) You want the svg namespace treatment to be extended to contain the batik extension tags and their behaviour relative to the svg context. As I understand, the FOP svg2pdf rasterizer is already an extension to the batik rasterizer, so perhaps we're kind of running in a circle here. Meaning, if you were to run batik's rasterizer standalone to render the svg to pdf, it would use the org.apache.fop.svg.PDFTranscoder class for that. So I guess the adjustments you would want to make would have to be made somewhere in there... Also, try taking a look at how batik treats its own extension tags before actually transcoding them. Unless the pdf-transcoder.jar that comes with batik contains classes not in (or different from) the FOP-release, the supplied sample wouldn't work running batik rasterizer standalone either. I see another remote possibility in rendering the svg through batik's rasterizer first (to a different graphics format - embedded svg is inserted as rasterized graphics anyway, could as well perform this beforehand. Due to the limitation WRT resolution of embedded svg, it might even give better results to let batik perform the rasterizing first.), then adding this as a graphic via fo:external-graphic...? Advantage of this approach would be that, instead of separate tables with intermediate 'relatively' positioned block-containers, you now get a continuous flow... The external graphic can be placed inside a fo:block ( in between the two tables ) - which in its turn could be placed inside a table-cell, unlike the seperate block-containers. That layout would definitely relieve you of having to supply exact page/viewport-relative co�rdinates, the freeform-data becoming part of the regular text-flow as it were. Hope these thoughts help you solve your prob. Greetz, Andreas Delmelle --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
