[net.text] Y positive up or down?

bonham@calgary.UUCP (10/28/86)

Thanks to all net.graphics readers responding with opinions
on the relative merits of putting the coordinate origin for an
integrated 2-D text and graphics support system at the top left
versus the bottom left of the screen.

The consensus so far is overwhelmingly in favour of the normal
Cartesian coordinate system with <0,0> at bottom left.

However, there must be *some* reason Sun, and many other window
system developers, chose the upper left with Y increasing downward.
Perhaps it is because their systems were intended primarily for ease
in programming text  displays.  Most typesetting / page description
languages use the inverted, Y-positive-down coordinate system.

To obtain perhaps a wider representation of views, I am posting
my original message to net.text and net.cog-eng and am inviting
further discussion in all three newsgroups.  Thank you.
-- 
    _|_    __/__
   __+__    /_	         Mike Bonham
    /__    |__|
   /\./     /|     ..!{ubc-vision,ihnp4}!alberta!calgary!bonham
   _/ \_  _/ |_|

bonham@calgary.UUCP (10/28/86)

This is a re-posting of a message originally sent under net.graphics.
If you have seen this before, perhaps read it again while wearing
your text programmer's hat!

We at the University of Calgary are implementing a graphics utility
as part of a larger project.  The utility is to support raster, vector
and text-oriented displays in 2-D.  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.

Both have advantages and disadvantages.  We think it a hard enough
and interesting enough philosophical question to put it to the net:
Should positive values represent upward or downward Y increments?

One advantage of a lower-left origin is that the coordinate system
is the familiar Cartesian space we learned our geometry with.
Using an upper-left origin means inverting our notion of up/down.

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.
We want to use a single coordinate system for drawing text-, vector-
and area-oriented graphics.

An upper left origin is more of a standard in display hardware,
due to the top-to-bottom/left-to-right scanning of raster lines
and the consecutive ordering in display memory of each line's bits.
This is a bit of a non-issue, as the primitive drawing routines can
adapt to negative scan line increments regardless of which high-level
coordinate system we adopt.

Has anyone had experience doing geometry/trigonometry programming
in an inverted (Y-positive-down) coordinate system?
Was it hard adjusting to it?

What ramifications does a normal (Y-positive-up) coordinate system
have on text processing?  On implementation with standard hardware?

Reply by email if these are old questions (with answers!), otherwise
I would like to see a discussion on the net.
-- 
    _|_    __/__
   __+__    /_	         Mike Bonham
    /__    |__|
   /\./     /|     ..!{ubc-vision,ihnp4}!alberta!calgary!bonham
   _/ \_  _/ |_|

stevesu@copper.UUCP (Steve Summit) (11/02/86)

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

greid@adobe.UUCP (Glenn Reid) (11/02/86)

I am personally in favor of the origin in the bottom-left corner, with
positive values increasing upward.

However, I am even more in favor of being able to change things in my
editing tools.  It seems feasible to make this configurable--that is, have
the coordinate system default one way, but make it possible to change it.
The only problem I can see with this is in transferring documents.  It would
probably be best to always save documents in one form, and allow on-the-fly
inversion as they are being edited, rather than storing them both ways.

Just a thought,

Glenn Reid
..decwrl!adobe!greid

guido@mcvax.uucp (Guido van Rossum) (11/08/86)

In article <1903@adobe.UUCP> greid@adobe.UUCP (Glenn Reid) writes:
>It seems feasible to make this configurable--that is, have
>the coordinate system default one way, but make it possible to change it.
>The only problem I can see with this is in transferring documents.  It would
>probably be best to always save documents in one form, and allow on-the-fly
>inversion as they are being edited, rather than storing them both ways.

This is easily remedied by putting the coordinate system used somewhere
in the document, maybe in a descriptive header or something, just like a
Unix plot(1,3,5) file has to start with a "space" command if it wants to
be device-independent.

Actually, if you let the user choose a coordinate system, the whole
question almost becomes a non-issue, or at least many of the arguments
in favour of either choice lose their importance.  Surely I want to be
able to use coordinates in centimeters, not pixels; so why not let me
decide where to put the origin?  (As for me, I would put the origin in
the center of the screen.)

	Guido van Rossum, CWI, Amsterdam <guido@mcvax.uucp>