Thanks. This looks very helpful. I've passed it on to our Arabic printing team.
Best Regards, Jonathan Levinson -----Original Message----- From: Vincent Hennebert [mailto:vhenneb...@gmail.com] Sent: Wednesday, February 03, 2010 5:36 AM To: fop-users@xmlgraphics.apache.org Subject: Re: FW: New FOP Hi Jonathan, Jonathan Levinson wrote: > I gave my team a FOP I built from trunk and it is much slower in rendering > seemingly because of extra time spent in font processing. Does anyone know > if this is an issue with FOP trunk? A change has been made to FOP Trunk to support TTC fonts. Without knowing more about the change, I can only assume that TTC fonts were not handled before and now are, which causes the loss of performance. There probably are log statements whose level could be reduced from info to debug. But, most of all, I wouldn’t enable font auto-detection, unless you don’t know in advance which fonts you are going to use. If you do, then it will be more efficient to configure them by hand, like this: <font embed-url="path/to/font.ttf"> <font-triplet name="FontName" style="normal" weight="normal"/> </font> That way, only the fonts that will actually be used will be parsed. HTH, Vincent > Best Regards, > Jonathan Levinson > > From: Andy Robb > Sent: Thursday, January 28, 2010 10:26 PM > To: Jonathan Levinson > Subject: RE: New FOP > Importance: High > > Hi Jonathan > > I applied this to our 2 reports dev servers, and I hit a significant issue > with one of them, which has necessitated rolling back the change on that > server. > > What happened is that after applying the change, the reports on that server > were taking 30-40 seconds to run, rather than the usual 2-4 seconds. When I > looked into this, I could see that on this server, the log file for FOP was > much larger than usual - around 30kb, and looking at the file all the entries > were related to TTC fonts collections. See attached log file for details. I > could also see that it was the call to FOP that was taking the extra time - > the xml & xsl files were generated almost instantly, and it was the pdf > generation that was the delaying factor. > > I compared the xml, and xsl files generated between the different FOP > versions, and the 2 dev servers, and they were identical in all cases for the > same report. > > I checked the fop.xconf file, and we have font auto-detect enabled, which is > recommended in the FOP docs as the most efficient way to construct the > required font metrics for a report. These settings had not changed when > upgrading FOP, and were the same as the other dev server. The only difference > between the 2 servers is that in the windows fonts folder, one server (which > runs Windows Server 2008) has a series of TTC font collections, while the > other server (which runs Windows Server 2003) has none. > > When I rolled back to the standard FOP 0.95 version, the problem went away, > and no fonts info was recorded in the FOP log. The font auto-detect was still > enabled, and was still working, and the TTC fonts were still present in the > windows fonts folder. > > So, it looks like something has changed in the custom FOP version, which is > causing FOP to do some very time consuming font-related processing for TTC > font collections, although the end result is the report renders exactly the > same as the previous standard FOP version. > > Can you take a look at this, as it's potentially a serious issue for > deploying this custom FOP version. If you need any more info just let me know. > > Thanks > Andy > > ________________________________ > From: Jonathan Levinson > Sent: Thursday, 28 January 2010 1:03 AM > To: Andy Robb; Ajwad Cader; Campbell McKilligan > Cc: Hui Zhao > Subject: RE: New FOP > > No, I welcome your applying this version to your test envirionments. > > Best Regards, > Jonathan Levinson > > From: Andy Robb > Sent: Tuesday, January 26, 2010 11:10 PM > To: Jonathan Levinson; Ajwad Cader; Campbell McKilligan > Cc: Hui Zhao > Subject: RE: New FOP > > Thanks Jonathan, we'll stick to this version for now then. > > I assume we need a new runwithfop.bat aswell at some stage? > > If you're ok with this current FOP version, and there are no immediate > changes in the pipeline, do you have any concerns if we apply this version to > our Test environments? If there are imminent changes then I'll hold back for > these. > > Cheers > Andy > > ________________________________ > From: Jonathan Levinson > Sent: Wednesday, 27 January 2010 3:14 AM > To: Ajwad Cader; Andy Robb; Campbell McKilligan; Robert Nagle > Subject: RE: New FOP > > Please continue to use old FOP that I sent you a few days ago and do not use > new FOP from this morning. > > Problem is breaking SVG support for Arabic text. We don't use SVG support, > so is harmless, but still older patch I sent you which restricts scope of > patch to PDF is correct. We need to handle additional formats outside of PDF > - on a case-by-case basis. Right now we just want to support PDF. > > Best Regards, > Jonathan Levinson > > From: Jonathan Levinson > Sent: Tuesday, January 26, 2010 9:24 AM > To: Ajwad Cader; Andy Robb; Campbell McKilligan > Subject: New FOP > > I changed the FOP code so that now in addition to Arabic PDFs we support > Arabic rtfs, AFPs, PCLS - all the other FOP output file formats. > > This represents the FOP I gave to Robert Nagle to submit to Apache FOP > organization as a patch. > > Best Regards, > Jonathan Levinson --------------------------------------------------------------------- To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
