Hi,
The following code produces an unexpected result in current McCLIM HEAD:
(in-package :clim-user)
(with-open-file (ps "/tmp/foo.ps" :direction :output :if-exists :supersede) (with-output-to-postscript-stream (s ps) (draw-rectangle* s 10 10 20 20) (new-page s) (draw-rectangle* s 30 30 40 40)))
The reason is that the new-page output record is no longer contributing to the bounding rectangle of the stream output history, so that when the history is replayed (to actually write the postscript file) the new-page output records are not replayed. If instead the code is
(with-open-file (ps "/tmp/foo.ps" :direction :output :if-exists :supersede) (with-output-to-postscript-stream (s ps) (draw-rectangle* s 10 10 20 20) (new-page s) (draw-rectangle* s 30 30 40 40) (new-page s) (draw-rectangle* s -5 -5 5 5)))
You get the expected three pages (rather than the one you get when there is no drawn content around 0,0).
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...
Any ideas?
Cheers,
Christophe
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.
To get at the promised-by-Krystof beverages tomorrow, I've hacked up a patch for tree ORs that should fix things again.
Andy Hefner wrote:
- 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..
Agreed.
- 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).
Right.
- 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?).
I agree, but to get something working, I've made a compromise: To consider null-BR children when +everywhere+ is queried. That is, to interpret questions about everywhere as questions about nowhere as well.
The attached patch implements this, and yields the expected two pages of output from Christophe's first example. It runs the examples, but I can't say anything about its performance (-:
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.
That sounds enormously sensible. I would go with this.
Cheers,
Andreas Fuchs asf@boinkor.net writes:
To get at the promised-by-Krystof beverages tomorrow, I've hacked up a patch for tree ORs that should fix things again.
Andreas and I met up last night, and we agreed that he didn't deserve a beer, because although his patch gets my page postscript test case right, it also causes every clim application we tested to deadlock on startup.
Oh well :-)
Cheers,
Christophe
-
Andreas Fuchs -
Andy Hefner -
Christophe Rhodes