Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Jeremias Maerki wrote: Hi Bug is filed against SAXON including patch: http://sourceforge.net/tracker/index.php?func=detailaid=1483350group_id=29872atid=397617 Let's see what happens. Michael seems to just have included your patch. See the full comment on the issue page. Thanks for having reported the issue. Regards, --drkm ___ Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. Rendez-vous sur http://fr.yahoo.com/set - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Dear All, You guys are absolute legends. Thank you so much for acting so quickly and being so thorough. I look forward to what Mr. Kay has to say :) Richard. Jeremias Maerki wrote: Bug is filed against SAXON including patch: http://sourceforge.net/tracker/index.php?func=detailaid=1483350group_id=29872atid=397617 Let's see what happens. On 07.05.2006 15:06:10 Florent Georges wrote: Jeremias Maerki wrote: No, I did not, but I think the whole thing will be resolved more quickly if I write the necessary patch for SAXON and submit that with the error description. But first, I want to look at the PDF size problem. Ok, thanks a lot. Jeremias Maerki - 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]
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
No, I did not, but I think the whole thing will be resolved more quickly if I write the necessary patch for SAXON and submit that with the error description. But first, I want to look at the PDF size problem. On 07.05.2006 14:39:43 Florent Georges wrote: Jeremias Maerki wrote: Hi Jeremias As I suspected, it's a bug in SAXON 8.7.1. net.sf.saxon.dom.DOMWriter.attribute() does not convert empty Strings (for no namespace) to null when it calls element.setAttributeNS(). Of course, one could argue who exactly is at fault here, SAXON or Batik. IMO, Batik did well with the fix to accept an empty String and null, but SAXON shouldn't send an empty String in the first place. I'd file a bug in the SAXON project. Did you report the bug? I can't find it in the Saxon bug tracker, and Michael doesn't seem to be aware of it. I can do it if you want, but while I understand the bug description, I don't have intimate knowledge of the different elements involved here. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Jeremias Maerki wrote: No, I did not, but I think the whole thing will be resolved more quickly if I write the necessary patch for SAXON and submit that with the error description. But first, I want to look at the PDF size problem. Ok, thanks a lot. Regards, --drkm ___ Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. Rendez-vous sur http://fr.yahoo.com/set - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Bug is filed against SAXON including patch: http://sourceforge.net/tracker/index.php?func=detailaid=1483350group_id=29872atid=397617 Let's see what happens. On 07.05.2006 15:06:10 Florent Georges wrote: Jeremias Maerki wrote: No, I did not, but I think the whole thing will be resolved more quickly if I write the necessary patch for SAXON and submit that with the error description. But first, I want to look at the PDF size problem. Ok, thanks a lot. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Not necessary. It's a known problem. Please see here: http://www.nabble.com/fop-trunk-svg-problems-t1177182.html What's new is that Saxon 8 seems to have a similiar problem. Anyway, since the thread quoted above Batik has been fixed in terms of attribute handling but unless Batik does a new release FOP will have this problem and we have to look into the XML parser and XSLT problem to fix the problem. Note: This may be seen as a regression of FOP but FOP is doing something perfectly valid. The code is correct. The problem occurs due to bugs in attribute handling in dependent packages outside FOP's control. I'm looking into why the same problem appears with SAXON 8, too. Richard, are you using the latest SAXON 8 release? On 30.04.2006 06:13:23 Clay Leeds wrote: Thank you for the report, Richard. Could you provide a small sample FO file + SVG which demonstrates the problem, so we can recreate the problem ourselves (and also have something which shows we've fixed the problem!)? Thanks! On Apr 29, 2006, at 8:29 PM, Richard Kennard wrote: Dear All, There seems to have been a regression in embedded SVG support between 0.92beta and 0.91beta? Using Cocoon 2.1.8, Saxon 8, Batik 1.6 and FOP 0.91beta my FOP with embedded SVG renders well. However upgrading to 0.92beta (and keeping everything else the same) gives me a stack trace (see below). I have checked and all rect elements definitely do have a width attribute (and besides it renders fine in 0.91beta). Interestingly the problem is related to upgrading FOP (not Batik). Thanks for an excellent product, Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Dear All, There seems to have been a regression in embedded SVG support between 0.92beta and 0.91beta? Using Cocoon 2.1.8, Saxon 8, Batik 1.6 and FOP 0.91beta my FOP with embedded SVG renders well. However upgrading to 0.92beta (and keeping everything else the same) gives me a stack trace (see below). I have checked and all rect elements definitely do have a width attribute (and besides it renders fine in 0.91beta). Interestingly the problem is related to upgrading FOP (not Batik). Thanks for an excellent product, Richard. THE STACK TRACE: 2006-04-30 12:42:46,843 ERROR [org.apache.fop.render.pdf.PDFSVGHandler] svg graphic could not be built: file:/C:/jboss-4.0.4.CR2/bin:-1 The attribute width of the element rect is required org.apache.batik.bridge.BridgeException: file:/C:/jboss-4.0.4.CR2/bin:-1 The attribute width of the element rect is required at org.apache.batik.bridge.SVGRectElementBridge.buildShape(Unknown Source) at org.apache.batik.bridge.SVGShapeElementBridge.createGraphicsNode(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source) at org.apache.batik.bridge.GVTBuilder.build(Unknown Source) at org.apache.fop.render.pdf.PDFSVGHandler.renderSVGDocument(PDFSVGHandler.java:181) at org.apache.fop.render.pdf.PDFSVGHandler.handleXML(PDFSVGHandler.java:80) at org.apache.fop.render.AbstractRenderer.renderXML(AbstractRenderer.java:843) at org.apache.fop.render.pdf.PDFRenderer.renderDocument(PDFRenderer.java:1475) at org.apache.fop.render.pdf.PDFRenderer.renderForeignObject(PDFRenderer.java:1440) at org.apache.fop.render.AbstractRenderer.renderViewport(AbstractRenderer.java:743) at org.apache.fop.render.AbstractPathOrientedRenderer.renderViewport(AbstractPathOrientedRenderer.java:551) at org.apache.fop.render.AbstractRenderer.renderInlineArea(AbstractRenderer.java:634) at org.apache.fop.render.AbstractRenderer.renderLineArea(AbstractRenderer.java:609) at org.apache.fop.render.pdf.PDFRenderer.renderLineArea(PDFRenderer.java:1017) at org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:535) at org.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:585) at org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:525) at org.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:585) at org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:525) at org.apache.fop.render.AbstractRenderer.renderBlock(AbstractRenderer.java:585) at org.apache.fop.render.AbstractRenderer.renderBlocks(AbstractRenderer.java:525) at org.apache.fop.render.AbstractRenderer.renderFlow(AbstractRenderer.java:430) at org.apache.fop.render.AbstractRenderer.renderMainReference(AbstractRenderer.java:409) at org.apache.fop.render.AbstractRenderer.renderBodyRegion(AbstractRenderer.java:343) at org.apache.fop.render.AbstractRenderer.renderRegionViewport(AbstractRenderer.java:288) at org.apache.fop.render.AbstractRenderer.renderPageAreas(AbstractRenderer.java:261) at org.apache.fop.render.AbstractRenderer.renderPage(AbstractRenderer.java:235) at org.apache.fop.render.pdf.PDFRenderer.renderPage(PDFRenderer.java:648) at org.apache.fop.area.RenderPagesModel.addPage(RenderPagesModel.java:119) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.finishPage(PageSequenceLayoutManager.java:703) at org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:154) at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:320) at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:147) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:357) at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:193) at org.apache.cocoon.xml.AbstractXMLPipe.endElement(AbstractXMLPipe.java:111) at net.sf.saxon.event.ContentHandlerProxy.endElement(ContentHandlerProxy.java:286) at net.sf.saxon.event.ProxyReceiver.endElement(ProxyReceiver.java:172) at net.sf.saxon.event.NamespaceReducer.endElement(NamespaceReducer.java:204) at net.sf.saxon.event.ComplexContentOutputter.endElement(ComplexContentOutputter.java:389) at net.sf.saxon.instruct.ElementCreator.processLeavingTail(ElementCreator.java:165) at net.sf.saxon.instruct.Choose.processLeavingTail(Choose.java:283) at net.sf.saxon.instruct.Choose.processLeavingTail(Choose.java:283) at net.sf.saxon.instruct.Template.expand(Template.java:95) at
