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

Re: [Bug #1264105] In currrent CVS version plotting matrix is broken

[Juergen W. <wie...@fr...>]

On Saturday 22 October 2005 20:42 Ethan A Merritt wrote:
> How about if we could plot Petr's example:
>   splot 'matrix.dat' matrix using (1+$1/100):(1+$2*10):3
> as
>   f(x) = 1 + x/100
>   g(y) = 1 + y*10
>   splot 'matrix.dat' matrix xticlabels(f(x)):yticlabels(g(y))
>
> Would that be more natural?

With this, I would expect one label for each row and each column.  I
think it would be more natural to introduce some

set format x function f(x)

where f(x) is a string valued expression with a dummy variable "x".

But in the case of matrix, I prefer Petr's example.


Juergen

'help matrix' -- Re: [Bug #1264105] In currrent CVS version plotting matrix is broken

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

> You don't find it confusing that in 2D plots you need to say
>   plot 'data' matrix using ($1):($3)
>
> Why ($3)?

I never know I can use
 	plot ... matrix
I'm still learning gnuplot :-))

It would be nice to organize that
 	plot 'a.dat' matrix
is equivalent to
 	plot 'a.dat' matrix using 1:3

***

Proposal for 'help matrix', please modify:

Datafile can be in an ascii or binary matrix format. The `matrix` flag 
indicates that the file is ascii, the `binary` or `matrix binary` stands for 
a binary format. For details, see `matrix ascii` or `matrix binary`.

Basic usage in `splot`:
      splot 'a.dat' matrix
      splot 'a.gpbin' {matrix} binary
Advanced usage in `splot`:
      splot 'a.dat' matrix using 1:2:3
      splot 'a.gpbin' {matrix} binary using 1:2:3
allows to manipulate the axes coordinates and the z-data.

Usage in `plot`:
      plot `a.dat` matrix using 1:3
      plot 'a.gpbin' {matrix} binary using 1:3
will plot rows of the matrix, while using 2:3 will plot matrix columns, and 
1:2 point coordinates. Applying the `every` option you can specify explicit
rows and columns.

Example -- rescale axes for an ascii matrix:
      splot `a.dat` matrix using (1+$1):(1+$2*10):3

Example -- plot the 3rd row of an ascii matrix:
      plot 'a.dat' matrix using 1:3 every 1:999:1:2
(rows are enumerated from 0, thus 2 instead of 3).

***

Proposal for 'help matrix ascii', please modify:

The `matrix` flag in
        {s}plot 'a.dat' matrix
indicates that the ASCII data are stored in matrix format.

The z-values are read in a row at a time, i. e.,
        z11 z12 z13 z14 ...
        z21 z22 z23 z24 ...
        z31 z32 z33 z34 ...
and so forth.

X- and y-indices of the matrix correspond to column and row index of the 
matrix, starting from 0. You can rescale or transform the axes as usual for 
a data file with three columns (x=$1, y=$2, z=$3), for example
        splot 'a.dat' matrix using (1+$1/100):(1+$2*10):3

A blank line or comment line ends the matrix, and starts a new
surface mesh. You can select among the meshes inside a file by the
`index` option to the `splot` command, as usual.


---
PM

Re: [Bug #1264105] In currrent CVS version plotting matrix is broken

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

On Saturday 22 October 2005 03:02 pm, Petr Mikulik wrote:
> I think I've tracked the bug down

Found it. Bleah. It really has been there since forever.
It's in df_tokenise(), and it is specific to ascii matrix data.
Here is the fix:

--- gnuplot/src/datafile.c      2005-10-21 22:50:13.000000000 -0700
+++ gnuplot-cvs/src/datafile.c  2005-10-22 21:10:08.276728128 -0700
@@ -1145,6 +1146,7 @@
             if (df_matrix) { duplication=TRUE; break; }
             df_matrix = TRUE;
 #endif
+           fast_columns = 0;
             continue;
     }

Corey Satten's monster optimization test skips all columns past the
first three unless some test has previously cleared the fast_columns
flag.  Examples of things that clear the flag are parentheses in the
using spec and the presence of the "binary" flag. The optimization
test is also skipped if there are no using specs at all.
Ascii matrix data is not covered by any of these exceptions, so
df_tokenise() only parses the first 3 columns.

Amazing that no one has complained in all the time since 3.7 came
out.

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

Re: [Bug #1264105] In currrent CVS version plotting matrix is broken

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

On Saturday 22 October 2005 02:55 pm, Petr Mikulik wrote:

>>>  x = $1, y = $2 (autogenerated row and column index of the matrix)

>> It is very confusing because it is not consistent with all other
>> plot/splot "datafile" commands. In all other cases $1 means
>> column 1 of the file, regardless of whether it is being used as
>> an x value.

> It's not confusing, because you specify the "matrix" keyword. Same for
> (the new) "binary" stuff.

You don't find it confusing that in 2D plots you need to say
   plot 'data' matrix using ($1):($3)

Why ($3)?


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

Re: [ 1218873 ] Change text rotating angle from int to float

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

On Saturday 22 October 2005 03:30 pm, Petr Mikulik wrote:
> I propose this goes to cvs, once sync'ed with current cvs.
> Any objection / opinions?

No objections.
But it really should be tested on as many terminals as possible
before commiting to cvs.

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

[ 1218873 ] Change text rotating angle from int to float

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

I propose this goes to cvs, once sync'ed with current cvs.
Any objection / opinions?

---
PM

Re: [Bug #1264105] In currrent CVS version plotting matrix is broken

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

On Saturday 22 October 2005 03:02 pm, Petr Mikulik wrote:
> I think I've tracked the bug down; it seems to be in datafile.c:
> df_readbinary(double v[], int max).

Remember that this bug was already present in version 4.0,
and in version 3.7 for that matter.  The earlier versions did
not use df_readbinary for input of ascii matrix data.

> Who else can find the problem?

I have had no luck so far.
My prime suspect is get_3ddata() in plot3d.c, but I have not
found it there either.

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

Re: [Bug #1264105] In currrent CVS version plotting matrix is broken

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

I think I've tracked the bug down; it seems to be in datafile.c: 
df_readbinary(double v[], int max).

Use this script:

set grid
set ticslevel 0.3
set auto fix
set xlabel "xxxx"
set ylabel "yyyy"
splot 'a.dat' matrix u 1:2:3
set table
replot

with this a.dat:

11  12  13  14  15
21  22	23  24  25


==> it produces:

#IsoCurve 0, 5 points
#x y z type
  0  1  21 i
  1  1  22 i
  2  1  23 i
  3  1  0 i
  4  1  0 i

#IsoCurve 1, 5 points
#x y z type
  0  0  11 i
  1  0  12 i
  2  0  13 i
  3  0  0 i
  4  0  0 i

Thus, it reads only 3 columns, not the full line.


It looks that df_readbinary() is used also for reading the ascii matrix 
file. However, I couldn't found where is the problem. Who else can find the 
problem?

---
PM

Re: [Bug #1264105] In currrent CVS version plotting matrix is broken

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

>> no, x = $1, y = $2 (autogenerated row and column index of
>> the matrix)
>
> Apparently that is how the program currently interprets
> $1 and $2.  I dind't know that.
> It is very confusing because it is not consistent with all other
> plot/splot "datafile" commands. In all other cases $1 means
> column 1 of the file, regardless of whether it is being used as
> an x value.

It's not confusing, because you specify the "matrix" keyword. Same for 
(the new) "binary" stuff.

> But I would like to provide a more logical syntax for this
> operation, so that this confusion isn't necessary.

>  splot 'matrix.dat' matrix using (1+$1/100):(1+$2*10):3
> as
>  f(x) = 1 + x/100
>  g(y) = 1 + y*10
>  splot 'matrix.dat' matrix xticlabels(f(x)):yticlabels(g(y))
>
> Would that be more natural?
>
> Alternatively, we could allow dummy variables in the using specs
> directly:
>  splot 'matrix.dat' matrix using (f(x)):(g(y)):(z)
> Unfortunately that has no obvious meaning for non-matrix plots.

I would stay with my proposal
     splot 'matrix.dat' matrix using (1+$1/100):(1+$2*10):3
For me, it's easy to understand, and consistent with "binary".

---
PM

Re: [Bug #1264105] In currrent CVS version plotting matrix is broken

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

> this works:
>   plot 'file.dat' mat  w image
> but this doesn't anymore:
>   plot 'file.dat' mat u 1:2:3  w image
>
> Comment By: Petr Mikulik (mikulik)
> Date: 2005-10-22 11:26
>
>> the x and y coords are coming from the row and column indices
>> of the file, right?  So x is $0, but y is a problem because
>> we have no pseudo-column assigned for the column.
>
> no, x = $1, y = $2 (autogenerated row and column index of
> the matrix)

Apparently that is how the program currently interprets
$1 and $2.  I dind't know that.
It is very confusing because it is not consistent with all other
plot/splot "datafile" commands. In all other cases $1 means
column 1 of the file, regardless of whether it is being used as
an x value.

> I think we have reduced the bug to this:
> This works (at least one of $1, $2 or $3 appears at least once):
>    splot 'file.dat' matr u ($1/100):2:3
> This works in a very strange way:
>    splot 'file.dat' matr u 1:2:3
>
> Once this is fixed, we can extend 'help matrix ascii' to

Sure, it should be fixed (although the behaviour has not
changed since 3.7 so the original bug report is misleading).
But I would like to provide a more logical syntax for this
operation, so that this confusion isn't necessary.

This is really just an axis-labelling operation, right?
The "true" x and y indices of the matrix points are still
integers running from 1 to however many rows/columns of
data are in the file.

How about if we could plot Petr's example:
  splot 'matrix.dat' matrix using (1+$1/100):(1+$2*10):3
as
  f(x) = 1 + x/100
  g(y) = 1 + y*10
  splot 'matrix.dat' matrix xticlabels(f(x)):yticlabels(g(y))

Would that be more natural?

Alternatively, we could allow dummy variables in the using specs
directly:
  splot 'matrix.dat' matrix using (f(x)):(g(y)):(z)
Unfortunately that has no obvious meaning for non-matrix plots.


> ----------------------------------------------------------------------
>
> Comment By: Juergen Wieferink (wieferink)
> Date: 2005-10-22 09:18
>
> Message:
> Logged In: YES
> user_id=1090807
>
> Weird.  You are right.
>
> Using ($1):($2):3 instead of 1:2:3 works fine, though. And even
> more confusing: When I try to play around with the ranges, I can
> find no systematic at all... Once I only set the xrange:
>
>    plot [0:1] "file.dat" matrix using 1:2:3 with image
>
> It doesn't even respect the plot borders... There is something
> that really goes wrong here.
> I would attach the resulting image -- if I could.
>
> Juergen
>
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2005-10-21 23:11
>
> Message:
> Logged In: YES
> user_id=235620
>
> Huh.
> Were you using the data file provided in the bug report?
>
> I see the problem in 3.7,  4.0 and current cvs. Well, I
> don't see it as a "problem" because it does not seem like a
> reasonable command in the first place.  See attached png output.
> file A:   splot 'matrix.dat' matrix
> file B:   splot 'matrix.dat' matrix using 1:2:3
>
>
>
> ----------------------------------------------------------------------
>
> Comment By: Juergen Wieferink (wieferink)
> Date: 2005-10-21 22:10
>
> Message:
> Logged In: YES
> user_id=1090807
>
> Ethan:
> It might be confusing, but it works -- at least for me.
>
>
> I have been using this for quite a while (I'd even say pre-4.0) in a
> wide set of scripts.  And it has worked fine all the time.  I cannot
> reproduce the problem of the OP.
>
> Juergen
>
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2005-10-21 21:54
>
> Message:
> Logged In: YES
> user_id=235620
>
> Petr:
> Your use of $1 and $2 in that example is confusing. IIn the
> case of 3D matrix data, the x and y coords are coming from
> the row and column indices of the file, right?  So x is $0,
> and y is... well y is a problem, because we don't have a
> pseudo-column assigned for the column number.
>
> I assume your intent is more something like:
>    splot 'file.dat' matrix thru f(x,y,z)
>
> even though x and y are being autogenerated from the file
> layout rather than being explicitly contained in the data.
>
>
> ----------------------------------------------------------------------
>
> Comment By: Petr Mikulik (mikulik)
> Date: 2005-10-21 21:38
>
> Message:
> Logged In: YES
> user_id=31505
>
> Thus
>    splot 'file.dat' matrix using ($1*2):(1+10*$2):3
> can work? Then I would like it too -- I though axes
> transformations are not allowed for 'matrix'.
>
> When it works, it should be properly documented in 'help
> matrix', the best with few examples, like above.
>
>
> ----------------------------------------------------------------------
>
> Comment By: Hans-Bernhard Broeker (broeker)
> Date: 2005-10-21 21:07
>
> Message:
> Logged In: YES
> user_id=27517
>
> @Petr: no, that's not a bug, that's a very crucial feature.
>  I'm strictly against going back to the ancient days when
> you couldn't do any parameter transformations on a data set
> just because it was given as 'matrix' or 'binary'.  The
> difference caused by those have to be resolved  for good, by
> the time 'using' and friends get applied.
>
> ----------------------------------------------------------------------
>
> Comment By: Martin Horvat (martin_horvat)
> Date: 2005-10-21 18:57
>
> Message:
> Logged In: YES
> user_id=473606
>
> Greatings,
>
> Thanks for the comments and the explanation. It just strange
> that few months ago this thing worked and all my scripts
> were accordingly modified. I don't really know the
> implementation of matrix data format, but the syntax  "splot
> 'file.dat' mat u 1:2:3 w l" seems plausible to me. But ok,
> it doesn't matter, I rewrote the scripts and the programs
> and so on. Now I use basic (standard) gnuplot syntax and it
> works.
>
> Thanks guys.
>
> Best regards,
>
> Martin
>
> ----------------------------------------------------------------------
>
> Comment By: Petr Mikulik (mikulik)
> Date: 2005-10-21 18:28
>
> Message:
> Logged In: YES
> user_id=31505
>
> I think it is rather a bug that
>       splot 'file.dat' mat u 1:2:3 w l
> passes the parser.
> Gnuplot works only with
>            splot 'file.dat' matrix
> or
>            splot 'file.dat' matrix using (f($1,$2,$3))
>
> I think an error should be issued if nb_of_using_params >= 2.
>
>
>
>
>
>
>
> ----------------------------------------------------------------------
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2005-10-18 04:51
>
> Message:
> Logged In: YES
> user_id=235620
>
> I am inclined to close this report, since the command being
> used seems intrinsically incorrect for the data file
> provided as an example.
>
> The data file is entirely filled with z-values, with one
> entire row of values per line of the file. This is normal
> for matrix data.  Trying to pull x and y out of columns in
> the files makes no sense at all, and will end up discarding
> all but 1 z-value per line.
>
> The earlier procedure you remember working must have
> involved a rather different layout of data in the file.
> Does that make sense?
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=102055&aid=1264105&gro
>up_id=2055

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

Re: [RFC] introduce new routine draw_clip_arrow()

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:

> This is actually a reduction in the number of global variables.

Only at the outermost level. There's no change to the number of
individual global status variables, nor to their total size, by packing
things in structs.  It's a null-sum game.

But storing globals in special storage to replace their values by 
something else, for the duration of one function call, is still 
atrocious, which should be avoided by

1) passing the relevant thing in as a parameter
2) having the routine use its own global status, which you set as
    needed before calling it.

I'm against 2) because it again increases the number and size of
globals.

>>Please consider making the clip area to be used a parameter  
>>of draw_clip_arrow.

> This would not reduce the requirement for a global pointer, 
> unless the lower level clipping routines clip_point() and clip_line()
> were also modified to take an extra parameter.  

Well, refactoring can be done a bit more builtin intelligently than 
that: one could split these up into an actual engine holding a modified
version of the current clip_line()'s code:

	clip_line_actually()

and make a new clip_line like this:

	clip_line(parameters...) {
		clip_line_actually(&global_bounds, parameters...)
	}

No interface change to the outside, but new code can use 
clip_line_actually() if it doesn't want to use the global default
bounding box.

> Here again I agree in principle, but that would mean reworking
> all the existing lower-level clipping routines as well.

Not necessarily.  Just duplicate them and have them take coordval's.

Re: [RFC] introduce new routine draw_clip_arrow()

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

On Friday 21 October 2005 03:38 am, Hans-Bernhard Broeker wrote:
> > BoundingBox *clip_save = clip_area;
> > clip_area = &(BoundingBox *){ 0, xmax, 0, ymax };
> > draw_clip_arrow(...)
> > clip_area = clip_save;> 
> Objection, your honour --- we should absolutely not add more global 
> variables.

This is actually a reduction in the number of global variables.
Before this we had xright, xleft, ybot, ytop all as globals.
Now all 4 of these are contained in a single (struct BoundingBox)clip_area.

> Please consider making the clip area to be used a parameter  
> of draw_clip_arrow.

This would not reduce the requirement for a global pointer, 
unless the lower level clipping routines clip_point() and clip_line()
were also modified to take an extra parameter.  I have no objection
to that as a design goal, but it would require changing the current
code everywhere the routines are called. 
[greps a bit.... that's about 45 places, each of which may in turn
need to be modified to work with coordvals]

 
> > draw_clip_arrow( int sx, int sy, int ex, int ey, int head)
> 
> I'm not at all sure that doing this in ints is a good plan.  These
> should probably be coordvals (or even a complete struct arrow_def, by
> joining draw_clip_arrow() with get_arrow()).

Here again I agree in principle, but that would mean reworking
all the existing lower-level clipping routines as well.
If that were done in one large sweep over the code, draw_clip_arrow()
would be just one caller out of 40+. So I don't think that a 
long-term goal of revamping all the clipping to use coordvals is a
reason not to introduce arrow clipping first.

 
> > {
> >     /* Don't draw head if the arrow itself is clipped */
> >     if (head == BOTH_HEADS && clip_point(sx,sy))
> >         head = END_HEAD;
> >     if (head == BOTH_HEADS && clip_point(ex,ey))
> >         head = BACKHEAD;
> >     if (head == BACKHEAD && clip_point(sx,sy))
> >         head = NOHEAD;
> >     if (head == END_HEAD && clip_point(ex,ey))
> >         head = NOHEAD;
> 
> This sequence hints at a design flaw.  We should have individual flag
> bits for each head, not a single combined enum name for both.  Put in 
> another way, BOTH_HEADS should be killed.

There I definitely agree.

Harald -  Do you want to have a look at that?
On a related note, your patch on SourceForge only adds the
backwards head code to do_arrow(); it doesn't add it for the
drivers that have private code (tgif, metapost, texdraw,
probably others as well).



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: color loop for gd.trm

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

> | So your goal is not to reduce the total number of colors, instead
> | it is to have the same default colors on all terminals?
>
> No. I only want to realize x11 or win term's color loops on png
> term simply.
>
> | My feeling is that the default colors on different terminal types
> | should *not* be the same, because each terminal has its own set
> | of visual properties.

Then there should be these groups of color terminals, each group with the 
same color sequence:
   screen&bitmaps:
 	x11, windows, pm, wx
 	png, gif, jpeg, ...
 	svg, cgm, wmf, ...
 	xfig, corel, ...
   postscript and other paper printings:
 	postscript, pdf, pslatex, pstex

But both should not "differ too much". Maybe a "screen_color_sequence" 
option for postscripts?

It would be really great if someone unitifies the sequence for at least 16 
colors.

---
PM

Re: [RFC] introduce new routine draw_clip_arrow()

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:

> Current state of the code in cvs, as recently modified:
> 
> - full clipping is done in do_arrow(), which is a generic
>   routine called by most terminals. Because this is a
>   terminal entry point, the not-yet-clipped coordinates have
>   already been forced to (unsigned int).  Casting them back
>   to (int) works, but is an ugly hack.

IOW, that was exactly the wrong way of doing it ;-(

> This would replace the clipping code in do_arrow() and
> possibly code in some individual terminal drivers.
> 
> The call site could specify a bounding box to clip
> against if the default is not appropriate:
> 
> BoundingBox *clip_save = clip_area;
> clip_area = &(BoundingBox *){ 0, xmax, 0, ymax };
> draw_clip_arrow(...)
> clip_area = clip_save;

Objection, your honour --- we should absolutely not add more global 
variables.  Please consider making the clip area to be used a parameter 
of draw_clip_arrow.

> draw_clip_arrow( int sx, int sy, int ex, int ey, int head)

I'm not at all sure that doing this in ints is a good plan.  These
should probably be coordvals (or even a complete struct arrow_def, by
joining draw_clip_arrow() with get_arrow()).

> {
>     /* Don't draw head if the arrow itself is clipped */
>     if (head == BOTH_HEADS && clip_point(sx,sy))
>         head = END_HEAD;
>     if (head == BOTH_HEADS && clip_point(ex,ey))
>         head = BACKHEAD;
>     if (head == BACKHEAD && clip_point(sx,sy))
>         head = NOHEAD;
>     if (head == END_HEAD && clip_point(ex,ey))
>         head = NOHEAD;

This sequence hints at a design flaw.  We should have individual flag
bits for each head, not a single combined enum name for both.  Put in 
another way, BOTH_HEADS should be killed.

[RFC] introduce new routine draw_clip_arrow()

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

On Sunday 16 October 2005 12:12 pm, Ethan A Merritt wrote:
> 
> today's patchset adds generic clipping of arrows,
> fixing bug  #1187336  and a bunch of others.

Clipping arrow to the visible screen is messy because
the component lines and fill areas must be individually
clipped.  This is particularly nasty if the start/end
coordinates have been forced to (unsigned int), because
negative coordinates are masquerading as large positive
numbers.  

Clipping the vector itself before calling term->arrow()
may not be sufficient, because the head flag needs to be
adjusted so that a head is not draw on an end that was
clipped. (Or so it seems to me; perhaps there are cases
where one wants to draw the head anyway).

Until very recently, arrows were basically not clipped.
This caused problems on many terminals.

Current state of the code in cvs, as recently modified:

- full clipping is done in do_arrow(), which is a generic
  routine called by most terminals. Because this is a
  terminal entry point, the not-yet-clipped coordinates have
  already been forced to (unsigned int).  Casting them back
  to (int) works, but is an ugly hack.

- The clipping in do_arrow() does not help terminals which
  have a private term->arrow() routine (e.g. metapost, TeX
  variants).

- Terminals which want to do clipping themselves (e.g. post)
  set a flag TERM_CAN_CLIP, in which case the generic code
  does not, in fact, clip the arrow. I think that's OK, but
  I mention it for completeness.

I suggest that the clipping code below become a new routine
draw_clip_arrow(), analogous to draw_clip_line(), and all
places which currently call (term->arrow)() directly be
changed to call this intermediate layer routine instead.
This has the advantage that it will apply equally to all
terminals, can operate on coordinates before they have
been stuffed into an (unsigned int), and benefits from the
fact that draw_clip_line() and clip_point() can now be set
to clip against any desired bounding box.

This would replace the clipping code in do_arrow() and
possibly code in some individual terminal drivers.

The call site could specify a bounding box to clip
against if the default is not appropriate:

BoundingBox *clip_save = clip_area;
clip_area = &(BoundingBox *){ 0, xmax, 0, ymax };
draw_clip_arrow(...)
clip_area = clip_save;



draw_clip_arrow( int sx, int sy, int ex, int ey, int head)
{
    /* Don't draw head if the arrow itself is clipped */
    if (head == BOTH_HEADS && clip_point(sx,sy))
        head = END_HEAD;
    if (head == BOTH_HEADS && clip_point(ex,ey))
        head = BACKHEAD;
    if (head == BACKHEAD && clip_point(sx,sy))
        head = NOHEAD;
    if (head == END_HEAD && clip_point(ex,ey))
        head = NOHEAD;
    clip_line(&sx, &sy, &ex, &ey);

    /* Call terminal routine to draw the clipped arrow */
    (term->arrow)((unsigned int)sx, (unsigned int)sy,
                  (unsigned int)ex, (unsigned int)ey, head);
}


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Clipping code - history?

[Hans-Bernhard B. <br...@ph...>]

Ethan A Merritt wrote:
> In gadgets.c we have the very nice clipping routines:
>  clip_line() draw_clip_line()
> 
> In graphics.c we have a separate collection of very specialized
> but also rather complicated routines:
>   edge_intersect() two_edge_intersect()
>   edge_intersect_steps() edge_intersect_fsteps()
>   two_edge_intersect_steps() two_edge_intersect_fsteps() 
> 
> Is this a code duplication due to historical artifact?

Not really.  The /.*edge_intersect.*/ routines clip in ways specific to 
individual plot styles, governed at least partly by the 
INRANGE/OUTRANGE/UNDEFINED information from function/data parsing.  At 
least the UNDEFINED flag is not available in any other way, so it has
to be like that.  And checking INRANGE / OUTRANGE flags is faster than 
calling a generic clipper every iteration of a (possibly loong) list of 
data points.

These are not really just clipping routines for individual edges; 
they're parts of the plot routines for outputting plots in a correctly 
clipped way.   That's why steps and fsteps get their own clippers, and 
why these clippers work in data coordinates (floating point), not in 
terminal integers.

> At first glance all of the 100-200 line *_edge_intersect_* routines
> appear to do essentially the same thing as a simple series of calls
> to clip_line(). 

Yes.  But there are differences, and IIRC, some of those are somewhat 
easy to miss on casual reading.   BTDT years ago.

> Many code sections in graphics.c and graph3d.c test and sort line
> segments 

I don't recall any sorting being involved.

 > by the inrange/outrange property of their endpoints,
> and then call these single-purpose *_edge_intersect_* routines to
> perform clipping. 

... and they do that *only* in those case where it's actually needed.
That's an important aspect of how that's being done.

 > I am wondering if these sections can be simplified
> dramatically by instead drawing all of the individual segments via
> draw_clip_line().

I don't think so.  Doing this in data space, on floats, has some 
advantages that would be lost if you did this in terminal coordinates.

Re: make dist

[<wie...@we...>]

On Monday 17 October 2005 14:12 Lars Hecking wrote:
>  The current method works just fine for me, and I check make dist on an
>  irregular basis. Are your auto* tools up to date?

I have automake-1.9.5, the newest one is automake-1.9.6, and you are
right, that was the problem.  The installation was quite new, so I
thought ...

> > While in demo/html/: Shouldn't GNUPLOT_LIB be set to .. for
> > webify.pl by default?  I don't know how to achieve that without
> > overwriting some prior value, though.
>
>  It is set to ".." in the Makefile, or are you refering to webify.pl
> itself? Ethan should be able to answer this one ...

The script webify.pl reads the environment variable GNUPLOT_LIB.  If
this one is not set, webify.pl should omit the leading slash in the
resulting path.  So it is not a problem with the Makefile.

Juergen

Re: make dist

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

On Monday 17 October 2005 05:12 am, Lars Hecking wrote:
> Juergen Wieferink writes:
> > 
> > "make dist" generally isn't very stable.
>  
>  The current method works just fine for me, and I check make dist on an
>  irregular basis. Are your auto* tools up to date?

It works for me if I let everything default.
It fails if I first do ./configure --without-lisp-files, which is
my normal build mode.  Not a big deal, since presumably for distribution
you would not want to disable lisp. 

> > While in demo/html/: Shouldn't GNUPLOT_LIB be set to .. for
> > webify.pl by default?  I don't know how to achieve that without
> > overwriting some prior value, though.

 
>  It is set to ".." in the Makefile, or are you refering to webify.pl itself?
>  Ethan should be able to answer this one ...

The webify script inherits GNUPLOT_LIB from its calling environment.
That is true whether you run it yourself, or as part of the "make"
process.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: make dist

[Lars H. <lhe...@us...>]

Juergen Wieferink writes:
> Hi,
> 
> "make dist" generally isn't very stable.  The attached patch has got
> it working for me at least for one computer.  It explicitly includes
> the source files in demo/html instead of the directory.  Is there a
> better way to include demo/html?
 
 The current method works just fine for me, and I check make dist on an
 irregular basis. Are your auto* tools up to date?

> While in demo/html/: Shouldn't GNUPLOT_LIB be set to .. for
> webify.pl by default?  I don't know how to achieve that without
> overwriting some prior value, though.

 It is set to ".." in the Makefile, or are you refering to webify.pl itself?
 Ethan should be able to answer this one ...

Re: Ethans patch of 2005-10-15 (fwd)

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

On Sunday 16 October 2005 03:52 pm, mi...@ph... wrote:
>
> There is yet another need for "size > 1": 3D splot drawings are
> sometimes too small (only "set lmargin" works) and a bit larger plot is
> more optimal for screen terminals.

But this use is yet another illustration that size>1 is not handled
consistently.  

Yes, on screen terminals "set size 1.1,1.1" will increase
the scale of the plot by 10% but will not change the size of the canvas.
Therefore the plot will fill more of the canvas.

But if you do this for the postscript terminal, it will make the 
plot bigger but it will also make the canvas bigger. Therefore the
plot will fill the same fraction of the canvas as before, and will
have just as much whitespace around it.  The only net effect is to
reduce the size of the linewidths and fonts relative to the overall
size of the resulting document.

I can live with the screen-terminal behaviour, so long as we fix
the clipping everywhere so that terminals like pdf/cgm/emf do not
segfault or abort when you are draw off the edge of the canvas.

I know I sound like a broken record 
(or to update the idiom, like xmms/winamp set on "loop track" :-)
when I claim that the postscript behaviour is what needs to be
changed.

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

Clipping code - history?

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

In gadgets.c we have the very nice clipping routines:
 clip_line() draw_clip_line()

In graphics.c we have a separate collection of very specialized
but also rather complicated routines:
  edge_intersect() two_edge_intersect()
  edge_intersect_steps() edge_intersect_fsteps()
  two_edge_intersect_steps() two_edge_intersect_fsteps() 

Is this a code duplication due to historical artifact?

At first glance all of the 100-200 line *_edge_intersect_* routines
appear to do essentially the same thing as a simple series of calls
to clip_line(). Am I missing a more sophisticated function or
extra benefit of the longer routines?

Many code sections in graphics.c and graph3d.c test and sort line
segments by the inrange/outrange property of their endpoints,
and then call these single-purpose *_edge_intersect_* routines to
perform clipping. I am wondering if these sections can be simplified
dramatically by instead drawing all of the individual segments via
draw_clip_line().

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

Re: Ethans patch of 2005-10-15 (fwd)

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

> Introduce a new method for scaling the canvas, using absolute measures
> (mm, in, pt, pixels). I propose to introduce a common set command that can
> be given independently on the 'set terminal' line, e.g.,
>     set canvas mm 50,30
>     set terminal <whatever>
> The 'size' option of the different terminals could serve as alternative to
> set the canvas.

Maybe
  set size canvas ...


> In addition, all things that can be given in screen coordinates at the
> moment (labels, arrows, offsets, ...) and the size of multiplots
> (set size) can be given in the absolute units (mm, ...).

Question: "fig" can be metric or inches, how it will be rescaling?

> But, the 'set size' method should be maintained since it is used by many
> existing scripts. A warning should be issued:
>   Using `set size` for resizing the canvas is deprecated. Use `set canvas`
>   instead. Beware that `set canvas` uses the screen coordinate 1,1 for the
>   upper right corner, in contrast to `set size`.

You mean to issue this message if "set size != 1,1" when parsing commands
"set term ..." or "set out ..."?

> maintain compatibility with existing scripts. But this also means that we
> have to deal with the clipping problem 'size > 1'.

There is yet another need for "size > 1": 3D splot drawings are sometimes
too small (only "set lmargin" works) and a bit larger plot is more optimal
for screen terminals.

---
PM

Re: Ethans patch of 2005-10-15 (fwd)

[Harald H. <h.h...@tu...>]

On Sun, 16 Oct 2005, Ethan A Merritt wrote:

> On Sunday 16 October 2005 12:02 pm, Harald Harders wrote:
> >
> > But I still do not understand what it does. Because the variable canvas
> > is a pure copy of  { 0, term->xmax, 0, term->ymax }. Why do we now have
> > the term->xmax and term->ymax and a copy of them?
>
> Because it abstracts the notion of a clipping area to the generic case.
> The 15 Oct patch by itself does nothing. Previously the routines
> clip_line() and clip_point() were hard-coded to clip against the plot
> boundaries.  Now they have been generalized to clip against whatever
> the current clipping area is.
>
> > What does it really do?
>
> "Patience, grasshopper". It paves the way.

Okay, I will be patient.

> > Try this:
> >
> > set size 2,2
>
> I am not interested in fixing bugs that arise from
> setting size > 1.

For me, it is one of the largest problems because I am working with the
epslatex and eps terminals with plots at 0.85 x 0.85, but sometimes
multiplots. These rely on sizes > 1 until we will have absolute measures.
But I am not willing to change the old scripts that have worked with
former versions. Since the eps and epslatex terminal do not clip at all,
the labels work here. But the arrows need my local patch.

> I thought we had agreed to work
> toward making such kludges unnecessary.

Mmh, I think I have not made my opinion clear enough. I really like the
idea of absolute measures (mm, in, pt, pixels). But I also think that the
compatibility with old scripts has to be ensured (which is in accordance
with Hans-Bernhard's opinion). And many old script use the 'set size'
mechanism for setting the bounding box/canvas.

If we have the absolute measures new scripts will not rely on screen
coordinates above 1.

Let me conclude:
I want a solution that can be agreed by everyone. Since the opinions of
you and Hans-Bernhard seem nearly incompatible I see one solution that may
be agreeable by both of you:

Introduce a new method for scaling the canvas, using absolute measures
(mm, in, pt, pixels). I propose to introduce a common set command that can
be given independently on the 'set terminal' line, e.g.,
    set canvas mm 50,30
    set terminal <whatever>
The 'size' option of the different terminals could serve as alternative to
set the canvas.
In addition, all things that can be given in screen coordinates at the
moment (labels, arrows, offsets, ...) and the size of multiplots
(set size) can be given in the absolute units (mm, ...).

But, the 'set size' method should be maintained since it is used by many
existing scripts. A warning should be issued:
  Using `set size` for resizing the canvas is deprecated. Use `set canvas`
  instead. Beware that `set canvas` uses the screen coordinate 1,1 for the
  upper right corner, in contrast to `set size`.

By this approach, we create a clean method for resizing the canvas and we
maintain compatibility with existing scripts. But this also means that we
have to deal with the clipping problem 'size > 1'.

And, please discuss these important changes with us, uploading a patch,
before applying them to cvs.

Regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Ethans patch of 2005-10-15

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

On Sunday 16 October 2005 12:02 pm, Harald Harders wrote:
>
> But I still do not understand what it does. Because the variable canvas
> is a pure copy of  { 0, term->xmax, 0, term->ymax }. Why do we now have
> the term->xmax and term->ymax and a copy of them?

Because it abstracts the notion of a clipping area to the generic case.
The 15 Oct patch by itself does nothing. Previously the routines 
clip_line() and clip_point() were hard-coded to clip against the plot
boundaries.  Now they have been generalized to clip against whatever
the current clipping area is.

> What does it really do?

"Patience, grasshopper". It paves the way.

It is much cleaner to change the infrastructure first,
with *no* intentional change in program behaviour, and then
introduce actual changes in separate incremental steps.
It makes it a whole lot easier to pinpoint the source of
a bug later on.

> Still, the clipping of
> labels and arrow does not work at all.

Indeed.  But today's patchset adds generic clipping of arrows,
fixing bug  #1187336  and a bunch of others.  Give me another
hour or so of running test scripts though it.

And following that I will re-visit the clipping of labels.
That's a more difficult problem, however, because gnuplot itself
is not very good at predicting whether a text string will
exceed the clipping limits.

> Try this:
>
> set size 2,2

I am not interested in fixing bugs that arise from
setting size > 1.    I thought we had agreed to work
toward making such kludges unnecessary.



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

Ethans patch of 2005-10-15

[Harald H. <h.h...@tu...>]

I do not really understand what the aim of Ethans patch of 2005-10-15 is.
It introduces a new structure type which can take bounds of plots and the
canvas. This is good.

But I still do not understand what it does. Because the variable canvas is
a pure copy of  { 0, term->xmax, 0, term->ymax }. Why do we now have the
term->xmax and term->ymax and a copy of them? What does it really do?

Still, the clipping of
labels and arrow does not work at all.

Try this:

set size 2,2
set term png size 320,240
set arrow from screen 0.9,0.5 rto screen 0.2,0.0
set arrow from screen 1.1,0.7 rto screen -0.2,0.0
set output 'asdf.png'
splot sin(x)*cos(y)
quit

What we get is a plot that only contains labels below screen 1,1 and
arrows that start below screen 1,1. So, what was the aim of the patch?

What we need is to set the canvas boundaries at 'set terminal' (and not
in term_start_plot()) to

canvas.xright = term->xmax * xsize;
canvas.ytop = term->ymax * ysize;

In addition, the clipping routines, e.g. on_page, get_arrow3d, have to use
canvas.xright and canvas.ytop.

I have provided a patch that has been working before this new change in
CVS, and I will not provide a new one.

We will have to fix the old system (enabling sizes > 1) before we
can even think of changing it.

Ethan, why have you put your patch to cvs without discussing it in the
mailing list?

Regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de