Useful info. Thanks! On 16.11.2010 17:48:47 Vincent Hennebert wrote: > Installing a font on a printer is a problem, post-processing > a PostScript file is another one. > > It is indeed an issue to determine how to reference a font that has been > manually installed on a printer. I tried once to install a TrueType font > on a Xerox printer, and the Xerox utility I used for that tried to > convert it. Into what? No idea. > > I tried to reference the Kochi Gothic font manually installed on a HP > printer and using the PostScript name (Kochi-Gothic) didn’t work. > Printing the font list was giving ‘Kochi Gothic’ with the space in > between and AFAIK it’s not possible to use a space in a font name in > PostScript.
Yes, the PS names use hyphens instead. I would also expect the PostScript name from the TTF font to be used. > I tried to reference an ornaments font installed on the Xerox printer, > using the TrueType file provided with the printer to get the metrics. > I got it working be deriving a font with a custom encoding. I don’t know > wether the actual font on the printer was in Type 1 or TrueType format. > The method of deriving a custom encoding would have been the same > anyway. Maybe it was even some proprietary format. Yes, the glyph description type really doesn't matter, as long as you know how to address the individual glyphs (Adobe names or CIDs). > So, it’s difficult to know whether a font that is manually installed on > a printer will be converted or not, accessible as a single-byte font or > a CIDFont, etc. And each make is likely to do it differently. That's what I feared. When analysing the last problem (HP printed some glyphs badly), I started to write some PS code to dump a font dictionary to the console. I didn't get too far. If a PostScript program could be written that creates a report for one or more PS fonts on a printer, we might learn more about how the printer offers the fonts. But if some printers present pre-installed TTF fonts differently than others, that would make the whole thing rather complicated for users which means to recommend embedding full fonts. > However, AFAIU from Chris, there still is an interest to fully embed > a font to allow post-processing by a print bureau. For example, > concatenating several FOP-produced documents into a single big print > job. In that case we don’t care about the printer. Everything remains in > the control of FOP. It’s up to us whether we want to use base fonts or > CID-keyed fonts. And I don’t think the user even wants to know how we do > it, as long as they have the option to either fully embed, or > subset-embed the font. Agreed. <snip/> Jeremias Maerki
