You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Ralf Steppacher <st...@esteam.de> on 2002/04/30 16:18:13 UTC
Basic-link problem in JSPs
Hi all.
I transform a xml file and add FO vocabulary, generating a PDF with fop
afterwards. Now that I got it work using xalan and fop from the command
line I embedded both into a JSP and a bean following the example code
from docs/examples/embedding.
The problem: When I generate the PDF with the JSP my fo:basic-links
don't make it into the PDF. If I dump the FO DOM tree to a file and use
fop from the commandline the links are present in the PDF.
Here is the code I use:
<!-- JSP Code -->
<%
byte[] result = null;
pdfHelper.FOPit( docAllInOne, "allInOne2FO.xsl" );
response.setContentType("application/pdf");
response.setContentLength(result.length);
response.getOutputStream().write(result);
response.getOutputStream().flush();
%>
/* Bean */
public byte[] FOPit( Document doc, String styleSheet ) {
XMLTransform tf = new XMLTransform();
if ( !tf.setStyleSheet( styleSheet ) ) return null;
/* Transform the Document. */
DOMResult result = tf.process( doc );
if ( result == null ) return null;
/*
* allInOne_1.fo used with fop on the command line
* creates links in the PDF file.
*/
XMLWriter.debugToFile(
(Document)result.getNode(), "allInOne_1.fo" );
DocumentInputSource source = new DocumentInputSource();
source.setDocument( (Document)result.getNode() );
ByteArrayOutputStream out = new ByteArrayOutputStream();
Hierarchy hierarchy = Hierarchy.getDefaultHierarchy();
Logger log = hierarchy.getLoggerFor("fop");
log.setPriority(Priority.DEBUG);
Driver driver = new Driver( source, out );
driver.setLogger( log );
driver.setRenderer(Driver.RENDER_PDF);
try {
driver.run();
}
catch ( Exception e ) { e.printStackTrace(); }
return out.toByteArray();
} // end FOPit()
I'd be glad if someone could give me a hint where the reason for this
behavior might be found.
Ralf
Re: Problem after generating PDF
Posted by Ralf Steppacher <st...@esteam.de>.
[..]
> Driver driver = new Driver();
> driver.setRenderer(Driver.RENDER_PDF);
> InputHandler inputHandler = new XSLTInputHandler(xmlFile, xslFile);
> XMLReader parser = inputHandler.getParser();
/**** changes start here ****/
FileOutputStream fos = FileOutputStream( outFile );
driver.setOutputStream( fos );
> driver.render(parser, inputHandler.getInputSource());
fos.close();
/**** changes end here ****/
Is that what you need?
Ralf
Re: Absulute Pagenumber
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Ingo Peter wrote:
> In the reference I find no reference for print the absolute pagecount on
> every page:
> Page: <page-number> of <absolute-page>
>
> Is there any solution for this problem...?
It's an old hat, the list archives as well as the FO
part of the XSL FAQ have solutions.
Put an id on some block element which will end up on
the last page, for example an empty block, and refer
to it. Code snippet:
<fo:page-sequence master-reference="...">
<fo:static-content>
<fo:block text-align="end">
<fo:page-number/> of <fo:page-number-citation ref-id="last"/>
</fo:block>
</fo:static-content>
<fo:flow>
...
<fo:block id="last"/>
</fo:flow>
</fo:page-sequence>
Be aware of some pitfalls: you'll get a page number, not
a page count, so it won't work if you use multiple page
sequences with discountinuous numbering. And worst of all:
you are generating a forward reference, forcing FOP to
hold all pages in memory.
J.Pietschmann
Absulute Pagenumber
Posted by Ingo Peter <in...@ip-software.de>.
Hi,
first thanks for the last help generating pdf embedded.
In the reference I find no reference for print the absolute pagecount on
every page:
Page: <page-number> of <absolute-page>
Is there any solution for this problem...?
thanks
IP
AW: Problem after generating PDF
Posted by Tobias Mueller <tm...@a-i-c.de>.
Hi!
In my case, the following code worked:
import java.io.*;
import java.util.*;
import org.xml.sax.InputSource;
import org.xml.sax.XMLReader;
import org.apache.fop.apps.Driver;
import org.apache.fop.apps.Version;
import org.apache.fop.apps.InputHandler;
import org.apache.fop.apps.XSLTInputHandler;
//import org.apache.log.*;
public class generatePDF {
public String Publish(String XMLfile, String XSLfile, String outFile)
throws Exception {
File MyXMLfile = new File(XMLfile);
File MyXSLfile = new File(XSLfile);
FileOutputStream MyOutputFile = new FileOutputStream(outFile);
try {
Driver driver = new Driver();
driver.setRenderer(Driver.RENDER_PDF);
InputHandler inputHandler = new XSLTInputHandler(MyXMLfile, MyXSLfile);
XMLReader parser = inputHandler.getParser();
driver.setOutputStream(MyOutputFile);
driver.render(parser, inputHandler.getInputSource());
MyOutputFile.close();
} catch (Exception ex) {
System.out.println(ex);
}
return "built " + outFile;
}
}
Hope this helped you out,
Tobi
-----Ursprüngliche Nachricht-----
Von: Ingo Peter [mailto:ingo.peter@ip-software.de]
Gesendet: Freitag, 3. Mai 2002 12:11
An: fop-user@xml.apache.org
Betreff: Problem after generating PDF
Hi,
I use fop embedded to generate pdf-files and it works very fine.
But after generating the pdf, I have to close my java-application, because
the the outputfile is still open.
If I don't close my application acrobat tells me a locking-error.
I use the example for empedding from apache:
Driver driver = new Driver();
driver.setRenderer(Driver.RENDER_PDF);
InputHandler inputHandler = new XSLTInputHandler(xmlFile, xslFile);
XMLReader parser = inputHandler.getParser();
driver.setOutputStream(new FileOutputStream(outFile));
driver.render(parser, inputHandler.getInputSource());
Is there any command to close the outputfile?
thanks
IP
Problem after generating PDF
Posted by Ingo Peter <in...@ip-software.de>.
Hi,
I use fop embedded to generate pdf-files and it works very fine.
But after generating the pdf, I have to close my java-application, because
the the outputfile is still open.
If I don't close my application acrobat tells me a locking-error.
I use the example for empedding from apache:
Driver driver = new Driver();
driver.setRenderer(Driver.RENDER_PDF);
InputHandler inputHandler = new XSLTInputHandler(xmlFile, xslFile);
XMLReader parser = inputHandler.getParser();
driver.setOutputStream(new FileOutputStream(outFile));
driver.render(parser, inputHandler.getInputSource());
Is there any command to close the outputfile?
thanks
IP
Re: Basic-link problem in JSPs
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Ralf Steppacher wrote:
> > If this comes directly from your original style sheet, you should
> > better use matching precise templates instead of piping everything
> > into a match-all and then use a choose in it.
>
> Is this just a matter of style or do exact templates perform better?
A matter of robustness and maintainability. Just add
templates instead of adding when-clauses, perhaps with
ever more intricate conditions.
In general, templates are slower but there is rarely
a mesurable difference (you need hundreths of matching
tamplates).
> Hm, I generate quite a lot of cells (the document contains only tables)
> and thought that a template for generating cells would reduce filesize
> and improve readability of the stylesheet.
The verbose call-template syntax doesn't reduce the
filesize either, and named template invocations can
really hide what's going on. But it's your choice.
Try both on a small part and see what fits you better.
J.Pietschmann
Re: Basic-link problem in JSPs
Posted by Ralf Steppacher <st...@esteam.de>.
First of all: Thank you very much for your help!
>> <fo:basic-link internal-destination="addressListHeading">
>> <fo:page-number-citation color="blue" ref-id="addressListHeading"/>
>> </fo:basic-link>
>
> This is the real problem. You probably noticed that the link area is
> not the whole page number, in particular with multiple digit page
> numbers.
Yes, that is right. I will follow your advise and use the headline text
as link area.
> Your style sheet appear to be a bit more convoluted than usual. Some
> other hints:
>
>> <xsl:template match="address_list/row/*" mode="address_list">
>> <xsl:choose> <xsl:when test="local-name()='ZIP_CODE_CITY'">
>> <xsl:call-template name="plzOrtRow">
>
> If this comes directly from your original style sheet, you should
> better use matching precise templates instead of piping everything
> into a match-all and then use a choose in it.
Is this just a matter of style or do exact templates perform better?
> There is not all that much value in abstracting
> really low-level stuff like table cell generation.
Hm, I generate quite a lot of cells (the document contains only tables)
and thought that a template for generating cells would reduce filesize
and improve readability of the stylesheet.
Thanks for your hints!!!
Ralf
Re: Basic-link problem in JSPs
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Ralf Steppacher wrote:
> <xsl:output method="xml" encoding="UTF-8" indent="yes".../>
^^^
Well, mystery solved. Indenting the result should and usually
does not alter the semantics of the document, but there is no
guarantee, the spec explicitely warns that whitespace for
intendation could result in a different interpretation.
You'll see, if you set it to "no", the dumped FO file wont
generate a link area either.
I'll add this to the "shit happens" list.
><fo:basic-link internal-destination="addressListHeading">
> <fo:page-number-citation color="blue" ref-id="addressListHeading"/>
></fo:basic-link>
This is the real problem. You probably noticed that the link area
is not the whole page number, in particular with multiple digit
page numbers. This is due to the fact that the area generated by
the page number citation is not accounted for. Handling of page
number citations reffering to pages not yet rendered is kludgy,
there are no text decorations applied, and the can't be reliably
right aligned.
Your best bet is probably to use the chapter heading text for
the link instead of the page number. Another possibility is to
generate the TOC at the end and reshuffle the pages using iText
if necessary. If you really need to keep the current design,
Use xsl:text to insert a whitespace, perhaps a usual space
surrounded by two zero width spaces or something.
Your style sheet appear to be a bit more convoluted than usual.
Some other hints:
><xsl:template match="address_list/row/*" mode="address_list">
> <xsl:choose>
> <xsl:when test="local-name()='ZIP_CODE_CITY'">
> <xsl:call-template name="plzOrtRow">
...
> </xsl:call-template>
> </xsl:when>
> <xsl:when test="local-name()='ZIP_CODE_PO_BOX'">
If this comes directly from your original style sheet, you
should better use matching precise templates instead of
piping everything into a match-all and then use a choose
in it. Furthermore, either the mode or the path prefix
address_list/row appears to be redundant too.
<xsl:template match="address_list/row/ZIP_CODE_CITY">
<xsl:call-template name="plzOrtRow">
...
</xsl:template>
<xsl:template match="address_list/row/ZIP_CODE_PO_BOX">
<xsl:call-template name="plzOrtRow">
...
</xsl:template>
<xsl:template match="address_list/row/*">
<xsl:call-template name="keyValueRow">
...
</xsl:template>
> <fo:table-row>
> <xsl:attribute name="keep-with-next"><xsl:value-of select="$keep"/></xsl:attribute>
You can do yourself a favor and use attribute value templates
(short: AVT):
<fo:table-row keep-with-next="{$keep}">
> <fo:block end-indent="30pt" text-align="justify">
> <!--Increase indent for every sub-chapter. -->
> <xsl:attribute name="start-indent"><xsl:value-of select="$level * 30"/>pt</xsl:attribute>
You can keep this for documentation, but the following should
give the same result:
<fo:block end-indent="30pt" text-align="justify"
start-indent{$level * 30}pt">
> <xsl:template name="createCell">
> <xsl:param name="fillWith">[NOT SPECIFIED]</xsl:param>
> <xsl:param name="borderColor">gray</xsl:param>
> <xsl:param name="borderStartStyle">solid</xsl:param>
> <xsl:param name="borderEndStyle">solid</xsl:param>
...
> <fo:table-cell border-collapse="collapse" border-width="1pt" border-style="solid">
> <xsl:attribute name="padding"><xsl:value-of select="$padding"/></xsl:attribute>
> <xsl:attribute name="border-color"><xsl:value-of select="$borderColor"/></xsl:attribute>
> <xsl:attribute name="border-start-style"><xsl:value-of select="$borderStartStyle"/></xsl:attribute>
Instead of passing attribute in a parameter, you should look
into using attribute sets:
http://www.w3.org/TR/xslt#attribute-sets
You can prepare bundles of attributes, somewhat similar to CSS
classes, and use them in element creation.
Generally, you should more rely on apply-templates and reduce
the call-template stuff. There is not all that much value in
abstracting really low-level stuff like table cell generation.
J.Pietschmann
Re: Basic-link problem in JSPs
Posted by Ralf Steppacher <st...@esteam.de>.
> Can you post a trimmed down version of your source XML
> and the style sheet which demonstrates the problem?
I attached the XML source and the FO file as it is dumped for debugging
purpose from my code. The stylesheet is still a bit lengthy (main style
sheet is allInOne2FO_short). The link should be created in the template
named "toc".
Thanks!
Ralf
Re: Basic-link problem in JSPs
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Ralf Steppacher wrote:
> OK, I got rid of all the d-o-e.
> But the basic-links still are not present in the pdf generated by the
> embedded FOP but are if the .fo document is dumped to a file and then
> rendered using FOP from commandline.
Can you post a trimmed down version of your source XML
and the style sheet which demonstrates the problem?
J.Pietschmann
Re: Basic-link problem in JSPs
Posted by Ralf Steppacher <st...@esteam.de>.
>>> Are you, by any chance, using disable-output-escaping somewhere?
>>
>> Yes, [..].
>
> XSLT doesn't del with tags, it uses a tree of nodes for input and
> output.[..]
>
>> Behaviour does not change if I comment out the two lines (that do
>> not work with embedded fop either).
>
> If you delete the d-o-e stuff, dump the tree and check with the
> command line application, what happens?
OK, I got rid of all the d-o-e.
But the basic-links still are not present in the pdf generated by the
embedded FOP but are if the .fo document is dumped to a file and then
rendered using FOP from commandline.
Thank you very much for your help!
Ralf
Re: Basic-link problem in JSPs
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Ralf Steppacher wrote:
>> Are you, by any chance, using disable-output-escaping somewhere?
>
> Yes, but somewhere else in the stylesheet producing the fo document.
It doesn't matter where. Do not use d-o-e if you expect your style
sheet to work with short-circuit XSLT processor applications.
XSLT doesn't del with tags, it uses a tree of nodes for input
and output. What you think of as creating "single tags" is still
plain text until serialization. A serialization never happens
if the result is fed right into the XML consumer by using a
DOM tree or a SAX event stream.
> Behaviour does not change if I comment out the two lines (that do not
> work with embedded fop either).
If you delete the d-o-e stuff, dump the tree and check
with the command line application, what happens?
J.Pietschmann
Re: Basic-link problem in JSPs
Posted by Ralf Steppacher <st...@esteam.de>.
>> The problem: When I generate the PDF with the JSP my fo:basic-links
>> don't make it into the PDF. If I dump the FO DOM tree to a file and
>> use fop from the commandline the links are present in the PDF.
>
> Are you, by any chance, using disable-output-escaping somewhere?
Yes, but somewhere else in the stylesheet producing the fo document.
Behaviour does not change if I comment out the two lines (that do not
work with embedded fop either).
Ralf
Re: Basic-link problem in JSPs
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Ralf Steppacher wrote:
> I transform a xml file and add FO vocabulary, generating a PDF with fop
> afterwards. Now that I got it work using xalan and fop from the command
> line I embedded both into a JSP and a bean following the example code
> from docs/examples/embedding.
> The problem: When I generate the PDF with the JSP my fo:basic-links
> don't make it into the PDF. If I dump the FO DOM tree to a file and use
> fop from the commandline the links are present in the PDF.
Are you, by any chance, using disable-output-escaping somewhere?
J.Pietschmann