Re: Processing Feedback: How to handle things like Batik's user agent?
On 19.03.2008 21:21:16 J.Pietschmann wrote: Jeremias Maerki wrote: 2. I could also build a hook of some sort so the caller/user can control the creation of the SVG user agent [snip] 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. I also like the second option more than the first. Maybe the two can be combined: let FOP provide an user agent which funnels Batik's messages into FOP's event system and which is used by default, but allow for an override. I'd think of a service mechanism, so that applications which want to consume Batik messages directly just have to drop their jars before the FOP jar into the classpath, and use lazy creation of the user agent. Something like that. The only problem with creating this is a static context: I don't know for which processing run I create the user agent. To be clean, I think this has to be done through the user agent somehow. Anyway, I've decided to keep it simple for now and just implement option 1. If anyone really wants to do more in this area, this can always be added later. Thanks for your feedback. Jeremias Maerki
Re: Processing Feedback: How to handle things like Batik's user agent?
Jeremias Maerki wrote: Something like that. The only problem with creating this is a static context: I don't know for which processing run I create the user agent. I didn't have alook at the actual code, but I thought the Batik User Agent can be created once the first SVG is processed. (Same for user agents for other extensions) The current FOP user agent might be passed to the foreign-extension element which ought to be responsible to create the extension specific user agent, and might provide a context. The FOP user agent might have to get methods to store and retrieve extension specific user agents for use for rendering other extension elements of the same kind. J.Pietschmann
Processing Feedback: How to handle things like Batik's user agent?
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
Re: Processing Feedback: How to handle things like Batik's user agent?
Jeremias Maerki wrote: 2. I could also build a hook of some sort so the caller/user can control the creation of the SVG user agent [snip] 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. I also like the second option more than the first. Maybe the two can be combined: let FOP provide an user agent which funnels Batik's messages into FOP's event system and which is used by default, but allow for an override. I'd think of a service mechanism, so that applications which want to consume Batik messages directly just have to drop their jars before the FOP jar into the classpath, and use lazy creation of the user agent. J.Pietschmann
