From: Adrian C. <ad...@ah...> - 2006-02-28 10:32:36
|
>there is a way like xslt transforamtion, with xsl-fo. >You can find an implementation of this standard at apache web site ( >http://xmlgraphics.apache.org/fop/ ). There's quite a steep learning curve with XSL-FO. I came across an xslt stylesheet some time ago called something like XHTML2FO.xsl which allowed you to generate your output as XHTML then transform it to FO and then push it through FOP to get pdf. You could search google for it. Adrian. Michael Beddow wrote: >[Sava Jurisic] > > > >>What I need is ability to "somehow" link the XQUERY output from our eXist >> >> >DB > > >>(perhaps separate xml file) to PDF forms ... >> >> > >[Giuseppe Corrarello] > > > >>there is a way like xslt transforamtion, with xsl-fo. >>You can find an implementation of this standard at apache web site ( >>http://xmlgraphics.apache.org/fop/ ). >>Xsl-fo (xsl formatting object) permit to format any xml document in pdf >>form. You can query your database and then you have only to apply an xslt >>tranformation to create the pdf documents. >> >> > >True, but I'm not sure this will be feasible in Sava's use case. > >If I understand it correctly, these are forms delivered in PDF format by a >third party which his users have to fill in from their own records, held in >an eXist base. So he in effect would need to reverse-engineer the generation >of the actual forms so the responses could be inserted along with the >prompts and layout, then the whole lot regenerated as a new pdf. >For that to work >(a) the layout of the original forms would need to be pretty simple, to >ensure it can reliably be "forged". Generally, bodies that issue PDF forms >do so because they want to prevent respondents from messing around with any >aspect of the form, and they take a dim view of people who send back what >are recognisably their own home-made versions >(b) before committing programming time to this exercise, you would need to >be certain that the layout and content of the forms isn't going to change >(preferably by liaison with the body that produces them). Otherwise, a >change of design (even if in their view only cosmetic) on the part of the >form-issuers could make your application useless. >(c) you would need to check that there were no copyright minefields where >reverse-engineering and reproducing the original form are concerned. > >If all those issues can be solved, and you are prepared to learn the >techniques of driving XSL-FO via XSLT, then you could indeed try the >approach Giuseppe suggests. Another way (still using XSL-FO under the hood, >but avoiding the need to learn anything about it) would be to see if you can >transform your reverse-engineered form plus your users responses data into >Open Office Writer native XML (again, that requires some learning, and I >would't advise it unless the layout is really straightforward) and then pipe >the result through OO and its PDF output module (which runs XSL-FO for you) > >There is software, some of it from Adobe, that allows some degree of editing >of "finalised" pdf documents (so the "reverse engineering" phase wouldn't be >needed) but all the apps I've seen that can do anything really useful in >that area are (a) $$$$$$$$ and (b) clunky/nerdy, so ruled out for your use >case as I understand it. > >Michael Beddow > > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >_______________________________________________ >Exist-open mailing list >Exi...@li... >https://lists.sourceforge.net/lists/listinfo/exist-open > > > |