Jeremias Maerki wrote:

> > BTW, are these fonts well defined in the postscript standard? Or do 
> > they only exist in PDF?
> PDF was derived from PostScript, so yes, they are well-defined.

There is a group of so-called Base-35 fonts for PostScript that is a
superset of the Base-14 fonts. I was always under the impression that
PostScript implementations were required to support them just as PDF
Renderers are required to support the Base-14. However, I am currently under
the impression that the Base-35 is more of a convention than a standard, so
it may not be quite as well-defined, but it is probably reasonable to assume
that they are there.

> If the current approach is very difficult to implement, then 
> I think it's best to use the approach with the renderer hint. 

IIUC, the current approach is to define all fonts that are registered and to
embed all that are not Base-14. That is not too difficult to implement, but
I think Vincent's point was that it seemed wrong. It would not be too hard
to add a method that provides a collection of all registered fonts, but the
Font objects returned must actually be parsed, which could be a lot of
wasted overhead. The question would be whether that should be a standard
aXSL method or whether it should be viewed as a hack that would just require
an extension to FOrayFontServer.

Since I gather that FOP will not be supporting the reuse of a FontServer
instance (i.e. each document will have its own instance of FontServer),
perhaps it works fine to just have the user provide a separate
font-configuration file that contains only the fonts needed for the

> I can implement that for you if you want. Only referring to 
> the font name will not work since we currently have to 
> reencode each font to the WinAnsi charset.
> And since each PostScript page should be self-sufficient and 
> removable, we can't do this reencoding when the font appears 
> for the first time.

Actually, you are no longer tied to WinAnsi. We have a lot more flexibility
on encodings than before:
1. All of the predefined encodings for both PostScript and PDF are available
to either platform -- of course, if they are not predefined for the platform
used, they must be written into the output.
2. Both platforms have access to the font's internal encoding.
3. The user can specify custom encodings through the font-configuration

So, if a PostScript document can use the font's internal encoding, and if
the font is known to already be available to the interpreter, I think it
could safely be used by name. But perhaps I have forgotten something.

This may require a new font-configuration item for the font element that
allows it to tell whether it is known to be available to the PostScript
interpreter. There are some other possibilities here as well.

Anyway, there are some more options for you to consider.

Victor Mote

Reply via email to