getGeneratedBy() in 0.93
Hi, I'm trying to upgrade an application using the FOP API from 0.20 to 0.93. This application performs XML + XSLT - XSLFO then it uses FOP to render the document in a customized output format (I wrote my own renderer). This format needs to link Areas to their source elements in the original XML Document. In the previous implementation (FOP 0.20), I used customized a XSL stylesheets to propagate XML elements ids to XSL-FO, and then my renderer used the getGeneratedBy() method from the Area object. This method is no longer available in 0.93. Have you any idea to solve my problem ? Thank, Pierre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Overflow works in a strange way
Hi Eric, Lewis, Eric a écrit : snip/ However, I still don't know whether it's a FOP bug that before, the text went down to the bottom of the page, ignoring margins and was partially lost. This behaviour is specified by the overflow property [1]. When not specified the default behaviour is left to the implementation's choice and FOP chose visible. That is, the content will go down the region-body, and will be clipped only when reaching the bottom of the page. As to your needs, AFAICT there is no standard way in XSL-FO to make keep-together optional only if the content would otherwise not fit in the page. You could specify an integer value instead of always, but (besides the fact that integer values aren't supported yet by FOP) as I understand the spec this doesn't let you achieve what you want. [1] http://www.w3.org/TR/xsl11/#overflow Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Overflow works in a strange way
On 07.06.2007 10:01:23 Vincent Hennebert wrote: Hi Eric, Lewis, Eric a écrit : snip/ However, I still don't know whether it's a FOP bug that before, the text went down to the bottom of the page, ignoring margins and was partially lost. This behaviour is specified by the overflow property [1]. When not specified the default behaviour is left to the implementation's choice and FOP chose visible. That is, the content will go down the region-body, and will be clipped only when reaching the bottom of the page. As to your needs, AFAICT there is no standard way in XSL-FO to make keep-together optional only if the content would otherwise not fit in the page. You could specify an integer value instead of always, but (besides the fact that integer values aren't supported yet by FOP) as I understand the spec this doesn't let you achieve what you want. I disagree. I think it's exactly the feature that would be needed here. See also: http://www.dpawson.co.uk/xsl/sect3/keepsNbreaks.html An example: fo:block keep-together.within-page=1 id=section1 fo:block keep-together.within-page=2 id=block1 fo:block font-weight=bold keep-together.within-column=always keep-with-next.within-column=alwaystitle/fo:block fo:blocksome text/fo:block fo:block fo:block keep-together.within-page=2 id=block2 fo:block font-weight=bold keep-together.within-column=always keep-with-next.within-column=alwaystitle/fo:block fo:blocksome text/fo:block fo:block /fo:block This would do the following: - Never split a title apart and keep it together with the following text (or at least the first few lines specified by orphans) - Tries to keep block1 together but only if it fits in a page. - Tries to keep block2 together but only if it fits in a page. - Tries to keep section1 together but only if it fits in a page. - Splits between block1 and block2 if the whole section1 doesn't fit in a page but it will still try to keep together block1 and block2. In other words: if the keeps with strength 1 cannot be satisfied, they are relaxed but the strengths 2 will still be honored as if they were set to always. But if even that would lead to an overflow the keeps with strength 2 will also be relaxed. Keeps with strength always will never be relaxed and lead to an overflow if the content is longer than the available space (that's what happens in Eric's example). [1] http://www.w3.org/TR/xsl11/#overflow Vincent Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getGeneratedBy() in 0.93
I think what you're looking for is now: area.getTrait(Trait.PROD_ID); HTH On 06.06.2007 15:15:45 Heroux Pierre wrote: Hi, I'm trying to upgrade an application using the FOP API from 0.20 to 0.93. This application performs XML + XSLT - XSLFO then it uses FOP to render the document in a customized output format (I wrote my own renderer). This format needs to link Areas to their source elements in the original XML Document. In the previous implementation (FOP 0.20), I used customized a XSL stylesheets to propagate XML elements ids to XSL-FO, and then my renderer used the getGeneratedBy() method from the Area object. This method is no longer available in 0.93. Have you any idea to solve my problem ? Thank, Pierre Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Perfomance Issue need Help on generating PDF from XSL FO
Manuel already gave you some tips in
http://issues.apache.org/bugzilla/show_bug.cgi?id=42590
The example files you attached don't even take 2 seconds from the
command-line and that's including VM startup and class-loading. So the
problem is probably somewhere else (maybe the machine is swapping like
mad or the app server has not enough memory available and is constantly
in garbage collection). I also don't see anything wrong with your code
except that you set a system property within an application server which
is bad practice. Instead of:
System.setProperty(javax.xml.transform.TransformerFactory,org.apache.xalan.processor.TransformerFactoryImpl);
TransformerFactory factory = TransformerFactory.newInstance();
I'd write:
TransformerFactory factory = new
org.apache.xalan.processor.TransformerFactoryImpl();
...if you want to control which XSLT implementation you want to use.
Setting the system property affects the whole application server!
On 06.06.2007 16:36:46 manojkmi wrote:
Hi,
I created a code snippet to convert XML+XSL FO to PDF using FOP.
I am using OC4j as Application Server.
Here is the code:
FopFactory fopFactory = FopFactory.newInstance();
FOUserAgent foUserAgent = fopFactory.newFOUserAgent();
OutputStream out = new BufferedOutputStream(new FileOutputStream(new
file(/brodart.pdf)));
Try
{
System.setProperty(javax.xml.transform.TransformerFactory,org.apache.xalan.processor.TransformerFactoryImpl);
Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF, foUserAgent,
out);
TransformerFactory factory = TransformerFactory.newInstance();
Transformer transformer = factory.newTransformer(new
StreamSource(new File(/Brodart.xsl)));
transformer.setParameter(versionParam, 2.0);
Source src = new StreamSource(new File(/brodart.xml));
Result res = new SAXResult(fop.getDefaultHandler());
transformer.transform(src, res);
}
At the highlighted step seems to be taking a lot of time to execute (around
15 min).
Can any one please help on this issue? Here I attached the XML and XSL file
we are using.
Thanks
Manoj http://www.nabble.com/file/p10989960/XML_XSL.zip XML_XSL.zip
--
View this message in context:
http://www.nabble.com/Perfomance-Issue-need-Help-on-generating-PDF-from-XSL-FO-tf3878334.html#a10989960
Sent from the FOP - Users mailing list archive at Nabble.com.
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: start-indent correct behavior?
Hi Pascal, can you give me hint what to do: All I need is to move a whole table to a certain position from left. But leave the table-layout as it is. Thank you for your help, Alex Am 06.06.2007 um 14:34 schrieb Pascal Sancho: Ho Alex, There is no bug, but unexpected rendering... There is a very nice Wikipage that explain the *-indent inheritence behaviour: http://wiki.apache.org/xmlgraphics-fop/IndentInheritance HTH, Pascal -Message d'origine- De : Alexander Lohse [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 14:04 Hi, when I apply a start-indent to a fo:block containing a fo:table each and every fo:cell inherits this start-indent, producing very strange output. Is this a bug or correct behavior? This introduces a major incompatibilty for FO-Layouts written for 0.20.5 ... Any ideas? Best regards, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Alexander Lohse • Entwicklungsleitung Projektmanagement Tel +49 38374 752 11 • Fax +49 38374 752 23 http://www.humantouch.de Human Touch Medienproduktion GmbH Am See 1 • 17440 Klein Jasedow • Deutschland Geschäftsführung: Lara Mallien, Nele Hybsier, Alexander Lohse, Johannes Heimrath (Senior) Handelsregister Stralsund • HRB 4192 • USt-IdNr. DE128367684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: start-indent correct behavior?
Just reset start-indent and end-indent on fo:table-body (and table-header/table-footer) to 0mm. On 07.06.2007 21:19:37 Alexander Lohse wrote: Hi Pascal, can you give me hint what to do: All I need is to move a whole table to a certain position from left. But leave the table-layout as it is. Thank you for your help, Alex Am 06.06.2007 um 14:34 schrieb Pascal Sancho: Ho Alex, There is no bug, but unexpected rendering... There is a very nice Wikipage that explain the *-indent inheritence behaviour: http://wiki.apache.org/xmlgraphics-fop/IndentInheritance HTH, Pascal -Message d'origine- De : Alexander Lohse [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 14:04 Hi, when I apply a start-indent to a fo:block containing a fo:table each and every fo:cell inherits this start-indent, producing very strange output. Is this a bug or correct behavior? This introduces a major incompatibilty for FO-Layouts written for 0.20.5 ... Any ideas? Best regards, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Alexander Lohse • Entwicklungsleitung Projektmanagement Tel +49 38374 752 11 • Fax +49 38374 752 23 http://www.humantouch.de Human Touch Medienproduktion GmbH Am See 1 • 17440 Klein Jasedow • Deutschland Geschäftsführung: Lara Mallien, Nele Hybsier, Alexander Lohse, Johannes Heimrath (Senior) Handelsregister Stralsund • HRB 4192 • USt-IdNr. DE128367684 Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
embedded configuration of base directory
I am trying to load images onto my pdf file. When I use a configuration file to set my base directory, I have no issues. The problem arises when I try to programmatically set my base directory. Here is my fop.xconf (which works perfectly fine): fop version=1.0 !-- Base URL for resolving relative URLs -- base/workplace2/projects/DropShip/SelfService/mainline/Website/Central /src/main/resources//base Under Customizing the User Agent, I followed the doc: The base URL to use when resolving relative URLs. Example: * userAgent.setBaseURL(file:///mydirectory/directory file:///mydirectory/directory ); So I tried doing: foUserAgent.setBaseURL(file:/workplace2/projects/DropShip/SelfService/m ainline/Website/Central/src/main/resources); and foUserAgent.setBaseURL(file:///workplace2/projects/DropShip/SelfService/ mainline/Website/Central/src/main/resources); The error message I get is: Jun 7, 2007 5:51:48 PM org.apache.fop.fo.flow.ExternalGraphic bind SEVERE: Image not available: amazon-bw.jpg Any help with be very much appreciated! Thanks.
