Using Docbook stylesheets in FOP (was: Re: ToUnicode table for CID embedded fonts patch available)
(Cross-posting to fop-user) On Fri, Dec 02, 2005 at 01:58:39PM +0100, Jeremias Maerki wrote: On 02.12.2005 13:39:53 Adam Strzelecki wrote: Hello Jeremias, 3) Last thing I would really appreciate is I would love to generate PDF directly from XML files using stylesheets but FOP XSLT routine is somehow broken so I need to do the conversion with XSLTPROC which does it without the problem. This is the error when I use FOP with: fop -xml myfile.xml -xsl docbook/fo/docbook.xsl -pdf myfile.pdf Compiler warnings: file:/c:/Program%20Files/fop/docbook/fo/formal.xsl: line 433: Attribute 'border-left-style' outside of element. file:/c:/Program%20Files/fop/docbook/fo/formal.xsl: line 434: Attribute 'border-right-style' outside of element. file:/c:/Program%20Files/fop/docbook/fo/formal.xsl: line 435: Attribute 'border-top-style' outside of element. file:/c:/Program%20Files/fop/docbook/fo/formal.xsl: line 436: Attribute 'border-bottom-style' outside of element. ERROR: 'Syntax error in '* or $generate.index != 0'.' FATAL ERROR: 'Could not compile stylesheet' Exception javax.xml.transform.TransformerConfigurationException: Could not compile stylesheet Problem is in the XSL file of DocBook XLS 1.69.1 sheets: docbook/fo/autotoc.xsl Sounds more like a problem in either the stylesheet itself or in Xalan which FOP calls for doing XSLT. Maybe I should finally install DocBook on my machine. :-) It is indeed not really a FOP issue. The docbook stylesheets seem to be a pain for most XSLT processors. Restricting myself to Java XSLT processors, I have only been successful with Saxon6. Xalan and the Xalan processor built into Java 5 cannot compile the docbook/fo stylesheets. This can be achieved by putting saxon.jar first in the classpath. It must come before xalan.jar, in order to configure the Transformer factory to use Saxon. Unfortunately, this is not possible with the current fop shell script, because it puts the CLASSPATH variable at the end of the class path. (Sometimes this is what you want, here it is not.) The fop.bat batch file ignores the CLASSPATH variable completely. Another issue I have with FOP and Docbook is that FOP out of the box does not use catalogs. I think we should do something about this. It is unrealistic to expect Docbook users to write their own startup Java file. They want something that works from the command line. But before we try, it would be useful to hear how other people use FOP with Docbook. Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Using Docbook stylesheets in FOP (was: Re: ToUnicode table for CID embedded fonts patch available)
On Dec 4, 2005, at 13:35, Simon Pepping wrote: On Fri, Dec 02, 2005 at 01:58:39PM +0100, Jeremias Maerki wrote: snip / Sounds more like a problem in either the stylesheet itself or in Xalan which FOP calls for doing XSLT. Maybe I should finally install DocBook on my machine. :-) It is indeed not really a FOP issue. The docbook stylesheets seem to be a pain for most XSLT processors. Restricting myself to Java XSLT processors, I have only been successful with Saxon6. Xalan and the Xalan processor built into Java 5 cannot compile the docbook/fo stylesheets. This can be achieved by putting saxon.jar first in the classpath. FYI other options include: - modifying your %JAVA_HOME%/lib/jaxp.properties file (or creating one if it doesn't exist) - supplying the property via java's '-D' command-line option jaxp.properties would look something like: javax.xml.transformer.TransformerFactory=com.icl.saxon.TransformerFactor yImpl (analogous for 'java -D...') The first one has the advantage that it is completely independent of our FOP shell scripts, but it affects all Java Apps, so is really only useful when the user wants to use Saxon everywhere instead of Xalan (the default). The second one would still require a modification to the shell script, maybe in the form of an optional parameter you can pass to the script. If the parameter is present, the java command-line at the bottom of the script can be made to take into account the override for that particular system property. (So, this could turn out to be beneficial in other areas as well, where the user needs to override sysprops... Could this solve the issue of using catalogs?) How about allowing: fop -sysprop ... -fo ... -pdf ... The -sysprop switch is caught by the shell script, and incorporated into the java command-line. (Using '-D' here would create confusion with FOP's own '-d' switch, unless we were to allow only the slightly more verbose '-debug') Just a thought. Cheers, Andreas
Re: Using Docbook stylesheets in FOP (was: Re: ToUnicode table for CID embedded fonts patch available)
On Dec 4, 2005, at 16:14, Simon Pepping wrote: On Sun, Dec 04, 2005 at 02:25:22PM +0100, Andreas L Delmelle wrote: snip / Could this solve the issue of using catalogs?) No. Catalogs can only be used by registering an EntityResolver with the XMLReader and a URIResolver with the Transformer. FOP's CLI code currently just does not do this. Good, that settles that. We'll have to look at other options here... How about allowing: fop -sysprop ... -fo ... -pdf ... The -sysprop switch is caught by the shell script, and incorporated into the java command-line. (Using '-D' here would create confusion with FOP's own '-d' switch, unless we were to allow only the slightly more verbose '-debug') Users do not like to have to know the name of such an obscure property. Configuring the class path is already a lot to ask from someone not interested in Java per se. Well then, maybe the solution would be to shield the user from the fact that it's a system property by having them supply only the name of the TransformerFactory implementation to use. Besides that, I don't really think it's an obscure property (quite on the contrary). It's not because someone isn't aware of the existence of something, that that something is to be considered as obscure. Given proper documentation, the user might learn something new while configuring FOP... Oh, sorry, I forgot that most people don't like to learn anything at all. :-P Cheers, Andreas
