RE: xercesImpl dependency

2015-06-25 Thread Jan Tosovsky
On 2015-06-25 Andreas Delmelle wrote:
> > On 2015-06-25 Luis Bernardo wrote:
> >
> > Does anyone know why we have the xercesImpl jar in the lib 
> > directory?
> 
> Good question... I am not 100% certain, but I think this was done
> mostly for reasons of convenience of the end users. 
> 

For processing of XIncludes?
http://www.sagehill.net/docbookxsl/Xinclude.html

But this is not really a FOP duty...

Jan
<>

Re: xercesImpl dependency

2015-06-25 Thread Clay Leeds


>> Can this jar be removed?
> 
> I would say so, yes, unless the policy is to keep it for the sake of 
> supporting old JVMs (1.3 and earlier?).

IIRC, FOPs Run page, Java 1.5 and above is required to rub FOP 2.0:

http://xmlgraphics.staging.apache.org/fop/2.0/running.html
System Requirements

The following software must be installed:

Java 1.6 or later Runtime Environment.

Re: xercesImpl dependency

2015-06-25 Thread Andreas Delmelle
Hi Luis

> On 25 Jun 2015, at 16:39, Luis Bernardo  wrote:
> 
> 
> Does anyone know why we have the xercesImpl jar in the lib directory? 
> Apparently we don't need it to compile and run the unit tests. This is unlike 
> xalan which we need for the unit tests.

Good question... I am not 100% certain, but I think this was done mostly for 
reasons of convenience of the end users. Recall that, in the past, way back in 
the dark ages, there was a time when an XML parser was not yet a standard part 
of most JRE and JDK bundles. Just in case you were running FOP on an older JVM 
which did not come with its own parser, FOP bundled its own.

Something like that? If anyone knows this to be wrong, feel free to correct.

> 
> Can this jar be removed?
> 

I would say so, yes, unless the policy is to keep it for the sake of supporting 
old JVMs (1.3 and earlier?).


KR

Andreas




xercesImpl dependency

2015-06-25 Thread Luis Bernardo


Does anyone know why we have the xercesImpl jar in the lib directory? 
Apparently we don't need it to compile and run the unit tests. This is 
unlike xalan which we need for the unit tests.


Can this jar be removed?



[jira] [Commented] (FOP-2485) Xalan dependency should be updated

2015-06-25 Thread Jochen Kemnade (JIRA)

[ 
https://issues.apache.org/jira/browse/FOP-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14601246#comment-14601246
 ] 

Jochen Kemnade commented on FOP-2485:
-

Looks like it: http://search.maven.org/#artifactdetails|xalan|xalan|2.7.2|jar

> Xalan dependency should be updated
> --
>
> Key: FOP-2485
> URL: https://issues.apache.org/jira/browse/FOP-2485
> Project: FOP
>  Issue Type: Wish
>Affects Versions: 2.0
>Reporter: Jochen Kemnade
>
> Fop 2.0 depends on Xalan 2.7.0 via {{batik-dom}}. Xalan 2.7.0 pulls in 
> {{xml-apis:2.0.2}}. That one overrides {{xml-apis:1.3.04}}, which is actually 
> *newer*. (see 
> http://swordsystems.com/2011/06/29/xerces-and-xml-api-dependency-hell/). 
> Updating Xalan to 2.7.2 fixes the issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (FOP-2485) Xalan dependency should be updated

2015-06-25 Thread Luis Bernardo (JIRA)

[ 
https://issues.apache.org/jira/browse/FOP-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14601233#comment-14601233
 ] 

Luis Bernardo commented on FOP-2485:


It seems xalan 2.7.2 needs xercesImpl 2.9.1 (which then pulls xml-apis 1.3.04). 
So we need to update xercesImpl to 2.9.1 too. Do you agree? 

> Xalan dependency should be updated
> --
>
> Key: FOP-2485
> URL: https://issues.apache.org/jira/browse/FOP-2485
> Project: FOP
>  Issue Type: Wish
>Affects Versions: 2.0
>Reporter: Jochen Kemnade
>
> Fop 2.0 depends on Xalan 2.7.0 via {{batik-dom}}. Xalan 2.7.0 pulls in 
> {{xml-apis:2.0.2}}. That one overrides {{xml-apis:1.3.04}}, which is actually 
> *newer*. (see 
> http://swordsystems.com/2011/06/29/xerces-and-xml-api-dependency-hell/). 
> Updating Xalan to 2.7.2 fixes the issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (FOP-2489) An SVG file using markers is not rendered by FOP 2.0

2015-06-25 Thread Luis Bernardo (JIRA)

 [ 
https://issues.apache.org/jira/browse/FOP-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luis Bernardo resolved FOP-2489.

   Resolution: Fixed
Fix Version/s: trunk

Fixed on the Batik side instead: 
http://svn.apache.org/viewvc?view=revision&revision=1687506 and 
http://svn.apache.org/viewvc?view=revision&revision=1687510.

> An SVG file using markers is not rendered by FOP 2.0
> 
>
> Key: FOP-2489
> URL: https://issues.apache.org/jira/browse/FOP-2489
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: Linux; Java 1.6 64-bit (not relevant).
>Reporter: Hussein Shafie
> Fix For: trunk
>
> Attachments: EXPECTED__doc.pdf, __doc.fo, __doc.pdf, header_layout.svg
>
>
> h4. An SVG file using markers is not rendered by FOP 2.0
> How to reproduce the problem (see attached files)
> fop -fo __doc.fo -pdf __doc.pdf
> Running this command reports:
> {noformat}
> SEVERE: SVG graphic could not be built. Reason: 
> org.apache.batik.bridge.BridgeException: 
> resources/resources/header_layout.svg (No such file or directory)
> org.apache.batik.bridge.BridgeException: 
> resources/resources/header_layout.svg (No such file or directory)
> at org.apache.batik.bridge.BridgeContext.getReferencedNode(Unknown 
> Source)
> at org.apache.batik.bridge.BridgeContext.getReferencedElement(Unknown 
> Source)
> at org.apache.batik.bridge.PaintServer.convertMarker(Unknown Source)
> at org.apache.batik.bridge.PaintServer.convertMarkers(Unknown Source)
> at 
> org.apache.batik.bridge.SVGDecoratedShapeElementBridge.createMarkerPainter(Unknown
>  Source)
> at 
> org.apache.batik.bridge.SVGDecoratedShapeElementBridge.createShapePainter(Unknown
>  Source)
> at 
> org.apache.batik.bridge.SVGShapeElementBridge.buildGraphicsNode(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.PDFImageHandlerSVG.handleImage(PDFImageHandlerSVG.java:103)
> at 
> org.apache.fop.render.intermediate.AbstractIFPainter.drawImage(AbstractIFPainter.java:249)
> at 
> org.apache.fop.render.intermediate.AbstractIFPainter.drawImage(AbstractIFPainter.java:205)
> at 
> org.apache.fop.render.intermediate.AbstractIFPainter.drawImageUsingImageHandler(AbstractIFPainter.java:170)
> at 
> org.apache.fop.render.intermediate.AbstractIFPainter.drawImageUsingURI(AbstractIFPainter.java:292)
> at org.apache.fop.render.pdf.PDFPainter.drawImage(PDFPainter.java:173)
> at 
> org.apache.fop.render.intermediate.IFRenderer.drawImage(IFRenderer.java:1295)
> at 
> org.apache.fop.render.intermediate.IFRenderer.renderImage(IFRenderer.java:1282)
> at 
> org.apache.fop.render.AbstractRenderer.renderInlineViewport(AbstractRenderer.java:858)
> {noformat}
> The expected result is EXPECTED__doc.pdf
> My workaround:
> To resolve URLs such as "marker-start:url(#TriangleInM)", Batik 1.8 needs 
> to know the URL of the SVG document it processes.
> Therefore in org/apache/fop/apps/FOUserAgent.java, I've replaced:
> {noformat}
> public StreamSource resolveURI(String uri) {
> // TODO: What do we want to do when resources aren't found??? We also 
> need to remove this
> // method entirely
> try {
> // Have to do this so we can resolve data URIs
> StreamSource src = new 
> StreamSource(resourceResolver.getResource(uri));
> src.setSystemId(uri);
> return src;
> } catch (URISyntaxException use) {
> return null;
> } catch (IOException ioe) {
> return null;
> }
> }
> {noformat}
> by:
> {noformat}
> public StreamSource resolveURI(String uri) {
> // TODO: What do we want to do when resources aren't found??? We also 
> need to remove this
> // method entirely
> try {
> // Have to do this so we can resolve data URIs
> StreamSource src = new 
> StreamSource(resourceResolver.getResource(uri));
> // A systemId is always expected to be absolute.
> // Anyway, without this, SVG files using markers 
> // (e.g. marker-start:url(#TriangleInM)) cannot be rendered.
> if (!uri.startsWith("dat

[jira] [Resolved] (FOP-2490) Embedded SVG 1.2 not supported by FOP 2.0

2015-06-25 Thread Luis Bernardo (JIRA)

 [ 
https://issues.apache.org/jira/browse/FOP-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luis Bernardo resolved FOP-2490.

   Resolution: Fixed
Fix Version/s: trunk

Fix applied in http://svn.apache.org/viewvc?view=revision&revision=1687458.

> Embedded SVG 1.2 not supported by FOP 2.0
> -
>
> Key: FOP-2490
> URL: https://issues.apache.org/jira/browse/FOP-2490
> Project: FOP
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: Linux, Java 1.6 64-bit (not relevant)
>Reporter: Hussein Shafie
> Fix For: trunk
>
> Attachments: EXPECTED__doc.pdf, __doc.fo
>
>
> h4. Embedded SVG 1.2 not supported by FOP 2.0
> How to reproduce the problem (see attached files)
> fop -fo __doc.fo -pdf __doc.pdf
> Running this command fails with:
> {noformat}
> org.w3c.dom.DOMException: The current document is unable to create an element 
> of the requested type (namespace: http://www.w3.org/2000/svg, name: 
> svg:flowRoot).
> at org.apache.batik.dom.AbstractNode.createDOMException(Unknown 
> Source)
> at 
> org.apache.batik.anim.dom.SVGDOMImplementation.createElementNS(Unknown Source)
> at org.apache.batik.anim.dom.SVGOMDocument.createElementNS(Unknown 
> Source)
> at org.apache.xml.utils.DOMBuilder.startElement(DOMBuilder.java:324)
> at 
> org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072)
> at 
> org.apache.fop.util.DelegatingContentHandler.startElement(DelegatingContentHandler.java:185)
> at 
> org.apache.fop.fo.extensions.svg.SVGDOMContentHandlerFactory$Handler.startElement(SVGDOMContentHandlerFactory.java:137)
> at 
> org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:179)
> at 
> org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072)
> {noformat}
> The expected result is EXPECTED__doc.pdf
> My workaround:
> In org/apache/fop/fo/extensions/svg/SVGDOMContentHandlerFactory.java, 
> I've replaced:
> {noformat}
> private DOMImplementation getDOMImplementation(String ver) {
> //TODO It would be great if Batik provided this method as static 
> helper method.
> if (ver == null || ver.length() == 0
> || ver.equals("1.0") || ver.equals("1.1")) {
> return SVGDOMImplementation.getDOMImplementation();
> } else if (ver.equals("1.2")) {
> try {
> Class clazz = Class.forName(
> 
> "org.apache.batik.dom.svg12.SVG12DOMImplementation");
> return (DOMImplementation)clazz.getMethod(
> "getDOMImplementation", 
> (Class[])null).invoke(null, (Object[])null);
> } catch (Exception e) {
> return SVGDOMImplementation.getDOMImplementation();
> }
> }
> throw new RuntimeException("Unsupport SVG version '" + ver + "'");
> }
> {noformat}
> by:
> {noformat}
> import org.apache.batik.anim.dom.SVG12DOMImplementation;
> private DOMImplementation getDOMImplementation(String ver) {
> //TODO It would be great if Batik provided this method as static 
> helper method.
> if (ver == null || ver.length() == 0
> || ver.equals("1.0") || ver.equals("1.1")) {
> return SVGDOMImplementation.getDOMImplementation();
> } else if (ver.equals("1.2")) {
> return SVG12DOMImplementation.getDOMImplementation();
> }
> throw new RuntimeException("Unsupport SVG version '" + ver + "'");
> }
> {noformat}
> org.apache.batik.anim.dom.SVG12DOMImplementation is always 
> included in Batik-1.8-all.jar. Even if you prefer to keep Class.forName(), 
> please note that org.apache.batik.dom.svg12.SVG12DOMImplementation 
> no longer exists in Batik 1.8.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)