Contact us Heritage collections Image license terms
HOME ACL ACD ICF SUS DCS G&A STARLINK Literature
Further reading □ ForewordContentsPrefacePrologueAcknowledgementsParticipants1. IntroductionA. GuedjB. HopgoodC. CrestinD. WarmanE. SabinF. EncarnacaoG. DunnH. BonoI. NewellJ. FoleyK. FoleyL. SanchaM. SanchaN. Sancha2. Working documentsCurrent positionGraphics primitivesCoreAttributesStructureMethodology: StructureDesignInputTransformationsFormal SpecificationConceptual FrameworkIFIP ReportRecommendationsFuture
C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACDLiteratureBooksMethodology in Computer Graphics
ACDLiteratureBooksMethodology in Computer Graphics
ACL ACD C&A INF CCD CISD Archives
Further reading

ForewordContentsPrefacePrologueAcknowledgementsParticipants1. IntroductionA. GuedjB. HopgoodC. CrestinD. WarmanE. SabinF. EncarnacaoG. DunnH. BonoI. NewellJ. FoleyK. FoleyL. SanchaM. SanchaN. Sancha2. Working documentsCurrent positionGraphics primitivesCoreAttributesStructureMethodology: StructureDesignInputTransformationsFormal SpecificationConceptual FrameworkIFIP ReportRecommendationsFuture

On the Concept of Current Position

Current Position

There has been a great deal of discussion around the problem associated with the current position which showed that the members of the group had two different backgrounds - single processor refresh display systems versus plotter.

People with a plotting background see all output as being produced on a large sheet of paper. Rotation or translation is just a redefinition of the one co-ordinate system on the large sheet of paper. People with a refresh display background tend to have many sheets of paper with objects defined upon them and these lay on the world plane. Rotation and translation operations are used to move the sheets of paper and thus to position the individual items.

The problem can be illustrated by the example:

    INIT
    MOVE(0,0)
    DRAW(1,1)
    TRANS(3,3)
    DRAW(2,2)

Initially we have the A coordinate system. The sequence MOVE(0,0) to DRAW(1,1) produces:-

CP A

Figure 1

Note that the current position is now at (1,1) in the A coordinate system. We then have the operation TRANS(3,3) which is seen by the refresh screen advocates as providing a new local coordinate system within the same sheet of paper which is used as a temporary coordinate system for subsequent line drawing.

The new coordinate system B is given as follows: (Figure 2)

A CP B

Figure 2

The translate command defines a new coordinate system B which has its origin at the position (3,3). The problem is that we have defined a transformation operation within the drawing commands. What happens to our current position? The new current position CP' must be defined with respect to the new B coordinate system. However, it is unclear what its value should be.

The possibilities are as follows:

(1) CP' = undefined
The main argument is that a transformation for model building in the middle of drawing is a suspect operation which will lead to confusion and, therefore, should be discouraged.
(2) CP' = (0,0)
Each time a new coordinate system is introduced, the current position is set to a specific point, the origin.
(3) CP' = (-∞, -∞)
The only motivation for this is that we have a well-defined undefined which will show up on any subsequent line drawing.
(4) CP' = (-2, -2)
This approach is the one favoured by packages like GPGS and GINO-F. The current position is felt to be something like beam position (apart from scissoring etc.) so that the actual position on the global sheet is unchanged by the introduction of the B coordinate system.
(5) CP' = (1,1)
The motivation here is the one favoured by the plotting package community. We have moved the sheet of paper being worked upon, together with the current position. This can be looked at another way. We may consider that CP is just a syntactic shorthand for abbreviating the argument lists to routines. Thus, only a specific drawing command, or one that moves the current point specifically, will alter its value.

On the whole, the reporting group felt that the recommendation should be to go along with the GPGS and GINO-F definition and leave the beam position, whatever that means, at the same position in the original coordinate system.

The final DRAW (2,2) would then generate: (Figure 3):

A CP B

Figure 3

Comments

The Working Group as a whole had a number of misgivings as far as the proposed solution was concerned. These can be summarised as follows:

  1. There is something intuitively wrong about drawing a line between a point in one coordinate system and a point in a different coordinate system.
  2. Tom Sancha mentioned that this problem had arisen in the past. One solution was to define an entity called a REF POINT. At any stage, a user could define a REF POINT in the current coordinate system and its position on the global piece of paper was remembered. At any subsequent time, possibly in a different coordinate system, the REF POINT could be accessed. The advantage is that the joining of points between coordinate systems is made much more obvious.
  3. Transformations are for viewing and should not be used for model building if they cause trouble. Thus you should not have transformations in the middle of drawing commands.
  4. The problem can perhaps be resolved by teaching people not to do it.
⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site