J.Pietschmann wrote:

> Jeremias Maerki wrote:
> > 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.
> That's probably the X Windows font registry which is used by the
> AWT, whose fonts are in turn used by Batik.

That makes sense, and I'll investigate it further on my Linux box. I
hesitated to do so before because I assumed that the use of the font metrics
files was to overcome a limitation here, perhaps when running *n*x in
character mode.

Jeremias Maerki wrote (speaking of problems with font metrics in Type 1

> 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

If java can see the font files, this work has already been done for us. I
guess I am trying to push the level of font abstraction up a notch or two
higher if possible.

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

My three proposals were predicated on the assumption that there was some
cross-platform need for the generated font metrics information. If in fact
we can find a way to register the fonts at the O/S level and let java see
them that way, would that not be better than any of the three options above?
The following objections come to mind:
1. Refactoring work. Answer: True, but all of the other options generate
work as well, including the status quo (which generates work for the user,
and support questions for us).
2. We exchange support of font metric generation for support of getting
fonts registered at the O/S level. Answer: True, but it would seem that
these would pretty much offset.
3. This might reduce FOP functionality on some platforms (ie. if unable to
register the fonts, can't use them anymore). Answer: True, and this is the
one that concerns me the most. However, they won't be able to run Batik
either (if I understand correctly). Is it safe to assume that all *n*x
platforms have or could get an X environment?

Unless java.awt.GraphicsEnvironment can be tricked into seeing unregistered
fonts, the current design and using java.awt.Font seem mutually exclusive.
It would be very helpful to hear comments about objection 3 above (potential
reduced functionality on some platforms).

Thanks to both Jeremias & Joerg for their help. I think I have enough to
keep me busy for a while.

Victor Mote

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

Reply via email to