Re: [xsl] creating multiple pdf-files from one xml
Andreas L. Delmelle wrote: -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] So we not can assume the xml->xsl->fo processing was had via Xalan--and even if it were so, it also could have been done via its translets (compiled XSLT) feature. Aw, great! You just *had* to come and throw that one in as well, didn't you... ;) No, seriously. I was indeed looking at Xalan's API merely for an example of how to deal with such for one particular processor. This seems already difficult enough --if we could get a basic framework for that, maybe it would facilitate the emergence of ideas on a more general, vendor-neutral approach... Cheers, Andreas Indeed, we should be able to use their code...we both have the same Apache copyright. Glen
RE: [xsl] creating multiple pdf-files from one xml
> -Original Message- > From: Glen Mazza [mailto:[EMAIL PROTECTED] > So we not can assume the xml->xsl->fo > processing was had via Xalan--and even if it were so, it also could have > been done via its translets (compiled XSLT) feature. > Aw, great! You just *had* to come and throw that one in as well, didn't you... ;) No, seriously. I was indeed looking at Xalan's API merely for an example of how to deal with such for one particular processor. This seems already difficult enough --if we could get a basic framework for that, maybe it would facilitate the emergence of ideas on a more general, vendor-neutral approach... Cheers, Andreas
Re: [xsl] creating multiple pdf-files from one xml
Andreas L. Delmelle wrote: Nightmares... Anyone to come and chase them away? Please...? ;) One thing to keep in mind, although I'm unsure of its relevance to this discussion, is we use Xalan only through JAXP--so if I'm not mistaken, the user is welcome to replace that with another JAXP-compatible XSLT processor such as Saxon. So we not can assume the xml->xsl->fo processing was had via Xalan--and even if it were so, it also could have been done via its translets (compiled XSLT) feature. Glen
RE: [xsl] creating multiple pdf-files from one xml
> -Original Message- > From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] > 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' Something just struck me; might be a lot easier than I thought... Instead of looking at the attribute of the extension element, we need to check the root node of what is created inside... if that's a fo:root, we're in business. Cheers, Andreas
RE: [xsl] creating multiple pdf-files from one xml
> -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
RE: [xsl] creating multiple pdf-files from one xml
Andreas L. Delmelle said: >> -Original Message- >> From: Chris Bowditch [mailto:[EMAIL PROTECTED] > >> Andreas L. Delmelle wrote: >> >> >> >> > The related class in Xalan: org.apache.xalan.lib.Redirect >> > >> > It contains a HashMap, m_outputStreams, which is, >> unfortunately, protected, >> > so can't be queried from outside the xalan.lib package... >> >> Whats wrong with sub-classing, e.g. FopRedirect extends Redirect. > > Hmm. Good point indeed! (I don't even wanna think about how long it would > have took me to discover this by myself... after having tried and > considered > almost every other thinkable and way-too-complicated way of solving this > ;) ) > > Cheers, > > Andreas 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! -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
RE: [xsl] creating multiple pdf-files from one xml
> -Original Message- > From: Chris Bowditch [mailto:[EMAIL PROTECTED] > Andreas L. Delmelle wrote: > > > > > The related class in Xalan: org.apache.xalan.lib.Redirect > > > > It contains a HashMap, m_outputStreams, which is, > unfortunately, protected, > > so can't be queried from outside the xalan.lib package... > > Whats wrong with sub-classing, e.g. FopRedirect extends Redirect. > Hmm. Good point indeed! (I don't even wanna think about how long it would have took me to discover this by myself... after having tried and considered almost every other thinkable and way-too-complicated way of solving this ;) ) Cheers, Andreas
Re: [xsl] creating multiple pdf-files from one xml
Andreas L. Delmelle wrote: The related class in Xalan: org.apache.xalan.lib.Redirect It contains a HashMap, m_outputStreams, which is, unfortunately, protected, so can't be queried from outside the xalan.lib package... Whats wrong with sub-classing, e.g. FopRedirect extends Redirect. Bummer! Cheers, Andreas .
RE: [xsl] creating multiple pdf-files from one xml
> -Original Message- > From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED] > Far better would be if we could somehow get a handle to the streams the > redirection extension writes to. Place a buffer in between, and we're set. > Much faster, no need for a workaround of any kind. > But here, I think, is the point Glen was concerned about: the XSL > processor > might suddenly decide to drop the reference to that stream (upon finishing > one file) and close it... how would we make sure the stream stays opened > until FOP is finished with it? > The related class in Xalan: org.apache.xalan.lib.Redirect It contains a HashMap, m_outputStreams, which is, unfortunately, protected, so can't be queried from outside the xalan.lib package... Bummer! Cheers, Andreas
RE: [xsl] creating multiple pdf-files from one xml
> -Original Message- > From: Clay Leeds [mailto:[EMAIL PROTECTED] > > > In my application we create multiple page-sequences using multiple > "xsl:include" templates, which _look_ different, but are still one PDF > file. If certain flags are set in my source XML, my app creates: 1) a > bill; 2) a disclaimer; 3) a letter; 4) an extra document. All except > the Bill are optional. I suppose that, using iText or some other > post-processor, these could be extracted into separate files. Yup, I advised him to take a look at iText. Apparently, he already had, but wanted to keep it strictly an XSL-FO solution... > Even better, of course would be "no workaround" needed, whereby > FOP would just create separate files. Better still, would be for FOP to > create separate files, *and* be able to link portions on-the-fly. > His own (preliminary) solution was to re-open the redirected files in his application (using embedded FOP) after the main rendering run. Indeed suboptimal as he himself stated (open/close/open/close...) Far better would be if we could somehow get a handle to the streams the redirection extension writes to. Place a buffer in between, and we're set. Much faster, no need for a workaround of any kind. But here, I think, is the point Glen was concerned about: the XSL processor might suddenly decide to drop the reference to that stream (upon finishing one file) and close it... how would we make sure the stream stays opened until FOP is finished with it? And then there's the question on whether you would want FOP to wait to start a new Driver run until the main one finishes, or whether you would want to start a new run in a different Thread (--good exercise this would be, that's for sure) Cheers, Andreas
Re: [xsl] creating multiple pdf-files from one xml
On Feb 13, 2004, at 3:34 AM, Andreas L. Delmelle wrote: -Original Message- From: Kloeck, Erwin To: [EMAIL PROTECTED] mulberrytech. com (E-Mail) Hi, I have to create several pdf-files out of one xml document. Currently I write several fo-files using redirect:write to disk during xsl processing and then read them in again for fo processing. This strikes me as sub optimal. Does anybody have any ideas or pointers for a more straight forward process, i.e. one not requiring the intermediate writing to disk? This one appeared on Mulberry today... Damn', am I psychic or what? ;) Cheers, Andreas Damn! You're psychic! (not to mention IMHO, a boon to the FOP project as well!). In my application we create multiple page-sequences using multiple "xsl:include" templates, which _look_ different, but are still one PDF file. If certain flags are set in my source XML, my app creates: 1) a bill; 2) a disclaimer; 3) a letter; 4) an extra document. All except the Bill are optional. I suppose that, using iText or some other post-processor, these could be extracted into separate files. Perhaps this might be a workaround-type solution if one is looking for one. Can iText be used for this type of extraction? It appears so[1]. Perhaps that interaction could be improved if FOP supported some sort of PDF "comment", which iText could look for. That may not be necessary, though. Even better, of course would be "no workaround" needed, whereby FOP would just create separate files. Better still, would be for FOP to create separate files, *and* be able to link portions on-the-fly. [1] http://www.lowagie.com/iText/tutorial/ch13.html#tools
