cliff (01/18/83)
Does anyone use the plot routines supplied with v7, and 4.1bsd? We are experimenting with them, and have written a filter for the vk-100 (gigi). If anyone is interested, a copy could be sent. I am not too impressed with the actual implementation of the "device independent routines", but they were already there... If anyone else has plot(1G) filters, or other "device independent" software, I would be interested in hearing about it. Some people here are considering writing a plot-10 package in the routines that produce the intermediary characters. --Thanks ...!ucbvax!lbl-csam!lanl-a!unm-ivax!cliff ...!pur-ee!purdue!lanl-a!unm-ivax!cliff
brian@sdcc3.UUCP (Brian Kantor) (09/18/84)
I'm looking for a filter that will allow me to display the standard UNIX intermediate plot files on my sun. Any info, pointers, or copies of programs to do this will be greatly appreciated. ihnp4 \ Brian Kantor, UC San Diego decvax \ akgua >---- sdcsvax ----- brian dcdwest/ ucbvax/ Kantor@Nosc
henry@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
dan@rna.UUCP (Dan Ts'o) (02/28/85)
x Anyone have a plot(5) package (or any other graphics software) for either the TEK4027 or the TEK4105 ? Thanks. Cheers, Dan Ts'o Dept. Neurobiology Rockefeller Univ. 1230 York Ave. NY, NY 10021 212-570-7671 ...cmcl2!rna!dan
karsh@geowhiz.UUCP (Bruce Karsh) (03/18/85)
Does anybody know whether the unix plot(1g) subroutine
libraries are in the public domain. I would like to
enhance them and post enhanced versions to the net. Does
anyone know who wrote them?
--
Bruce Karsh | Esperanto: the Universal Second Language
U. Wisc. Dept. Geology and Geophysics | Easy to learn. Politically neutral.
1215 W Dayton, Madison, WI 53706 | Spoken by millions in 100 countries.
(608) 262-1697 | 100 magazines, thousands of books.
{ihnp4,seismo}!uwvax!geowhiz!karsh | Send for the Free Postal Course today!dan@rna.UUCP (Dan Ts'o) (04/21/85)
x Does any have plot(5) routines written for the Tektronics 4027 ? Thanks. Also, has anyone used a Tektronics 4027 with MOVIE.BYU ? Any comments as to how well this works ? We will be using a 4027 emulator - what commands of the 4027 must be implemented in order for MOVIE.BYU to work ? Thanks. Cheers, Dan Ts'o Dept. Neurobiology Rockefeller Univ. 1230 York Ave. NY, NY 10021 212-570-7671 ...cmcl2!rna!dan
mrl@oddjob.UUCP (Scott Anderson) (05/12/86)
Sender:
I am looking for an implementation of the plot(3) routines using
HP-GL, the Hewlett-Packard Graphics Language as implemented on,
for example, the HP 7470 Graphics Plotter. A plot(5) filter
would also be useful.
--
*
* *
* * * * Scott Anderson
* * ** ihnp4!oddjob!kaos!sra
* * * * * * * *
* * *
* * * * * * * * * * * * * * * * * * * * * * * * * *roy@phri.UUCP (Roy Smith) (05/14/86)
In article <1323@oddjob.UUCP> sra@oddjob.UUCP (Scott R. Anderson) writes: > I am looking for an implementation of the plot(3) routines using HP-GL We did that here a while ago. Anybody who want's a copy should write me for details. -- Roy Smith, {allegra,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016