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>