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]
