On 16.11.2010 16:12:53 Vincent Hennebert wrote: > On 09/11/10 14:43, Jeremias Maerki wrote: > > On 09.11.2010 14:48:30 Vincent Hennebert wrote: > >> There may be an interest in fully embedding a font for PostScript > >> output. IIUC there may be a print manager that pre-processes PostScript > >> files, extracts embedded fonts to store them somewhere and re-use them > >> whenever needed. It can then strip the font off subsequent files and > >> substantially lighten them, speeding up the printing process. > > > > It makes the files smaller, but that will be the only thing that > > improved printing performance. The PS interpreter still has to parse and > > process the actual resource. It also needs to be noted that extracting > > subset fonts doesn't make sense. I've already added the unique-ification > > prefix to the TTF font names (like in PDF) to avoid problems like that. > > That doesn’t solve the problem. AFAIU always the same prefix will be > used for the same font. If different FO files are being rendered into > PostScript using the same config file, then the PS outputs will all > contain the same font name. That may cause serious issues if > a post-processing tool concatenates all the files but uses the font > instance from the first file only. I think that violates the DSC > specification.
Right, I've blindly taken over the approach that was done for PDF where this problem does not apply because you can have two subset fonts with the same name. I assumed the prefix was a pseudo-random number but I failed to verify that. > The only way to ensure uniqueness is to compute some hash sum based on > the glyphs used. That may be costly. The alternative is to put the font > stream directly in the page stream and not advertise it as a DSC > resource. Yes, the hash is too costly. But a good hash would also have to be longer which also increases the PS file size due to the potentially numerous findfont calls. Putting the font in the page stream means you have to subset the font for every page because the DSC spec is also broken if the font is incrementally built inside the various pages. Restarting the font for every page makes the PS files very big. I think the only thing you can do is to get a near-uniqueness by using pseudo-random values for the prefix. That dials the risk for a colision down (but doesn't completely rule it out). Anyway, applying lots of DSC postprocessing to various PS files (split, concat, imposition etc.) screams for use of non-subset fonts. Even then it makes sense trying not to mix PS files from too many sources (FOP or otherwise) for one print stream. It only produces potential problems. So my take: 1. if you want to print many smaller PS files, use font subsetting. 2. if you are dealing with larger print streams and do PS post-processing, don't use font subsetting. ...which makes the uniqueness discussion less of an issue. Jeremias Maerki
