Displaying translated images in DomTerm does not work as expected.
opened this issue · comments
Consider two code examples:
(import (kawa pictures))
(zbox (with-transform (translate &P[100 100]) (fill (circle 30)))))
(import (kawa pictures))
(zbox (line &P[0 0]) (with-transform (translate &P[100 100]) (fill (circle 30)))))
it would be natural to expect the result be identical, since the length of the line is 0.
This is not the case, however.
The length and area of the (line &P[0 0]) is 0, but it still has a bounding box - which is just a point. When you create the zbox, it has bounding box which is the "union" of the bounding box of the circle and the point. The display shows whatever is in the resulting bounding box.
(It's been a while since I working all this out, but I think that is what is going on, and I think it is reasonable behavior.)
I.e. there is an implicit translation during display to fit the resulting picture.
I do not think that an "implicit translation back to the origin" is a reasonable thing to have. Essentially it makes the (translate) function behave in a funky way and guarantee potential users a lot of debugging.
I.e., the calls
(with-transform (translate &P[100 100]) (fill (circle 30))))
and
(with-transform (translate &P[-100 -100]) (fill (circle 30))))
would both display the same result, which is counter-intuitive, and especially to students who are new to all of the quirks computing is to offer.
You can argue both ways. If a picture is translated to a negative offset, it would be invisible,
I think it is more consistent to do the automatic translation. Consider a picture whose y bounds to 400 to 700. We could display from 0 to 700, but that would be wasteful. We stop the display (and print the next prompt) at the upper y bound (otherwise we'd need an infinite amount of space), so it makes to start the display at the lower y bound - otherwise it would be non-symmetric. So if we translate and truncate for y, it makes sense to do that for x too.
However it makes sense to cover this point explicitly, perhaps with an example or two.
One useful feature would be an option to overlay a grid with coordinate markings, perhaps with a line every 100 pixels. This could be function: (with-grid [options] picture), and perhaps a setting which automatically adds the with-grid.
Well, invisibility is not a very nice thing, but is less confusing than straightforwardly-looking functions having their effect cancelled out. A negative coordinate (at least to me) is more or less expected to be off-screen and thus invisible.