( Re Message From: John W. Eaton )

>

> On 2-Dec-1996, Mario Storti <

[hidden email]> wrote:

>

> : BTW, is there a way to know the aspect ratio of the gnuplot window?

>

> I don't know if gnuplot can return this information. Even if it can,

> it is not currently possible to have it returned in a variable in Octave.

>

> : I want to have the same scale factor in both axis, since I'm plotting

> : finite element meshes, and similar things. In Matlab 3.5 for DOS there

> : was the axis('square') feature.

>

> With some terminal drivers, the commands

> set size square

> or

> set size ratio 1

> will set the plot axes to be square, though the scales are not

> necessarily forced to be the same, so circles may still be displayed

> as ellipses. For example,

> gnuplot> set size ratio 1

> gnuplot> set parametric

> dummy variable is t for curves, u/v for surfaces

> gnuplot> plot sin(t), cos(t)

> shows a circle on my X display, but

> gnuplot> set xrange [-2:2]

> gnuplot> replot

> turns it into an ellipse.

>

> This works with gnuplot 3.6beta, anyway. I didn't check earlier

> versions.

>

> jwe

With regard to the above: I haven't used 3.6-beta, but am a long-time user

of gnuplot-3.5. In 3.5, the "set size <anything>" command sets the size of

the total /plotting/ area, including tic-labels, axis labels, plot title,

etc. The /graph/ itself (i.e. the axes and the plotted points) fits into

this according to the space taken up by the "furniture". Therefore it is

not possible to directly control the size of the /graph/, and you can only

get a 1:1 aspect ratio for the /axes/ by experiment. Also, a size setting

that gives 1:1 on a screen display may well give non-1:1 when printed on

paper. I know there were intentions to address these and other questions

during the development of 3.6, but can't answer for where they're at.

With regard to the other query from Jay St Pieere ("I wonder how hard it

would be to make a modification to the gnuplot source code to allow it to

support a ginput interface"), my guess is that this might be possible. It

would involve modifying, not gnuplot, but gnuplot-X11 (which is a

"backend" to gnuplot that gnuplot writes to, which in turn writes to the X

display). In fact, the best approach would be to produce a totally

different X "back-end" which could interpret gnuplot X-output (the

character stream), and have a mouse-event handler built-in. If this could

then write to file/named pipe/screen (and be based on Tcl/Tk perhaps) then

it might be possible.

But this would not be a trivial task, and I myself don't propose to try --

for the following reasons.

Based on my experience of 3.5 (and I may be doing 3.6-beta an injustice),

while gnuplot is a very useful rough-and-ready graphics display tool, and

can produce quite decent output on many occasions, it is not a top-class

package for "production" output. As well as the sort of minor roughness

such as the "size" question above, 3.5 at least was capable of making a

total mess of contouring and of surface plotting, and there are many other

technical shortcomings as well. Unless 3.6 (when finished) solves all

these problems, I would remain of the same view of gnuplot. Gnuplot's

basic problem is that it tries to be all things to all "terminals", and

builds the lot into the main code (with the partial exception of X11).

When 3.6 was first mooted, there was discussion of moving ALL the

terminal-dependent code out into backends like gnuplot-x11, with gnuplot

itself concerned only with generating "terminal-independent" code. If they

had gone down this road I would have joined in enthusiastically, but

apparently they decided not to, and I think this means that gnuplot is

going to continue to try to break out of its dead-end, but in fact only

tinker with the problem. My understanding is that, while this approach

would have been straightforward on UNIX systems, it would have been too

difficult, or impossible, on other OSs, and there was a policy decision to

keep gnuplot "universal". So be it. But then my wish is to see something

other than gnuplot.

Gnuplot has served octave well, but is not adequate to allow octave to

reach its full potential. Octave has reached a new stage of maturity, and

it is time to address the graphics question seriously. Along with this

goes the contouring/surface-plotting question. Again, up to a point

gnuplot has served octave reasonably well for these two purposes, but

(leaving aside the occasional complete collapse of contour/surface) there

are important possibilities which remain remote (though not absolutely

impossible) so long as these functions are delegated to gnuplot, rather

than being computed within octave.

1. You cannot directly obtain the coordinates of the countour lines

(planar or surface) as you can in MatLab (where the function "contour"

returns lists of numerical coordinates directly to MatLab); the best

you can do in gnuplot is to "set terminal table" and "set output file",

and then write an octave function to recover this information from the

file.

2. Similar considerations apply to surfaces themselves.

3. (A different point). It is not possible to fill, shade or colour boxes,

facets of surfaces, or bands between contours etc, in gnuplot. This is

because all these things are simply collections of line segments to

gnuplot, which has no concept of closed region.

So far, using octave, I have on accasion substituted other graphics

software (mainly PlotMTV and sometimes GLE) for gnuplot, especially when I

want a professional finish or special effects (not so special -- these are

not only normal expectation for good presentation, but often essential to

represent the information at all).

Therefore I warmly welcome John's announced intention to develop octave

graphics in a new direction, and will be happy to help as best I can.

The main thing needed by anyone who wants to think about "new graphics for

octave" is what the "graphics output stream" is expected to look like.

Given that, we can try the effects and capabilities of different tools.

Given these views, I think modifying gnuplot for "ginput" would be yet

another stop-gap in the long line of such attempts to rememdy gnuplot

deficiencies.

This is also the moment to, at least, put contouring where it belongs:

fair and square in octave!

Sorry to have launched a mini-treatise on the questions, but the above

(and a good deal else besides) has been building up steam for some time.

Meanwhile, my hearty thanks and deep appreciation to John Eaton for having

brought octave to where it is, and for his continuing efforts and

intentions to further enhance it.

Best wishes to all,

Ted. (

[hidden email])