It looks as if the pdf transcoder is still painting text as shapes. As a result PDFGraphics2D.fill takes most of the time for transcoding. (Yes we finally ran the system through a profiler).
I noticed there is a PDFTextPainter available, but it wasn't being used. When we tried it, the text wasn't being placed correctly (It seemed to be ignoring the x and y attributes on the tspan element). I've also got the textAsShapes property on the Graphics object set to false, but it looks like the StrokingTextPainter bypasses it (based on my very limited knowledge of the code) and paints the text as shapes anyways. I had to extend and overwrite much of PDFTranscoder (for the pagination), so its entirely possible I missed something in my code (although i don't see anything related to text painting). Is there anything else I should look for or try? If you want me to paste some code or want any other information let me know. I'll let you know if I find out anything else. Thanks, Tom -----Original Message----- From: Litton, Tom - CEPM [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 01, 2005 6:30 PM To: [email protected] Subject: RE: improving the pdf transcoder performance I just updated our stuff to use batik 1.6. There wasn't any noticible performance improvements for us. I still haven't run it under any performance profilers yet, so I can't say there wasn't any improvements. -----Original Message----- From: Litton, Tom - CEPM [mailto:[EMAIL PROTECTED] Sent: Thursday, May 26, 2005 8:49 AM To: [email protected] Subject: RE: improving the pdf transcoder performance We are transcoding the SVG to PDF and sending that to the printer using CUPS (which is capable of printing PDFs directly). So, in both cases the SVG is transcoded in the same way and then sent to 2 different destinations (email and printer). We originally were using something similar to the PrintTranscoder that I wrote, but that produced large images that were taking too long to spool. As far as buffering the output stream, I'm currently using ByteArrayOutputStream and keeping the document in memory. I've tried writing it out to a temporary file instead, but that was much slower. Maybe I should try that again, except use buffering with it. I briefly messed with upgrading to batkik 1.6, but the resulting PDF image wasn't scaled correctly. However, I may have grabbed the wrong transcoder. I'll try it again. Thanks for your help, it is certainly appreciated. Tom -----Original Message----- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Thursday, May 26, 2005 1:24 AM To: [email protected] Subject: Re: improving the pdf transcoder performance Now there's some interesting information in there. You say you're using the print API. Does that mean you actually don't really use the PDFTranscoder but only the PDFDocumentGraphics2D in conjunction with JPS? If yes, you have to be aware that the faster text painting routines from the PDF Transcoder can only be used if Batik controls the painting. That's because Batik uses some special extensions to the Graphic2D interface that allows more sophisticated painting operations. Just printing to a Graphics2D (via JPS) results in even more of the text being painted as shapes which takes time because these extensions can't be used. That's probably the reason why you identified GraphicsNode.paint as time consuming. If you say that PDFDocument.output() consumes a lot of time then please make sure that the OutputStream you write the output to is buffered (decorate with java.io.BufferedOutputStream). I've done some performance testing on FOP recently where I discovered that the PostScript renderer is about 50% slower if its OutputStream isn't buffered. On the other side, it didn't really make a big difference for the PDF output since most output is buffered in memory buffers anyway, though not with BufferedOutputStream. But I think it's worth to check. I'm not sure when the snapshot of FOP was taken for the Batik 1.5 release. There have been certain improvements in that part. I think you should consider upgrading to 1.6 so it's easier for us to help you. On 26.05.2005 05:41:20 Litton, Tom - CEPM wrote: > I've done some very crude performance testing (basically printing the > times to the log file), just to get an idea of what is happening. > > It seems you were right. Most of the time is spent in the call to > GraphicsNode.paint, but a non-significant amount of time is spent on the > call to PDFDocument.output. > > Whats stranger is the times vary greatly depending on the destination of > the file. Emailing the pdf is much quicker then printing it. I'm > guessing java's print api takes up alot of memory and slows things down? > > I'll try to get a hold of better tools (like JProbe). > > I hope you find this useful. > > By the way, i'm using batik 1.5. It looks like the PDFTranscoder is > rather old as well (not sure what version of fop it came from). > Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- The information contained in this transmission is intended only for the personal and confidential use of the designated recipients named herein. If the reader of this transmission is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this transmission in error, and that any review, dissemination, distribution, or copying of this transmission is strictly prohibited. If you have received this communication in error, please notify the sender and return and delete the original transmission immediately. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
