> > 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.
I'm not a guru on this but the AWT font metrics are not that bad just not fully complete. Using our own FontMetrics abstraction means that we can adapt to other metric sources. That's what is in place and what I think can be built upon. So yes, the problems I see are related to font metrics. > 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? I think so. This is another reason not to rely too heavily on AWT. Once we have the possibility to supply JDK-dependent code it will make it easier to provide the best functionality possible. > > - ...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. I agree. Maybe we can simplify the embedding business by just having a section in the configuration where you can supply a list of font names that should be embedded. That provides an opportunity to break away from having to register each single font though that should still be possible. I'd like to go as far as providing an extension so you could specify in the FO file that some particular font should be embedded (but that's for later). > > - 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. I hope so. :-) The AWT renderer already relies on this but I know there are noticable differencies between PDF and AWT output. The issue of producing the same output with different renderers has come up several times already. I'm talking mainly about font metrics at the moment. There are several areas to the whole discussion though: - font metrics (has an effect on the layout/appearance) - available fonts (different font types and sources, different quality of information) - font embedding (how do I get to the physical font and how do I transform it for the target format) - character encodings - speed and memory consumption issues (forgot anything?) > > 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). Right. What would that class you propose be? I don't think you have to change a lot, just do a refactoring step to streamline the whole stuff. If you like my font manager approach (which handles the different font sources), maybe that's your class to build. It would be rather cool if the font stuff could be moved from the layout and render packages over to the font package so it is pretty isolated. Also makes it easier to work on and to provide a clean solution. > I think that will keep me busy for a couple of minutes :-) Thanks again for > all of the good insight. Glad to help where I can. One last question: you're planning to work on the redesign branch, right? Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
