I'm finding myself a little at a loss to decide what's best. I've
started to convert the render package to events and then noticed
org.apache.fop.svg.SVGUserAgent. It currently just dumps all messages 
(info, alert, error) coming from Batik through the user agent to the
logger. I would also want to catch such messages per processing run, i.e.
the must not be sent to the logger. I see two possible approaches:

1. I just add event methods to an event producer for these methods in
SVGUserAgent. I can probably add some context info for forensics. That
way I'd basically adapt Batik's feedback mechanism to FOP's.

2. I could also build a hook of some sort so the caller/user can control
the creation of the SVG user agent (i.e. slip in his own user agent).
That way, event notifications inside Batik would go directly to the
caller instead of being piped through FOP. As a side-effect, the user
would also have a more direct influence on the behaviour of Batik. After
all, the SVG user agent does much more than just report back events.

Obviously, this topic doesn't just apply to the Batik integration but
for other integrated components, too: the PDF and font packages (which
cannot use the event system as they are going to be moved out), the
image loading framework and possibly more. Every component might have
its own set of events that could be of interest to the user. For
example: font substitution.

Option 1 sounds more straight-forward but somehow 2 feels better even
though it's probably more complex and takes a little experimenting to do
right. It also means that the user has more work and needs to learn
about more than just FOP's event system.

Any thoughts perhaps?

Jeremias Maerki

Reply via email to