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.

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.

> 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. When you add vector (EPS and SVG)
into the mix to make a complete Graphic package, there are some other
things.

> 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. FontConsumer is
an interface that the client application implements, and, it can return null
for the logger if it wants to. The FontServer implementation then has to
deal with that, presumably by using its own logger as a default.
Constructive suggestions about better ways to deal with this are welcome.

The last time I looked at HEAD logging (a year ago??), it looked like every
class that needed a logger was an extension of one of the Avalon logging
classes. The approach I have used is vastly superior to that. If it *does*
need to be changed (and it might), it only needs to get changed one place
instead of 500.

> 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!)

OK. Message received.

Victor Mote

Reply via email to