I know exactly what you mean. The only way around this is to do a two-pass approach when writing PostScript, meaning that you keep track of resources (like fonts) while writing the pages and later you put together the complete PostScript document by including the needed resources in the right places. Obviously, that means loosing a lot of processing speed. PDF is in a better position because it's a random-access file format while PS is streaming. We can add the font objects to the PDF after we've already used them. On the other side, the PDF generated this way cannot be not a linearized file which allows "Fast Web View". The browser always has to load the whole PDF file to display it because the cross-reference table is at the end of the file. So, even PDF has, in a way, the same problem.
So you see: the problem is speed versus beauty. BTW, that was the reason why I started introducing a better resource handling with PS support, so we can later add such a mode where we write the PS file in a two-pass approach. On 12.09.2005 21:40:11 Vincent Hennebert wrote: > In PSDocumentGraphics2D.writeFileHeader (and also in > PSRenderer.startPageSequence) the font dictionary is written into the PS file > by > a call to PSFontUtil.writeFontDict. > At this time all of the fonts present in the fontInfo (defaults + those found > in > the config file) seem to be written out, even those that won't be used in the > fo > file. > > I'm a bit worried because I can't reproduce that easily with FOrayFont. All I > can get is the set of fonts that were used within the document. I guess that > rendering starts as soon as possible and that at the time when the file > header > is written out the whole document may not have been entirely parsed yet? (but > the PDFRenderer only stores used fonts by making a call to > FontInfo.getUsedFonts!? This also is the case in PSRenderer.stopRenderer). > > So the question is: is there a mean to only put used fonts when writing out a > PS > font dictionary? This would be cleaner anyway. > > I hope I'm clear. > Vincent Jeremias Maerki
