> -----Original Message----- > From: Clay Leeds [mailto:[EMAIL PROTECTED] > > Can you give an example of how would his look? Would it be an ant task? > Would it be some type of java class? Thanks! >
Well, Maestro, started to think about subclassing, but I'm not sure in what form *exactly* yet, neither whether it will solve the riddle... Thing I haven't quite figured out: how to _reach_ them from within the formatting process? how to _catch_ the redirection events from the XSLT, and keep them in the process? Maybe best to break it down to a few smaller questions (--easiest first, I think): How do we test, from within our current API, whether there's any XSL-FO-redirection at all to be taken into account? Or, to describe in XSLT terms, I think closest would be: all elements in the vendor's redirection extension's namespace having their target URI attribute end in '.fo' --I take it to be beyond discussion that one names one XSL-FO files '*.fo' ;) Besides, it leaves a foot between the door again when you don't actually need the redirected FOs rendered. One for the docs! .. Ouch! Forgot the following possibility: a template creating redirection events, but with a variable target URI... (could be '.fo', could be anything; you don't know that at stylesheet compile-time :) sorry, a bit of Schadenfreude...) .. So *if* this part is dealt with, we could then eventually set up our possible FOP-Redirect subclass (or whatever?), and what would it do? This still leaves the question as to how the vendor's redirected output-streams are going to be 'collected' in that subclass... Before the XSL transform begins, you can find out (maybe even quite easily) *that* redirected streams are going to be created, but they're not created yet at that stage. Nightmares... Anyone to come and chase them away? . . Please...? ;) Cheers, Andreas
