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. It simply has to provide bitmaps as decoded bitmaps and as 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. Sorry to be so negative today.
The code in FOP CVS HEAD already has a refactoring cycle behind it that addressed most of the above issues. What remains is a lack of flexibility in coping with the availability of certain adapters. There should be no hard-coded routing to the individual implementations but rather a priority based plug-in mechanism that makes sure a certain image type is handled properly and by the best implementation available. What's also missing, for example, is a ImageIO-based adapter (in the java-1.4) directory. I nudged a certain Philip Shanks who approached me recently with an offer to help contribute to FOP in this direction. (Hi Philip!) On 12.03.2005 00:43:53 Victor Mote wrote: > FWIW, I just completed extracting an interface for axslGraphic, have made > FOrayGraphic conformant to it, and have made the other FOray modules use > axslGraphic instead of FOrayGraphic. (The one exception to this is the Foray > Application itself, which creates a FOrayGraphicServer if no other > GraphicServer implementation is passed to it -- this is similar to the way > the interface for Fonts works). > > Graphics are much less pervasive than Fonts, so the benefits are not as > dramatic. Nevertheless, flexibility will be gained by writing client > applications to axslGraphic instead of FOrayGraphic. > > The next logical module to axsl-ise is FOTree. I don't see an immediate need > for it. It may become useful in the future for comparing the performance > profiles of the various approaches. However, the cost of building it will be > substantial, and it may not ever be worth it. So I'll probably leave it on > the back burner until someone sees a need for it. > > Victor Mote Jeremias Maerki
