> -----Original Message----- > From: Glen Mazza [mailto:[EMAIL PROTECTED] > <snip /> > Keep in mind, for FOP's xml+xsl->fo->pdf, we don't > output an intermediate fo file. So there may be *no* > redirected files to keep track of. >
Yah... wonder where these redirected parts would end up in this case... that's up to the processor (Xalan/Saxon/XT). > > (--as > > this may be too processor-specific to deal with in > > our code) and storing > > them in extension elements in the main FO. > > Err--I'm not sure of what you mean by "main FO"--the > redirect mechanism doesn't have a hierarchy--just a > series of separate output files. > Exactly. The main FO is the result of the main transformation (whether stored in a file or not), the redirected output files are, in a way, side-effects of this transformation. Strictly code-wise, Xalan's or Saxon's API could provide us with a file-list of these, or, even better a direct reference to their Result objects (?) If not, we may have to resort to this sort of precaution --instructing users to keep track of these, collect and pass the URIs of the redirected FOs back into the process in some way... > > Our own extension-handling code for the elements in > > question should be able > > to the rest, maybe in combination with an Ant task. > > > > I'm unsure here--our extensions are just for > (additional) formatting objects, perhaps unrelated to > how many FO files are being processed. > Yes, but we'd definitely need a way to trigger a run for them from within the formatting process of what is referred to as the main FO. Extension elements just seemed like one way to go about that. Cheers, Andreas > > Glen (it's apparently "Xalan Week" over here at FOP... > ;) > > > >
