You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Richard Kennard <ri...@kennardconsulting.com> on 2006/04/30 05:29:06 UTC
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 net.sf.saxon.instruct.Template.processLeavingTail(Template.java:79)
at
net.sf.saxon.instruct.ApplyTemplates.applyTemplates(ApplyTemplates.java:290)
at net.sf.saxon.instruct.ApplyTemplates.apply(ApplyTemplates.java:169)
at
net.sf.saxon.instruct.ApplyTemplates.processLeavingTail(ApplyTemplates.java:133)
at net.sf.saxon.instruct.Block.processLeavingTail(Block.java:330)
at net.sf.saxon.instruct.Instruction.process(Instruction.java:90)
at
net.sf.saxon.instruct.ElementCreator.processLeavingTail(ElementCreator.java:162)
at net.sf.saxon.instruct.Choose.processLeavingTail(Choose.java:283)
at net.sf.saxon.instruct.Template.expand(Template.java:95)
at net.sf.saxon.instruct.Template.processLeavingTail(Template.java:79)
at
net.sf.saxon.instruct.ApplyTemplates.applyTemplates(ApplyTemplates.java:290)
at
net.sf.saxon.instruct.ApplyTemplates.defaultAction(ApplyTemplates.java:325)
at
net.sf.saxon.instruct.ApplyTemplates.applyTemplates(ApplyTemplates.java:283)
at net.sf.saxon.Controller.transformDocument(Controller.java:1406)
at
net.sf.saxon.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:125)
at
org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:55)
at
org.apache.cocoon.transformation.TraxTransformer.endDocument(TraxTransformer.java:585)
at
net.sf.saxon.event.ContentHandlerProxy.close(ContentHandlerProxy.java:167)
at net.sf.saxon.event.ProxyReceiver.close(ProxyReceiver.java:88)
at
net.sf.saxon.event.ComplexContentOutputter.close(ComplexContentOutputter.java:454)
at net.sf.saxon.Controller.transformDocument(Controller.java:1432)
at
net.sf.saxon.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:125)
at
org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:55)
at
org.apache.cocoon.transformation.TraxTransformer.endDocument(TraxTransformer.java:585)
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Posted by Richard Kennard <ri...@kennardconsulting.com>.
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=detail&aid=1483350&group_id=29872&atid=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: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
> .
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Posted by Florent Georges <da...@yahoo.fr>.
Jeremias Maerki wrote:
Hi
> Bug is filed against SAXON including patch:
>
http://sourceforge.net/tracker/index.php?func=detail&aid=1483350&group_id=29872&atid=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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Bug is filed against SAXON including patch:
http://sourceforge.net/tracker/index.php?func=detail&aid=1483350&group_id=29872&atid=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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Posted by Florent Georges <da...@yahoo.fr>.
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Posted by Florent Georges <da...@yahoo.fr>.
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.
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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. If you can, you can use the latest
Xalan-J release in the meantime, which doesn't have this bug. Older
Xalan-J releases have a similar bug.
On 30.04.2006 09:39:07 Jeremias Maerki wrote:
> 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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Posted by Clay Leeds <we...@mac.com>.
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,
>
> Richard.
>
> THE STACK TRACE:
Clay Leeds
webmaestro@mac.com
My religion is simple. My religion is kindness.
-- HH Dalai Lama of Tibet
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org