# PDF-Generating doesn't work with saxon

asked Dec 2, 2016 in Bug

Hey there,

we're using plantuml in an encapsulated Cygwin environment incl. Java and all necessary jar files. Because it is not that easy to use Java inside Cygwin (because of the mix of unix and Windows-like paths) we decided to put all our jar files into the classpath (env variable).

We're using saxon9 for other purposes, so we added this jar file also to the classpath variable.

Now my problem:

Running plantuml by calling it via java -jar plantuml.jar will use xalan for transformation. The pdf file will be generated as usual. See here: http://pastebin.com/cNmxBc0g

Calling plantuml via classname java net.sourceforge.plantuml.Run will use saxon. A pdf file with 0kb (empty, blank file) is generated. See here: http://pastebin.com/rdnheQSc

I compared both logs and found out that the difference seems to be the xalan/saxon usage. Is there a parameter to switch between them? It seems to me that saxon is called, because I put the jar file into the classpath.

EDIT: If I remove the saxon.jar from the classpath, plantuml is using xalan and everything will be fine.

jar Files:

avalon-framework-4.2.0.jar
batik-all-1.7.jar
commons-io-1.3.1.jar
commons-logging-1.0.4.jar
Diagram_modulename1.pdf
Diagram_modulename1.uml
diagramStyle.txt
fop.jar
org.eclipse.jgit-3.1.0.201310021548-r.jar
plantuml.jar
xml-apis-ext-1.3.04.jar
xmlgraphics-commons-1.4.jar

answered Dec 2, 2016 by (289,720 points)
Unfortunatly, the PDF generation is done by batik and we have very little control on this.

The full code is here https://github.com/plantuml/plantuml/blob/master/src/net/sourceforge/plantuml/pdf/PdfConverter.java

We are just converting the SVG generated file by PlantUML to PDF using this convertion method.

However, I think the issue come from the SVG generation and not the PDF itself.

Could you confirm that by trying to generate SVG files, first with saxon, then with xalan to confirm this ?

My guess is that SVG be generated with xalan, but not with saxon.

If it's the case, there is hope : I think we could add a parameter to force use of xalan

EDIT (for future reference) http://stackoverflow.com/questions/2968190/how-to-select-saxon-transformerfactory-in-java
commented Dec 3, 2016 by (340 points)
I'll have a look on Monday :)
answered Dec 5, 2016 by (340 points)
edited Dec 5, 2016

Ok, I tried generating svg in both ways and both are working for me.

1)

$java net.sourceforge.plantuml.Run myfile -tsvg -verbose (0.000 - 15 Mo) 14 Mo - PlantUML Version 8046 (0.053 - 15 Mo) 12 Mo - GraphicsEnvironment.isHeadless() false (0.058 - 15 Mo) 12 Mo - Setting current dir: . (0.058 - 15 Mo) 12 Mo - Setting current dir: <<<CUT>>>\App\Runtime\cygwin\opt\plantuml\bin (0.059 - 15 Mo) 12 Mo - Using default charset (0.065 - 15 Mo) 12 Mo - Setting current dir: <<<CUT>>>\App\Runtime\cygwin\opt\plantuml\bin (0.069 - 15 Mo) 11 Mo - Using default charset (0.072 - 15 Mo) 11 Mo - Using default charset (0.073 - 15 Mo) 11 Mo - Setting current dir: <<<CUT>>>\App\Runtime\Cygwin\opt\plantuml\bin (0.074 - 15 Mo) 11 Mo - Setting current dir: <<<CUT>>>\App\Runtime\cygwin\opt\plantuml\bin (0.083 - 15 Mo) 13 Mo - Setting current dir: <<<CUT>>>\App\Runtime\cygwin\opt\plantuml\bin (0.083 - 15 Mo) 13 Mo - Reading file: fm_smgw_prot.class (0.084 - 15 Mo) 13 Mo - name from block=null (0.266 - 15 Mo) 5 Mo - Creating file: <<<CUT>>>>\App\Runtime\cygwin\opt\plantuml\bin\fm_smgw_prot.svg (1.184 - 15 Mo) 5 Mo - Starting Graphviz process [<<<CUT>>>\App\Runtime\cygwin\bin\dot.exe, -Tsvg] (1.185 - 15 Mo) 5 Mo - DotString size: 1661 (1.253 - 15 Mo) 5 Mo - Ending process ok (1.253 - 15 Mo) 5 Mo - Ending Graphviz process (1.906 - 15 Mo) 7 Mo - TransformerFactory=class com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl (1.909 - 15 Mo) 7 Mo - Transformer=class com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl (1.951 - 15 Mo) 6 Mo - Number of image(s): 1 2)$ java -jar plantuml.jar fm_smgw_prot.class -tsvg -verbose
(0.000 - 15 Mo) 14 Mo - PlantUML Version 8046
(0.043 - 15 Mo) 12 Mo - GraphicsEnvironment.isHeadless() false
(0.048 - 15 Mo) 12 Mo - Setting current dir: .
(0.048 - 15 Mo) 12 Mo - Setting current dir: <<<CUT>>>\App\Runtime\cygwin\opt\plantuml\bin
(0.049 - 15 Mo) 12 Mo - Using default charset
(0.052 - 15 Mo) 12 Mo - Setting current dir: <<<CUT>>>\App\Runtime\cygwin\opt\plantuml\bin
(0.056 - 15 Mo) 12 Mo - Using default charset
(0.057 - 15 Mo) 12 Mo - Using default charset
(0.058 - 15 Mo) 12 Mo - Setting current dir: <<<CUT>>>\App\Runtime\Cygwin\opt\plantuml\bin
(0.059 - 15 Mo) 11 Mo - Setting current dir: <<<CUT>>>\App\Runtime\cygwin\opt\plantuml\bin
(0.068 - 15 Mo) 13 Mo - Setting current dir: <<<CUT>>>\App\Runtime\cygwin\opt\plantuml\bin
(0.069 - 15 Mo) 13 Mo - Reading file: fm_smgw_prot.class
(0.069 - 15 Mo) 13 Mo - name from block=null
(0.244 - 15 Mo) 7 Mo - Creating file: <<<CUT>>>\App\Runtime\cygwin\opt\plantuml\bin\fm_smgw_prot.svg
(0.521 - 15 Mo) 7 Mo - Starting Graphviz process [<<<CUT>>>\App\Runtime\cygwin\bin\dot.exe, -Tsvg]
(0.521 - 15 Mo) 7 Mo - DotString size: 1661
(0.566 - 15 Mo) 6 Mo - Ending process ok
(0.566 - 15 Mo) 6 Mo - Ending Graphviz process
(1.215 - 15 Mo) 8 Mo - TransformerFactory=class com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl
(1.217 - 15 Mo) 8 Mo - Transformer=class com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl
(1.241 - 15 Mo) 7 Mo - Number of image(s): 1

EDIT:

And don't get me wrong: I don't want to use saxon inside the plantuml process. I'm just looking for a safe and stable way to produce my pdf files ;-)

commented Dec 5, 2016 by (289,720 points)
There is something strange: both are generated through xalan.
Indeed, both contains the following line:
Transformer=class com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl

This means that saxon is not used here.
Could you double check that your classpath changes between the two tries ?
answered Dec 5, 2016 by (340 points)

You're right; my fault. I forgot to put saxon into the classpath again.

Everything is now working as intended. One run with xalan (calling the jar file) and the other run with saxon (calling the class the name).

I found out, that there is a small difference in both svg files:

xalan:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<defs/>
<g>
...

saxon:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<defs xmlns=""/>
<g xmlns="">
...

The saxon-version of the svg can not be displayed in a browser (like Chrome). After removing ' xmlns="" ' the files are exactly the same. Maybe that's the bug?
commented Dec 5, 2016 by (289,720 points)
The xmlns thing is probably the bug.

Just a guess, here is a new beta https://dl.dropboxusercontent.com/u/13064071/plantuml.jar
We have tried to remove this xmlns adding a line:

theElement.removeAttribute("xmlns");

Since we are not using saxon, we have not tested it.

It would be nice if you could tell us the result.
Thanks
answered Dec 5, 2016 by (340 points)

No, the xmlns is still there...

$java net.sourceforge.plantuml.Run -version PlantUML version 8052beta3 (8052beta3) (GPL source distribution) Java Runtime: Java(TM) SE Runtime Environment JVM: Java HotSpot(TM) Client VM Java Version: 1.8.0_91-b15 Operating System: Windows 10 OS Version: 10.0 Default Encoding: Cp1252 Language: de Country: DE Machine: DESKTOP-TPLHMSR PLANTUML_LIMIT_SIZE: 4096 Processors: 8 Max Memory: 259,522,560 Total Memory: 16,252,928 Free Memory: 12,702,648 Used Memory: 3,550,280 Thread Active Count: 1 The environment variable GRAPHVIZ_DOT has been set to C:\Users\holger\Desktop\tex_buildsystem\portableBuildSystem\App\Runtime\cygwin\bin\dot.exe Dot executable is C:\Users\holger\Desktop\tex_buildsystem\portableBuildSystem\App\Runtime\cygwin\bin\dot.exe Dot version: dot - graphviz version 2.38.0 (20140413.2041) Installation seems OK. File generation OK$ java net.sourceforge.plantuml.Run fm_smgw_prot.class -tsvg -verbose
(0.000 - 15 Mo) 12 Mo - PlantUML Version 8052beta3
(0.009 - 15 Mo) 11 Mo - GraphicsEnvironment.isHeadless() false
(0.035 - 15 Mo) 11 Mo - Setting current dir: .
(0.036 - 15 Mo) 11 Mo - Setting current dir: C:\Users\holger\Desktop\tex_buildsystem\portableBuildSystem\App\Runtime\cygwin\opt\plantuml\bin
(0.036 - 15 Mo) 11 Mo - Using default charset
(0.040 - 15 Mo) 11 Mo - Setting current dir: C:\Users\holger\Desktop\tex_buildsystem\portableBuildSystem\App\Runtime\cygwin\opt\plantuml\bin
(0.047 - 15 Mo) 13 Mo - Using default charset
(0.048 - 15 Mo) 13 Mo - Using default charset
(0.049 - 15 Mo) 13 Mo - Setting current dir: C:\Users\holger\Desktop\tex_buildsystem\portableBuildSystem\App\Runtime\Cygwin\opt\plantuml\bin
(0.050 - 15 Mo) 13 Mo - Setting current dir: C:\Users\holger\Desktop\tex_buildsystem\portableBuildSystem\App\Runtime\cygwin\opt\plantuml\bin
(0.057 - 15 Mo) 11 Mo - Setting current dir: C:\Users\holger\Desktop\tex_buildsystem\portableBuildSystem\App\Runtime\cygwin\opt\plantuml\bin
(0.057 - 15 Mo) 11 Mo - Reading file: fm_smgw_prot.class
(0.058 - 15 Mo) 11 Mo - name from block=null
Dez 05, 2016 3:47:56 PM java.util.prefs.WindowsPreferences <init>
WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
(0.281 - 15 Mo) 6 Mo - Creating file: C:\Users\holger\Desktop\tex_buildsystem\portableBuildSystem\App\Runtime\cygwin\opt\plantuml\bin\fm_smgw_prot.svg
(0.551 - 15 Mo) 4 Mo - Starting Graphviz process [C:\Users\holger\Desktop\tex_buildsystem\portableBuildSystem\App\Runtime\cygwin\bin\dot.exe, -Tsvg]
(0.552 - 15 Mo) 4 Mo - DotString size: 1661
(0.586 - 15 Mo) 4 Mo - Ending process ok
(0.587 - 15 Mo) 4 Mo - Ending Graphviz process
(1.354 - 17 Mo) 6 Mo - TransformerFactory=class net.sf.saxon.TransformerFactoryImpl
(1.363 - 17 Mo) 6 Mo - Transformer=class net.sf.saxon.IdentityTransformer
(1.391 - 17 Mo) 9 Mo - Number of image(s): 1
commented Dec 5, 2016 by (289,720 points)
Ok, thanks for the test.
In V8051beta4, we force the usage of xalan, so it may work for you:
https://dl.dropboxusercontent.com/u/13064071/plantuml.jar

Just tell us if it is working.

Thanks,
commented Dec 5, 2016 by (340 points)
yep, this is working for me! I think this is the best way for you and your users. This makes bug hunting and fixing much easier ;-)