Hi Victor On 05.10.2002 22:51:28 Victor Mote wrote: > 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.)
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. Don't know about the other unixes but I guess they will be the same. > 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". Not really. I think it's more of a historical thing. In the beginning there was a class for each of the base 14 fonts (still in use today). These classes are generated from XML files in the codegen directory. Then, when I started to get involved, I finished work by others so we could programmatically register Java classes generated from XML font metric files (almost the same as today) in FOP. Tore Engvig then took over, implemented TrueType support and provided a way for FOP to load the XML font metric files directly. That's how things are today. > 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. I don't know what would be faster. We'd have to do some performance measurings. As Joerg said, there's a benefit of being able to edit the XML font metrics. You may have read the recent problem Paul Thibodeaux reported with a PS Type 1 font. I've had this kind of problems before. 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 support may have similar problem but far less often. I'm not sure because I don't work with TrueType fonts. > 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. For Type 1 font support that would mean that we have to write a AFM and/or PFB parser (already on my todo list, but I'm lacking time ATM) so we get better reliability for these fonts. > 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. Today, making fonts available is the responsibility of the renderer. I'm not sure if this is good. I'd prefer a central font manager which can provide fonts from various sources (AWT, directories containing TTFs and PFBs, legacy font config from XML font metric files etc). The target renderer(s) then only reports back what kinds of font sources it supports. We would probably have to provide a way to give some font sources a higher priority than others depending on the renderer. Disclaimer: I haven't thought this through to the end. Maybe we also have to think a little bit about Batik. It depends a lot on AWT for font management even if we're using it in the context of a PDF renderer. If I understand it correctly fonts cannot always be rendered by FOP but have to be rendered by Batik by painting polygons or bézier curves. I hope this helps. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
