Re: Antw: New gda-report's DTD

["David T. Bath" <bathd edipost auspost com au>]

I have no CVS because of firewalls, but a couple of comments about
the headers/footers.

The printfrequency could be extended to allow the following primitives
   1. first (on|off)
   2. last (on|off)
   3. second-through-penultimate (2tp) (on-off)
Building on this
   4. none = (first=off)(last=off)(2tp=off)
   5. all = (first=on)(last=on)(2tp=on)
   6. allbutfirst = (first=off)(last=on)(2tp=on)
   7. allbutlast = (first=off)(last=on)(2tp=on)

This does not address even vs odd page printing.

One thing worth mentioning is though I hate to admit it, Microsoft
have a darned good idea with a few properties of the widgets (where
a section can be considered a widget) is the idea of "can grow" and
"can shrink".  This is marvellous for items that contain variable
length of text.  If the widget has more text in it than comfortably
fits, it expands vertically, and widgets with a vertical start below
the start of the growing widget have their origins shifted down by
the growth amount.

OK this makes rendering tricky if a widget WOULD have started near
the bottom of the page, and gets pushed below it.

Similarly, what do we do if the widget would be cut in half?  Here
MS have implemented a "keep together" (for groups, but it should
also apply to individual fields).  Here is my understanding of
how it should work.
   if (Widget Height fits on page) {
       PRINT
   } else {
      if (keep_together = true) {
         THROW TO NEW PAGE
      } else {
         PRINT FIRST PART, REST ON NEXT PAGE
      }
   }
But what if keep together is ON but the widget height is bigger than
available space on the page?

Also consider their attribute for headers which is "keep together
with first detail" - so a header does not appear at the bottom of
the page.

Also consider the old troff command "requires" which required a
certain amount of space left on the page, or it would through to
a new page anyway.

I know that this complicates matters, and each section will need to
be effectively rendered into a buffer, see if it fits on the rest of
the page, and if so, flush.

Another thing to worry about is that origins and geometries appear
to be required numbers.  This might be fine once it gets to the
rendering engine, but an alternative would be to references back
to other widgets and relative values:
   Group footer widgets should often be under their related fields
   An element might be left (or right) shifted relative to
      the preceding element.
   A label and field are often aligned.

I might be wrong, but it seems that little attention is being paid to
the difference between a "free" label and one intimately associated
with a data field.  Maybe there needs to be a new element that is
a combo of repfield and label, or ALL repfields have a (possibly
null) label.

If so, there a number of positions where the label might be:
    a) Freely positioned (independent)
    b) Left or right of repfield (possibly check $LC_LANG for default)
    c) Above the repfield WITHIN the section
    d) Above the repfield IN THE GROUP HEADER
A "bound" label thus might need two possible values
    a) A short label, often for use in headers
    b) A long label, often for use to left/right
    These could even default to stuff in metadata dictionaries.

I'm wondering whether the geometry stuff ought to allow empty values
and the renderer act like the perlTk or glade "packers".  If so, then
much work could be taken from anything down with the XML output of
glade and treating report elements as widgets.  Just a thought.  It
all depends on whether this is the DTD that specs out the language
programmers use (where a few conveniences and late bindings are often
required) or whether it is more for generation of printer output after
a rendering engine has figured out the placement of everything.

    A halfway version of this would be to allow something like
    the following for setting the "x" origin of an element compared
    to another
       other_repfield_id.width + other_repfield_id.x + NMTOKEN
points|cm|pixels|...

Why do programmers need to leave a lot of this undefined?  Because the
report should be sensitive to defaults set by the user at runtime.
One might be half blind, and need larger fonts, etc, by default.

Similarly in reporting sections, certain elements are often set together
and designed to be moved/resized as a unit.  The 

    Unit0Label      Unit1Label
    Lbl0:Data0      Lbl3:Data3Data3Data3Data3Data3Data3Data3Data3
    Lbl1:Data1           Data3Data3Data3Data3  
    Lbl2:Data2      Lbl4:Data4

Lbl0-2 and Data0-2 should be aligned the same, and the left origin
for the labels is typically the left origin of the unit as a whole.

Again, if this is a programmer-used DTD, it might be nice to indicate
it as a symbol "monospaced" "variable_width" and sizes of fonts relative
to those in various config files: "+0", "-2" etc.

However, the more I think about this, the more I think that looking at
glade, libglade and libxml is a good idea.  The report should be
capable of being rendered for screen (with resizeable grid columns,
explodable trees) or for print (where everything is displayed fully).
This implies ONE report spec and TWO renderings.  I am reminded of
the idea associated with libglade/libxml of using glade to generate
the first cut of the UI, with associated events/signals, but the
C program binds the UI at runtime.  Anybody need a rundown on the
details of this?  I can give pointers to a tutorial at IBM Developer
Works if needed.

I'll have more to say next week about group headers/footers, and the
possible need for them to run their own query, this query having
parameters
bound to values passed down from the main query, and thus avoiding
HUGE joins in the main query.
-- 
David T. Bath bathd@edipost.auspost.com.au
+613 9204 8713 (W) 0418 316 634 (Mbl)