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
anyway.
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
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.
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...
Vincent
