Jeremias Maerki wrote: > In the back of my mind I have a reminder that AWT has some strange > behaviour in font handling making it difficult to produce high-quality > text. Looking at org.apache.fop.render.awt.AWTFontMetrics there is a > pointer to an AWT bug. There's other code in there that hints at > deficiencies in AWT. And there are differences between JDK versions!
Acknowledged. Being quite a bit of an incrementalist myself, the scope of the project that I am contemplating revolved around only the FontMetrics -- in other words, it would only replace the font metric information that we currently get from the generated XML files. Layout and rendering chores could be added later, iff they made sense. Are the problems you are seeing related to the metrics or to other issues? Obviously if the basic metrics we get out of AWT are bad, that would be a deal killer. In addition to the JDK version, there is a JRE issue here as well that I neglected to mention. Since the createFont method doesn't exist until 1.3, wouldn't that be the minimum JRE that could be used to run FOP if we rely on that to get unregistered font information? > - ...but will we be able to get at the physical font in order to embedd > it in the target file? While quickly looking into the AWT API I > haven't found anything approriate. And where will we configure that a > particular font should be embedded? This is a good point. I don't see where java tells us how to get to the physical file either. However, we have to configure a path to the physical file now to embed the font, so we aren't really going backwards on this issue. Also, I see no problem with using the current scheme for configuring the embedding (i.e. if "embed-file" exists, use it, otherwise, don't embed). The trick will be, if we use the AWT, to teach the users how to make sure that the names match or map properly. We may need to build a q&d tool to let the users see the fonts (and names) on their system that AWT can see. > - Will we have enough information out of AWT to produce high-quality > text? For example, you need accurate information for the placement of > under/overlines and superscript stuff. If we are talking about metric info only, I think so, but I could be wrong. > So having said that and considering what has been said before I think > relying on AWT for font handling cannot be the only answer. I'm still on > the same track as before wanting a font manager for FOP that can handle > multiple font sources. This means a good heap of work but will give us > the necessary flexibility to cope with almost every situation. That > doesn't mean we have to provide everything immediately. Incremental > improvement will do just fine. You have convinced me. Here is what I propose: Hide both the current design and the AWT fonts behind a class that is used everywhere within FOP. If the AWT approach is flaky for any reason, we can always fall back on the current approach, but we can then experiment at will with AWT (at the metrics level). To make this work, we'll need to look in the configuration info for fonts before looking at AWT. This also means we don't need to do anything with createFont for the moment, which also makes the JRE issue go away. The downside is that we won't be able to mess with AWT for layout help (unless a similar approach is taken to hide the differences there). I think that will keep me busy for a couple of minutes :-) Thanks again for all of the good insight. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
