Jeremias Maerki wrote: > TextInfo looks better but could IMO be merged with FontState which only > hold the font name and size and a link to the FontMetrics. Anyway, I > think this merged class will be a candidate for the Flyweight pattern so > we don't generate so many TextInfo/FontState objects (one for each FObj > I think). Brings up the question of efficiently looking up existing > Flyweights, on the other side.
I also saw elements of the Facade pattern here on the font stuff. I documented some of these thoughts at http://xml.apache.org/fop/dev/fonts.html. I suppose a wiki would have been better & that is pretty much how I viewed this page -- the point is to feel free to hack away at that document if you wish. It looks like you have started some of the moving and consolidating work that needed to be done with the scattered classes. I thought that most of the surviving font-related classes should be private & used only by a Font class that was a Facade for all of the underlying types of fonts, including (eventually) AWT fonts seen by any existing graphical environment. I was all set to put the FontInfo into static variables so that it didn't have to be passed around so much. I see that multiple threads make that a bad idea. What we need (and probably already have -- I haven't had time to look) is the equivalent of a Document class that the FontInfo lists can be put into. Thus, our Font, Typeface, and TypefaceFamily classes apply to an FOP Session, but the /Document/ object keeps a list of at least Typeface information for purposes of embedding & listing at render time. The /Document/ object needs to get passed almost everywhere, but at least all I think the FontMetrics should eventually be seen only by the Font object. However, it might need to be a Facade itself to deal with the different ways font metric information can be returned. To get the Flyweight working, when a Font resource is requested during layout, we have to look in the tables of pre-existing objects (this should be static), and either return an existing one or create a new one, then also update the /Document/ info. Something like FontState or TextState (one or the other) is probably good to keep pointers to all of this stuff (including Font) in one place. However, since the other items are basically (I think) boolean in nature (underline on or off), maybe it is just as good to simply pass the area object around which should have all of this stuff. One of the "bad smells" was the amount of information that had to be passed to get anything done. I don't know how this matches up with where you are going, but I thought I ought to throw it out there FWIW. You are probably way ahead of me on all of this. Also, I thought that a discussion of how "Session" stuff is separated from "Document" stuff for multithreading might be worthwhile. It will probably be a couple of weeks before I can get back into this much. Sorry to be on the sidelines for a bit. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
