Re: Performance PDFRenderer vs. PCLRenderer
Andreas L. Delmelle wrote: How precise is PDF anyway? Should placement of block-containers be near 100% correct? If all other related settings are correct ( in particular the print settings in Acrobat ), this should be the case, It depends. Acrobat Reader still seems to have roundoff problems in the screen rendering, and I got odd inaccuracies in print apparently due to the "unprintable" paper frame, which is different from printer to printer. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Performance PDFRenderer vs. PCLRenderer
Andreas L. Delmelle wrote: > > -Original Message- > > From: Michael Reiche [mailto:[EMAIL PROTECTED] > > > > On søn, 2003-11-02 at 14:39, Andreas L. Delmelle wrote: > > > > > Well, the FOP Output Targets page > > (http://xml.apache.org/fop/output.html) > > > does indicate that SVG support for the PCL Renderer is > somewhat limited. > > > > As far as my testing have been done, I found following errors (or > > missing features) in the PCLRenderer: > > > > No SVG! > > > Could be... I have never needed PCL output so far, and I have at > the moment > no PCL printer at my disposal, so I can't confirm That's why > I'm sending > this in CC to the fop-user list. Maybe over there, someone has more > experiences to share ? > > If SVG support for PCL is really *that* limited, this should definitely be > mentioned on the website. http://xml.apache.org/fop/output.html#pcl-limitations says "SVG is not supported." Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Performance PDFRenderer vs. PCLRenderer
> -Original Message- > From: Michael Reiche [mailto:[EMAIL PROTECTED] > > On søn, 2003-11-02 at 14:39, Andreas L. Delmelle wrote: > > > Well, the FOP Output Targets page > (http://xml.apache.org/fop/output.html) > > does indicate that SVG support for the PCL Renderer is somewhat limited. > > As far as my testing have been done, I found following errors (or > missing features) in the PCLRenderer: > > No SVG! > Hi Michael, Could be... I have never needed PCL output so far, and I have at the moment no PCL printer at my disposal, so I can't confirm That's why I'm sending this in CC to the fop-user list. Maybe over there, someone has more experiences to share ? If SVG support for PCL is really *that* limited, this should definitely be mentioned on the website. > White text on red background ended up beeing black (b/w printer). > I would call this a bug... If you know how to use bugzilla for bug-reporting, it's better to use that. ( http://nagoya.apache.org/bugzilla ) That way it will certainly get the attention of dev. If you don't (--or if you're too lazy ;P ), let us know and we'll enter one. In any case, can you send us a minimal version of the FO you're trying to render? Makes reproduction of the issue a bit more straightforward, IYKWIM. > Alignment on page is different than PDF-output. Perhaps due to the fact that the SVG is not correctly rendered? (Not certain at all, just guessing) > How precise is PDF > anyway? Should placement of block-containers be near 100% correct? > If all other related settings are correct ( in particular the print settings in Acrobat ), this should be the case, I presume. Best to check this with Acrobat's grid view. Up to now, I never really had any problems with coordinates deviating slightly from what I specify in FO, but then again, I have never really needed 100% exactness WRT placement of text and/or graphics. I'm thinking of something I've mentioned before on this ( sometime, can't remember when :) ) : I would certainly advise to use the same measurement units throughout the FO... ( If your page dimensions are defined in cm, try to use metrics everywhere for defining spaces and coordinates. ) The more conversions needing to be made, the greater the probability that some numbers get rounded or truncated... Greetz, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Performance PDFRenderer vs. PCLRenderer
> -Original Message- > From: Michael Reiche [mailto:[EMAIL PROTECTED] > > I use an embedded version of FOP, primarly to keep the Java "hot" > getting benefit from JIT. PCL-output is top priority rather than PDF. > But I face the problem that the PCL-renderer is rather slow compared to > the PDF-renderer (which my initital testing was based on ). > > I feed FOP with an XSL-FO document, which in this test generates 7 pages > (source is 176464 bytes). The document contains in-stream SVG-graphics, > which the PCL-renderer completly ignores - thats another challenge. Its' Well, the FOP Output Targets page (http://xml.apache.org/fop/output.html) does indicate that SVG support for the PCL Renderer is somewhat limited. This shows itself in the source, I guess, where the PDFRenderer contains import statements for the Batik bridges as well as a reference to the java.awt.geom lib (as opposed to the PCLRenderer). If you really want to have a go at extending the PCLRenderer to offer the same support as the PDFRenderer, I think this is your starting-point. Explanation for this probably lies in the fact that Batik offers direct SVG2PDF conversion via its Rasterizer (which in turn uses FOP's PDFTranscoder), so every once in a while, members of the Batik dev-team or Batik users happily provide FOP with a few patches to enhance the SVG support when rendering to PDF. > running in Java1.4.2 on Linux in a headless environment. > > Timing of the 6 first runs of the same document, each sequence starting > from a new "cold" Java VM, is like this: > > > Notice that the PDF-renderer just needs 1 run to benefit from JIT, but > the PCL-renderer neverer improves performance. It should be noted that > the server running the Java VM is doing nothing besides my tests. > I'm not too well-informed about the particulars of JIT, but the PDFRenderer *is* the most advanced Renderer offered by FOP. Maybe a redesign of the PCLRenderer modeled according to the current PDFRenderer could improve performance in this way. ( I, for one, would be *very* curious to see how the Batik team would respond to a full-fledged PCLTranscoder ). Currently the PCLRenderer consists solely of a PCLRenderer and a PCLStream, whereas the PDFRenderer has a whole lib (org.apache.fop.pdf) at its disposal, allowing for a more controlled and detailed optimization. > A note regarding the PCL-rendering: starting with the 2. run the first 3 > or 4 pages renders quickly, but then a complete slowdown occurs. This > could indicate massive garbage collection or.? > Could be... Have you tried changing the size of the JVM heap? If that has an impact, this would indeed be what is happening over here. > I've had my eyes on both PDFRenderer.java and PCLRenderer.java, but I > haven't been able to spot that magic difference. Could it be that the > PDF-renderer has suffered from the same performance-problem, and someone > remembers how it was improved, or otherwise has some tips to improve the > PCL-renderer? Browsed through the fop-dev list searching for this, but haven't yet found traces of previous discussions about this. I have noticed that the PCLRenderer was donated to FOP, whereas the PDFRenderer was there from the very start. My guess would be that, initially it was more of a convenience-addition, allowing to skip the intermediate generation of a (physical) PDF and send the output directly to the PCL printer ( same goes for the PS Renderer ). Suggestion would be to study the PDF rendering process very closely, and try to 'mimic' it in terms of PCL, maybe this gets you on track ...? And of course, when you *do* decide to make changes like this, and they turn out to work properly and improve performance, don't forget to let us know about this :) Hope these help! Greetz, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
