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

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".

-------

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.

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.

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.

Victor Mote (mailto:[EMAIL PROTECTED])
2025 Eddington Way
Colorado Springs, Colorado 80916
Voice 719-622-0650


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

Reply via email to