New reporting system (Re: Again font size when printing)

[Josh Sled]

On Thu, March 29, 2007 3:16 pm, two old wrote:
> First I agree a script should output content to a HTML template. The
> template would secure the way my invoices or reports look on every update
> of GnuCash or even an update of the script.

There's a separate set of concerns about customizing reports.  If we
install a revised report as a script + template, and you customize the
template in the install location, it'll still get over-written at upgrade
time.  There are use-cases for both customizing only the template, and
more so customizing the whole report (and likely the template).

In my experience -- particuarly: customizing bugzilla both before and
after they introduced explicit UI templates -- it can be almost as hard
either way.  Effort is required to revise a report in a way that
customized templates are guaranteed to work going forward.  Most likely,
one wants to enhance the report, and thus the template, which will to some
degree invalidate the customized templates as well.

It's a pretty standard problem, so I'm not sure that we should do anything
more than make it: a/ easier to customize the reports and templates, b/
encourage those customizations to be conditional/config-driven and c/
encourage contribution and thus our re-distribution.  Basically: remove
the reasons why individuals users need to have a customized/non-installed
report that can be overwritten or invalidated.


> If we can make a script that put content into a HTML template and then
> launch a web-browser to view and/or print it, this would be a huge step
> forward.

That's an interesting idea ... I'm not sure that it's the best user
experience, though, in terms of the interactive refinement of the standard
reports... where you change the date range, change the graph parameters,
and don't really want to see another spawned browser instance.  Moreover,
we do support hyperlinking strings (and historically plot/graph elements)
with other GnuCash interface elements like accounts registers and
customers.  In that case, you even more so want the browser embedded for
practical/integration concerns.

But if we do embed or use a browser component to which we can offload most
of the heavy lifting of printing, we should leverage that.


> Besides that, step one can be developed without interfering with the
> printing libraries as they are now. I think ...........

The printing libraries are changing, so we do need to modify gnucash's use
of them to stay "current" with our dependent libraries.  The reports are
the major consumer of printing services in GnuCash, but there are others.


> So first of all I'm looking for an understanding of how this
> printing/reporting/scripting business essentially works. I understand C
> but I know nothing of Scheme. Nevertheless maybe I can make a start

For the existing code, there is some documentation in the source tree; in
short...

The report (a scheme script) is evaluated; it calls on the
gnucash-provided reporting system to install itself into the report list
and menu.  When the menu item is invoked, a report-defined callback is
called to generate a (html) document, which is then rendered in the
gnc-plugin-page-report window, using gtkhtml.  The report also defines an
operation generator (another callback function), which is used to create
the report options UI; when Apply (or Ok) is pressed in the options
dialog, the old document is thrown away and the report's rendering
callback is re-run.

-- 
...jsled
http://asynchronous.org/