> My guess is the demand for this is still quite low (esp. WRT pdf output), > due to the extended functionality offered by the Acrobat SDK, which allows > the .NET-minded ( C# / VB ) folks to _easily_ generate pdf output from > whatever source they want (w.o. the intermediate use of anything like > XML/XSL-FO). > I don't see FOPs main use as a means to generate PDFs on platforms without Acrobat support, but instead to generate PDF (and more) from a standardised XML layout.
Acrobat SDK has no functionality that even remotely resembles FOP. Not only does it lack the layout engine of FOP, but its intended purpose is not to generate pdf output, it's to interact with Acrobat. There are of course a bunch of commercial solutions (DynamicPDF, TallPDF etc.) which is great for PDF generating apps, but.. 1. They lack the layout engine 2. They are not open source. The .NET community is generally quite fond of open source. 3. They are not based on FO, and standards are nice. What you gain from using them is speed, but since most of them don't have to care about the layout part, that is quite understandable. Do I think the FOP project should consider .NET? No! It should definetly focus on Java. There are more important issues than .NET availablility. Would a .NET port be worthwhile? Very much so. > As far is I understand M$ tactics, they'll just wait for fop-dev to complete > their work, then suddenly release some nifty tool called Microsoft > FO-'something'? (perhaps add it as a supplement to Office 2006, which will > of course be released in fall 2007 ;) ) > They just might do that, and while they're at it, they'll probably launch an alternative to PDF... /Gunnar PS. Currently I'm using FOP from .NET using a Web Service wrapper, which works just fine, although there is some overhead in this solution. DS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
