gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Connect gnuplot_x11 to exterior application window

[Petr M. <mi...@ph...>]

>> What should happens if you type 'q' or 'ctrl-q' in the exterior
>> application  window?  As it stands now, this seems to close the
>> window or at least disconnect gnuplot from it.
>> But that is probably not such a great idea if it really is somebody
>> else's window, and gnuplot is just a guest.  I am inclined to say
>> that when gnuplot_x11 is running in this guest mode, the 'quit'
>> hotkey should be disabled.  Maybe some of the other hotkeys as well.
>
> Good point.  It would be nice to get this all under one "mouse" category.

'q' and 'ctrl-q' should be disabled during "pause mouse" (e.g. "pause mouse 
any" should return 'q' if you pressed 'q').

Any idea how to change x11's accordingly?

---
PM

Re: How to minimize code damage when adding new features. [was Re: Connect gnuplot_x11 to exterior application window]

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> 
>> On Saturday 08 April 2006 07:30 pm, Daniel Sebald wrote:
>>  
>>
>>> Anyway, I know that this is bloated.  My philosophy to these patches 
>>> with conditional code has always been that if one turns off the 
>>> experimental feature it goes back *exactly* to the code before the 
>>> patch was applied.
>>
>>
>>
>> Right idea, but there is a better way to accomplish this.
>>
>> Step 1-5:
> 
> 
> Got it.  I can create a couple patches to reduce this the conditionals.

I've created some updated patches, Ethan.  Give them a try.  Conditional code is greatly reduced with replacement by defines in header files when possible.

After some extra variables to rid the -3/-2/-1 confusion, I moved this

>>>+#ifdef FOO
>>>	if (plot_number < 0) return NULL; 
>>>+#endif

to x11.trm and so that the gplt_x11.c code has no concern about sign.  I think we learned from the palette code of a few weeks back that blocking things before going into the pipe is a good idea.

We can hagle over what should be proper behavior if you think the code looks more organized.

Dan

Re: Connect gnuplot_x11 to exterior application window

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> I thought of another issue with this patch that is worth
> some discussion.  
> 
> What should happens if you type 'q' or 'ctrl-q' in the exterior
> application  window?  As it stands now, this seems to close the
> window or at least disconnect gnuplot from it.
> But that is probably not such a great idea if it really is somebody
> else's window, and gnuplot is just a guest.  I am inclined to say
> that when gnuplot_x11 is running in this guest mode, the 'quit'
> hotkey should be disabled.  Maybe some of the other hotkeys as well.

Good point.  It would be nice to get this all under one "mouse" category.  After the next revision let's think if there is some better way to handle the de/activation of ButtonRelease.

Dan

Re: Connect gnuplot_x11 to exterior application window

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Sunday 09 April 2006 05:14 pm, Daniel J Sebald wrote:
> 
>>For an X11 window there can't be two clients desiring the ButtonPress
>>event at the same times.
> 
> 
>>The external client that created the window may or may not have requested 
>>ButtonPress via ButtonPressMask.  
> 
> 
> That would clearly be a programming error.  Why open a window for the purpose
> of displaying gnuplot output, and then fail to let gnuplot have access to the
> window events?

Well, not necessarily.  Maybe someone likes the cursor position information but wants a button press to be interpreted by the parent application to load some new data and replot.  I don't know.  It boils down to what can accomplish.  Can't defy X11 behavior.  If there were no documentation about this option, it would be likely the programmer of the outside application might never understand the problem even though it may be their "error".

> 
> 
>>If it did and gplt_x11.c attempts to also set ButtonPressMask, the window will crash.   
> 
> 
> Seems unlikely.
> Shouldn't you just get an error return from the call to XSelectInput?

No, I'm fairly certain I tried this.  I wouldn't have added this "b" option if all that would happen is some kind of benign error value.  The system does something bad, from what I remember.  (I can probably force it with an internal code change just to test out.)  From what I remember, when two clients want the ButtonPress the plot would appear and then clicking in the window would cause the window to go away.

> 
> 
>>The "b", "B" option is a solution that may not be elegant, but it works.  
>>It could be changed and placed under {un}set mouse if ever we find an X11 expert. 
> 
> 
> How do you know it works, if the tcl demo you have either crashes or
> prevents mousing?

In the past I have tried this manually.  There are some utilities to print out the XID for a window.  I'd create a window in some application that doesn't use a mouse, use the utility to print out the XID and then manually type the XID into the command line.  It worked.  (I left a note in gpdemos.tcl.)

>  Sounds to me like the mousing code is basically untested.
> Do you have another demo that does work?

No, but I think it is behaving as one might expect.  Wait until I get my patch set up on SourceForge and we'll revisit its behavior.

Dan

Re: Connect gnuplot_x11 to exterior application window

[Ethan A M. <merritt@u.washington.edu>]

I thought of another issue with this patch that is worth
some discussion.  

What should happens if you type 'q' or 'ctrl-q' in the exterior
application  window?  As it stands now, this seems to close the
window or at least disconnect gnuplot from it.
But that is probably not such a great idea if it really is somebody
else's window, and gnuplot is just a guest.  I am inclined to say
that when gnuplot_x11 is running in this guest mode, the 'quit'
hotkey should be disabled.  Maybe some of the other hotkeys as well.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Connect gnuplot_x11 to exterior application window

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 09 April 2006 05:14 pm, Daniel J Sebald wrote:
> 
> For an X11 window there can't be two clients desiring the ButtonPress
> event at the same times.

> The external client that created the window may or may not have requested 
> ButtonPress via ButtonPressMask.  

That would clearly be a programming error.  Why open a window for the purpose
of displaying gnuplot output, and then fail to let gnuplot have access to the
window events?

> If it did and gplt_x11.c attempts to also set ButtonPressMask, the window will crash.   

Seems unlikely.
Shouldn't you just get an error return from the call to XSelectInput?

Regardless. Even if you are correct that there is a potential conflict,
it is the fault of the application that opens the window and then 
hands it over to gnuplot without letting go of the mouse input.
Gnuplot should expect mousing as normal, including mouse button events.

> The "b", "B" option is a solution that may not be elegant, but it works.  
> It could be changed and placed under {un}set mouse if ever we find an X11 expert. 

How do you know it works, if the tcl demo you have either crashes or
prevents mousing?  Sounds to me like the mousing code is basically untested.
Do you have another demo that does work?

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Connect gnuplot_x11 to exterior application window

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Sunday 09 April 2006 12:26 pm, Daniel J Sebald wrote:
> 
>>1) "b" for "buttonable". 
>>If no "b" appears gnuplot's mouse cursor will still move around but will not respond to clicks. 
>>
>>2) "m" for "mousable", 
>>If no "m" appears have gplt_x11.c also disable the mouse activity for that window so the cursor will not even move. 
>>
>>Can anyone conceive of a need for (1)?
> 
> 
> I don't see a need for any of that.
> What's wrong with '{un}set mouse'?

For an X11 window there can't be two clients desiring the ButtonPress event at the same times.  See

http://tronche.com/gui/x/xlib/event-handling/XSelectInput.html

last bullet point in the list.  The external client that created the window may or may not have requested ButtonPress via ButtonPressMask.  If it did and gplt_x11.c attempts to also set ButtonPressMask, the window will crash.

So gnuplot needs to be told whether it is OK to take control of the ButtonPress events.

Now, this could be eliminated if there were some way to inquire from within gplt_x11.c if there is or isn't some outside client who has control of the ButtonRelease event.  In that case, the functionality could be placed under {un}set mouse.  I've looked, but none of the routines in the windowing functions give such a solution.  Perhaps there is some other Xlib routine for looking at processes and so on.

Here is about the closes thing I could find:

http://tronche.com/gui/x/icccm/sec-4.html

4.1.7. Input Focus

There are also routines that read like they might be worthwhile:

http://www.xfree86.org/current/XGrabButton.3.html

but I'm just not sure if these means to take hold of the ButtonPress events.  But somehow I just think that an outside client can't override the ButtonPress of some parent client.

So, it's a lot work to find out the proper method of forcing control of ButtonPress (or even determining if an outside client has control of ButtonPress events).  The "b", "B" option is a solution that may not be elegant, but it works.  It could be changed and placed under {un}set mouse if ever we find an X11 expert.

Dan

Re: Connect gnuplot_x11 to exterior application window

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 09 April 2006 12:26 pm, Daniel J Sebald wrote:
> 
> 1) "b" for "buttonable". 
> If no "b" appears gnuplot's mouse cursor will still move around but will not respond to clicks. 
> 
> 2) "m" for "mousable", 
> If no "m" appears have gplt_x11.c also disable the mouse activity for that window so the cursor will not even move. 
> 
> Can anyone conceive of a need for (1)?

I don't see a need for any of that.
What's wrong with '{un}set mouse'?



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Connect gnuplot_x11 to exterior application window

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:

> I propose to remove the verification.
> 
> I've already met a trouble where plotting of an experimental map (in 
> gnuplot binary format) was refused because "equidistant" stepper motor 
> positions were above the built-in tolerance.
> 
> If a user wants to draw a non-equistant map, then he should use with 
> pm3d, not with image.

I'll make this change if no objections appear in the next few days.  (I doubt there will be any.)

Dan

Re: Connect gnuplot_x11 to exterior application window

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:

>>The issue here is that two applications cannot share the mouse device 
>>of the same X windows.
> 
> 
> I don't think that is true, because gnuplot is
> catching and handling the mouse positional events.
> It's only the button clicks that are getting lost.
> I don't know why.

I just about have the revised, cleaned up patch.  (But I have to run in a few minutes.)  I was going to change the set term control flag from "m" to "b" for "buttonable" to reflect the fact that it is only the ButtonPress/ButtonRelease that can't be shared among two applications.

However, I then thought there might be a preferred alternative.  Which would people want?

1) "b" for "buttonable".  If no "b" appears gnuplot's mouse cursor will still move around but will not respond to clicks.

2) "m" for "mousable", If no "m" appears have gplt_x11.c also disable the mouse activity for that window so the cursor will not even move.

Can anyone conceive of a need for (1)?

Dan

Binary data | String handling

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 08 April 2006 11:28 am, Daniel J Sebald wrote:
> 
> So, abstractions:
> 
> ------------------
> level 1 (low) 
> df_readline_ascii and df_readline_binary put data into similar format, double floats.

> ------------------
> level 2 (intermediate) 
> interpret that data into more meaningful chunks, for example *strings*

I have no idea what you mean by this.
How can you represent or store a string in a "double float"?

> Right now, there is no intermediate level of processing.

Doesn't expression evaluation count as exactly this intermediate level of
processing?  For instance the last plot in stringvar.dem:

	plot 'silver.dat' using 1:2 with linespoints notitle,  \
             '' using 1:2:(sprintf("[%.0f,%.0f]",$1,$2)) with labels

> But let me illustrate one that could be: strings.  
> Recently introduced, strings are meant to read in strings as though 
> they were some type of data object.

You are confusing two separate things, added at separate times.
The "datastrings" capability, which allows reading string constants from
a data file, was first offered as a patch in 2001/2002.
It probably should have gone into version 4.0 since at that point it had
already been tested for 2 years or so.  It was stable then, and it remains
stable now.

The "string variables" capability was added much more recently.
It was refined over 3 years or so, guided by extensive feedback from
various people with regard to 2 earlier attempts I made at string
handling. The earlier attempts never made it into cvs.
As I pointed out in a separate posting, the only interaction I can
think of at the moment between string variables and data input 
(either ascii or binary) is through the use of string-valued
expression evaluation in the 'using' specification.

> No problem.  However, the code for it was placed in df_readascii using 
> a global variable, placing strings I think (correct me if I'm wrong), 
> into a slightly different "container" than the "points" model that seems 
> to be the basis of much of gnuplot.

I'm not entirely sure what "it" you are talking about.
If you mean the implementation of xtics(col) and 'using title <col>',
then of course they do not fit the "points model", because they are
not points within a curve at all.  They are axis labels or key title
entries, respectively. Since they are not points, they are not stored
as points.

The other capability that the original datastings code added is
	plot with labels
Here you could argue that these strings are indeed analagous to
"points", but they are even more analogues to "labels".
At that time the only mechanism we had for placing strings onto a
plot was the "set labels" code, so that was what I used.
Remember that string variables were still 4 years in the future.

> Had the strings instead been implemented at the (currently non-existent)
> intermediate level, it would work automatically for ascii and binary.

You've lost me. What is a "binary string"?

I think this intermediate level already exists, and works for both
ascii and binary data.  If the syntax
	plot "foo" binary using (expr($1)):(expr($2)):(expr($3))
doesn't work, then file a bug report.  But that would be a general
problem to do with expression evalution of binary data, nothing
in particular to do with strings.

In other words, if you want to use binary data to construct a string,
that should work already. But I'm having trouble coming up with an
example where you would want to do this.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Connect gnuplot_x11 to exterior application window

[Petr M. <mi...@ph...>]

>>>   Enable verify every pixel coordinate in image (EXPERIMENTAL)
>> I don't even know what that 'verify' one does.
>
> Because we are forced to stay with the "points" method of storing data (see 
> above), every pixel in an image has an (x,y,z) location.  Now, that data 
> could have come from binary or ascii, with or without implied physical 
> position.  So, it could be the case that the user did or did not supply the 
> coordinates.  If the user did supply coordinates, there is the possibility 
> that the the coordinates don't form a valid grid.  We then ask, should or 
> should we not verify the location of every individual pixel?  Or is it good 
> enough just to know the four corners of the image and assume an evenly spaced 
> grid even though the user may have entered data that doesn't fit to that.
>
> I'm happy with not verifying the points.  (Matlab/Octave sometimes does that 
> sort of thing... just looks at the end points and assumes even spacing. 
> Also, speeds things up a bit.)  I don't know how others feel.

I propose to remove the verification.

I've already met a trouble where plotting of an experimental map (in gnuplot 
binary format) was refused because "equidistant" stepper motor positions 
were above the built-in tolerance.

If a user wants to draw a non-equistant map, then he should use with pm3d, 
not with image.

---
PM

Re: 'set size ratio' plot

[<br...@ph...>]

jun...@so... wrote:
> How about the syntax below?
> 
>     set size {{no}squre | ratio { center | xaxis | yaxis } <r> | noratio } {<xscale>,<yscale>}

No better, arguably even worse then the previous proposal.  As I said 
before, controlling this aspect of the positioning has no business being 
in "set size" in the first place, simply because it doesn't change the 
size at all.  It changes the origin.  So it should go into 'set origin'.
And it'll need positioning options along the lines those of 'set key',
'left', 'right', 'top', 'bottom', ....

Re: How to minimize code damage when adding new features. [was Re: Connect gnuplot_x11 to exterior application window]

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Saturday 08 April 2006 07:30 pm, Daniel Sebald wrote:
>  
> 
>>Anyway, I know that this is bloated.  
>>My philosophy to these patches with conditional code has always been 
>>that if one turns off the experimental feature it goes back *exactly* 
>>to the code before the patch was applied.
> 
> 
> Right idea, but there is a better way to accomplish this.
> 
> Step 1-5:

Got it.  I can create a couple patches to reduce this the conditionals.

> 
> 	- changing manifest constants into enums or #defines
> 

This one I would definitely like to see in the case of gplt_x11.c.  I.e., combine all the letter codes into one group of defines.

> I'm still learning this game myself, inspired by watching the development
> process of the linux kernel.  Have a look yourself.  The amazing thing is
> that the linux kernel has virtually no conditional segments despite a huge
> number of configuration options; their effects are hidden in definitions,
> header files, and in the choice of alternative source files to build from.

I have looked at the Linux code, having had to compile special kernels from time to time.  It's some of the best code out there.  (And their method of tracking bug fixes and notifying the public is excellent.)


> 
>>>    Find_Plot_In_Linked_List_By_Number(int plot_number)
>>>    {
>>>+#ifdef FOO
>>>	if (plot_number < 0) return NULL; 
>>>+#endif
> 
> 
> The linux kernel approach would be to change the above line unconditionally
> to something like
> 	if (plot_number < MIN_PLOT_NUMBER) return NULL;
> And then in some configuration header file you would have
> 	#ifdef FOO
> 	#define MIN_PLOT_NUMBER 0
> 	#else
> 	#define MIN_PLOT_NUMBER (-MAXINT)
> 	#endif

Well, that is sort of the C header file model of things.  Given how far the optimization of GPL compilers have come along, the case where MIN_PLOT_NUMBER is -MAXINT will be optimized out of the assembled code.  I'd be fine with that approach to things.


> Yes.  But as I said, I think that if the code is properly cleaned up
> there will only be a handful of places where such conditional code is needed.

A pre-patch is no problem.  Let me work on it.

Dan

How to minimize code damage when adding new features. [was Re: Connect gnuplot_x11 to exterior application window]

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 08 April 2006 07:30 pm, Daniel Sebald wrote:
 
> Anyway, I know that this is bloated.  
> My philosophy to these patches with conditional code has always been 
> that if one turns off the experimental feature it goes back *exactly* 
> to the code before the patch was applied.

Right idea, but there is a better way to accomplish this.

Step 1: Figure out how you want the new feature to work, and what
	might need to be added to the infrastructure to support it.

Step 2:	Modify the infrastructure accordingly, confirm that everything
	still works.  That becomes a pre-patch.

	Things in this category include

	- moving routines from one source module to another because they
	  can no longer be static. But the routine itself is unchanged

	- consolidation of variables into a shared structure, so that
	  the whole structure can be passed instead of 5 separate
	  variables. Better to change and test the revised calling
	  interface now, so that a bug in this sort of house-keeping change
	  doesn't get misinterpreted as a bug with your actual new code
	  features. The eventual new feature may add new fields to the
	  structure, but this way they will not require changes to the
	  various call sites or routine PROTO definitions.

	- making a chunk of in-line code into a subroutine, so that it
	  can later be shared with new callers in your main patch

	- changing manifest constants into enums or #defines

Step 3: Apply the pre-patch, and test thoroughly to insure that no bugs
	have been introduced and that the original behaviour is maintained.
	Or, if you are proposing to change something (new syntax, new
	restrictions on the parameter values, etc) make sure it gets
	tested this way in advance of your actual new feature code.

Step 4:	Keep this pre-patch separate from your main patch. If it cleans
	up existing code, lobby to get it in cvs now rather than waiting
	for the main patch to be finalized.

Step 5:	With the pre-patch in place, adding the new features should be
	a much less intrusive change.  You should strive for as few
	conditional code locations as possible.  Anywhere you end up
	with suspiciously parallel code chunks separated by #if/#else/#endif,
	go back and repeat steps 1 to 3.

I'm still learning this game myself, inspired by watching the development
process of the linux kernel.  Have a look yourself.  The amazing thing is
that the linux kernel has virtually no conditional segments despite a huge
number of configuration options; their effects are hidden in definitions,
header files, and in the choice of alternative source files to build from.

> >Here is one small example of utterly pointless conditional code:
> >
> > Add_Plot_To_Linked_List(int plot_number)
> > {
> > #ifdef EXTERNAL_X11_WINDOW
> >     plot_struct *psp;
> >     if (plot_number >= 0)
> >         /* Make sure plot does not already exists in the list. */
> >         psp = Find_Plot_In_Linked_List_By_Number(plot_number);
> >     else
> >         psp = NULL;
> > #else
> >     /* Make sure plot does not already exist in the list. */
> >     plot_struct *psp = Find_Plot_In_Linked_List_By_Number(plot_number);
> > #endif
> 
> The point is that when EXTERNAL_X11_WINDOW is deactivated the code 
> goes back to what it was before the patch.

Even if you think that allowing negative window numbers is not a bug,
you *still* don't need the above code sections.  A less intrusive change
would be

> >     Find_Plot_In_Linked_List_By_Number(int plot_number)
> >     {
> > +#ifdef FOO
> > 	if (plot_number < 0) return NULL; 
> > +#endif

The linux kernel approach would be to change the above line unconditionally
to something like
	if (plot_number < MIN_PLOT_NUMBER) return NULL;
And then in some configuration header file you would have
	#ifdef FOO
	#define MIN_PLOT_NUMBER 0
	#else
	#define MIN_PLOT_NUMBER (-MAXINT)
	#endif

> My thinking is that after the decision is made to remove its experimental status, 
> then I or the developers could simply remove code for one of the conditions and  
> if one recognizes "hey this could be simplified here or there" then do so.    

The time you have the deepest understanding the code details is when you are
first creating a patch.  It's far easier to clean things up at that time
then it is 3 years later when you've forgotten half of the complications
or possible side effects.  The best simplification is to prepare things
so that there *is no change* to the mainline code if you back out a new
feature.

> You've inherently accepted already that the experimental code should be 
> applied because if EXTERNAL_X11_WINDOW is deactivated, this change is still present.

Exactly.  That is what I want to see.  *First* make any small changes to the
main code, the ones that are not supposed to harm anything but might turn out
to have unforeseen side effects. Get that all sorted out and debugged, make
it a separate patch, and request that it be added to CVS before the main
patchset. 

> Second thing, and it probably suggests my preference for "bottom up" style 
> of programming, I see no reason to limit the routine Find_Plot... in that way.
> It's not a sanity check.  As far as the linked list is concerned the plot number
> can be any integer value positive or negative, so why limit it at that level?      

If that is true then you have a different kind of design flaw.
If negative id numbers are legal, but your new code uses them to signal
something else, then you have created a conflict between the two
implementations. That is bad. It would be better in that case to leave
the plot_number parameter alone and introduce a new flag or parameter
that carries whatever your new information is (I haven't looked at it
in detail to see what is now special about negative ids).

> When the new feature is deactivated, guaranteed no bug introduced because of patch.

I think you have this exactly backwards.  Doing it your way in fact
maximizes the chance that trying to back it out later will fail.

As an example, let me just point out that when I tried to
deactivate either the BINARY or IMAGE parts of gplt_x11.c, it wouldn't
even compile.  That is IMHO the direct result of your approach to
throwing bits of conditional code here and there at the risk of getting
some of them wrong.  Particularly because there are now multiple code
paths that must be modified in parallel during any unrelated new
development work *even though only one of the code paths gets tested*.
They start out parallel, but the non-default path suffers from bit rot.
If the conditional feature is later turned off, the original code no
longer works. Better to arrange things so that the bulk of the code
is the same with or without the conditional feature.

> You are alright then with changing the name "plot" to "current_plot" 
> to better reflect the meaning of the pointer, right?

I don't care one way or the other about the name. But if you want to
change the name and it removes a lot of your conditionals, then send me
a patch for the name change alone and I'll apply that right now.
Or keep it on the side as patch 1 in a series of N.

> And you think this should still have the conditional code for "new feature"
> so that there is some way of turning off the external window capability? 

Yes.  But as I said, I think that if the code is properly cleaned up
there will only be a handful of places where such conditional code is needed.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Connect gnuplot_x11 to exterior application window

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 08 April 2006 11:28 am, Daniel J Sebald wrote:
> 
> >>   Enable general binary data file reading (EXPERIMENTAL)
> >>   Enable X11 polygon info in binary, not ascii (EXPERIMENTAL)
> > 
> > I have mixed feelings about these.  They do work, but the code is so
> > tangled that at some point we may have to rip it apart and re-do it.
> 
> I don't think that is the case.  
> [...]
> The implementation of that is hidden behind the scenes at a low level 
> such that plot3d/graph3d never needs to worry about such things.    

Yeah, but my gripe is with this:
  lascaux [333] grep -c 'BINARY_DATA' datafile.c pl*.c
  datafile.c:30
  plot2d.c:3
  plot3d.c:5
The code in datafile.c has become practically unreadable

>>   Enable string variables (EXPERIMENTAL)
> I like the string variables, 
> I just wish there were some way of incorporating them at a higher level.
> I mean, binary is really meant for large data files in my mind.  
> If strings don't work for binary, that's OK.  

I think you are confused here. The "string variables" configuration option
refers to support for an internal data type STRING.
It affects mostly command line parsing and expression evaluation.  E.g.
	myfilename = "datafile_" . sprintf("%g", A+B)
	splot myfilename
I am unaware of any bad interaction with binary data files, but if there
is one please let me know.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: 'set size ratio' plot

[<jun...@so...>]

How about the syntax below?

    set size {{no}squre | ratio { center | xaxis | yaxis } <r> | noratio } {<xscale>,<yscale>}



The option "center" is default behavior same as the present.

In the option "x(y)axis", <y(x)scale> is neglected and a graph boundary 
is calculated with the reference to only the length of the x(y)-axis. 
Then, y(x)scale is calculated by the graph boundary and reset.

This option should resolve all the problem in multiplot, 
since we can fixate the bottom left corner and know the position of 
the right top one. 

Patches below are just my idea and there should be more appropriate 
methods to implement. 
Those two feature must be very useful to put several graphs of 
the same ratio and the same length of the axis in multiplot.
So, I hope such features are implemented in future gnuplot by any way.


*** gadgets.h.org	Sun Apr  9 03:49:05 2006
--- gadgets.h	Sun Apr  9 03:49:14 2006
***************
*** 305,310 ****
--- 305,318 ----
  extern float yoffset;		/* y origin setting */
  extern float aspect_ratio;	/* 1.0 for square */
  
+ /* graph position in set size ratio plot */
+ typedef enum ratio_position_type {
+   CENTER,
+   XAXIS,
+   YAXIS
+ } ratio_position_type;
+ extern enum ratio_position_type ratioposition;   /* CENTER */
+ 
  /* plot border autosizing overrides, in characters (-1: autosize) */
  extern float lmargin, bmargin, rmargin, tmargin;
  



*** gadgets.c.org	Sun Apr  9 03:47:55 2006
--- gadgets.c	Sun Apr  9 03:48:17 2006
***************
*** 75,80 ****
--- 75,81 ----
  float xoffset = 0.0;		/* x origin */
  float yoffset = 0.0;		/* y origin */
  float aspect_ratio = 0.0;	/* don't attempt to force it */
+ enum ratio_position_type ratioposition = CENTER;      /* graph position in ratio plot */
  
  /* space between left edge and plot_bounds.xleft in chars (-1: computed) */
  float lmargin = -1;




*** set.c.org	Sun Apr  9 03:49:43 2006
--- set.c	Sun Apr  9 03:50:14 2006
***************
*** 3452,3457 ****
--- 3452,3467 ----
  	    ++c_token;
  	} else if (almost_equals(c_token,"ra$tio")) {
  	    ++c_token;
+ 	    if (almost_equals(c_token,"cen$ter")) {
+ 	      	    ++c_token;
+ 		    ratioposition = CENTER;
+ 	    } else if (almost_equals(c_token,"x$axis")) {
+ 	      	    ++c_token;
+ 		    ratioposition = XAXIS;
+ 	    } else if (almost_equals(c_token,"y$axis")) {
+ 	      	    ++c_token;
+ 		    ratioposition = YAXIS;
+ 	    }
  	    aspect_ratio = real(const_express(&s));
  	} else if (almost_equals(c_token, "nora$tio") || almost_equals(c_token, "nosq$uare")) {
  	    aspect_ratio = 0.0;





*** graphics.c.org	Sun Apr  9 03:49:52 2006
--- graphics.c	Sun Apr  9 03:55:36 2006
***************
*** 319,324 ****
--- 319,326 ----
      int xtic_height;
      int ytic_width;
      int y2tic_width;
+     int top_margin;             /* calculated top margin */
+     int right_margin;           /* calculated right margin */
  
      int key_cols = 1;		/* # columns of keys */
  
***************
*** 444,450 ****
      plot_bounds.ytop = (int) (0.5 + (ysize + yoffset) * t->ymax);
  
      if (tmargin < 0) {
! 	int top_margin = x2label_textheight + title_textheight;
  
  	if (timetop_textheight + ylabel_textheight > top_margin)
  	    top_margin = timetop_textheight + ylabel_textheight;
--- 446,452 ----
      plot_bounds.ytop = (int) (0.5 + (ysize + yoffset) * t->ymax);
  
      if (tmargin < 0) {
!       top_margin = x2label_textheight + title_textheight;
  
  	if (timetop_textheight + ylabel_textheight > top_margin)
  	    top_margin = timetop_textheight + ylabel_textheight;
***************
*** 461,466 ****
--- 463,469 ----
  	plot_bounds.ytop -= top_margin;
  	if (plot_bounds.ytop == (int) (0.5 + (ysize + yoffset) * t->ymax)) {
  	    /* make room for the end of rotated ytics or y2tics */
+  	    top_margin += (int) (t->h_char * 2);
  	    plot_bounds.ytop -= (int) (t->h_char * 2);
  	}
      } else
***************
*** 849,865 ****
  
      if (rmargin < 0) {
  	/* plot_bounds.xright -= y2label_textwidth + y2tic_width + y2tic_textwidth; */
! 	plot_bounds.xright -= y2tic_width + y2tic_textwidth;
  	if (y2label_textwidth > 0)
! 	    plot_bounds.xright -= y2label_textwidth;
! 
  	if (plot_bounds.xright == (int) (0.5 + t->xmax * (xsize + xoffset))) {
  	    /* make room for end of xtic or x2tic label */
  	    plot_bounds.xright -= (int) (t->h_char * 2);
  	}
  	/* DBT 12-3-98  extra margin just in case */
  	plot_bounds.xright -= 0.5 * t->v_char;
- 
      } else
  	plot_bounds.xright -= (int) (rmargin * t->h_char);
  
--- 852,869 ----
  
      if (rmargin < 0) {
  	/* plot_bounds.xright -= y2label_textwidth + y2tic_width + y2tic_textwidth; */
!       right_margin = y2tic_width + y2tic_textwidth;
  	if (y2label_textwidth > 0)
! 	    right_margin += y2label_textwidth;
! 	    plot_bounds.xright -= right_margin;
  	if (plot_bounds.xright == (int) (0.5 + t->xmax * (xsize + xoffset))) {
  	    /* make room for end of xtic or x2tic label */
+ 	    right_margin += (int) (t->h_char * 2);
  	    plot_bounds.xright -= (int) (t->h_char * 2);
  	}
  	/* DBT 12-3-98  extra margin just in case */
+ 	right_margin += 0.5 * t->v_char;
  	plot_bounds.xright -= 0.5 * t->v_char;
      } else
  	plot_bounds.xright -= (int) (rmargin * t->h_char);
  
***************
*** 896,904 ****
  	if (current_aspect_ratio >= 0.01 && current_aspect_ratio <= 100.0) {
  	    double current = ((double) (plot_bounds.ytop - plot_bounds.ybot)) / (plot_bounds.xright - plot_bounds.xleft);
  	    double required = (current_aspect_ratio * t->v_tic) / t->h_tic;
! 
! 	    if (current > required) {
! 		/* too tall */
  		int height = plot_bounds.ytop - plot_bounds.ybot;
  		plot_bounds.ytop = plot_bounds.ybot + required * (plot_bounds.xright - plot_bounds.xleft);
  		height -= (plot_bounds.ytop - plot_bounds.ybot);
--- 900,909 ----
  	if (current_aspect_ratio >= 0.01 && current_aspect_ratio <= 100.0) {
  	    double current = ((double) (plot_bounds.ytop - plot_bounds.ybot)) / (plot_bounds.xright - plot_bounds.xleft);
  	    double required = (current_aspect_ratio * t->v_tic) / t->h_tic;
! 	    /* CENTER */
! 	    if (ratioposition == CENTER ) {
! 	      if (current > required) {
! 		/* too tall */  	
  		int height = plot_bounds.ytop - plot_bounds.ybot;
  		plot_bounds.ytop = plot_bounds.ybot + required * (plot_bounds.xright - plot_bounds.xleft);
  		height -= (plot_bounds.ytop - plot_bounds.ybot);
***************
*** 912,917 ****
--- 917,949 ----
  		width /= 2;
  		plot_bounds.xright += width;
  		plot_bounds.xleft += width;
+ 	      }
+ 	    /* XAXIS */
+ 	    } else if (ratioposition == XAXIS ) {
+ 		plot_bounds.ytop = plot_bounds.ybot + required * (plot_bounds.xright - plot_bounds.xleft);
+ 		if ( fabs((current-required)/required) > 0.001  ) /* for replot */
+ 		  { /* calculate ysize */
+ 		  if(tmargin<0) {
+ 		    ysize = ((double) (plot_bounds.ytop + top_margin)) / ((double) (t->ymax)) + yoffset;
+ 		    fprintf(stderr, "\tsize is set to %g,%g\n", xsize, ysize);
+ 		  } else {
+ 		    ysize = ((double) (plot_bounds.ytop + tmargin * t->v_char)) / ((double) (t->ymax)) + yoffset;
+ 		    fprintf(stderr, "\tsize is set to %g,%g\n", xsize, ysize);
+ 		  }
+ 		}
+ 	    /* YAXIS */
+ 	    } else if (ratioposition == YAXIS ) {
+ 		plot_bounds.xright = plot_bounds.xleft + (plot_bounds.ytop - plot_bounds.ybot) / required ;
+ 		if ( fabs((current-required)/required) > 0.001  ) /* for replot */
+ 		  { /* calculate xsize */
+ 		  if(rmargin<0) {
+ 		    xsize = ((double) (plot_bounds.xright + right_margin)) / ((double) (t->xmax)) + xoffset;
+ 		    fprintf(stderr, "\tsize is set to %g,%g\n", xsize, ysize);
+ 		  } else {
+ 		    xsize = ((double) (plot_bounds.xright + rmargin * t->h_char)) / ((double) (t->xmax)) + xoffset;
+ 		    fprintf(stderr, "\tsize is set to %g,%g\n", xsize, ysize);
+ 		  }
+ 		}
  	    }
  	}
  	/*}}} */

Re: Connect gnuplot_x11 to exterior application window

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 08 April 2006 07:43 am, Petr Mikulik wrote:
> > I've updated the patch, 1027032, for connecting to the external X11 window 
> > against the most recent CVS version.

I've looked at it.
It is IMHO a long way away from being suitable for cvs.

> > [Is SourceForge updating the CVS version? 

Unfortunately, no.  SourceForge suffered a major failure on the main
server about 10 days ago. The anonymous cvs copy has been frozen at the
pre-failure state, and won't be updated until the integrity of the
main server has been restored.  As of last night, there were still
whole projects and disk areas off-line.  We seem to be fortunate
in that the gnuplot cvs area is back on line, and so far as I can
tell it has no corruption.  But it may be a while yet before any
changes to the main cvs tree are mirrored to the anonymous server.

> > This left off where Ethan couldn't get the TCL demo to run on his system. 
> > Ethan, please give it a try and let me know if it is work.

I applied the patchset, re-configured and rebuilt.
Then from the source directory I fired up
	../demo/gpdemos.tcl
This opened a wish UI window, but it would not respond to any mousing
or keystrokes. I couldn't select or type in a directory or file name
for display. So the wish file-browser widget seems to be broken.

I tried again in a different directory:
	cd ../demo
	./gpdemos.tcl

This partially worked.  It allowed me to select and display
files, and it echoed mouse cursor positions.  However, no other
mousing functions worked.  No zoom, no 3D click-and-drag, 
no anything involving mouse buttons, no hot keys.

This patch segment looks utterly wrong to me, and may be part of
the problem:

#ifdef EXTERNAL_X11_WINDOW
    XSelectInput(dpy, plot->window, event_mask);
    XSync(dpy, 0);
#else
    ProcessEvents(plot->window);
#endif



> It would simply be bloating CVS with a 
> bunch of conditionals for slightly different code.

No kidding!

The code needs a *lot* of cleanup. The conditional code is hugely
redundant and unnecessary.  This is similar to the ugliness in the
binary file code, and I would rather not see the same mistakes repeated
elsewhere.  Here is one small example of utterly pointless conditional
code:

Add_Plot_To_Linked_List(int plot_number)
{
#ifdef EXTERNAL_X11_WINDOW
    plot_struct *psp;
    if (plot_number >= 0)
        /* Make sure plot does not already exists in the list. */
        psp = Find_Plot_In_Linked_List_By_Number(plot_number);
    else
        psp = NULL;
#else
    /* Make sure plot does not already exist in the list. */
    plot_struct *psp = Find_Plot_In_Linked_List_By_Number(plot_number);
#endif


No conditional code *at all* is needed here. 
In fact no change to the current code at this site is needed.
Instead there should be a single line of error-checking in 

    Find_Plot_In_Linked_List_By_Number(int plot_number)
+      if (plot_number < 0) return NULL;

So instead of adding a one-line sanity check that should probably be
there already, this patchset adds 9 lines of conditional code that 
does nothing at all but make the source harder to read.

This sort of thing is present all through the patchset.

> The amount of extra code is actually small but the patch is big because 
> "plot" is changed to "current_plot" in a lot of places.

Exactly.  That is, it adds conditional code segments whose two
branches differ only in the name of one variable. 
Why do that? It just adds a ton of pointless conditional code that
doesn't accomplish anything useful.

At a rough guess, this patchset can be re-worked to achieve exactly
what it does now with only about one fifth the number of conditional
code segments.  Let's aim for that.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Connect gnuplot_x11 to exterior application window

[Daniel J S. <dan...@ie...>]

>>   Enable general binary data file reading (EXPERIMENTAL)
>>   Enable X11 polygon info in binary, not ascii (EXPERIMENTAL)
> 
> 
> I have mixed feelings about these.  They do work, but the code is so
> tangled that at some point we may have to rip it apart and re-do it.
> To me that deserves the "experimental" label.  But it is the code
> layout, rather than the actual user interface or capability that 
> might change.  So I don't know that the experimental nature needs to
> be exposed to the user during ./configure. 

I don't think that is the case.  I'll re-iterate what is accomplished with the above code.  (I've said this to the list several times, I think.)

>>   Enable general binary data file reading (EXPERIMENTAL)

The situation before this patch was that 2D plots got data one way, 3D plots effectively got data another way, with the "binary matrix" being unique to 3D plots for things like pm3d.  [This was the result of the two being separated early on and allowed to grow on their own.]

The EXPERIMENTAL portion of this brings everything together.  Data comes into 2D/3D plots the very same way.  There is no longer a special routine for "binary matrix".  The implementation of that is hidden behind the scenes at a low level such that plot3d/graph3d never needs to worry about such things.

Let me try to illustrate the levels of abstraction by considering this key routine from datafile.c:

/*{{{  int df_readline(v, max) */
int
df_readline(double v[], int max)
{
#ifdef BINARY_DATA_FILE
    if (df_read_binary)
        /* General binary, matrix binary or matrix ascii
         * that's been converted to binary.
         */
        return df_readbinary(v, max);
    else
#endif
        return df_readascii(v, max);
}
/*}}} */

After the command has been parsed, the internal data file routines, via static (not global) variable "df_read_binary" knows whether it will be attempting to read a binary file or an ascii file.  "df_readline" is the only thing that plot2d/3d needs to know.  [This approach is in fact attributable to Ethan who worried about the original approach of binary code mixed in with ascii code of the original df_readline.  Admittedly, that was a mess.]

So that is one level of abstraction.

Now, that means at some point *everything* that comes in looks like "double floats" in the array "v".  What that means for big data files is that there is a bit of churning of data.  Petr and I proposed a long time ago that there be left open some way of allowing an array of data to not bloat things with the "points" concept.  That proposal was met with strong opposition, so fine.  I then think that the above is a reasonable approach.

So, abstractions:

------------------
level 1 (low)

df_readline_ascii and df_readline_binary put data into similar format, double floats.
------------------
level 2 (intermediate)

perhaps interpret that data into more meaningful chunks, for example *strings*
------------------
level 3 (application)

plot2d/3d do their things making all kinds of nifty graphs
------------------

Right now, there is no intermediate level of processing.  But let me illustrate one that could be: strings.

Recently introduced, strings are meant to read in strings as though they were some type of data object.  No problem.  However, the code for it was placed in df_readascii using a global variable, placing strings I think (correct me if I'm wrong), into a slightly different "container" than the "points" model that seems to be the basis of much of gnuplot.  (Why was it not good for there to be an array of data for big data sets, but strings should fall outside the "points" model?  Anyway...)

Had the strings instead been implemented at the (currently non-existent) intermediate level, it would work automatically for ascii and binary.  It might not be as bad as one would think.  If at the intermediate level, one knew a string was to be read, you'd just keep calling either "df_read_ascii" or "df_read_binary" until a string was complete and then return flow back up to plot3d/plot2d.  Of course, there is the detail of a char value stored in the "v" array (i.e., treating a char as a double or vice versa), but that can be worked out.

Now, as for the code in df_read_binary, I think that if one studied this code, they'd find it to be very good code.  You might have to tune into a slightly unconventional way of programming, but it does very logical stuff.  Tell me what is bad about it and needs to be redone.  I'm listening and can probably offer an explanation for why things are done the way they are or change things if there is an obvious better method.

But note that what I've offered as a level of abstraction means that if binary can be done better, it is isolated to df_read_binary() and doesn't cause problems throughout various source files.

> 
>>   Enable plot style image (EXPERIMENTAL)
>>   Enable verify every pixel coordinate in image (EXPERIMENTAL)
> 
> 
> I don't even know what that 'verify' one does.

Because we are forced to stay with the "points" method of storing data (see above), every pixel in an image has an (x,y,z) location.  Now, that data could have come from binary or ascii, with or without implied physical position.  So, it could be the case that the user did or did not supply the coordinates.  If the user did supply coordinates, there is the possibility that the the coordinates don't form a valid grid.  We then ask, should or should we not verify the location of every individual pixel?  Or is it good enough just to know the four corners of the image and assume an evenly spaced grid even though the user may have entered data that doesn't fit to that.

I'm happy with not verifying the points.  (Matlab/Octave sometimes does that sort of thing... just looks at the end points and assumes even spacing.  Also, speeds things up a bit.)  I don't know how others feel.

> Is it worth marking this separately from the image processing proper?

Maybe yes, maybe no.  But keeping this separate is good in the sense that I think the pertinent question is what I expressed above.  Does the group think it should be one way or the other?  If strong opinion in one direction emerges, we'll either get rid of the conditional part of the code or get rid verification code.

> 
> 
>>   Enable string variables (EXPERIMENTAL)
>>   Enable command line macros (EXPERIMENTAL)
>>
>>I propose to remove these flags -- these features work for some time 
>>already.

See discussion above.  I like the string variables, I just wish there were some way of incorporating them at a higher level.

I mean, the laudable idea is to remove the binary/ascii dependence as soon as possible.  It's a difficult balance of flexibility and not repeating code.

As it is in CVS now is fine.  I mean, binary is really meant for large data files in my mind.  If strings don't work for binary, that's OK.

But there is a comment in the code somewhere about wanting to introduce a variable to df_readline() which would give the file reading code an idea of what type of data it is dealing with.  This is a paradigm shift from the "all things are double floats" approach.  However, it is workable, but again I'd hope the conditional parts of it doesn't work its way all the way down to the lowest level of abstraction.

Dan

Re: Connect gnuplot_x11 to exterior application window

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:

> And no, I won't have flags that weren't even present in the previous=20
> release be *removed* just yet.

That's fine.

>  Remove the "EXPERIMENTAL" notice and=20
> make them default-on, OK, but no removing of conditionals that never sa=
w=20
> an wide-range user test by being enabled in the default build of a=20
> release version.

I'd say leave the EXPERIMENTAL in place if there is conditional code ther=
e.  It's an organized way to keep track of things, promotes discussion, a=
nd notify people who compile the code that there are some new features th=
ere.

Dan

Re: Connect gnuplot_x11 to exterior application window

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 08 April 2006 07:43 am, Petr Mikulik wrote:
> 
> Well, I see there are many other EXPERIMENTAL's in ./configure:
> 
>    Enable placement of rectangles and other objects (EXPERIMENTAL)

That one really *is* experimental. Please leave it marked as such. 

>    Enable general binary data file reading (EXPERIMENTAL)
>    Enable X11 polygon info in binary, not ascii (EXPERIMENTAL)

I have mixed feelings about these.  They do work, but the code is so
tangled that at some point we may have to rip it apart and re-do it.
To me that deserves the "experimental" label.  But it is the code
layout, rather than the actual user interface or capability that 
might change.  So I don't know that the experimental nature needs to
be exposed to the user during ./configure. 

>    Enable plot style image (EXPERIMENTAL)
>    Enable verify every pixel coordinate in image (EXPERIMENTAL)

I don't even know what that 'verify' one does.
Is it worth marking this separately from the image processing proper?

>    Enable string variables (EXPERIMENTAL)
>    Enable command line macros (EXPERIMENTAL)
> 
> I propose to remove these flags -- these features work for some time 
> already.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Connect gnuplot_x11 to exterior application window

[<br...@ph...>]

Petr Mikulik wrote:
>   Enable placement of rectangles and other objects (EXPERIMENTAL)
>   Enable plot style image (EXPERIMENTAL)
>   Enable verify every pixel coordinate in image (EXPERIMENTAL)
>   Enable general binary data file reading (EXPERIMENTAL)
>   Enable X11 polygon info in binary, not ascii (EXPERIMENTAL)
>   Enable string variables (EXPERIMENTAL)
>   Enable command line macros (EXPERIMENTAL)
> 
> I propose to remove these flags -- these features work for some time 
> already.

Not all of them.  That rectangles and other objects only went into CVS 
earlier this week.

And no, I won't have flags that weren't even present in the previous 
release be *removed* just yet.  Remove the "EXPERIMENTAL" notice and 
make them default-on, OK, but no removing of conditionals that never saw 
an wide-range user test by being enabled in the default build of a 
release version.

Re: Connect gnuplot_x11 to exterior application window

[Petr M. <mi...@ph...>]

> I've updated the patch, 1027032, for connecting to the external X11 window 
> against the most recent CVS version.  [Is SourceForge updating the CVS 
> version... the last update seems over a week ago and there is a bug.]
>
> This left off where Ethan couldn't get the TCL demo to run on his system. 
> Ethan, please give it a try and let me know if it is work.
>
> The amount of extra code is actually small but the patch is big because 
> "plot" is changed to "current_plot" in a lot of places.  I'd propose if this 
> is added to CVS I go back and simply get rid of the EXPERIMENTAL option of 
> "--disable-external-x11-window".  It would simply be bloating CVS with a 
> bunch of conditionals for slightly different code.

The TCL demo works OK on my system.

I propose to move it to cvs, without the EXPERIMENTAL message.

Well, I see there are many other EXPERIMENTAL's in ./configure:

   Enable placement of rectangles and other objects (EXPERIMENTAL)
   Enable plot style image (EXPERIMENTAL)
   Enable verify every pixel coordinate in image (EXPERIMENTAL)
   Enable general binary data file reading (EXPERIMENTAL)
   Enable X11 polygon info in binary, not ascii (EXPERIMENTAL)
   Enable string variables (EXPERIMENTAL)
   Enable command line macros (EXPERIMENTAL)

I propose to remove these flags -- these features work for some time 
already.

---
PM

Re: 'set size ratio' plot

[Daniel J S. <dan...@ie...>]

Lots of typos in last email (crumps):

> active at the same time.  Is that the case.

? (not .)

> parameter, i.e., it can be turned on and off.  If there is a "nosquare" 

"parameters"

> and a "noratio", does that mean than can both be on at the same time?  

"they can both"

> Or is "nosquare" and alias for "noratio".

"an alias"

Re: 'set size ratio' plot

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> jun...@so... wrote:
>=20
>> The ratio-corrected box is seemed be centerd on the page.
>> This change looks good for ploting just one graph, but it becomses
>> practically impossible to put some ratio-corrected graphs on the=20
>> positions
>> which I want.=20
>=20
>=20
> That's at least 50% practically impossible anyway --- a graph with 'set=
=20
> size ratio' turned on changes shape outside the control of 'set size'.
> That's how that whole feature works.  Even after you fixated its
> bottom left corner, its top right one can be anywhere.  I don't see how=
=20
> changing half the problem is of any help.  It would be just as easy to
> adjust the main 'size' parameters manually, such that the difference=20
> between left-justified and centered position of the actual graph area=20
> becomes negligible.
>=20
>  > Thus, I made some patches to controll this centering behavior
>=20
>> by using the sign of the ysize.
>=20
>=20
> I find that unacceptably obfuscated.  This is basically a change to
> the origin and/or margin settings, not to the size of the graph.  It ha=
s=20
> no business being controlled as part of 'set size' at all --- even less=
=20
> so being hidden in the sign of a must-be-positive parameter.

The two of us seem to agree on negative parameters.  Even the existing sy=
ntax:

 Syntax:
       set size {{no}square | ratio <r> | noratio} {<xscale>,<yscale>}
       show size

...

 The meaning of a negative value for <r> is different.  If <r>=3D-1, gnup=
lot
 tries to set the scales so that the unit has the same length on both the=
 x
 and y axes (suitable for geographical data, for instance).  If <r>=3D-2,=
 the
 unit on y has twice the length of the unit on x, and so on.

seems a bit obfuscating, and probably why Jun thought to use negative num=
bers for the scale.  Even square/nosquare/ratio/noratio isn't the most ob=
vious thing.  There is an implication that square and ratio are active at=
 the same time.  Is that the case.

What I mean is that if there is a "no" associated with a parameter, it is=
 implied in a sense that said parameter is independent from other paramet=
er, i.e., it can be turned on and off.  If there is a "nosquare" and a "n=
oratio", does that mean than can both be on at the same time?  Or is "nos=
quare" and alias for "noratio".

Maybe a syntax like:

       set size {auto | square | ratio {plot|unit} <r>} {<xscale>,<yscale=
>}

or something similar would be more appropriate.

Dan