Re: What XSLT and XSL-FO editor do you use?
Roger wrote: Do you know of any good wysiwyg editor for FO, and one that allows you to edit or import the code? I don't expect Dreamweaver quality. Other good tools are also welcome. XMLSpy works fine to create an XSD, but I've seen a lot of tools out there, so I'm wondering what your experiences are, what tips you have. I have given up on Altova too. Currently I use Emacs with nxml-mode and the RenderX RELAX files for XSL-FO. This does not give wysiwyg, but it helps a lot getting the FO-file right, and then run a FO-previewer like FOP from a shell occasionaly to see what you are doing. The feeling of this is a lot like writing in LaTeX (or WordPerfect for oldtimers:) -- Thorbjoern Ravn Andersen "...plus...Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to handle &in fop
[EMAIL PROTECTED] wrote: Hi everybody, When the data contains ‘&’ like CUSTOMER_NAME= "L&G ASSURANCE SOCIETY LTD " fop is throwing the following error: Caused By : javax.xml.transform.TransformerException : org.xml.sax.SAXParseExcep tion: The reference to entity "G" must end with the ';' delimiter. Can anybody help in handling the character ‘&’. Use & instead. To ensure that you always generate proper XML regardless of character set, you should change all characters above 127, and <, > and & to "numericvalue;" instead. The numeric value is the unicode value of the character. -- Thorbjoern Ravn Andersen "...plus...Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OutOfMemoryError by large tables: Alternative solution?
Chris Bowditch wrote: Splitting the table up is the best way to reduce the ratio memory:input size. Also, there have been some tweaks made to the maintenance code in CVS that help improve the memory usage of tables. To use this latest code, you will need to install a CVS client, download the 0.20.5 code from the maintainance branch and then re-compile. See website for further info: We found that for a complex 23 page print, the memory usage fell from 100 Mb to 75 Mb (rough measurement) by using the CVS-version. The overall performance is much more influenced by the memory usage of the many pages (when rendering to a PageSet which we do instead of rendering to e.g. a PDF) than by the complexity of the tables. -- Thorbjoern Ravn Andersen "...plus...Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: spending too much time in PropertyList.findProperty
Chris Bowditch wrote: The changes to Table performance dont apply to AWT Renderer mainly because AWT Rendering uses very different code to the main part of FOP's layout/rendering engine, which is geared up for PDF, Postscript and other print formats. Now I have done a quick test of this on our server with a large print. With 0.20.5 I end up with a footprint after FOP has run of 120 Mb, which falls to 20 Mb, and with the latest CVS I end up with 96 Mb which also falls to 20 Mb.I Thank you for letting me know. The saving is enough to make a difference. By accident I first checked with the code in HEAD, which did not work well, so I am convinced that 1.0 is still some time away :) Could you elaborate on what isnt working? One of my current goals is to get the development version working to a similar level as 0.20.5. I just ran the sample FO file described above through. No tables showed up, and a lot of text was put on top of each other in a single place. This was AWT only. Feel free to download and try. -- Thorbjoern Ravn Andersen "...plus...Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: spending too much time in PropertyList.findProperty
J.Pietschmann wrote: I suspect this is be cause row and cell areas are referenced from their corresponding FOs itself and are therefore kept in memory together with all their descendants until the page sequence is completely rendered (in contrast to all other area objects which are reclaimed after a page is rendered). There is a fix for this in CVS. I have now made a comparison between 0.20.5 and the latest maintainance code in CVS, and I do not see the effects described above. I have tested with the sample AWT-previewer in FOP, and found that the memory footprint are very similar, but I will now check in the actual environment. Do I need to provide some configuration parameters which may change the behaviour of FOP? To clarify what I currently need to render, I would have attached a sample FO-file but this is not accepted on the list. Interested parties may have a look at http://unixsnedkeren.dk/fop/t2.zip. Suggestions are appreciated. We are considering redesigning this to avoid using tables so much, but if better performance can be achieved with what we have, that would be nice. Basically the JVM in which this runs, has a very large heap and little CPU to spare, and spends much too much time garbage collecting, as well as take quite a while in rendering. By accident I first checked with the code in HEAD, which did not work well, so I am convinced that 1.0 is still some time away :) -- Thorbjoern Ravn Andersen "...plus...Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: spending too much time in PropertyList.findProperty
Steven McNeel wrote: (2) org.apache.fop.fo.PropertyList.findProperty -> 26.4% - this is the other main culprit. The time spent here is divided fairly evenly among the following three methods of PropertyListBuilder: computeProperty -> 8.8% isCorrespondingForced -> 5.7% getShorthand -> 5.8% Similar numbers are found with OptimizeIt (6.21%, 7.9%, 7.78% respectively) with JDK 1.4.1 under Windows with FOP 0.20.5. Those three were the top 3 hotspots. It also appears that I have CPU and memory problems with FOP due to too complex tables. -- Thorbjoern Ravn Andersen "...plus...Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there going to be another release of the 0.20 branch?
Chris Bowditch wrote: No, no further releases are planned from the maintenance branch, and all development is focused on CVS Head. I am browsing through archives to find pointers for performance improvement, and found the above comment a bit confusing. Why having a maintainance branch, if you do not intend to release anything from it? This is an issue since I cannot use unreleased CVS code even if it performs much better. -- Thorbjoern Ravn Andersen "...plus...Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How Generate .fo file from PDF?
Robert Paris wrote: Here's the problem/need. I have users who know how to create PDFs and MS Word documents (only by using MS Word though). I have seen a pdf2svg tool that can convert your PDF to SVG, which FOP can read. Then put your information on top of that. I have only tested this as a proof-of-concept in case we needed to do the same. -- Thorbjoern Ravn Andersen "...plus...Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: docbook pdf
Derek Poon wrote: file:/home/poond/flowdemo/cvs_trunk/docu/book/build.xml:118: org.apache.fop.apps.FOPException: file: /home/poond//cvs_trunk/docu/book/build/book_pdf_en/book.fo:1:65589 Flow 'xsl-region-body' does not map to the region-body in page-master 'blank' You probably have an incorrect FO-file. The trial version of XEP gives quite good error messages, which may help you figure out exactly what is wrong. -- Thorbjoern Ravn Andersen "...plus...Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug in FOP release 0.20.5
Stan Pinte wrote: How can I figure out what's happening? You may have an invalid XSL-FO file. Either validate it against a DTD or XML Schema if such a thing exist, or use the trial version of XEP from RenderX to check as it reports such things. -- Thorbjoern Ravn Andersen "...plus...Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]