[jira] [Created] (FOP-2362) Rendering AFP extension to intermediate format throws NullPointerException
Hauke Haastert created FOP-2362: --- Summary: Rendering AFP extension to intermediate format throws NullPointerException Key: FOP-2362 URL: https://issues.apache.org/jira/browse/FOP-2362 Project: Fop Issue Type: Bug Components: general Affects Versions: 1.1 Environment: Apple OSX 10.9.2 / Java version 1.7.0_11 Reporter: Hauke Haastert When rendering an XSL-FO file that contains an AFP-Extension to the intermediate format while using Saxon as XSLT transformer, a NullPointerException is thrown. Steps to reproduce: 1. Download and unpack the FOP 1.1 binary release. 2. Change into the root directory fop-1.1 of the release 3. Download Saxon HE from http://repo1.maven.org/maven2/net/sf/saxon/Saxon-HE/9.4/Saxon-HE-9.4.jar and copy the file to the lib directory of the FOP 1.1 release 4. Edit the file fop that is located in the root directory of the release and add the following JVM parameter to the java_exec_args: -Djavax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl The line should now look like: java_exec_args=-Djava.awt.headless=true -Djavax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl 5. Download the attached files test.fo and simple.xsl and run the following fop command: fop -fo test.fo -out application/X-fop-intermediate-format test.if.xml Actual Results: Application throws NullPointerException: java.lang.NullPointerException at net.sf.saxon.event.ReceivingContentHandler.getNodeName(ReceivingContentHandler.java:391) at net.sf.saxon.event.ReceivingContentHandler.startElement(ReceivingContentHandler.java:316) at org.apache.fop.util.DelegatingContentHandler.startElement(DelegatingContentHandler.java:185) at org.apache.fop.render.afp.extensions.AFPPageSetup.toSAX(AFPPageSetup.java:125) at org.apache.fop.render.intermediate.IFSerializer.handleExtensionObject(IFSerializer.java:680) Expected Results: Application should render IF from FO Additional Information: In the toSAX method of the class org.apache.fop.render.afp.extensions.AFPPageSetup the method addAttribute of the class org.xml.sax.helpers.AttributesImpl is called with null as first argument. Due to the APIDOC of the class org.xml.sax.helpers.AttributesImpl the first argument must either be the namespace or an empty string, but not null: uri - The Namespace URI, or the empty string if none is available or Namespace processing is not being performed. When changing the parameter value to an empty string, no NullPointerException is thrown anymore. The same problem exists in other classes in the package org.apache.fop.render.afp.extensions, so I added a diff file for the complete package (extensions.diff). The exception is not thrown when using Xalan as XSL transformer. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2362) Rendering AFP extension to intermediate format throws NullPointerException
[ https://issues.apache.org/jira/browse/FOP-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hauke Haastert updated FOP-2362: Attachment: extensions.diff test.fo simple.xsl Rendering AFP extension to intermediate format throws NullPointerException -- Key: FOP-2362 URL: https://issues.apache.org/jira/browse/FOP-2362 Project: Fop Issue Type: Bug Components: general Affects Versions: 1.1 Environment: Apple OSX 10.9.2 / Java version 1.7.0_11 Reporter: Hauke Haastert Attachments: extensions.diff, simple.xsl, test.fo When rendering an XSL-FO file that contains an AFP-Extension to the intermediate format while using Saxon as XSLT transformer, a NullPointerException is thrown. Steps to reproduce: 1. Download and unpack the FOP 1.1 binary release. 2. Change into the root directory fop-1.1 of the release 3. Download Saxon HE from http://repo1.maven.org/maven2/net/sf/saxon/Saxon-HE/9.4/Saxon-HE-9.4.jar and copy the file to the lib directory of the FOP 1.1 release 4. Edit the file fop that is located in the root directory of the release and add the following JVM parameter to the java_exec_args: -Djavax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl The line should now look like: java_exec_args=-Djava.awt.headless=true -Djavax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl 5. Download the attached files test.fo and simple.xsl and run the following fop command: fop -fo test.fo -out application/X-fop-intermediate-format test.if.xml Actual Results: Application throws NullPointerException: java.lang.NullPointerException at net.sf.saxon.event.ReceivingContentHandler.getNodeName(ReceivingContentHandler.java:391) at net.sf.saxon.event.ReceivingContentHandler.startElement(ReceivingContentHandler.java:316) at org.apache.fop.util.DelegatingContentHandler.startElement(DelegatingContentHandler.java:185) at org.apache.fop.render.afp.extensions.AFPPageSetup.toSAX(AFPPageSetup.java:125) at org.apache.fop.render.intermediate.IFSerializer.handleExtensionObject(IFSerializer.java:680) Expected Results: Application should render IF from FO Additional Information: In the toSAX method of the class org.apache.fop.render.afp.extensions.AFPPageSetup the method addAttribute of the class org.xml.sax.helpers.AttributesImpl is called with null as first argument. Due to the APIDOC of the class org.xml.sax.helpers.AttributesImpl the first argument must either be the namespace or an empty string, but not null: uri - The Namespace URI, or the empty string if none is available or Namespace processing is not being performed. When changing the parameter value to an empty string, no NullPointerException is thrown anymore. The same problem exists in other classes in the package org.apache.fop.render.afp.extensions, so I added a diff file for the complete package (extensions.diff). The exception is not thrown when using Xalan as XSL transformer. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FOP-2293) Whitespace management extension
[ https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seifeddine Dridi updated FOP-2293: -- Attachment: FO_multi-switch_best-fit_ext_rev11.patch Hello, I added support for multiple dynamic contents at the same page, this was fairly easy to add. I also merged class BestFitUtils into MultiSwitchLayoutManager as suggested by Vincent, and included a short documentation which might be useful as a quick introduction... There is nothing to be added for now, so I'd like to propose integrating this extension to trunk. Any objections? Thanks Seifeddine Whitespace management extension --- Key: FOP-2293 URL: https://issues.apache.org/jira/browse/FOP-2293 Project: Fop Issue Type: New Feature Components: general Affects Versions: trunk Reporter: Seifeddine Dridi Priority: Minor Labels: XSL-FO Fix For: trunk Attachments: FO_multi-switch_best-fit_ext_rev10.patch, FO_multi-switch_best-fit_ext_rev11.patch, FO_multi-switch_best-fit_ext_rev2.patch, FO_multi-switch_best-fit_ext_rev3.patch, FO_multi-switch_best-fit_ext_rev4.patch, FO_multi-switch_best-fit_ext_rev5.patch, FO_multi-switch_best-fit_ext_rev6.patch, FO_multi-switch_best-fit_ext_rev7.patch, FO_multi-switch_best-fit_ext_rev8.patch, FO_multi-switch_best-fit_ext_rev9.patch, FO_multi-switch_test.fo, FO_multi-switch_with_best-fit_extension.patch, bestfit.fo, doc.pdf, empty-last-page.fo, multi-switch-testcases.zip, multi-switch_bestfit.fo, multiple-feasible-nodes.fo, patch-rev1.1.patch, patch-rev1.patch, patch-rev2.patch, patch.patch, two-valid-variants.fo I have been working on an extension for whitespace management, similar to what's described here: http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement The logic of the extension is very simple: the user defines a set of alternatives that he wishes to insert at the end of a page, then if there is enough space left, FOP will pick the alternative that best matches the user's selection criteria (first fit, smallest fit, biggest fit). This is my first work on FOP and it took me almost 2 months to reach this stage in development. But it's not the end of course, so I'm relying on your feedback to improve it. Thank you -- This message was sent by Atlassian JIRA (v6.2#6252)
RE: DITA-OT and FOP
On 2014-03-30 Ron Wheeler wrote: On 30/03/2014 5:19 PM, Jan Tosovsky wrote: I personally think it would be much easier to attract developers to create a completely new paged media CSS engine than to add several niche XSL-FO features into FOP. But when mentioning the new engine, I don't think it is a good idea. Sooner or later these CSS features will be adopted by major browsers and in that time it won't be necessary to produce PDFs at all :-) The supposes that paper documentation will disappear. There are regulatory issues, industry practices, etc. that need to change. There will still be face to face meetings where someone wants to hand a piece of paper to someone for the next few years. Slightly off-topic, but a short comment... I didn't mean paper-less way, but http://en.wikipedia.org/wiki/MHTML way, where all dependencies are embedded in a single file which you can open in a browser (it acts as PDF, but it is HTML/CSS based). Jan
Re: DITA-OT and FOP
On 01/04/2014 1:33 PM, Jan Tosovsky wrote: On 2014-03-30 Ron Wheeler wrote: On 30/03/2014 5:19 PM, Jan Tosovsky wrote: I personally think it would be much easier to attract developers to create a completely new paged media CSS engine than to add several niche XSL-FO features into FOP. But when mentioning the new engine, I don't think it is a good idea. Sooner or later these CSS features will be adopted by major browsers and in that time it won't be necessary to produce PDFs at all :-) The supposes that paper documentation will disappear. There are regulatory issues, industry practices, etc. that need to change. There will still be face to face meetings where someone wants to hand a piece of paper to someone for the next few years. Slightly off-topic, but a short comment... I didn't mean paper-less way, but http://en.wikipedia.org/wiki/MHTML way, where all dependencies are embedded in a single file which you can open in a browser (it acts as PDF, but it is HTML/CSS based). Jan Good point. PDF is not the only form that moves nicely to paper. Issues like signatures and version control are still open issues for me. DITA is already ahead in this area with a single set of source documents being able to be processed into PDF, HTML and other output formats. My feeling is that bringing this standard XML source document format with its editing tools into XMLGraphics will accelerate the development of better processes for producing these new formats and put the XMLGraphics tools into the mainstream of document production in for organizations that want a process that is supported by standards and a strong technical open source organization such as Apache. Ron -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
