On 13.03.2005 16:30:13 Victor Mote wrote: > Jeremias Maerki wrote: > > > I've had a quick look. I'm afraid that what you already have > > there wouldn't be good enough for FOP CVS HEAD. There are > > suspicious references to PDF and PostScript, for example. IMO > > a general image adapter should not know anything about the > > way the images are used later. > > First of all, thanks for taking the time to look at it. > > The reason for creating aXSL was to make a place where FOP and FOray and > anybody else who is interested can negotiate the differences, or at least > attempt to. I have not attempted to lay out a standard that you should > either take or leave.
My bad. Sorry. > I understand your concern about the "suspicious" references to PDF and > PostScript (there are some for SVG also). These items are certainly > negotiable. The reason they are there is because without them, I have to > either 1) expose details of EPS files through the interface (specifically > the bounding box), or 2) add interfaces for the specific image types. I > thought 1 was unacceptable and that 2 was very undesirable. The tradeoff > between adding one format-specific method and one format-specific class went > to the method for me this time. I don't mind rethinking that. Might be the same as 2) but 3) would be to subclass the Graphic interface to expose additional info such as the bounding box (->EPSGraphic). > > It simply has to provide bitmaps as decoded bitmaps and as > > raw image data (for JPEG and EPS). Also, the Avalon Logger in > > No. You are thinking of an image adapter. Yes, I am. > 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 improvements but mainly in other parts than this. > > raw image data (for JPEG and EPS). Also, the Avalon Logger in > > there is suboptimal. > > That's an implementation detail and should not be present in > > the interface specification. Obviously, that also applies to > > axsl-font. > > 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/framework/container/ContainerUtil.html <snip/> Jeremias Maerki
