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

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
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...? ;)



Reply via email to