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



> Glen (it's apparently "Xalan Week" over here at FOP...
> ;)

Reply via email to