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

[Andreas Fuchs]

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

Agreed.

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

Right.

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

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, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ,implement-ungeometric-tree-record-children.patch
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070923/64f0feb3/attachment.ksh>