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 fonts): > 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]
