Jeremias Maerki wrote:

> In the back of my mind I have a reminder that AWT has some strange
> behaviour in font handling making it difficult to produce high-quality
> text. Looking at org.apache.fop.render.awt.AWTFontMetrics there is a
> pointer to an AWT bug. There's other code in there that hints at
> deficiencies in AWT. And there are differences between JDK versions!

Acknowledged. Being quite a bit of an incrementalist myself, the scope of
the project that I am contemplating revolved around only the FontMetrics --
in other words, it would only replace the font metric information that we
currently get from the generated XML files. Layout and rendering chores
could be added later, iff they made sense. Are the problems you are seeing
related to the metrics or to other issues? Obviously if the basic metrics we
get out of AWT are bad, that would be a deal killer.

In addition to the JDK version, there is a JRE issue here as well that I
neglected to mention. Since the createFont method doesn't exist until 1.3,
wouldn't that be the minimum JRE that could be used to run FOP if we rely on
that to get unregistered font information?

> - ...but will we be able to get at the physical font in order to embedd
>   it in the target file? While quickly looking into the AWT API I
>   haven't found anything approriate. And where will we configure that a
>   particular font should be embedded?

This is a good point. I don't see where java tells us how to get to the
physical file either. However, we have to configure a path to the physical
file now to embed the font, so we aren't really going backwards on this
issue. Also, I see no problem with using the current scheme for configuring
the embedding (i.e. if "embed-file" exists, use it, otherwise, don't embed).
The trick will be, if we use the AWT, to teach the users how to make sure
that the names match or map properly. We may need to build a q&d tool to let
the users see the fonts (and names) on their system that AWT can see.

> - Will we have enough information out of AWT to produce high-quality
>   text? For example, you need accurate information for the placement of
>   under/overlines and superscript stuff.

If we are talking about metric info only, I think so, but I could be wrong.

> So having said that and considering what has been said before I think
> relying on AWT for font handling cannot be the only answer. I'm still on
> the same track as before wanting a font manager for FOP that can handle
> multiple font sources. This means a good heap of work but will give us
> the necessary flexibility to cope with almost every situation. That
> doesn't mean we have to provide everything immediately. Incremental
> improvement will do just fine.

You have convinced me. Here is what I propose: Hide both the current design
and the AWT fonts behind a class that is used everywhere within FOP. If the
AWT approach is flaky for any reason, we can always fall back on the current
approach, but we can then experiment at will with AWT (at the metrics
level). To make this work, we'll need to look in the configuration info for
fonts before looking at AWT. This also means we don't need to do anything
with createFont for the moment, which also makes the JRE issue go away. The
downside is that we won't be able to mess with AWT for layout help (unless a
similar approach is taken to hide the differences there).

I think that will keep me busy for a couple of minutes :-) Thanks again for
all of the good insight.

Victor Mote

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

Reply via email to