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.

There is no svg:link element.  The svg:a element is used to specify a link.

It would help to see the xsl file to which your refer to further understand what is going on.

Best Regards,

Jonathan

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

I think there may be another jar, probably available from hibernate.org, which has the driver.  I don't know for certain, but I think that is how things work.  Note "org.hibernate.dialect" as the prefix of the URL means that hibernate has and owns the driver, including its support.

Just my two cents,

Jonathan

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.

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

 

If the question is, can XSLT process JavaScript, the answer is no.  XSLT processors are not able to process JavaScript.  If the question is can XSLT include JavaScript as character data by using appropriate escapes the answer is yes.