Re: (Chris) Re: Traits
From: Glen Mazza [EMAIL PROTECTED] snip/ I wouldn't worry too much about that. I believe methods themselves don't take up that much memory--and to a certain degree, we're supposed to be a reference implementation--so methods not relevant for all instances of a certain base class should not be defined with that class. Your right methods dont take up much memory. My only concern was increased cost of maintaining multiple copies of the same code. But I guess Trait retrieval isnt exactly rocket science stuff. OTOH not every class that derives from Area will have Padding and spacing attributes. Yes, for that reason I would recommend keeping those methods in the child classes--even if duplicated. Yes this makes sense. snip/ You said you were interested in working with block-centering issues. The examples\fo\basic\normal.fo example in the 1.0 distribution--which I've been looking at--when run for PDF in 1.0 has three errors in it (you can see how it should look if you run it w/0.20.5): 1.) The Extensible Markup Language 1.0 title (the one with a blue background) it not centered properly within the block. This is probably an issue within PDFRenderer.java renderText() function. 2.) The first lines of text within each fo:block incorrectly have a leading space appended to them. I'm looking at this one currently, it's a problem with layoutmgr.TextLayoutManager and fo.flow.Block, not related to the above. I noticed this as well. 3.) The inline font-variant=small caps for Extensible Markup Language in the Abstract section is not working. (However, I'm not trained in fonts at all--this may be very difficult to fix.) Would you like to tackle the first one (and the third, if you want a real challenge)? I'm looking at the second right now (although you're welcome to beat me to it on that one as well!), and the third may not be that bad, given that it's already implemented in 0.20.x (hopefully it can be copied over into 1.0). Thanks for taking the time to find some small issues for me to tackle. As it happens I have already got my teeth stuck into getting padding-left working. I'll write a separate post for that in a minute. I'll definitely add (1) and (3) to my todo list and take a look probably later in the week. snip/ Thanks, Chris _ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger
DO NOT REPLY [Bug 24775] - padding-left in PDF Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775 padding-left in PDF Renderer --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 10:39 --- Created an attachment (id=9153) PDF Renderer patch file
DO NOT REPLY [Bug 24775] - padding-left in PDF Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775 padding-left in PDF Renderer --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 10:40 --- Created an attachment (id=9154) Abstract Renderer Patch file
DO NOT REPLY [Bug 24775] - padding-left in PDF Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775 padding-left in PDF Renderer --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 10:40 --- Created an attachment (id=9155) test FO
DO NOT REPLY [Bug 24775] - padding-left in PDF Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775 padding-left in PDF Renderer --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 10:41 --- Created an attachment (id=9156) resulting PDF
DO NOT REPLY [Bug 24775] - padding-left in PDF Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775 padding-left in PDF Renderer --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 10:53 --- Ooopss. I forgot to include the patch for BlockLayoutManager that reduces the IPD in reponse to padding-left. Ive also included the wrong PDF the one that shows the unaltered IPD, where the text flows out of the body-region. Note that the coloured backgrounds dont follow the block exactly, but this is a separate issue.
DO NOT REPLY [Bug 24775] - padding-left in PDF Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775 padding-left in PDF Renderer --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 10:55 --- Created an attachment (id=9157) Patch for BLock Layout Mgr to reduce IPD for padding left
DO NOT REPLY [Bug 24775] - padding-left in PDF Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775 padding-left in PDF Renderer --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 10:56 --- Created an attachment (id=9158) PDF with padding-left implemented AND IPD reduced
Rendering code/padding left
FOP Devs, As promised Ive done some investigation to work out why padding-left wasnt working. I did a little tidying up in the AbstractRenderer and made changes to the PDF Renderer to get it working. Also, changes were needed to BlockLayoutManager to reduce IPD in response to padding-left. Chris _ Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile
DO NOT REPLY [Bug 24775] - [PATCH] padding-left in PDF Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775 [PATCH] padding-left in PDF Renderer [EMAIL PROTECTED] changed: What|Removed |Added Summary|padding-left in PDF Renderer|[PATCH] padding-left in PDF ||Renderer
alt.design web pages broken
I don't know when it happened, but the alt.design iframes for display of code fragments are broken. They require html files containing the html-formatted code, and these seem to have been left behind somewhere. Could someone who is familiar with what has been happening with forrest have a quick look at this. I'll try to have a look at it myself tomorrow. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: alt.design web pages broken
Only some are broken. I'll check them all tomorrow. Peter Peter B. West wrote: I don't know when it happened, but the alt.design iframes for display of code fragments are broken. They require html files containing the html-formatted code, and these seem to have been left behind somewhere. Could someone who is familiar with what has been happening with forrest have a quick look at this. I'll try to have a look at it myself tomorrow. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
RE: FOP ~ PropertyList search gives linear performance (FROM: fop-user)
Peter B. West wrote: [This message was originally on fop-user. I have moved it here as it is mostly a dev topic.] The approach I took was to resolve all of the properties at every node in the tree during the parsing. As the FO tree builder descends to the leaf nodes, a complete properties array is maintained at each level. Before the tree builder exits a node though, all properties not relevant to that particular node type are discarded (i.e. the property sets are reduced) so that the maximal data arrays are short-lived. The relevant properties are maintained in sparse arrays. FWIW, we now have the FO Tree tied together in a more tree-like way. We have several methods which rely on going up the tree to an appropriate level to get information. Right now, that is mostly high-level stuff like the logger document-level information. For properties, I recommend that we use appropriately-named get methods for each individual property. Then we can hide the data structures behind that modify them as needed. So if a get method sees that the property is inherited, it can get it from the parent node instead of needing to walk through the tree to resolve the value. There is a flaw in this approach which is exposed when markers are processed. Because marker subtrees are conceptually re-parented in the static-content tree of the page on which they are laid out, the properties within the marker tree cannot initially be resolved, and the properties of the static-content trees cannot be reduced. This situation is not catered for in the existing code, but is quite easy to accommodate by not reducing the property sets of nodes in the static-content, and by slicing the marker subtrees out and storing them unresolved for later processing, including property resolution, in the context of static-content. All of this assumes that property resolution cannot be completed independently of layout. This is a major point of difference between me and everyone else on the FOP team, but the implication is there in the Rec. if you read it carefully. I think I agree with your statement that property resolution cannot be completed independently of layout for the specific case that you mention. I think where we differ is about whether the FO Tree can simply store a To Be Determined At Layout value and go on about life, or whether the concept of the FO Tree should be scrapped entirely because of this issue. Victor Mote
DO NOT REPLY [Bug 24791] - Generate .TXT files with FOP into command line
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24791. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24791 Generate .TXT files with FOP into command line [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Summary|Generate .TXT files with |Generate .TXT files with |FOP into command line |FOP into command line --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 22:18 --- It's not a bug, it's a feature. Even if you output text, layout is done like for every other format. THe TXT renderer then puts the laid out content on a coarse grid determined by the characters-per-line and line-per-page parameters. It may happen that lines fall on top of each other.
DO NOT REPLY [Bug 24775] - [PATCH] padding-left in PDF Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775 [PATCH] padding-left in PDF Renderer --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 22:38 --- Chris, for patches, we need the diff -u option with its wonderful +'s and - 's. Could you resubmit the code patches? Thanks.
DO NOT REPLY [Bug 24775] - [PATCH] padding-left in PDF Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775 [PATCH] padding-left in PDF Renderer --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 22:50 --- During my investigations I also found that the code for recording/restoring BPD and IPD for block-containers was duplicated in the AbstractRenderer. I have removed the duplicated code which makes understanding the code in AbstractRenderer a little easier. Chris, I'm not clear on your duplication point--AbstractRenderer is the base class of *every* non-structural renderer--PDF, PCL, PS, TXT, etc., whether the renderer is currently implemented or not. Why are you commenting out generic code in AbstractRenderer based on a particular overridden implementation in a subclass (here, PDFRenderer)? After all, once PDFRenderer overrides a function in AbstractRenderer, it's overridden--where is there a duplication issue? (Also, please clarify *which* methods had the duplication so I can zoom in immediately to what you are talking about--patches--until applied--rarely immediately inform us of that!) Also, commenting out is highly unpleasant here (people forget *why* it's commented out)--if the code is not correct (which I'm not sure of yet, either way), then it should be removed--we always have CVS to bring it back if needed! Thanks again, Glen
DO NOT REPLY [Bug 24775] - [PATCH] padding-left in PDF Renderer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24775 [PATCH] padding-left in PDF Renderer --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 23:04 --- Second thought, never mind w/resubmitting--I can handle these current patches. Just use cvs diff -u in the future though. Thanks!
DO NOT REPLY [Bug 24804] New: - SVG Text to PS Output generates incorrect outlines
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24804. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24804 SVG Text to PS Output generates incorrect outlines Summary: SVG Text to PS Output generates incorrect outlines Product: Fop Version: 0.20.5 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: svg AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have an FO document that includes an inline-foreign-object svg, which includes some text to render (see attached fo). When run, the postscript (as rendered by GhostScript and a PS Printer) is fouled. (see attached image) It appears that the StrokingTextPainter is sending out strokes that the PSRenderer cannot convert to PostScript correctly. Interestingly enough, this FOP/SVG renders perfectly when rendered to PDF, whether using strokeSVGText==true or strokeSVGText==false. I'm using Sun's j2sdk1.4.2_02, and the Batik that came with FOP 0.20.5.
DO NOT REPLY [Bug 24804] - SVG Text to PS Output generates incorrect outlines
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24804. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24804 SVG Text to PS Output generates incorrect outlines --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 23:05 --- Created an attachment (id=9186) Sample FO with SVG text that doesn't render correctly
Re: (Chris) Re: Traits
Glen Mazza wrote: 1.) The Extensible Markup Language 1.0 title (the one with a blue background) it not centered properly within the block. This is probably an issue within PDFRenderer.java renderText() function. This may be due to unstripped spaces, see next point. In any case, justified text seems to be broken. I can't even figure out *where* text justification is done. 2.) The first lines of text within each fo:block incorrectly have a leading space appended to them. I'm looking at this one currently, it's a problem with layoutmgr.TextLayoutManager and fo.flow.Block, not related to the above. That's probably in Block.handleWhiteSpace(), I think because bPrevWasLF starts with false. Ther's probably a superfluous trailing space as well, for a similar reason. Also, it seems that the current imlementation will collapse the two spaces between A and B A fo:wrapper text-decoration=underlineB/fo:wrapper but it shouldn't, there should be one space followed by an underlined space (it's in one of the spec errata). BTW the entire whitespace handling is incredibly wasteful if text is intented with multiple spaces to the level of surrounding elements. 3.) The inline font-variant=small caps for Extensible Markup Language in the Abstract section is not working. (However, I'm not trained in fonts at all--this may be very difficult to fix.) Well, in the maintenance code this was hacked in FOText.layout(), it checked for the font-variant and fed runs of lowercase letters to with a smaller font and uppercased to further processing in LineArea.addText() (through addRealText()). It's not out of the question to do the same in HEAD. Of course, it would be even better to check whether the font understands the small caps variant natively and try to take advantage of this first (there is a reason small caps is a variant, rather than everybody emulating it itself using uppercase and an 80% sized font). This requires extending FontState or something like this. Implementing small caps *efficiently*, well, this is probably a real challenge. J.Pietschmann
DO NOT REPLY [Bug 24804] - SVG Text to PS Output generates incorrect outlines
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24804. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24804 SVG Text to PS Output generates incorrect outlines --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 23:16 --- Created an attachment (id=9187) picture of the rendered postscript (ignore messed-up svg y-position, my bad)
DO NOT REPLY [Bug 24804] - SVG Text to PS Output generates incorrect outlines
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24804. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24804 SVG Text to PS Output generates incorrect outlines --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 23:20 --- Created an attachment (id=9188) okay, this is the right fo file. ignore/remove other one.
introduction
Hello, my name is Bruce Duncan and I'd like to get involved with helping out on FOP. I am currently using the 0.20.5 release to do some pretty simple fo-pdf conversions. The tags I use the most are fo:table, fo:external-graphic, fo:instream-foreign-object, and fo:block (in table cells and header/footer). The biggest issue to me, and the one I'd like to help with is table auto layout. In 0.20.5 I use table-column's with no specified column-width, which gets me the columns evenly sized. In the latest CVS version my columns run off the page, being given an unknown fixed size. What I'd like, of course, is column size based on cell content size for that column. So I guess my question is how can I get involved? Is there an area on the Wiki where individual tasks are posted? Someone who is in charge of this area of development? I hope this was the correct list to post to regarding this. Thanks, Bruce Duncan __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: FOP ~ PropertyList search gives linear performance (FROM: fop-user)
Looks like I really put my foot into it this time ;-) I have repeated the measurements I did yesterday and I think that it is a pretty reasonable conclusion that a lot of resources are consumed by FOP in its rather Byzantine property management code. I just spent a while trying to understand PropertyList and PropertyListBuilder and found out that I need to understand Property and Property.Maker as well. I think I am going to have to help with this part of the project but it is going to take a while. I offered (off-line) to look merging the Alt-Design code in to the main branch but I suspect that there are some different directions associated with this. Perhaps this is the reason it has not been done so far. I am still willing to work on this but I don't want to walk in to a firefight. I believe the measurements I did yesterday and I feel that a bit of algorithm replacement should produce a significant improvement in the program. I would also like to suggest that anyone interested in performance look at Java Memory Profiler at http://www.khelekore.org/jmp/performance.html I suspect there are still major memory leaks in FOP and this is one tool that will help you track them down. -- John Austin [EMAIL PROTECTED]
Re: FOP ~ PropertyList search gives linear performance (FROM: fop-user)
John Austin wrote: Looks like I really put my foot into it this time ;-) What makes you say that? I have repeated the measurements I did yesterday and I think that it is a pretty reasonable conclusion that a lot of resources are consumed by FOP in its rather Byzantine property management code. I just spent a while trying to understand PropertyList and PropertyListBuilder and found out that I need to understand Property and Property.Maker as well. I think I am going to have to help with this part of the project but it is going to take a while. I offered (off-line) to look merging the Alt-Design code in to the main branch but I suspect that there are some different directions associated with this. Perhaps this is the reason it has not been done so far. I am still willing to work on this but I don't want to walk in to a firefight. That way lies madness. When you look into the *actual* requirements for property processing, you may well draw the same conclusions as I did. In fact, when I got to the point of running some comparative timing tests, I had already decided that there were serious flaws in my design which I needed to address before proceeding. Some of those I have already mentioned. I will give you the benefit of my experiences off-line. You may be able to see a way to integrate the work I have done with the current directions of HEAD. I believe the measurements I did yesterday and I feel that a bit of algorithm replacement should produce a significant improvement in the program. The last assessment of the situation that I can recall on this list was that property handling is working satisfactorily so there is no need to pay any attention to it. Yes, really. I would also like to suggest that anyone interested in performance look at Java Memory Profiler at http://www.khelekore.org/jmp/performance.html I suspect there are still major memory leaks in FOP and this is one tool that will help you track them down. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: FOP ~ PropertyList search gives linear performance (FROM: fop-user)
--- John Austin [EMAIL PROTECTED] wrote: I just spent a while trying to understand PropertyList and PropertyListBuilder and found out that I need to understand Property and Property.Maker as well. I think I am going to have to help with this part of the project but it is going to take a while. I offered (off-line) to look merging the Alt-Design code in to the main branch but I suspect that there are some different directions associated with this. Perhaps this is the reason it has not been done so far. I am still willing to work on this but I don't want to walk in to a firefight. It would be great if you can help us out--you may be one of the few that can understand both Alt-Design and our current approach in HEAD--plus you seem to be very knowledgable in code optimization--what we need here. May I suggest, start tentatively sketching out your ideas for properties on our FOP wiki page--you'll probably get comments from many of the other committers. I believe the measurements I did yesterday and I feel that a bit of algorithm replacement should produce a significant improvement in the program. I would also like to suggest that anyone interested in performance look at Java Memory Profiler at http://www.khelekore.org/jmp/performance.html That looks like a fantastic product for us--I did a Google search on it as soon as I saw your screen shots on it--thanks--we possibly should even add it to our team page so others can critique our code as well. I suspect there are still major memory leaks in FOP and this is one tool that will help you track them down. Yes, this is something that will help us get to them--Thanks! Glen __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
