[mcclim-devel] output-record-count and postscript new-page

[Andy Hefner]

My thoughts, attempting to be brief:

1. The current bounding rectangle behavior is correct and desirable
(or if for some reason not correct, desirable anyway).
2. new-page-record is odd in that it exists in the output history but
does not represent or contain any geometry. It does not exist in
space. The tree output record doesn't really accommodate this, and any
current semblance of working is accidental. I don't think the
designers of CLIM considered such things either. I'm not sure it's a
good idea, as it raises various issues..
3. Though it doesn't affect this bug, map-over-output-records on tree
output records is arguably broken at present. I would expect it to
include new-page-records, but currently it does not. The
-containing-position and -overlapping-region variants are correct to
not include it (as these are spatial queries, and IMHO should not
report empty, positionless objects).
4. Considering the above, and that replay uses
map-over-output-records-overlapping-region, replay of new-page-records
shouldn't be expected to work. Also, the constraints on order are too
weak (records are only required by the spec to be reported in order of
creation when they overlap - anyone know what our current behavior is
here?).

There are two ways I can imagine a hardcopy stream with pages working
- either have a compound page-output-record class into which drawing
for an individual page is contained, or take the approach implied by
the CLIM spec, which is to force the generation of postscript when
new-page is called, then clear the output history, so only one page at
a time exists in the output history at a time.

An alternative to using replay would be to traverse the
output-record-children list directly, which is guaranteed to be in
order.

On 9/18/07, Christophe Rhodes <csr21 at cantab.net> wrote:

> This problem can be worked around by defining a method on
> output-record-count for tree output records which always returns 0:
> which suggests that the cases testing for output-record-count being
> eql to 1 (and then doing some optimized path) in
> recompute-extent-for-{new,changed}-child are optimized to the point of
> being wrong...

I think the current behavior is correct, and (due to
output-record-count lying to us) the previous answer was wrong. I
haven't yet worked through exactly what was happening, why it didn't
occur more often, and if it is the bug I note in recording.lisp.