New reporting system

[Josh Sled]

On Fri, March 30, 2007 2:53 pm, two old wrote:
> if custom script exist -> execute ([user dir]/script)
> else use standard script.
>
> if custom template exist -> use it ([user dir]/template)
> else use standard template

It's simpler to always just have the user create a custom report, which is
a copy of the existing report.  If they care to revise the script,
template, both (, or neither), then that's their prerogative.  But the
only option should be to create a new whole report.

Also, it's simpler to require all custom reports have a different
name/identity than the "standard" one.  So it's not so much "invoke
<Invoice> and use the override if it exists", but "invoke <Invoice>"
and/or "invoke <Joe's Invoice>".


> switch (option-browser)
> case internal browser:
> case external browser:

The reports would need to target the LCD of functionality between the
browsers (internal and external[s]) for most of their work, and the
reports do expect to be able to use gnucash-specific URLs to open GnuCash
resources.  We can't support using an external browser exclusively for
report content.

The option to Export should (continue to) exist, and we should probably
add a "... and launch browser" checkbox on the Export dialog.  But it
bears noting that preparing a report for export is different than
preparing a report for internal viewing.  Specifically, the graphs and
gnucash-specific URLs need to be handled very differently.  Also, a
different printing stylesheet may want to be used (though this might be
combined with a media=screen stylesheet).  Generally, an Exported report
needs to be more self-contained and less gnucash-coupled than a normal
report can get away with.

I think our best bet is to have a more capable internal browser (gecko),
and raise the level of reports to support its features for rendering,
formatting and printing.  Frankly, I don't think it's an unreasonable
dependency for a "top of the stack" desktop app.  Note that other parts of
gnome (yelp and epiphany, maybe devhelp indirectly via yelp) already
depend on it, so we can safely assume that it will be available for "GNOME
desktops".

I'm aware of two objections to a dep on firefox: political and technical. 
AFAIUI most political/freeness objections around firefox concern branding
and graphics, not the core rendering and browser component.  The technical
objections are mostly package-management concerns.  I'm aware that certain
Gentoo users don't want to have to build all of mozilla/firefox, and the
binary distribution can't be used in a development context.  But these are
distribution concerns, really, and can be resolved independently.


> In my opinion the individuals will customize the script/template, this is
> a fact. Therefor you have to define the restrictions rather then program
> for every eventuality.

The goal isn't to eliminate the reasons why people need customized
reports, but to minimize them.  If the common use-case is to add a logo
into an Invoice, then that should be a first-order configuration option of
the standard Invoice report.  If there's some more special-case concern,
then it's probably valid for the user to have a customized report.


As you've expressed, your goal is nicely-printed invoices.  Here are the
problems between here and there:

- the existing report is hard to customize (generally true...)

- the existing HTML engine cannot represent basic modern formatting
features (HTML > v3, CSS at all)

- HTML element creation via the reporting infrastructure only knows to
emit basic HTML 3 constructs.

- exporting is done *through* GtkHTML, which will munge any "complex"
HTML+CSS embedded in the output.

This last point is important, because it means we can't even have the
current reports generate "modern" HTML+CSS for export that gtkhtml could
display in a degraded capacity.

One more direct solution would be to have Export not use gtkhtml, but
instead to serialize the original report-generated document, which could
be enhanced to emit HTML 4 + CSS, and maybe have a "downsampler" between
that document and the input to GtkHTML.  There's a fair amount of work
there.


All that being said, it's not just a case of having an external browser,
but of some substantial changes to the way reports are architected.  I'm
hoping to detail how I think that should work in the coming months.

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