bub@ames-lm.UUCP (Bubbette McLeod) (02/23/84)
Does anyone know of a standard modification to UNIX device independent
plot(5) format to allow character size changes, ala Tektronix 4014?
Thank you
-bub
{hao,menlo70}!ames-lm!bubhenry@utzoo.UUCP (Henry Spencer) (11/20/84)
In the course of some work on our plot(5) filter for the HP 7470A plotter,
we ran across an interesting question: just what does it mean if you ask
plot(3) for a non-square space? There are two possible interpretations:
1. The viewport (physical plot area) remains square, and the
coordinate scaling is not the same in X and Y.
2. The viewport is as large as it can be, within the available
physical space, while preserving the aspect ratio of
the space() request. So the X and Y scales are the same.
The Bell documentation strongly implies interpretation (1), and that's
what their plot(5) code seems to do. Our opinion is that (2) is much more
useful behavior -- in particular, it makes it possible to use the full area
of non-square devices safely -- and is unlikely to break anything. The
Bell graphics software we've examined invariably uses square spaces, so it
would be unaffected.
Does anybody have any opinions on this? Anybody know for sure whether
any Bell stuff exploits interpretation (1)?
[Just in case anybody is wondering, the 7470A code we posted to the net
a little while ago went for interpretation (2).]
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryrcd@opus.UUCP (Dick Dunn) (11/28/84)
> In the course of some work on our plot(5) filter for the HP 7470A plotter, > we ran across an interesting question: just what does it mean if you ask > plot(3) for a non-square space? There are two possible interpretations: > > 1. The viewport (physical plot area) remains square, and the > coordinate scaling is not the same in X and Y. > > 2. The viewport is as large as it can be, within the available > physical space, while preserving the aspect ratio of > the space() request. So the X and Y scales are the same. > > The Bell documentation strongly implies interpretation (1), and that's > what their plot(5) code seems to do... I've been faced with this one (and worse, but more of that in a minute). 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. The manual is quite clear on the point that "the plotting area is taken to be square" in "every case"--so if you stay with the plot(5) definitions you probably ought to follow that. > ...The > Bell graphics software we've examined invariably uses square spaces, so it > would be unaffected. But 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? Incidentally, there are devices which have non-square (rectangular) pixels--I wrote a plot driver for a Printronix printer, which has 1/60 " horizontally by 1/72 " vertically. Now, in the context of the definition of plot(5), what is meant by the "unity mapping" of a square region? If I map 1-1 to pixels, I have X and Y ranges which differ whether I use the full rectangular page or a square subregion. And don't forget the definition of circle and arc. How should those behave if the scaling doesn't come out equal in X and Y on the physical surface? It would seem that an arc would always lie on the circle drawn with corresponding parameters--yet unless the arc crosses the axis (presumably X) on which the radius is interpreted, there may be no point on the arc which lies at a true distance of the radius from the center! -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Reality? Gad, that's worse than puberty!
henry@utzoo.UUCP (Henry Spencer) (11/30/84)
> 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