Frank Schönheit - Sun Microsystems Germany wrote: >Hi Daniel, > > > >>I've been working on a PDF Report Writer, named PDF::ReportWriter, for a >>while now. It's written in Perl. I'm not sure whether that makes it >>unsuitable for OO or not. I would say that this isn't a problem, but >>that's just me. PDF::ReportWriter is a part of an umbrella project, Axis >>Not Evil, which is a suit of open-source, cross-platform Perl modules >>that combine to provide an alternative to a /'leading'/ software >>vendor's RAD design tool for database access. ie it's competition for >>OpenOffice's database module. Not to worry though ... I think we're >>targetting different people with different needs. If people are >>interested in somehow including PDF::ReportWriter in OpenOffice, then >>that's fine by me, particularly if it means more people adding more >>features :) >> >> > >I think we would welcome everything which adds features to OOo :). > >How would a collaboration look like? OOo currently does not ship with >perl, nor does it have a UNO binding for perl [1], so how would OOo feed >your application with data? Are you interested in working on this? > >Ciao >Frank > > I really don't know how you'd approach it from the OOo side of things. Since PDF::ReportWriter requires complex items to be passed into it ( structures that describe fields, groups, and the data array itself ), I suppose the easiest ( and dodgiest ) way of approaching it would be to construct a temporary file in the format of a Perl data structure, and then add support to PDF::ReportWriter for loading the report definition and data from these files. Along the same theme, I suppose I could add support to PDF::ReportWriter for loading a report definition and data from a database.
Without being able to control things from Perl, however, you are making the task of creating complex reports quite difficult. PDF::ReportWriter supports multiple 'render' operations, allowing you to pass a new structure of fields and groups each time ... ie you can report on completely different data sources in the same report. You can also use this feature to render ad-hoc text etc, by packing your text into a data array and passing that in. I'm not sure how you would do this without being in Perl - I'm still relatively new to Perl myself. I suppose you could extend my previous idea of loading the report definition from a database to loading a report /script/ from a database, which would control multiple 'render' invocations with different field / group definitions. I haven't yet considered this option at length, but it sounds interesting. It's also highly likely that there are better approaches around. It's up to people here to discuss whether it's worthwhile pursuing PDF::ReportWriter option or not. As you say, OOo doesn't include a Perl distribution, so I suppose there's a hurdle to get over before you start. Of course OOo already relies on Java for the database module anyway, so IMHO all the arguments for this ( relying on Java ) also apply to Perl. Another option would be to rewrite PDF::ReportWriter in ( God forbid ) OOBasic or Java or something. Note that I'm not exactly offering to do this port - I find detest OOBasic. But PDF::ReportWriter is weighing in at only < 700 lines of code, and I use a lot of whitespace in my code, so I'm sure people who have an affinity for OOBasic / Java / whatever could port it relatively easily ... assuming OOo's PDF rendering support is up to it. Does anyone here know would to script OOo's PDF output thingy? One of the invaluable features of PDF::API2 is the ability to track *exactly* where you are on the page as well as the *exact* size of text you are about to render, allowing you to do things like break to the next page at the right time. Can you do this in OOo? This is obviously required. So. I suppose the best approach, now that I've thought about it, is the last one. I'm sure there would be almost unanimous consensus that OOo should not start relying on further external libraries and languages and things. If I discover that OOo's PDF ability is a) up to it, and b) easy to program, I *might* consider having a somewhat of a bash at it. I assume you want a GUI report designer ... somebody else can do that :) So what do people think? OOo does need a report writer. Which direction do people want to go in? Who knows how to script OOo's PDF abilities? -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: [EMAIL PROTECTED] website: http://www.nusconsulting.com.au --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
