# [racket] overlay and overlay/xy

 From: Stephen Bloch (sbloch at adelphi.edu) Date: Mon Jan 31 14:27:23 EST 2011 Previous message: [racket] overlay and overlay/xy Next message: [racket] overlay and overlay/xy Messages sorted by: [date] [thread] [subject] [author]

```On Jan 31, 2011, at 7:43 AM, Robby Findler wrote:

> How close does underlay/xy get to a function that seems useful?
>
> Also: what if I were to add overlay/align/xy and underlay/align/xy
> that accepted two images, a x-place, a y-place and a dx,dy coordinates
> that adjusted the x and y places by those amounts? Would that satisfy
> or is that getting too complex?

Off the top of my head, that sounds too complex.  And still not "fully general": do the x-place and y-place refer to the first image, or the second?  Whichever they don't apply to, what part of that image is to be lined up with the offset relevant part of the other one?

Perhaps a more flexible and yet easier-to-remember solution is "overlay/pinholes" which takes an image, two numbers, another image, and two more numbers.  We don't have to actually reintroduce pinholes, just have it behave like

(define (overlay/pinholes pic1 x1 y1 pic2 x2 y2)
(overlay (put-pinhole x1 y1 pic1) (put-pinhole x2 y2 pic2)))

The real point of eliminating pinholes (as far as I'm concerned) is that an image doesn't "know" its own pinhole.  You can't have two otherwise-identical images fail to be equal? just because they have different pinholes.  When writing a function that produces an image, you don't have to decide where to put the pinhole.  But pinholes can still be a legitimate part of an OPERATION, not a DATA OBJECT.

Stephen Bloch