[Gnue-dev] GNUe Reports Output Markup

[Jason Cater]

After looking at the feedback on using XML namespaces in Reports, I've
decided that's the route I'm going to take.  Now that I know *how*
output tags will be represented, I now need to know *what* these tags
will be :)

I am now officially soliciting input for the reports output format. Note
that this is for the *Official* GNue Reporting language and DOES NOT
include such things as preprinted forms and mailmerging. I plan to do
markups for those two tasks, but they are more specialized than a
generic reporting language (e.g., mailmerging would be specific to a
word processor and preprinted forms require absolute positioning, which
I'd prefer to avoid in the generic interface.  Incidentally, when I
refer to preprinted forms, I'm talking about overprinting onto
preprinted check stock or preprinted invoice stock, etc.)

So, what kinds of needs shall we address with our GNUe Reports output
format?

Here are some of my thoughts:

1. The report definition shouldn't contain references to page sizes,
   etc, for a few reasons:
      a) Paper sizes vary by locale (e.g., US Letter vs A4)
      b) For outputs such as html, csv, et al, papersize is
         irrelevant.

   We might, however, provide *hints* (e.g., this report looks
   best in a landscape format, etc)

2. I'm thinking in terms of a "logical" formatting markup, similar
   to HTML, DocBook, or TeX, as opposed to an "absolute" formatting
   markup (Postscript). I say this as doing such a format will make
   the various final outputs (html, csv, pdf, etc) easier to create
   from the same source stream.

   In other words, I don't think the report should denote <draw
   label at position x=100, y=100.>

3. Some "final" formats we will want to support are:
     * PS/PDF
     * HTML
     * RTF
     * CSV
     * TeX/LaTeX
     * ???

     (A lot of other formats can be created from these basic formats.
      e.g., once we have PS format, then ghostscript could convert to
      oddball formats such as Epson ESC/P, HP-PCL, ... )

     Odds are, we will initially use an XSLT script to convert from
     our "output" xml to these "final" formats.

4. I would like to see a generic report "skin", or template, that
   can be applied in between our "output xml" stream and the
   "final format" (possibly applied by the XSLT engine) that applies
   site-specific conventions (e.g., paper size, logos, standard header
   styles, etc)  I touched on this in an earlier email.


5. Um, there's a 5.  I KNOW there is a 5.

   <Jason heads off looking for his medication>


Here are some tags that Derek suggested some other reporting tool uses.
This doesn't mean we have to use them the same way, or use them at all.
But, food for thought:

-----------------------------------------------------------------
Beginning of list
-----------------------------------------------------------------
 o Label
   Much like a regular label only for reports.  Used
   to print static text on a report.
 o DBText
   Used to print any text field form a datasource.
 o Expression
   Used to calculate an expression during report generation.
 o SystemData
   Used to print system information like, report title
   current page number, date, time, etc...
 o Memo
   Used for large multiline text blocks can span pages.
 o ExpressionMemo
   Allows you to have memo text with embeded exprtions
   Expression go in brackets.
 o RichText
   Use to print rich text formatted memo text.
 o DBRichText
   Same as RichText only from DB Blob fields.
 o Image
   Use to print images in the report.
 o DBImage
   Used to print images from Blob in DB.
 o Shape
   Used to draw shapes like rectangles, circles, lines

**Band Types**

BandType is used to identify the role of a band in the report. Some band
types are reserved for special components and should not be used.

BandType           Description

rbTitle            Printedon the first page of the report after the page
header

rbPageHeader       Printed on top of each page. Printing on the first
page can be switched off with the Options property

rbDetail           Printed once for every record/row in the connected
dataset

rbPageFooter       Printed at the bottom of each page. Printing on the
last page can be switched off with the Options property

rbSummary          Printed after all detail bands and potential group
footers at the end of the report.

rbSubDetail        Reserved for use by the TQRSubDetail component. Do
not set this band type manually

rbColumnHeader     Printed a the top of each column on every page in a
multi column report. Printed once after the page header in a single
column report

rbGroupFooter      Footer band for TQRGroup or TQRSubDetail components.
Printed when the group breaks or all detail bands have been printed for
the TQRSubDetail

rbGroupHeader      Header band for TQRGroup or TQRSubDetail components.
Printed before any detail bands for a given group or TQRSubDetail

rbOverlay          Included for backwards compatibility with QuickReport
version 1. Do not use this band type

rbChild            Reserved for use by the TQRChildBand component. Do
not set this band type manually

-----------------------------------------------------------------
End of list
-----------------------------------------------------------------

Now, I'd think some of the ideas are applicle.  I'm thinking, though,
instead of having generic "bands" with a bandtype of "PageHeader",
having actual <pageheader>, <pagefooter>, <band>, <bandheader>,
<bandfooter>, <reportheader>, and <reportfooter> tags.

Also, I'm not sure of the need for "expressions" in the output format.
There will be "formulas" and "triggers" in the report definition file,
but these will be resolved to actual values prior to being placed in the
output stream.

-- Jason