New post
AllAccepted answers
Jonathan Levinson · Jun 18, 2020

Hi Lucas,

This looks to me like a bug in InterSystems FO generation.  You should contact the InterSystems WRC.

I see the following code in the FO:

<svg:link type="text/css" rel="stylesheet" id="dark-mode-general-link"  />
<svg:link type="text/css" rel="stylesheet" id="dark-mode-custom-link"  />
<!--  SVGStyle: %ZEN.SVGComponent.svgPage  -->
<!--  SVGStyle: %ZEN.Component.page  -->
<!--  SVGStyle: %DeepSee.UserPortal.standardPage  -->
<!--  SVGStyle: %DeepSee.UserPortal.DashboardViewer  -->
<!--  SVGDef: %ZEN.SVGComponent.svgPage  -->

While the comments are fine, the svg:link element should not be there.  Something else should be there instead.

HTML has a link elment and it looks like svg:link is supposed to be an HTML element, or maybe the generation for HTML intruded into the generation for PDF.

Jonathan Levinson · Sep 9, 2019

I think most XSLT implementations read the whole XML input file into memory before beginning to process it.  You need to test if an XSLT approach works with files of the size with which you deal.  Of course, you also need to test how files of a particular size work in the particular machine environment which is running the application.  There is not a one size fits all solution for parsing XML files using XSLT when memory issues are a concern.  I believe ISC supports a SAX parser. SAX parsers put less burdens on memory than XLST.

SAX is described here: https://docs.oracle.com/javase/tutorial/jaxp/intro/simple.html

Jonathan Levinson · Jun 13, 2019

In the namespace in which you are running the rendering, are you able to run the following: DO $SYSTEM.Status.DisplayError(%objlasterror) This might tell us more about the error you are encountering. Also, here is another approach, in the namespace follow instructions in the following link. https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY... In your namespace please set the following global.

 Set ^CacheTemp.ZEN("DebugZen","NoDelete")=1

In the intermediate file area /mgr/Temp you can examine the xml, xsl, and error messages from invoking Java. These files provide important clues in trouble shooting the kind of problem you are having. For instance, you can answer the following question: is the xml "well formed" xml. Also is the xsl "well formed" xsl. The files with extension .txt provide important information about the java invocation.

Jonathan Levinson · Apr 23, 2019

The ZEN Reports documentation has a helpful trouble shooting section.

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...

I have found it helpful to save to <CacheInstall>/mgr/Temp all the intermediate files, the error messages from invoking FOP, the .xsl files, the .fo files, if any, and the PDF files.

The easiest way to do this is to set in the namespace from which the reports are being run, the following global: 

Set ^CacheTemp.ZEN("DebugZen","NoDelete")=1

There are three common sources of ZEN Report errors:

1) The ObjectScript code for invoking the report has errors.  Very often these errors can be found by examining %objlasterror, and if not, standard Object Script debugging techniques will often show the problem.

2) The generated xml or xsl or fo are invalid.  If you have a decent parsing editor such as XMLSpy Professional or Oxygen Editor, you can open each of the generated files in turn, with the appropriate editor.  If these editors find a problem such as an invalid tag or attribute, one can use FindInFiles on the reports searching for the names or attributes that are part of the error the editor detected to find the report in error, and the area in the report that is erroneous.  Since intermediate fo files are not always generated, and since fo files can be invalid in terms of the XSL-FO 1.1 standard, one sometimes needs to generate the fo files using the instructions in the ZEN Reports User Guide.

3) If all the files are valid, then it is still possible that FOP has emitted a Java exception stack for some reason.  These stacks can be seen by lookin at the .txt files generated in <CacheInstall>/mgr/Temp.

I hope this helps.

Jonathan Levinson

Jonathan Levinson · Aug 16, 2016

You just have to add the right library to fop\lib.  I believe that is the only configuration required.

The JAI Image I/O Tools is not redistributable which is why it was not put in fop\lib.

You'll have to dig for the right JAI library to add to your lib area.  

The following link might work, but I haven't tried it.

http://www.oracle.com/technetwork/java/install-jai-imageio-1-0-01-139659...

Jonathan Levinson · Aug 16, 2016

You just have to add the right library to fop\lib.  That is the only configuration required.

The JAI Image I/O Tools is not redistributable which is why it was not put in fop\lib.

You'll have to dig for the right JAI library to add to your lib area.  

The following link might work, but I haven't tried it.

http://www.oracle.com/technetwork/java/install-jai-imageio-1-0-01-139659...