On 13.09.2005 15:47:12 Victor Mote wrote: > 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.
I just found this: Appendix E of the PS bible, uhm, PostScript Language Reference (third edition) says: "While there is not a standard set of fonts that is required by the PostScript language, most PostScript products include software for 13 standard fonts from the Times, Helvetica, Courier and Symbol families." Looks like you can't even be 100% sure that the base 14 fonts are available. > > 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. Let's look at it from another side. If someone writes some kind of FO editor or a configuration tool for FOray/FOP a method that reports all available fonts will certainly be useful. :-) > 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 > document. No, I think there will definitely come a point in time where I will want some kind of object holding on to global font configuration but which is not a static mechanism. Although it's possible to reuse the FOUserAgent, the user agent IMO is something that is bound to a rendering run. We simply haven't finalized the API, yet, or I'm at least not ready to call it finalized. :-) > > 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 > file. > > 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. No, that's true. I simply haven't cared, yet, about finding out how glyphs are accessed on-the-fly in PS that are not accessible through the encoding. Rewriting the encoding seemed easier. > 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. I bet. Sounds good. > Anyway, there are some more options for you to consider. We're surely not going to run out of discussion topics and things to do. :-) Thanks for your input. Jeremias Maerki
