Hi Victor

On 05.10.2002 22:51:28 Victor Mote wrote:
> Jeremias & other FOP Developers:
> In addition to OpenType support, the other goal that I had for font work is
> to support arbitrary fonts. My initial thoughts in this area revolved around
> using the Java 2D capabilities. I understood that the GraphicsEnvironment
> can only see what the O/S shows it, but it did not immediately dawn on me
> that the more popular O/Ss for running FOP are probably Linux & Unix may not
> have a concept of font registration like Windows & Mac do. (If there is a
> way to register fonts in the character environments of these platforms in
> such a manner that java can see them, please let me know -- I have looked
> for this, but have not found it.)

Don't ask me for details (because I wasn't directly involved) but we had
to register new fonts with Linux so they got available in Batik for SVG.
So there seems to be some kind of font registry in Linux. Don't know
about the other unixes but I guess they will be the same.

> Question: Is it therefore fair to conclude that the reason for using the
> generated XML metric files is to provide a platform-neutral way of getting
> such information, especially for non-graphical environments? The following
> discussion assumes that the answer to this question is "yes".

Not really. I think it's more of a historical thing. In the beginning
there was a class for each of the base 14 fonts (still in use today).
These classes are generated from XML files in the codegen directory.
Then, when I started to get involved, I finished work by others so we
could programmatically register Java classes generated from XML font
metric files (almost the same as today) in FOP. Tore Engvig then took
over, implemented TrueType support and provided a way for FOP to load
the XML font metric files directly. That's how things are today.

> I am thinking through ways to eliminate as much user involvement in using
> non-base-14 fonts as possible. Is there a performance benefit to parsing the
> XML metric files instead of extracting the information directly from the
> font file itself at runtime? If so, then perhaps I should just leave this
> alone. If not, then I see some options for possible improvement, listed from
> least radical to most.

I don't know what would be faster. We'd have to do some performance
measurings. As Joerg said, there's a benefit of being able to edit the
XML font metrics. You may have read the recent problem Paul Thibodeaux
reported with a PS Type 1 font. I've had this kind of problems before.
The reason for that is that currently, only the PFM file of a font is
used to generate the XML font metrics file. The PFM lacks certain values
that subsequently have to be guessed. These guesses tend to be wrong
relatively often. To fix this FOP would have to learn the ability to
also parse the AFM and maybe values from the PFB. I think the TrueType
support may have similar problem but far less often. I'm not sure
because I don't work with TrueType fonts.

> 1. Replace current font-by-font configuration item with a path to the font
> file itself. When the font is used in a session, parse the metric
> information in real time from the font file.
> 2. Add a configuration item that contains a PATH-like list of directories in
> which font files are located. When a font is requested in a session, search
> the path for the font file, parse it, and use it. (There would seem to be a
> performance penalty for this, so it should be optional).
> 3. [This one is only half-baked]. Extend or otherwise hack the
> GraphicsEnvironment and/or java.awt.font classes to "see" non-registered
> fonts as if they were registered. In other words, to parse the fonts from
> the font files (found in the configuration file or PATH) and create
> java.awt.font objects for them that can be used. I do not know whether this
> is feasible, but if it were, it seems like we might gain a bunch of benefits
> from using the Java 2D classes that use these classes. If this is an
> impossible or otherwise bad idea, perhaps it will trigger a good one in
> someone else.

Yes please!!! But don't forget to provide backwards compatibility
(loading a font from a XML font metric file). Depending on what's faster
it may be beneficial to generate an XML font metric file into some
configurable directory acting as some kind of persistant font cache, the
first time the font is loaded. Adobe Acrobat Reader does something
similar, too.

For Type 1 font support that would mean that we have to write a AFM
and/or PFB parser (already on my todo list, but I'm lacking time ATM) so
we get better reliability for these fonts.

> I am betting that some of you have thought about these issues for a while,
> so I ask the questions hoping that you can save me many hours of tedious
> unfruitful work.

Today, making fonts available is the responsibility of the renderer. I'm
not sure if this is good. I'd prefer a central font manager which can
provide fonts from various sources (AWT, directories containing TTFs and
PFBs, legacy font config from XML font metric files etc). The target
renderer(s) then only reports back what kinds of font sources it
supports. We would probably have to provide a way to give some font
sources a higher priority than others depending on the renderer.
Disclaimer: I haven't thought this through to the end.

Maybe we also have to think a little bit about Batik. It depends a lot on
AWT for font management even if we're using it in the context of a PDF
renderer. If I understand it correctly fonts cannot always be rendered
by FOP but have to be rendered by Batik by painting polygons or bézier

I hope this helps.

Jeremias Maerki

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to