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. :-)

OK. That makes sense. To avoid wasteful parsing, it will mean that at least
3 new classes need to be exposed through interfaces (RegisteredFont,
RegisteredFontFamily, and RegisteredFontDesc), which may be a good thing

Yes, I think it could be interesting. It would also be necessary to add getStream methods, now that font parsing is delegated to the font server. Currently there is only one getPDFFontFileStream method. There should perhaps be also a getPSFontFileStream, and something like getPDF/PSSubset? It seems that the client is unable to make font subsetting with the current interface.

RegisteredFontFamily and RegisteredFontDesc might also be interesting for the AWT renderer, but that's another purpose. I'll perhaps come back on this later.

(more below)

Very good. It sounds like you and I may end up with API visions that match
better than I might have thought at one 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

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.

I am very sure that for Type 1 fonts, specifying another encoding is the
only way to get it done. There is just no way to get more than 256
combinations out of 8 bits and there is no way to get more than 8 bits.
However, the good news is that I am 99% sure that for both PDF and
PostScript you can specify the same underlying font with two (or more)
different encodings. They will actually show up as two different font
"objects" in the document and must of course be referred to that way also.
I'll let you know how that turns out.

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.

The more I think about it, encapsulating the characteristics of a specific
PostScript interpreter is probably the "right" way to go. Then the rendering
run can use that to decide whether the font needs to be embedded or not.
I'll have to ponder that for awhile.

Here I'm beginning to get lost because I don't know the Postscript standard.

My hope to get ready before the upcoming realease starts vanishing... :-(
Here's my summary of the current discussion:
1. Currently the Fop PSRenderer embeds all of the configured fonts in the PS file, even those that will never be used. It does this by parsing itself the font files; 2. I can't reproduce this behavior with aXSL and FOray easily, because I've no direct access to the font files; 3. Still doing this would require hacking the FOrayFont subpackage; that would result in something dirty but that should work; 4. Anyway there are several improvements to bring to the PS renderer: mainly character encoding, font embedding and in a longer term two-pass rendering for a proper font handling.

Now I'm thinking of the next release: simply putting the font name in the postscript file would be rather straightforward to implement, and should work for most of cases (?), thanks to the non-standard but well-known base14 (and even base35) font set. But that's definitely a regression from the current state. Improving the PS renderer to allow proper embedding will require (1) changes to the aXSL interfaces (so a certain amount of discussions), (2) me to learn Postscript. That would prevent the FOrayFont subsystem from being integrated in the pre-release.

Do you agree with my summary?

Integrating FOrayFont in the pre-release would be great...
Deciding to delay the integration would give me more time to investigate the insides of FOrayFont, learn PS and PDF standards and so do things much better.

If there is a decision to make it does not belong to me...

Reply via email to