[reportlab-users] Using report lab for generating database reports.

John Leach reportlab-users@reportlab.com
Wed, 11 Sep 2002 00:12:19 +1000

I have a Forms Designer which is a Python tkinter GUI.
This then generates a python script with calls to python methods to call the 
reportlab methods to output the fields.
The script can be edited manually.
It's not quite what you have in mind but my experience in producing business 
documents such as Invoices, Purchase Orders etc is that it is possible to 
edit the script so it gives good results in all cases without manual 
intervention. This is done by having two passes through the data - one to 
work out the pagination - and the second pass to output the information.
This approach may work for you.
John Leach

On Tue, 10 Sep 2002 22:33, Henning von Bargen wrote:
> I consider using reportlab as a reporting toolkit
> in conjunction with an Oracle database application.
> Oracle provides a feature-rich reporting solution
> called "Oracle Reports", but it is expensive
> and the problem we have with it is that the end-user
> can not modify the output.
> Examples:
> 1. In order to change a text constant on the report,
> the user has to edit the report definition file
> (a binary format), so he has to open it
> with the quite complex Oracle Reports Builder tool.
> 2. The same is true if the change should be done only
> for one particular document and not for the report definition in general.
> (this could be achieved with Adobe Acrobat)
> 3. Deleting, inserting or modifiying the length of layout elements
> is much harder and can never be achieved in the resulting PDF file,
> because page-breaks can change.
> (usually, the position of all flowables following a flowable X in a story
> depend on the position and size of A.
> 4. There are always some cases in which the layout algorithm
> produces "ugly" page-breaks, even if 98% of the produces documents
> look fine.
> It would be fine if would could "manually override" the page-breaks.
> My idea of an ideal reporting solution is that the resulting documents
> is generated in two steps:
> (i) The "story" file is created from the database data.
>     This story could be RML markup
>     (sorry, but I think that RML is still too expensive)
>     or just a python script that uses an application-specific class-library
>     based on the platypus package, but provides a simpler interface.
>     Note that the story does not contain any code to fetch the data,
>     it is just an ASCII representation of what will be printed.
>     A simple story file could look like this:
>     story.add (Header1 ("Hello World!"),
>                Paragraph ("This is a simple example."),
>                Table (rows=3,
>                       cols=2,
>                       content=[HeaderRow ("Column A", "Column B"),
>                                DataRow ("A1", "B1"),
>                                DataRow ("A2", "B2")
>                               ]
>                      )
>               )
> (ii) The resulting PDF file is generated and rendered, together with 3
> buttons
>     "Accept", "Modify", "Cancel".
> (iiia) In most of the cases, the user will "Accept" the generated file
>     and submit it (print it or send it via e-mail or just save it).
>     The application could now save the story file together with the PDF
> file in an archive or in a document management system.
> (iiib) In rare cases the end-user decides that he wants to
>     make some slight changes to the document. So he clicks on "Modify".
>     Now he can directly edit the story file - somehow.
>     Then continue with (ii) again.
>     When finally saving the files in (iiia), save both
>     the original story file as well as the modified version.
> The easiest way to implement "somehow" would be to modify the file
> in an ASCII editor.
> This would enable a not too dumb user to modify text.
> A halfway clever user could also delete or insert paragraphs
> and table rows into the story.
> An expert user could even change the page-breaks by
> - adding spacer objects or page-break objects into the story at the places
> he likes
> - adding space-before or space-after attributes of some elements.
> A much more complex approach
> (but I think _possible_ with ReportLab, compare the platypus debug mode)
> would be to allow the user to change the story file by
> clicking with the mouse in the generated PDF file.
> Then the cursor would be positioned at the corresponding position in the
> story file.
> Even more complex approach: Complete GUI for editing the story file.
> Is anyone already using reportlab this way at least thinking about it?
> I'd also like to know if someone is using ReportLab for printing multi-page
> nested tables.
> Henning
> _______________________________________________
> reportlab-users mailing list
> reportlab-users@reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users

Scanned for viruses at osware.net