Thought its about time i start mentoning this on main mailing list. > Hello. > > > > > Ok i've started coding but not much coding. As in only got a small > > handful of C files and not even in CVS. Been working on database stuff > > with nasty things like sql parses. We are going for just postgresql > > direct support initially, just for ease of testing, and then we will put > > gnome-db and bonddb support in straight after we got layout sussed. > > anyway. xml file. I've attached it and it gives a good idea of what the > > end thing will look like. Its slightly different to your xml. > > > > I have seen the .xml file and I want to ask you if could you send us > patches for our DTD as modifications request to gnome-db-list gnome org, > I mean, with a few lines with a description of changes done. > > Also, I want start to implement all this in HEAD branch (GNOME 2.0 > version) so I need to work with you (and you with me) to do all as a > team work. Anyway my team (myself, andre (lead), and liam as at the moment) are working on reporting system in our spare time. We labeled it papyrus. If it should be called something else and you have a better suggestion let me know. We want this reporting system to work with gnome-db though still have some backend independent. gnome-print is used a lot for the actual printing, previewing etc. though we ran into a few minor short comings with it which wont take long to modify gnome-print to resolve these (like not been able to run reports non-interactively). libxml is used for rendering xml, langauges can be embedded into the xml but we are still fussing over python (has advantages for linking data but disadvanages with its tabbing), slang (its a bit messy) and guile (well its guile).. postitioning is both relative and absolete. relative been the first choice. data is managed in groups, and groups can be sub sets of groups. Report generation isn't single parse and the whole thing is generated in a 2d workspace before been dumped to gnome-print. This makes it resource hungry but it also gives us the best felixablity. I'm not worrying about the details of the xml files or the database intergration at moment as this is easy stuff. At the moment i'm concentrating on getting the xml overall structure right and making sure we can correctly represent 99% of the reports we would write with it. The embedded langauge wont at the moment let you reorganise the way layout is provided, most of the time you wont need this as your using the langauge to work out what values are displayed where like calc totals. what we arn't working on but would be good if we could have is a front end for generating reports. In regard to your DTD's your definations of xml tags will remain very similar, but the structure is different with the use of groups, group headers etc. I prefer to leave DTD's till i get the thing generating a sample report, which it doesn't do at the moment. the state of the code is that it just parses the xml and greats the nessary layouts and prints lots of debugging info out. it'll be another week or 2 at least before we have it generating simple reports. though i have a forced deadline on this one for mid jan. aggrr. regarding cvs. i'm running this from my cvs server at the moment but i'm fine with moving it tsover to the gnome cvs server but i dont have an account there. also is there tools for mirroring cvs from servers cause that could be another option. i got autoconf, autogen stuff etc already set up.
Attachment:
papyrus.tar.gz
Description: GNU Zip compressed data