Re: Report generator

Well, if you have a look to my project, at, 
you'll see all the features it has (The version on cvs has more features 
yet). The only feature I am not committed to do, even in Qt, is the graphic 
designer :(

I am decided to por it to GTK, but I need support from the GTK developers.
When I say porting it to GTK, I mean that I am going to abandon the 
development on Qt.

Here is a list of the main features that are fully implemented:

- OO design that allows the use of any kind of input or output. 
    - Current inputs: SQL, CSV, XML, Cached report, user defined
    - Current outputs: X, HTML, Text, XML, Open Office, Cached report, user 
- Definition of the report layout in XML. Unlimited number of objects, 
grouping levels and subsections.
- The measures of the objects can be given in mm, cm, inches, dots and 
percentages, and can be mixed.
- Comprehensive set of properties: Styles, fonts, colors, borders, margins, 
mask, formats, background images, alignment, adjustment, etc.
- Summary values: sums, counts, etc., both as total and running.
- Formulae that allow to change the properties of any object and perform 
calculations on the value of the objects.

In this moment, I am working in a trhee pass processing on the report to 
handle the use of summary values at the top of the group sections, and to be 
able to use expressions like page 1 of 20.

I have realized that in order to port it to GTK, I only need a very simple XML 
parser, a Date class and some classes to access databases. Here is where I 
need the suppor from this list.


On Wednesday 04 May 2005 05:41, Daniel Kasak wrote:
> Rodrigo Moya wrote:
> >On Wed, 2005-05-04 at 09:14 +1000, Daniel Kasak wrote:
> >>Francisco Santiago Capel Torres wrote:
> >>>Hi,
> >>>
> >>>I am porting my report generator done in Qt to GTK.
> >>>Before going on, could you tell me what other report generators are
> >>> already done or being done for GTK under the GPL?
> >>
> >>None.
> >
> >there is Papyrus:
> Yeah I know papyrus.
> I actually donated some money to get a couple of issues fixed ( which
> the author did promptly ).
> It's quite temperamental. I especially didn't like some of the
> formatting issues it had. Apparently this was due to it using latex. I
> found it incredibly difficult and frustrating to get a simple report
> working, and it offers practically no debugging information if something
> goes wrong. Plus it's written in C ( I'm using Perl ), so it really was
> a challenge to get working - even to get it compiled.
> I *did* like the XML report definition, which I hope to clone in
> PDF::ReportWriter down the track.
> I *didn't* like the idea of papyrus performing the query itself - I'd
> rather be able to pass the data in. And yes I know I can dump the data
> in a temporary table and the point papyrus at it ... this is what I
> ended up doing.
> Also, I'm pretty sure that papyrus didn't support colour. Oh yeah plus
> there was no GUI for it last time I checked, but the author was working
> on one.
> Anyway, the frustrations that latex caused me and the author led me to
> believe that a better way to go about things was to write something ( in
> Perl of course ) which renders to Postscript or PDF directly, and now
> that I've got a proof-of-concept in under 400 lines of code that handles
> formatting very gracefully, I stand by that view 100% :)
> I just checked out the homepage of papyrus again. The 'GUI' that it has
> is only a GUI to select which report to run ... not to define the
> report. The report definition still has to be edited in XML. Or am I
> wrong? Not that the XML layout was bad. Like I said, this was one of the
> best things about papyrus - it's just that the damned formatting didn't
> follow what I put in the XML - unless I read from the bible backwards
> while waving a dead chicken in the air...

Tengo que cambiar mi firma
Francisco Santiago Capel Torres
santiagocapel yahoo es

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]