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. Thanks, Robby On Sun, Jan 30, 2011 at 8:40 PM, Don Blaheta <dblah...@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-=-dblah...@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 > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
