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