[racket] overlay and overlay/xy

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Sun Feb 20 16:43:44 EST 2011

This thread seems to have died down so I took what I thought was the
best idea, namely doing what Don suggests but giving the function a
new name (I took the one suggested by Stephen). So now we have
overlay/offset, underlay/offset, overlay/align/offset, and
underlay/align/offset (just pushed to git). If you pass 0 and 0 for
the x and y arguments, then you get functions that behave like the
versions without the word "offset" in them (restricted to two
arguments, of course).

We have a few months before the next release, and feedback before that
time would be appreciated.


On Sun, Jan 30, 2011 at 8:40 PM, Don Blaheta <dblaheta at monm.edu> wrote:
> I shifted entirely to using 2htdp/image this semester; now all
> the pinhole stuff is gone and we can do "image arithmetic" with various
> combinations of overlay, underlay, above, and beside, which is great.
> The problem is, overlay/xy now sticks out like a weird wart on the
> system, and it's profoundly counterintuitive to my students (and me,
> actually), in at least two important ways:
> 1) One might expect the following two expressions to yield the same
> result:
>  (overlay    red-circ     black-sq)
>  (overlay/xy red-circ 0 0 black-sq)
> but they don't.  All the base image arithmetic functions default to
> aligning at the middle, but overlay/xy doesn't.  Which means that if
> (overlay a b) is almost what you want, but just requires a nudge of a
> few pixels, you can't just start with an overlay/xy with offset of 0 0
> and tweak from there.
> This expectation doesn't only come from the time-honoured "guess based
> on the function name" strategy; it's also based on the description in
> the documentation:
>  Constructs an image by overlaying i1 on top of i2 after shifting i2 over
>  by x pixels to the right and y pixels down.
> which would lead you to believe that it's just like overlay, except with
> an offset.  The docs could be clarified here, but that just raises the
> further question, "why is overlay/xy based on a top-left alignment but
> overlay based on a middle-middle alignment?"  Who knows?
> 2) The semantics of the offset are backwards.  Or at least, they feel
> backwards.  When my students typed
>  (overlay/xy red-circ 10 0 black-sq)
> they expected the red circle to be overlaid atop the black square and
> offset to the right by ten pixels; but in fact it is the reverse.  The
> natural interpretation of this is *not* "oh it's the black square that
> got shifted to the right", but rather, "why is the red circle shifted to
> the left when I gave it a positive offset?"  That's because it's the
> red circle being overlaid, so you expect it's also the red circle that
> gets shifted.  (The confusion here is only magnified by a confound with
> the y-increases-down property of the graphics system.)  I assume this is
> effectively a holdover from version 1 of the library, where it was the
> the second image overlaid upon the first, and thus it made sense for the
> second image to be the one that was offset, but it's still confusing
> (although here at least the documentation is correct).
> The net effect is that the only reliable way to use overlay/xy is to try
> a bunch of different numbers until one looks right, which is a big pain
> but less of a pain than having to figure out the weird offsets and
> backwards semantics of the function.  I'm trying to decide if I can just
> tell them to avoid overlay/xy entirely, but I don't think I can---although
> place-image is great, sometimes you need an offset without cropping.
> --
> -=-Don Blaheta-=-dblaheta at monm.edu-=-=-<http://www.monmsci.net/~dblaheta/>-=-
> "On two occasions I have been asked [by members of Parliament!], `Pray,
> Mr.  Babbage, if you put into the machine wrong figures, will the right
> answers come out?'  I am not able rightly to apprehend the kind of
> confusion of ideas that could provoke such a question."
>                                                        --Charles Babbage
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users

Posted on the users mailing list.