🚀 go-pugleaf

In article <479@vaxb.calgary.UUCP>, bonham@calgary.UUCP writes:
> The subject of picking a coordinate
> system origin has come up.  Several designers propose putting pixel
> <0,0> at the top left of the screen, with Y increasing downward;
> others propose putting it at the bottom left, with Y increasing upward.
> 
> One advantage of a lower-left origin is that the coordinate system
> is the familiar Cartesian space we learned our geometry with.
> 
> An upper-left origin seems better suited to text operations.
> Homing to the top left of the screen (or window) is done much more often
> than homing to the bottom left.  The address of the upper left corner
> would be a constant <0,0> rather than change for different-sized windows.

I'd say the choice is overwhelmingly in favor of the standard
Cartesian system, with (0,0) at the lower left, and positive Y
increasing upward.  This is what people are used to, and the
system is to be used by people, right?

The human-use issue is really the most significant one.  If you
go with an inverted scheme, you'll be frustrated with it for as
long as you use it.  It won't just be pictures coming out
upside-down, either -- it's pretty easy to remember to invert
coordinates when doing absolute positioning, but somehow it's
harder to remember when doing relative operations.  One ends up
remembering to change the sign for some of the Y's in a
complicated positioning expression, but not the others, leading
to a scrambled picture.

Even if there were implementation difficulties in translating
"normal" coordinates to the inverted ones many pieces of display
hardware use, the argument would be still be in favor of regular
coordinates, because computers are good at transformations like
that, and even if the transformation is hard, you only have to
code it once, and then every time you use the package you don't
have the frustration of having to stand on your head to get your
pictures to come out right.

Of course, the transformation is quite simple, so there's really
no argument.  For instance, I have my own implementation of the
Unix plot(3) subroutines for a number of devices.  The coordinate
scaling code is device-independent; it is driven by a device-
dependent header file which describes the device's resolution,
etc.  For instance, the header for the Tektronix 4014 says:

	#define XLO 0		/* hardware units for full screen */
	#define YLO 0
	#define XHI 1023
	#define YHI 780

The first time I set up a version of the package to drive
inverted hardware, I was afraid I was going to have to rewrite
some code, until I realized that the same transformations could
take care of it!  Here are the definitions for a Selanar graphics
board in a VT100 (which has 0,0 at the upper left):

	#define XLO 0		/* hardware units for full screen */
	#define YLO 239		/* YLO > YHI since hardware has origin */
	#define XHI 1224				/* at upper left */
	#define YHI 0

When converting user coordinates to screen coordinates, there is
a term involving YHI-YLO, which comes out negative in this case,
accomplishing the inversion.

I don't think the frequency of homing to the upper left has
anything to do with the question.  Also, having the coordinate of
the upper-left corner change with different-sized windows doesn't
bother me any more than having the lower-left corner change under
an inverted scheme.

                                         Steve Summit
                                         tektronix!copper!stevesu