You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Simon Pepping <sp...@leverkruid.nl> on 2005/12/04 13:35:39 UTC
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
Posted by Adam Strzelecki <on...@java.pl>.
Simon wrote:
> 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.
I managed to pass over that problem using Xalan 2.7.0. However I cannot
still find out the way how to configure CATALOG files so it will work
with Xalan while I just use command:
fop -xml mybook.xml -xsl docbook.xsl -pdf mybook.pdf
however URIResolver and EntityResolver are specified only on Xalan's
command line... so no idea how to push that directly trough FOP without
mod to sourcecode.
Regards,
--
Adam Strzelecki |: nanoant.com :|
Re: Using Docbook stylesheets in FOP (was: Re: ToUnicode table for CID embedded fonts patch available)
Posted by Andreas L Delmelle <a_...@pandora.be>.
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
Re: Using Docbook stylesheets in FOP (was: Re: ToUnicode table for CID embedded fonts patch available)
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Sun, Dec 04, 2005 at 02:25:22PM +0100, Andreas L Delmelle wrote:
> On Dec 4, 2005, at 13:35, Simon Pepping wrote:
>
> >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
>
> 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?)
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.
> 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.
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)
Posted by Andreas L Delmelle <a_...@pandora.be>.
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: PNG renderer not closing output streams properly.
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Thanks for spotting that one. I've just fixed it in Subversion:
http://svn.apache.org/viewcvs?rev=354537&view=rev
On 04.12.2005 15:35:50 Amin Ahmad wrote:
> Hi Team FOP,
>
> I was playing around with the PNG Renderer, and I think I noticed a problem
> -- when it produces multiple files (one per page) it does not appear to be
> explicity closing the files it creates. Java GC takes care of closing the
> files automatically, but, running Java 5, the final file is left open until
> the JVM terminates.
>
> In the code below from PNGRenderer, on the last line of the for loop, the
> output stream is flushed but never closed. At the top of the loop, os is
> reassigned to a new output stream for the next page.
>
> thanks,
> Amin
>
>
> public void stopRenderer() throws IOException {
>
> super.stopRenderer();
>
> for (int i = 0; i < pageViewportList.size(); i++) {
>
> OutputStream os = getCurrentOutputStream(i);
> if (os == null) {
> log.warn("No filename information available."
> + " Stopping early after the first page.");
> break;
> }
> // Do the rendering: get the image for this page
> RenderedImage image = (RenderedImage)
> getPageImage((PageViewport) pageViewportList
> .get(i));
>
> // Encode this image
> log.debug("Encoding page " + (i + 1));
> renderParams = PNGEncodeParam.getDefaultEncodeParam(image);
>
> // Set resolution
> float pixSzMM = userAgent.getPixelUnitToMillimeter();
> // num Pixs in 1 Meter
> int numPix = (int)((1000 / pixSzMM) + 0.5);
> renderParams.setPhysicalDimension(numPix, numPix, 1); // 1 means
> 'pix/meter'
>
> // Encode PNG image
> PNGImageEncoder encoder = new PNGImageEncoder(os, renderParams);
> encoder.encode(image);
> os.flush();
> }
> }
Jeremias Maerki
PNG renderer not closing output streams properly.
Posted by Amin Ahmad <am...@hotmail.com>.
Hi Team FOP,
I was playing around with the PNG Renderer, and I think I noticed a problem
-- when it produces multiple files (one per page) it does not appear to be
explicity closing the files it creates. Java GC takes care of closing the
files automatically, but, running Java 5, the final file is left open until
the JVM terminates.
In the code below from PNGRenderer, on the last line of the for loop, the
output stream is flushed but never closed. At the top of the loop, os is
reassigned to a new output stream for the next page.
thanks,
Amin
public void stopRenderer() throws IOException {
super.stopRenderer();
for (int i = 0; i < pageViewportList.size(); i++) {
OutputStream os = getCurrentOutputStream(i);
if (os == null) {
log.warn("No filename information available."
+ " Stopping early after the first page.");
break;
}
// Do the rendering: get the image for this page
RenderedImage image = (RenderedImage)
getPageImage((PageViewport) pageViewportList
.get(i));
// Encode this image
log.debug("Encoding page " + (i + 1));
renderParams = PNGEncodeParam.getDefaultEncodeParam(image);
// Set resolution
float pixSzMM = userAgent.getPixelUnitToMillimeter();
// num Pixs in 1 Meter
int numPix = (int)((1000 / pixSzMM) + 0.5);
renderParams.setPhysicalDimension(numPix, numPix, 1); // 1 means
'pix/meter'
// Encode PNG image
PNGImageEncoder encoder = new PNGImageEncoder(os, renderParams);
encoder.encode(image);
os.flush();
}
}