Hi, Andreas The problem you got was the first the problem I got before. Basically you need use batik jar file with resource property files. I guess you use the batik.jar file comes with FOP package. That batik jar does not contain the resource property files. You may add xml-batik\resource\META-INF\services\* from batik package into batik.jar file ( directly use batik distribution jar). This resource files request batik use extesions.
But if you can even not solve even this simple problem, then please do not try to solve the problem for me. Geln Mazza asked me to file a bugzilla report and Thomas DeWeese thought batik implementation may require some changes. You may check fop-dev mail list for the same subject for details. I hope Glen may implement this feature as early as possible. I have thought about the extenal fop obejct approach. But it is not feasible for me. Our approach is: (1) a setting file + an XSLT template ==> XSLT file (2) DATA file + a generated XSLT file ==> HTML/FO With one setting file and one XSLT template, it is impossible to transform to multiple files. XSLT does not support writing out to multiple document files. Thanks. Jay ---- On Mon, 8 Sep 2003, Andreas L. Delmelle ([EMAIL PROTECTED]) wrote: > > 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] > > > ________________________________________________ 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]
