Hi Victor Good that you spoke up, so we can discuss this.
On 08.01.2003 19:31:35 Victor Mote wrote: > 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. Have seen that now for the first time. I shall check the design docs more frequently in the future. :-) > 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. A Wiki is probably easier to work with in this case. CVS update, edit, CVS commit, Website update is a lot of work. I'll start a Wiki page and add my thoughts to it. We can always transfer the contents back to XML later. > It looks like you have > started some of the moving and consolidating work that needed to be done > with the scattered classes. Yep, it also helped me understand a lot more about its "design". It has grown too much over time. > 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 see it this way: As you already figured out there are several aspects to the font subsystem: - Provide information (font metrics -> FontMetrics) for the layout process - Provide information (more detailed font metrics, pointers to font files -> FontDescriptor) for the various output format handlers. I don't say "renderers" here because the PDF library is actually the recipient of the font information. - Management of various font sources (file-based, AWT...) - Management of the fonts actually used during a rendering run. - Parsing of font files During the refactoring I've made FontDescriptor extend from FontMetric. That was a natural thing to do at that point. Thinking about this some more, I don't think that was a wise move. From an SoC (Separation of Concerns) point of view this is bad, because I mix the concerns "information for layout" (ex. Ascender depending on the font size) and "information for output formats" (ex. Ascender for standard font size). It's probably best to break off a common anscestor interface (probably containing on two methods: getFontName() and getFontType()). FontMetrics und FontDescriptor will then extend from that common interface. A font implementation may implement one or both interfaces. AWT output will probably only implement FontMetrics. > 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 Is that sentence finished? Anyway... I don't like FontInfo. I want that to be an interface. Last night, I've come up with a few ideas that I'm going to add to the Wiki page. There's more and more Avalon that should be taken into account. I'm slowly starting to understand how Avalon can be used within FOP. > 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. No, I think it's the other way around. FontMetrics should only be seen by the layout engine. I don't even know what a Font object will be. We'll have to define what a Font object is, if something like that will ever exist. The Font object for me is just an implementation of a font. Nothing that will be used directly, at least by the layout engine, well, probably by the output handlers that need to access a myriad of values for font registration. > 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. No statics please. We'll use an interface for lookup. The interface will be provided (IoC) to the objects that need font lookup (through Avalon's ServiceManager for example). You'll see that I have a two-step font lookup in mind. One step is the low-level registry of fonts (all fonts that are available, a number of font sources provide fonts) and the other is some kind of selector that returns fonts that are usable by the set of renderers (the idea of having multiple renderers in one run plays in here) used in one rendering run. This second step will also do font substitution. > 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. yes, and the amount of little objects that are similar or equal that are generated. That's the reason for the Flyweight pattern. > 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. We'll see how this matches up. We probably have to start with synchronizing our dictionaries. I also think that it's VERY important to properly discuss things like Session, Document, Rendering run, FOP instances etc. Where to cache what? What objects/services hold/provide which objects/services etc. Uh, I'm just going to create yet another Wiki page for that and see what good comes from there. I think this is very important to understand how Avalon fits into this. > 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. I hope that I will have finished some preparational work (especially Avalon) until then, so we can move forward. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
