Paulo, it was (is) my first attempt to remedy for the problem by making one only instance of the DefaultFontMapper in our application. And every thread uses this one. But still it takes too long for the DefaultFontMapper to read in our font directory. We cannot afford the time on app startup, and even less on the first 'toPdf'-action. All I'd expect from the FontMapper is to build a table mapping font-name and -attributes to the appropriate font-file, so that the fontfactory later will know which file to load (avoiding a scan of the font directory in each FontFactory.getFont()-call). But the DefaultFontMapper does way more than that, apparently it instantiates each possible font... and then throws most of each instantiated font away again.
Cheers Erwin > -----Original Message----- > From: Paulo Soares [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 14, 2002 11:28 AM > To: Erwin Achermann; iText ML (E-Mail) > Subject: RE: [iText-questions] DefaultFontMapper.insertDirectory is > (too) slow > > > There's no problem here. First of all the class DefaultFontMapper is a > generic class that may not be suitable for all the cases. You > can sub-class > it or create a new one if special capabilities are needed. > You only have to create an instance of it once and then use > it everywhere in > other threads; I don't think the load time is that important > in this case. > Lazy evaluation would require scanning the directory and > reading all the > files to find the font, saving no time in the process. > > Best Regards, > Paulo Soares > > > -----Original Message----- > > From: Erwin Achermann [SMTP:[EMAIL PROTECTED]] > > Sent: Friday, June 14, 2002 10:08 > > To: iText ML (E-Mail) > > Subject: [iText-questions] > DefaultFontMapper.insertDirectory is (too) > > slow > > > > Hi Bruno, > > > > we are facing the problem, that inserDirectory processes > 250 font files, > > consuming more time than acceptable (8 seconds). I was > browsing to code > > and observed that for each font file a basefont is created. > This includes > > loading mapping tables (which is what we need in the first > place) but this > > also include construction of kerning tables, and numerous other > > datastructure: > > > > TrueTypeFont.process() > > ... > > fontName = getBaseFont(); > > fullName = getNames(4); //full name > > familyName = getNames(1); //family name > > fillTables(); > > readGlyphWidths(); > > readCMaps(); > > readKerning(); > > ... > > > > I would propose that these font information are only loaded > when the font > > is actually needed in the document, and thus speeding up the > > insertDirectory-call. A lazy Font construction, if you wish. Is this > > problem recognized, planned to be solved or am I completely > mistaken here? > > > > > > Cheers > > Erwin > > > > > > _______________________________________________________________ > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > August 25-28 in Las Vegas - > > http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > > > _______________________________________________ > > iText-questions mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/itext-questions > _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ iText-questions mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/itext-questions
