Re: Antw: New gda-report's DTD

["Gerhard Dieringer" <DieringG eba-haus de>]

>>> "David T. Bath" <bathd@edipost.auspost.com.au> 28.07.2000  10.08 Uhr >>>
> 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.

A question to 4. none
What do you want to print into a header/footer that is never printed? :-)


> 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.


I propose the following changes:
we should allow more than one pageheader/footer. Then we can define (for example) one for even and one for odd pages.

<!ELEMENT report (reportheader?, pageheader*, reportdata?, 
                                 pagefooter*, reportfooter?)>

Also the list of attributes should be changed

<!ATTLIST pageheader [or pagefooter]
  height        NMTOKEN   #REQUIRED
  printonfirst  (yes|no)   "yes"
  printonlast  (yes|no)   "yes"
  printinside  (yes|no)   "yes"
  printoneven  (yes|no)   "yes"
  printonodd (yes|no) "yes"
>

or alternatively

<!ENTITY % positionfrequency "first|inside|last|firstandinside|insideandlast|firstandlast|all">
<!ENTITY % pagenumfrequency "even|odd|all">

<!ATTLIST pageheader  [or pagefooter]
  height        NMTOKEN   #REQUIRED
  positionfrequency  (%positionfrequency;)   "all"
  pagenumfrequency (%numberfrequency;)    "all"
 >

<!ATTLIST groupheader [or groupfooter]
  height        NMTOKEN   #REQUIRED
  newpage       (yes|no)  "no"
  keeptogether (yes|no) "yes"
>



>  "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 wouldn't consider a label, that is found in the metadata dictionaries call a 'label', but a repfield of it's own. But maybe I'm wrong.


> 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.

IMO this DTD describes a report template, that is fed into some db-engine, that drops all the query tags, replaces the repfield tags by some value tags
and outputs a new XML doc, with a very similar DTD. This new doc is finally rendered.

But I'm not the original author of this, I just jumped into the boat a few days before you.


> 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.

If you are speeking about my proposal, you might have noticed, that the group headers/footers already do have their own queries.

Gerhard