The problem with this is that the file ist completly read in to generate a new basefont. Because the FontFactory.createFont(...) calls new TrueTypeFont(filename, ...) and similar for other file types, only to get the names of the font String names[][] = bf.getFullFontName(); and then bf=null; again.
I would hope that a FontMapper.getFullFontName(filename) could be implemented without really building a new basefont, but only by peeking into the file. How difficult would that be? Cheers Erwin > -----Original Message----- > From: Paulo Soares [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 14, 2002 12:34 PM > To: Erwin Achermann; iText ML (E-Mail) > Subject: RE: [iText-questions] DefaultFontMapper.insertDirectory is > (too) slow > > > If you just need a couple of fonts use this class (untested): > > import com.lowagie.text.pdf.*; > > public class SpeedFontMapper extends DefaultFontMapper { > > /** Inserts a single font into the map. The encoding > * will be <CODE>BaseFont.CP1252</CODE> but can be > * changed later. > * @param file the font file name > * @return <CODE>true</CODE> if the font was inserted > */ > public boolean insertSingleFont(String file) { > String name = file.toLowerCase(); > BaseFont bf = null; > try { > if (name.endsWith(".ttf") || name.endsWith(".afm")) { > bf = BaseFont.createFont(file, BaseFont.CP1252, false, > BaseFont.NOT_CACHED, null, null); > String names[][] = bf.getFullFontName(); > bf = null; > insertNames(names, file); > } > else if (name.endsWith(".ttc")) { > String ttcs[] = BaseFont.enumerateTTCNames(file); > for (int j = 0; j < ttcs.length; ++j) { > String nt = file + "," + (j + 1); > bf = BaseFont.createFont(nt, > BaseFont.CP1252, false, > BaseFont.NOT_CACHED, null, null); > String names[][] = bf.getFullFontName(); > bf = null; > insertNames(names, nt); > } > } > } > catch (Exception e) { > return false; > } > return true; > } > } > > Best Regards, > Paulo Soares > > > -----Original Message----- > > From: Erwin Achermann [SMTP:[EMAIL PROTECTED]] > > Sent: Friday, June 14, 2002 11:05 > > To: iText ML (E-Mail) > > Subject: RE: [iText-questions] > DefaultFontMapper.insertDirectory is > > (too) slow > > > > 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 > _______________________________________________________________ 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
