> I think this is very much the right idea; there is no doubt but that
> there will be value to having a variety of output forms.
>
> Creating what amounts to a "financial reporting language" that can
> be used to push data at multiple output forms would be a *big* win.
>
I think we're all in agreement on this.
However, from reading your sample language, I'm not clear whether my
understanding of how such a language would work matches yours.
My conception was that there would be NO output-format specific
information in the reporting language. Therefore, we shouldn't
be specifying font names, page length, and the like in the reporting
language. The output filters would obtain this information from
elsewhere (from the user or hardcoded into them). That way,
report generators could be written to output to this reporting
language without worrying about how the output filter would
deal with them.
My comments below should primarily interpreted in this context.
> The basic operators would include things like the following, which
> I've added to report.scm as comments at this point...
>
> ;;; Suggested set of functions to manage report data in a
> ;;; device-independent manner.
>
> ;;; report-string, report-total, report-value are used to output
> ;;; values. "string" should be obvious; "value" will be a currency
> ;;; amount, and probably should be currency-aware. "total" allows
> ;;; a bunch of "values" to be collected into a single total "cell."
> ;;; The point to totals being distinct from values is that this allows
> ;;; the total to remain a dynamic calculation if, for instance, output
> ;;; is going into a spreadsheet.
> ;;;
> ;;; (define (report-string string indentation style))
How do we place a string in a specific column?
> ;;; (define (report-value value collector-thunk column
> ;;; linkname style))
> ;;; (define (report-total input-collector-thunk
> ;;; output-collector-thunk column
> ;;; linkname style))
What's the "linkname" parameter?
> ;;; You pass a list of the thunks established above into (report-line)
> ;;; which combines them into a single line.
> ;;; (define (report-line report-port . list-of-thunks))
> ;;;
> ;;; (define (define-report-total-collector))
> ;;; define-report-total-collector returns a thunk used by report-value
> ;;; and report-total to collect together values to establish a "total"
> ;;; In the case of HTML/Text output forms, this can just grab the
> ;;; values. In the case of a spreadsheet output form, this would
> ;;; collect up the cell IDs so that (report-total) would generate a
> ;;; formula like "=D2+D3+D4+D5+...+D15"
Makes good sense.
> ;;; (define (report-start-section report-port linkname))
> ;;; (define (report-end-section report-port))
> ;;; These functions are necessary for the HTML output form to generate
> ;;; the table start/end info. It would not be a bad move to change
> ;;; this to:
> ;;; (define (report-start-section report-port linkname . list-of-thunks))
> ;;; that works like (report-line), so that the first line in the table
> ;;; can contain header data.
>
Yep.
> ;;; style:
> (define style-structure
> (make-record-type
> "style"
> '(alignment fontinfo color)))
>
Hmmmm. I'm not so sure about this, as this encodes output-format
specific information into the intermediate language, doesn't it?
Wouldn't it make more sense to define a limited set of styles, such as
Heading, subheading, body text, emphasis (roughly analagous to
\emph{} in LaTeX), etc, and let the final renderer interpret these?
> ;;; (define (report-newpage) report-port)
> ;;; Jump to a new page... More-or-less a no-op with HTML, but could
> ;;; do a switch to a new sheet with Gnumeric...
>
Fine.
> ;;; (define (report-open physical-port title medium
> ;;; page-dimensions collist))
> ;;; This "opens" the report, associating it with a "physical" port,
> ;;; indicating a title, medium (e.g. - 'html 'text 'gnumeric
> ;;; 'postscript ...),
> ;;; page dimensions such as:
> ;;; (80 'cols 66 'rows) - Common text formats
> ;;; (132 'cols 66 'rows)
> ;;; (8.5 'in 11 'in) - Likely useful for Postscript
> ;;; (8.5 'in 14 'in)
> ;;; (0 'generic 0 'generic) - For formats with no fixed limits
> ;;; like HTML/Spreadsheet
Are the medium and page dimensions something we want to code into our
reporting language?
> ;;; collist is a list of columns:
> ;;; ('text (1 55) (57 10) (69 10)) -- For use with text
> ;;; - This describes 3 cols, one 55 chars wide, and 2 of width 10.
> ;;; Good for a report that is to have 2 numeric columns
> ;;; ('html (8 'in) ((5 'in) (1.5 'in) (1.5 'in)))
> ;;; - Hopefully obvious?
> ;;; ('html (8 'in) (('rest) (1.5 'in) (15 'percent)))
> ;;; (15 'percent) is equivalent to 15% of 8 'in, e.g. (1.2 'in)
> ;;; ('rest) takes up the "rest" of the width, in this case, (5.3 in)
> ;;; ('columns 3)
> ;;; Good for a spreadsheet; indicates that there are three columns.
> ;;; It might be nice for this to add further options to configure
> ;;; the widths of these columns...
> ;;;
Yes, we want to specify how many columns there are, and some measure
of how wide they have to be, but, again, this is output-form specific.
> ;;; (define (report-close report-port))
> ;;; This cleans up the data structures so that they may be
> ;;; garbage-collected.
> ;;;
> ;;; (define (report-page-header report-port thunk))
> ;;; (define (report-page-footer report-port length thunk))
> ;;;
> ;;; These two functions attach thunks that do stuff at the top and
> ;;; bottom of each page. The footer needs to know how its length so
> ;;; that (report-need) can be aware of this in determining how close
> ;;; to the bottom of the page it can safely get...
> ;;;
> ;;; (define (report-need report-port need-amount))
> ;;; This function indicates that if there aren't "need-amount" lines
> ;;; left on the present page, the system should display the footer and
> ;;; jump on to the next page... Note that in the "body," this will
> ;;; add in the number of lines that the footer produces...
> ;;; (define (report-newpage) report-port)
> --
This make sense.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
