On Tue, 04 Jan 2000 15:48:46 +1100, the world broke into rejoicing as
Robert Graham Merkel <[EMAIL PROTECTED]> said:
> I have suggested that we might want to add the ability to draw lines
> on reports. Does the following interface sit well with
> you?
It's close enough that I can *usefully* disagree.
> As well as report-string, report-value, report-date (BTW, could you
> add another argument to report-date so you can give it *any* date
> rather than just the current one), and report-total, could you
> add in:
I'm not entirely thrilled with report-date; can I suggest it to be
superfluous?
The way that it would be most sensible to implement it would be to
take a date stamp from (gettimeofday), reformat that into a date, in
string form, and then use (report-string) to display it.
The critical point, here, is to try to keep the number of main
functions down, at least initially, to those that are truly necessary
primitives.
report-string is *absolutely* necessary, and makes sense to perhaps be
used to implement most of the other bits. (Rather like the "glue" and
"boxes" in TeX.)
report-value is also crucially necessary, as it adds in the critical
abstraction of collecting up totals, which is an important thing you
do in a report. (The *display* of the value is probably handled by
having report-value call report-string, with the value turned into a
suitable string...)
In thinking further, report-total might actually just be a
specialization on report-value, if we look at both a bit sideways.
That isn't the case at the main level, as different output methods
will work differently.
But. In text mode, *all* of the other functions will ultimately
create strings, and pass them to (report-string-text). Similar will
be true with HTML. Gnumeric, um, would be different, at least for the
formula-oriented functions.
Displaying dates isn't the same as formulae; dates, once rendered, are
pretty static. I'd be quite game to have some functions that help
"prettyprint" dates into a string. But I don't think it warrants
(report-date).
> ;; draws a line above or below the present report line
> ;;
> ;; horizontal positions for n columns are numbered 0 . . . n, where
> ;; position 0 is left side of the first column, position 1 is the
> ;; position of the boundary between the right of the first column
> ;; and the left of the second, and so on, linestyle is a line
> ;; style structure (content yet to be determined)
>
> (report-horizontal-rule vertical-position position-from position-to linestyle
>
> ;; draws a vertical line on the present line at the appropriate
> position
>
> (report-vertical-rule horizontal-position style)
>
> The reason I prefer using rule than line is to avoid confusion with
> report-line.
>
> As for line style, how about a structure containing the following
> attributes:
>
> #(solidity width colour)
>
> where solidity is one of
>
> 'solid 'dotted 'dashed 'dot-dash 'double
>
> width is one of
>
> 'normal 'double
>
> and colour is specified in the same manner that text colour is
> specified.
>
> Is this enough flexibility for specification of line style?
The terminology is fair enough, except that I would suggest having all
of this stuff be "style," so that rather than writing code that looks
like:
(report-line (report-string ...) (report-value ... 'creditvalue)
(report-value ... 'income))
(report-line (report-string ...) (report-value ... 'creditvalue)
(report-value ... 'income))
(report-line (report-string ...) (report-value ... 'creditsubtotal)
(report-value ... 'creditsubtotal))
(report-rule ...) (report-rule ...))
(report-line (report-string ...) (report-value ... 'credittotal)
(report-value ... 'credittotal))
(report-rule ...) (report-rule ...))
We can omit the report-rule calls, and write code that looks like:
(report-line (report-string ...) (report-value ... 'creditvalue)
(report-value ... 'creditvalue))
(report-line (report-string ...) (report-value ... 'creditsubtotal)
(report-value ... 'creditsubtotal))
(report-line (report-string ...) (report-value ... 'credittotal)
(report-value ... 'credittotal))
The point is that any \hrules or \vrules (to coin TeX/LaTeX) should be
associated with the style, so you don't need to code for them in the
report.
Thus, if we decide that subtotals should have a single line above and
below, and that grand totals have a single line above, and 2 below, we
simply indicate that a particular field has style 'creditsubtotal, and
that another has style 'creditgrandtotal. Stick that in one place,
not connected *at all* with the report itself.
[Aside: Obviously there needs to be code to *implement* having the
hrules and vrules *drawn.* I am suggesting that this be taken out of
the report proper, and instead put into the style.]
Cool part: This means that the appearance can get hacked on without
touching report code. If we decide that there need to be 3 lines, the
Scheme that generates the income statement doesn't change.
Also... I'll suggest looking at the model for the style in a more
"declarative" way, consciously parallelling the way that word
processors that support tables tend to do this. If you look at MS
Word, or at any GUIed spreadsheet package, the table formatting
configuration provides a very simple grid thus:
+---+---+
| | |
+---+---+
| | |
+---+---+
You get to "click" on the 6 lines to indicate pattern to be used to
control each kind of line.
That *precise* scheme tends to get used for "automagic" table
formatting, which is not *quite* what we're doing, although the
difference may be a bit awkward to describe.
> I've checked my LaTeX books, and this is a reasonably good match for
> the line-drawing commands for the tabular styles. I don't know
> whether this can be made to work for HTML or not.
>
> What do you think?
I now consult a (Wrox) HTML CSS reference instead, to get a "second
opinion." Methinks it's similar enough to be instructive...
*First* comment from it is that CSS1 describes these as "borders."
That seems to me to be a useful term, preferable for our purposes to
"rules." Calling them "rules" would make sense if we were just
drawing them some place; when they're surrounding a field, the term
"border" sounds ever so much more, um, geographical. :-)
*My* first cut is that for styling this we'd have a structure thus:
#(border-set left right top bottom)
where the four values are each a structure of the form
#(border solidity thickness colour)
- colour should be obvious (or, at least, deferred for later judgement!)
- solidity allows dotted/dashed/morse-code/...
CSS1 terms this "border-style" and permits values in:
(none dotted dashed solid double groove ridge inset outset)
- thickness would allow varying from thin to THICK lines
CSS1 terms this "border-width" and allows values (thin medium thick)
--
"By your private definition, they were poor, but who cares?. By my
private definition, you are a elm tree."
-- Mike Coffin <[EMAIL PROTECTED]>
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
