Robert Graham Merkel <[EMAIL PROTECTED]> writes:
> Two other things. Firstly, has there been any discussion on how
> best to produce printed reports? There are a couple of different
> approaches that come to mind:
A little.
> 1) Feed the generated HTML to a HTML/PS converter, and print the
> postscript.
That would work, but as you point out, it might or might not look
reasonable, but it could be a good short-term solution.
> 2) Modify the reports to provide an option to generate (La)TeX,
> which we can then process.
>
> Pros:
> * More control over output
> * High quality rendering
>
> Cons:
> * Considerably more work to implement
> * Might be rather slow on very large reports
> * Gives us yet another dependancy (and I doubt Corel Linux
> and the other consumer distros that are about to be foisted
> on us will have TeX on them)
While I'm a pretty big LaTeX fan, I don't think we really want to add
that as another dependency. I lean toward this:
> 3) Place text ourselves - maybe using gnome-print (which I admit
> I know absolutely nothing about), or something else?
> Pros:
> * Absolute control over output
> * Most flexibility
I think that gnome-print is probably the right way to go, but I'm not
sure how long it's going to be before it's ready for prime time. Do
you know, Dave?
Actually, for printed output, another option to consider would be to
generate scheme forms containing the data, and then just write some
(trivial) converters that would spit out postscript, LaTeX, text, or
whatever. This would be similar to the idea of defining a DTD and
then using XML, but using XML would require additional dependences,
whereas using scheme forms would be free, parser-wise.
So far, I've just been implementing the "shortest-path" solutions in
scheme, so we can have something working, but there's no reason why we
can't step back, and implement a more modular (and probably superior)
setup where the report scripts generate a well-defined set of scheme
forms (comparable to a DTD def) representing the data, and then these
forms are passed to converters that generate various output formats.
Given scheme forms as input, parsing in these converters would be
trivial.
Another advantage to this would be that we'd immediately have a way to
save reports to disk. We just save the scheme forms with a form
indicating what type they are at the top.
> Last, but not least, I'm getting the following warnings when I start up gnucash.
>
> <trell> ~ : gnucash &
> [2] 825
> <trell> ~ : gnucash: bootstrap file is
>/usr/local/stow/gnucash-CVS/share/scm/bootstrap.scm
> gnucash: [W] "failure loading
>""/usr/local/stow/gnucash-CVS/share/scm/srfi/srfi-8.guile.scm"
> gnucash: [W] "failure loading
>""/usr/local/stow/gnucash-CVS/share/scm/text-export.scm"
> gnucash: [W] "failure loading
>""/usr/local/stow/gnucash-CVS/share/scm/report/balance-and-pnl.scm"
>
>
> I'm using a current potato system (relevant package information
> below).
> Any suggestions? It'd help to
> have your report code working before I work on any new stuff . .. .
It looks like you're missing src/scm/srfi/* These are a set of *very*
useful implementations of the accepted schme "Scheme Request For
Implementation's" at www.schemers.org. The most useful one ATM is
SRFI-1 which contains some very efficient list processing algorithms.
Docs are available at the web site.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
