View source for Kexi/Plugins/Reports/Reusing word processors

=== RFC: Proposal for the future Reusing KWord's framework (kotext) as reporting layer for Kexi ===
While we're both agree with dfaure that this '''may work''', here is some discussion log from #koffice irc channel (2004-03-26).

Please help with your advice...

-- begin log --

[dfaure] i.e. generating kword documents for reports? interesting, but isn't kugar the tool for this?

[js] 1) For me, it's not developed to heavily now .... 2) reusing it at a current state would lead to rewriting parts of it... If kword supports floating textboxes, etc. (that's a requirement coming from OASIS, I suppose? ) - it can be usable for Kexi (by floating I just mean a possibility of inserting data in particular place on a page

[dfaure] Sure kword supports text boxes, that's its main feature

[js] good, it's most expected reature to allow absulute positioning of text/data boxes withing the report page AFAIK, reusing rich paragraph features from kword -- this would outperform MSAccess functionality ...and could avoid requirement of doing a mailmerge by exporting to kword.. etc. etc. I hope, if it's good idea, not so much "generalization/glue" should needed in KWord / kotext libs ... on the other hand: strategically, both Kexi and KWord could benefit from increasing interest thanks to that unique reporting framework

[dfaure] yes, koffice is starting to cover a much broader scope than OOo

[dfaure] I'm a bit unsure how you want people to create templates with kword where things have to be repeated, etc. (for every record)

[js] there are ideas: AFAIK OASIS have definable variables within a doc?

[dfaure] sure; kword too

[js] so you just can create a page as a template and Kexi will put values in the variable fields (of course this can be done transparently, via GUI and using kparts)

[dfaure] yes but what if you want "client: XXX bill number: NNN" for every client? you need to say which part of the document must be repeated

[js] ok, you mean nested reporting levels; that's why i told about generalizing kword's framework Couldn't we add something like (schematically speaking):
  <foreach ...>
   <your OASIS doc part/>
  </foreach>
(of course more nested levels would be possible)

[dfaure] yes. But the XML is the easy part, more difficult is how do users enter this in the application It sounds to me like you'd want to create a new application around libkotext. ..which uses the richtext rendering etc., but which doesn't do page layouting etc. in "creation mode". In creation mode, you want users to create the above structure, so that's where it's a bit like kugar ;) Kugar with a libkotext core rendering engine :)

[js] Exactly Btw, you know, it's a bit about talking fantasy because I wouldnt touch this until 1st kexi stable (september), however it's good if we all would know what is on the horizon..

[dfaure] ok. that's good anyway, since libkotext might change a lot since then :)

-- end log --