Re: Basic-link problem in JSPs
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
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
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
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
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
