[racket] overlay and overlay/xy

I find this to be a compelling argument but I am worried about
backwards compatibilty for others.

The least I can do is a better job documenting this (and thanks to
your message I think I'll be able to do that) but I'm not sure about
changing the semantics.

Do others that may depend on 2htdp/image have an opinion?

Robby

On Sunday, January 30, 2011, 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
>