Jeremias Maerki wrote: > > When you add vector (EPS and SVG) > > into the mix to make a complete Graphic package, there are > some other > > things. > > Hmm, not so much. I think the implementation in FOP CVS HEAD > is already a good start. As I said, it still needs some
OK. I understand you to be saying here that you could take the FOP CVS HEAD graphics code, and extract an interface from it that would not expose EPS- or SVG-specific items in any way. That is definitely worth looking at, and I'll try to do so within the next few days. > is already a good start. As I said, it still needs some > improvements but mainly in other parts than this. You are talking here about implementation-specific things, right? IOW, FOray's implementation vs. FOP HEAD's implementation? If FOP has made improvements to the Graphic system, then I certainly understand that those would need to be folded into FOray code before FOP would consider using the FOrayGraphic package. But those aren't related to the aXSL interface, right? > > The loggers in the servers are an oversight, and I have > removed them. > > However, I don't think there is a way to get rid of the logger in > > FontConsumer. Because FontServer can serve multiple documents at a > > time, it allows FontConsumer to tell it what logger instance to use. > > The Avalon way is IoC (Inversion Of Control). A FontServer > implementation would simply implement the LogEnabled > interface, as would the FontConsumer. In FontServer you can > set the Logger on a FontConsumer through > ContainerUtil.enableLogging. If a FontConsumer doesn't > support LogEnabled this step is automatically skipped. The > result: all this is hidden in the implementation and does not > have to be exposed in the API specification. > > http://excalibur.apache.org/apidocs/org/apache/avalon/framewor > k/container/ContainerUtil.html I'm confused here. FontServer doesn't *ever* "set the Logger on a FontConsumer." The Logger instance that FontConsumer provides is an optional feature that allows the FontConsumer to control where logging messages that are specific to its document go. FontServer doesn't have to use it, and FontConsumer can simply return null if it doesn't want that feature. IOW, the control *is* inverted. (Remember that FontConsumer is an interface for the *client* side and that one FontServer can server many FontConsumers). But to provide that feature at all, how can FontConsumer tell FontServer what logger to use without telling it what logger to use? That seems like a necessary binding for that feature. Now, if the real quibble here is about Avalon vs. Commons, that can probably be resolved. I'm not up-to-speed on the issues there. And also it wouldn't be too hard to provide both. Victor Mote
