plot(3,5) vs. non-square plot areas

[Henry Spencer]

> At the outset, it's just as well to admit that the definition of plot(5)
> doesn't really address the scaling question very well and it might be
> better just to choose a different interface and be done with it.
> 
> ... you may find other software (i.e., plot(5) but non-Bell) which relies
> on using differing X and Y scales to get a non-square mapping.  If you want
> compatibility, you need to preserve the definitions; if you don't need the
> compatibility, why not use a better interface definition?

What we want, frankly, is to have our cake and eat it too:  we want to
access non-square physical plot areas in a reasonable way, without breaking
existing programs by changing the interface.  The point of my query was
that programs which always feed square spaces to space() don't have an
incompatibility problem; none of them will break if the interpretation is
changed.  I speculate that there are few or no existing programs which use
non-square space() requests, which means that there is little or no
compatibility problem.

Devices with anisotropic coordinates (i.e. X and Y physical scales not
the same) are a headache.  Just ask the Lisa people at Apple; it's not an
accident that the Mac screen *is* isotropic.  But the correct way to tackle
the problem is clear:  such hardware botches should *NOT* be visible to the
customer.

Incidentally, for those who are interested, the replies I've had on the
matter have (so far) run unanimously in favor of the suggested change.
(Which is, for those coming in the middle of the discussion, interpreting
a non-square space() request as a request for a non-square physical plot
area, rather than as a request for anisotropic coordinates.)  Typically
the replies say "we did this long ago; nothing broke; we think it's the
only sensible way to handle the issue".  I agree.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry