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

Re: Terminal driver cleanup

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

On Wed, 12 Nov 2003, Ethan Merritt wrote:

> Any objections if I update all terminal drivers in the CVS tree to
> explicitly enumerate all entries in TERM_TABLE?
[...]

I don't actually see a need for this (the compiler could almost certainly
catch any errors in this area), but if you feel like doing it, go right
ahead ;-)

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Terminal driver cleanup

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

> Any objections if I update all terminal drivers in the CVS tree to
> explicitly enumerate all entries in TERM_TABLE?

For me it is OK.

Petr

Terminal driver cleanup

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

Any objections if I update all terminal drivers in the CVS tree to
explicitly enumerate all entries in TERM_TABLE?

For example:
diff -urNP gnuplot/term/aed.trm gnuplot-enhanced/term/aed.trm
--- gnuplot/term/aed.trm        1999-06-22 04:54:13.000000000 -0700
+++ gnuplot-enhanced/term/aed.trm       2003-11-10 20:35:38.000000000 -08=
00
@@ -183,7 +183,15 @@
     AED_VTIC, AED_HTIC, options_null, AED_init, AED_reset,
     AED_text, null_scale, AED_graphics, AED_move, AED_vector,
     AED_linetype, AED_put_text, null_text_angle,
-    null_justify_text, do_point, do_arrow, set_font_null
+    null_justify_text, do_point, do_arrow, set_font_null, NULL,
+    0, /* flags */
+    NULL, NULL, NULL, NULL
+#ifdef MOUSE
+    , NULL, NULL, NULL, NULL, NULL
+#endif
+#ifdef PM3D
+    , NULL, NULL, NULL, NULL
+#endif
 TERM_TABLE_END(aed512_driver)
=20
The reason for doing this is that I would like to add a new
set of TERM_TABLE entries to support enhanced mode
text.  I've split out the driver-independent parts and moved them
to term.c. This requires driver-callbacks to do the actual=20
output.  There is no particular reason that a driver couldn't
support enhanced text without supporting MOUSE or PM3D,
and leaving the various TERM_TABLEs incompletely
specified is just asking for trouble if someone later tries to=20
implement the new call-backs at the end of an incomplete
table.

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

Re: show palette palette <n> savergb

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

On Wed, 12 Nov 2003, Petr Mikulik wrote:

> Now, I have it working that way.

Congratulations and thanks for that.

> However, I wonder about the documentation syntax above. Yes, there are some
> commands with help written as
> 	set xxxxx {
> 			{ opt 1 | opt2 }
> 			{ opt3 | opt5 }
> 		}
> 
> but is this somewhere documented that {{bla1 | bla2}} means something
> an additional option, instead of a compulsory of {bla1 bla2}? I don't see
> it -- from 'help':
> 
>  In this document, curly braces ({}) denote optional arguments and a
>  vertical bar (|) separates mutually exclusive choices.  
[...]

Let's put it like this:  there has to be _some_ way to distinguish between
"either a or b" and "either a or b or nothing" in the Syntax description.
We need some kind of braces around the series of alternatives separated by
| to have proper grouping, which means that {a|b} should really mean
"either a or b".  So "either a or b or nothing" has to be expressed in
some other way.  Using the existing meaning of "{}" as "optional
argument", {{a|b}} does have that meaning.  As does {|a|b}.


> Looking to help of some commands, it does not seem very unified. 

Well, the docs has been written by many people over a long time, and it's
pretty hard to get all the fine print right.  So I wouldn't put too much
weight in examples from it.  

> It would be worth if someone goes through gnuplot.doc and makes it all
> right.

Right.  But who has all that time and determination?

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: show palette palette <n> savergb

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

> > 	show palette palette <n> {float | int}
>
> 	show palette palette <n> { | float | int }
> 	show palette palette <n> {{float | int}}
>
> to indicate that {float|int} is optional.

Now, I have it working that way.

However, I wonder about the documentation syntax above. Yes, there are some
commands with help written as
	set xxxxx {
			{ opt 1 | opt2 }
			{ opt3 | opt5 }
		}

but is this somewhere documented that {{bla1 | bla2}} means something
an additional option, instead of a compulsory of {bla1 bla2}? I don't see
it -- from 'help':

 In this document, curly braces ({}) denote optional arguments and a
 vertical
 bar (|) separates mutually exclusive choices.  `gnuplot` keywords or `help`
 topics are indicated by backquotes or `boldface` (where available).  Angle
 brackets (<>) are used to mark replaceable tokens.  In many cases, a
 default
 value of the token will be taken for optional arguments if the token is
 omitted, but these cases are not always denoted with braces around the
 angle brackets.


Looking to help of some commands, it does not seem very unified. See e.g.
'help format' vs 'help log'.

It would be worth if someone goes through gnuplot.doc and makes it all
right.

---
Petr Mikulik

Re: image/binary patch updated

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

[Folks... tell me if this email is too big to be submitting
to the mailing list.  Are people able to see the PNG
images in their browsers?]

Ethan Merritt wrote:

>On Monday 10 November 2003 09:30, you wrote:
>  
>
>>Ethan A Merritt wrote:
>>    
>>
>>>I'll try to test it on an alpha next week (other endian, 64-bit).
>>>      
>>>
>>That will be interesting.  Let me know how it goes.
>>    
>>
>
>First report:  not so good.
>

Well, not too bad either.  I'm encouraged the images
look reasonable.

>There are additional warnings during compilation for datafile.c and gplt_x11.c
>
>cc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/3.8j\" -DCONTACT=\"bug...@da...\" -DHELPFILE=\"/usr/local/share/gnuplot/3.8j/gnuplot.gih\" -I/usr/local/include    -g -c datafile.c
>cc: Warning: datafile.c, line 3156: In this statement, the expression "*pchar=*++pchar" modifies "pchar", and fetches its value in a computation that is not used to produce the modified value without an intervening sequence point.  This behavior is undefined.
>                        *pchar = *++pchar;
>------------------------^
>

I will change that in the code.  But if you want, try
changing, in your code, the three lines in that loop to

            char temp = *pchar;
            *pchar  = *(pchar+1);
            *++pchar = temp;

>cc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/3.8j\" -DCONTACT=\"bug...@da...\" -DHELPFILE=\"/usr/local/share/gnuplot/3.8j/gnuplot.gih\" -I/usr/local/include    -g -c gplt_x11.c
>cc: Warning: gplt_x11.c, line 2435: In this statement, the referenced type of the pointer value "&R_rshift" is "short", which is not compatible with "unsigned short".
>                            R_msb_mask = BitMaskDetails(vis->red_mask, &R_rshift, &R_lshift);
>-----------------------------------------^
>cc: Warning: gplt_x11.c, line 2435: In this statement, the referenced type of the pointer value "&R_lshift" is "short", which is not compatible with "unsigned short".
>                            R_msb_mask = BitMaskDetails(vis->red_mask, &R_rshift, &R_lshift);
>-----------------------------------------^
>cc: Warning: gplt_x11.c, line 2436: In this statement, the referenced type of the pointer value "&G_rshift" is "short", which is not compatible with "unsigned short".
>                            G_msb_mask = BitMaskDetails(vis->green_mask, &G_rshift, &G_lshift);
>-----------------------------------------^
>cc: Warning: gplt_x11.c, line 2436: In this statement, the referenced type of the pointer value "&G_lshift" is "short", which is not compatible with "unsigned short".
>                            G_msb_mask = BitMaskDetails(vis->green_mask, &G_rshift, &G_lshift);
>-----------------------------------------^
>cc: Warning: gplt_x11.c, line 2437: In this statement, the referenced type of the pointer value "&B_rshift" is "short", which is not compatible with "unsigned short".
>                            B_msb_mask = BitMaskDetails(vis->blue_mask, &B_rshift, &B_lshift);
>-----------------------------------------^
>cc: Warning: gplt_x11.c, line 2437: In this statement, the referenced type of the pointer value "&B_lshift" is "short", which is not compatible with "unsigned short".
>                            B_msb_mask = BitMaskDetails(vis->blue_mask, &B_rshift, &B_lshift);
>-----------------------------------------^
>

The above warnings I can fix by just declaring chars and
uchars correctly.  I can get to it this evening.  But the
graphics card details you printed below look reasonable.

>Attached are some screen shots from the X11 output.
>Tux starts out looking a bit ill, and gets worse from there.
>
>Terminal output during the first demo (tux_1) is
>  vis->visualid: 0x23   vis->class: 4   vis->bits_per_rgb: 8
>  vis->red_mask: ff0000   vis->green_mask: ff00   vis->blue_mask: ff
>  ImageByteOrder:  0
>

There certainly is a problem with the graphics mapping.
(The sort of thing seen before.)  It looks like the usual
masks, but there seems to be a lot of variation just exactly
what bits within that mask do what.  And the mangled
image is not good.  (Not seen before.)  I can only assume
that has to do with the decoding of data.  These may all
have something to do with the signed/unsigned warnings
above.

The blue channel seems to come out correctly.  No
surprise since that is the one with the mask associate
with the rightmost bits.

>The PNG output looks OK, so I think this part of it is due to problems in 
>gplt_x11.c
>

Yes, definitely.

>However, the program then dies on a floating exception from the
>1st binary data demo, right after printing:
>

Not so good.  But these usually aren't so hard to
track down.  Gnuplot crashes for PNG as well I assume.
That particular example is a rather innocuous one.  I wonder
what happened.  Could you please try a few things in
image.dem to isolate the problem just a bit more?  Try
inputting the lines one at a time.  Try skipping that example.
Etc.

>        The following binary data sizes are machine dependent:
>
>          name (size in bytes)
>
>          "char" "schar" "c" (1)
>          "uchar" (1)
>          "short" (2)
>          "ushort" (2)
>          "int" "sint" "i" "d" (4)
>          "uint" "u" (4)
>          "long" "ld" (8)
>          "ulong" "lu" (8)
>          "float" "f" (4)
>          "double" "lf" (8)
>
>        The following binary data sizes attempt to be machine independent:
>
>          name (size in bytes)
>
>          "int8" "byte" (1)
>          "uint8" "ubyte" (1)
>          "int16" "word" (2)
>          "uint16" "uword" (2)
>          "int32" (4)
>          "uint32" (4)
>          "float32" (4)
>          "float64" (8)
>

Well hey!  This is very nice.  This is probably the first case
where the doubles, longs and ulongs are 8 bytes.  Also, notice
that the "machine independent" code did what it is supposed
to do.  However, it looks like an "int64" and "uint64" are needed.

>I am not sure yet whether this is due to the error message from
>datafile.c, or whether it is something more fundamental.
>

At first glance, it doesn't look like that command would
be the problem.  That is part of the PDP endian, which
I suspect isn't being reached in this case.

Let me think these over.

Thanks,

Dan


>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

image/binary patch updated

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

I've updated the image/binary patch (694789) to include Ethan's
drivers for PDF and PNG/JPEG.  (I'm intending that to be the
last update.)

-------

I'm now going to offer some comments about ways I feel Gnuplot
can be improved in terms of code and enhanced in terms of
features.  (Call it a harangue if you like, but I'm not intending this
to be critical.)  No one need respond because the suggestions
are more long term.  Or should I say post 4.0?  Maybe just keep
this post around for future ideas.

1)  Convergence of 2D and 3D plots:  I'm not sure how Gnuplot
developed in terms of 2D and 3D plots.  Perhaps they were
coded separately and then combined.  Perhaps there was a
bifurcation along the way for some reason.  In any case it seems
there is some duplication of code for plotting in 2D and in 3D.

For example, there is "plot_lines()" in "graphics.c" and "plot3d_lines()"
in "graph3d.c".  But are these really that different?  (Perhaps someone
knows better than I do if in fact they are drastically different.)  It
seems to me that "map3d_xy" is the most important detail.  But
couldn't this just be "map_xy()" and if the current mode is PLOT_MODE
as opposed to SPLOT_MODE, say, the map_xy() routine does a simple
unity mapping?

Another example is the image drawing routine I put in
the patch, which  is designed to work for 2D or 3D plots.  If a
Boolean variable indicates that a 3D mapping should be done
then the code will call "map3d_xy()".  [I pause to make a point that
this mapping has to be at the point right where the data is utilized.
The reason is that the data stored in 3d plots is before mapping
because the viewing angle can be changed and the splot redrawn.
The only other way is to map all data and store in a temporary chunk
of memory and pass that in.  But I don't think anyone would think
that is a good idea.]  This image plotting routine is in "graphics.c".

Also in "graphics.c" I see some notes left by Hans such as

> /* FIXME HBB 20020225: this is shared with graph3d.c, so it shouldn't
>  * be in this module */


so I'm guessing he's been faced with trying to adhere to the practice
of code reuse as well.

The point, I believe, is that when it boils down to the actual process
of plotting something, it is always in the 2D viewing plane that this
is done.  Whether this means first mapping from the 3D space or not
is a minor detail, I think.

So a bit contrary to Hans remark in the code, I would contend that
graphics.c is the appropriate spot for all graphic object drawing
routines.  Then the dimension-specific details should go into
"graph3d.c" and a new file "graph2d.c".  Furthermore, consider that
there are two different structures for 2D plots and 3D plots,
"curve_points" and "surface_points".  An argument could be made
for having just one structure.  But even if that shouldn't be the case,
it is the

    int p_count;            /* count of points in points */
    struct coordinate GPHUGE *points;

which are important to the actual graphics drawing routines.  So
my suggestion would be to make all graphics drawing routines
operate on a pointer to the points and number of points or combine them in
their own structure and pass that into the routine.  In fact, if one were to
think about this, I bet if these were packed together and put at the
start of both the "curve_points" and "surface_points" structures the
pointers to these plots could be passed in and there would be no need to
distinguish between the two types of pointers because the important data
would have the same offset in the structures.  The graphics routines would
have a "map_xy()" right before they are used.  (The conditional done
inside the "map_xy()" function to conserve code space.)  So I guess that
means the mode would also need to be packed with those two.  Anyway,
I hope you get my point.

2) Not too far removed from #1, with the image stuff I've added a
a short bit of code to allow a colorbox in 2D plots.  It became clear
to Petr and me that the "3d" associated with colorboxes should be
dropped.  So, it seems that a nice consistent method of adding a colorbox
to a plot, either 2D or 3D, is in order.  Right now they are separate.
However, they should essentially use the same code when laying out
the plot.  Petr had some ideas for enhancing the positioning of the color
box and it is logical to not have to change that in multiple spots.  Also,
the slick routine should place the colorbox at the side of the plot.  Petr
and I have agreed that having the colorbox embedded in the splot 3D
space, so that it moves and changes shape when panning the view, is
a bit lacking.  We contemplated fixing that, but I think it is better 
for the
group to think that one through.

3)  Add the capability of RGB to polygons:  Currently polygons use palette
lookup for generating the fill color.  However, I don't see why there can't
be RGB components just like for images.  I personally can't think right
now what the applications might be, but it doesn't seem too far fetched that
such a thing could find a use.  (I don't know, contouring for landscapes,
color image warping, etc.)  One might argue that would require altering
so many of the terminal drivers so the term->polygon has one extra
variable.  But with xemacs, something like "xemacs *.trm" at the command
line will open all files and a replace function could get the job done in an
hour or two.  Sure it would take some more work to add functionality to
the drivers, but various people could choose their favorite and make the
alterations.

4)  Memory usage for storing data points:  This one probably has the
least chance of being addressed.  The "struct coordinate GPHUGE"
is a bit wasteful of memory if only a few columns of it store data that
is actually used.  It would be nice to have a scheme not so wasteful,
say using a "void" pointer and store just the number of columns actually
used.  However, this is some very "advanced" programming, especially
when there is a group of developers.  Many would make the "worst
case scenario" argument for not doing this.  So, ey, just an idea and
I wonder how many feel this is important.

5)  There are some routines in "show" and "set" that list the options
for plot styles, etc.  The strings for these always have to be updated
and some times may become out of date.  Would a little routine be
worthwhile to simple go to the table and pull out the style strings and
print them?  The routine would have to know when there is no more
room on an 80 character line to show the next string and first enter a
carriage return.

6)  How about a simple "help search <text>" routine that searches through
all the gnuplot.doc strings and dumps out the headings of all subtopics that
contain <text>?

Dan

Re: Color structures

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

In summary:

**************** color.h **************

*** this we keep:

/* Contains a colour in RGB scheme.
   Values of  r, g and b  are all in range [0;1] */
typedef struct {
    double r, g, b;
} rgb_color;


*** new structure:

/* Contains a colour in RGB scheme.
   Values of  r, g and b  are all in range [0;255] */
typedef struct {
    unsigned char r, g, b;
} rgb255_color;



**************** getcolor.h **************

void color_from_gray( double gray, rgb_color *color )

=> will be renamed to

void rgb1_from_gray( double gray, rgb_color *color )


New routine:

void rgb255_from_rgb1( rgb_color *color1, rgb255_color *color255 )
{
    *color255.r = (unsigned char)(255 * color1.r + 0.5);
    *color255.g = (unsigned char)(255 * color1.g + 0.5);
    *color255.b = (unsigned char)(255 * color1.b + 0.5);
}


void rgb_from_gray( double gray,
	unsigned char *r, unsigned char *g, unsigned char *b )

=> will be renamed and changed to

void rgb255_from_gray( double gray, rgb255_color *color )
{
	rgb_color color1;
	color_from_gray( gray, &color1 );
	rgb255_from_rgb1( &color1, color );
}


> I think it should be bundled up into a separate patch so that it can be
> tested independent of your pixel/image stuff.

It is code cleanup, so I will put it directly into cvs (sending you the
patch in advance for test).


Further, I remember: the other candidate for rename is
	set_pm3d_zminmax()	=>	set_cbminmax()

---
Petr Mikulik

Re: Color structures [ was Re: image and binary data file]

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

Ethan Merritt wrote:

>On Tuesday 04 November 2003 13:39, Daniel J Sebald wrote:
>  
>
>>So I would propose in the header file have two types of structures
>>
>>/* Contains a colour in RGB scheme.
>>   Values of  r, g and b  are all in range [0;1] */
>>typedef struct {
>>    double r, g, b;
>>} rgb1_color;
>>    
>>
>
>We already have such a structure defined in color.h
>

Right.  I was thinking of just adding a "1" to "rgb" for clarity.
It could be left as is.

>I'm all in favor code cleanups, up to a certain point.
>But this potentially touches a lot of code,
>

There are only about 20 occurrences in 4 files.  Not too bad using
a "replace" edit function...

> so I think it
>should be bundled up into a separate patch so that 
>it can be tested independent of your pixel/image stuff.
>

I agree.

Dan

Color structures [ was Re: image and binary data file]

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

On Tuesday 04 November 2003 13:39, Daniel J Sebald wrote:
> So I would propose in the header file have two types of structures
>
> /* Contains a colour in RGB scheme.
>    Values of  r, g and b  are all in range [0;1] */
> typedef struct {
>     double r, g, b;
> } rgb1_color;

We already have such a structure defined in color.h

> /* Contains a colour in RGB scheme.
>    Values of  r, g and b  are all in range [0;255] */
> typedef struct {
>     uchar r, g, b;
> } rgb255_color;

OK.

[snip description of passing the structure to subroutines,
 rather than passing the individual r,g,b components]

> I sort of don't like large numbers of arguments in high
> level programming, only at the driver and assembly level.

I'm all in favor code cleanups, up to a certain point.
But this potentially touches a lot of code, so I think it
should be bundled up into a separate patch so that=20
it can be tested independent of your pixel/image stuff.

=09Ethan


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

Re: show palette palette <n> savergb

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

> as a function that prints its output.  So the command sequence
> would become
> 	set print '<palettefile>'
> 	print palette(n)

Result of palette(n) would be a matrix, not a number, so I don't like this
syntax.

> As to the float/int option, can't we just write both into the file?
> Each line would have an integer triplet and a float triplet.
> So output of 'print palette(n)' would be 8 numbers per line:
> <index> <grey value> <r> <g> <b> <ir> <ig> <ib>

Only one triplet has to be saved into the file so that 3rd party
applications can read that gnuplot palette. That was the main idea for
implementing this feature (gnuplot palette models are really extremely
powerful).


BTW, there are also binary palette ".lut" files accepted by some
applications, e.g. ImageJ. Does somebody know their structure?

---
Petr Mikulik

Re[4]: arrowheads too long in PostScript terminal

[Alan G I. <ai...@am...>]

> On Sat, 1 Nov 2003, Alan G Isaac wrote:
>> I would still expect the ink not
>> to pass the point the arrow is drawn "to" (in the direction
>> of the arrow).

On Sat, 01 Nov 2003, Hans-Bernhard Broeker apparently wrote:
> I don't think so.  The question is why you drew an arrow, and how the
> average reader would read the resulting plot.  If the tip is visibly
> rounded, the most obvious position to be read out of it would indeed be
> the center of that arc, not some point on it, because it'd be hard to tell
> where on the arc that should be.

If we were talking about headless arrows with rounded caps,
I would agree with this.  (In otherwords, I am certainly
not arguing that the caps should be offset for a line 
segment.) But an arrowhead pins down a sense
of direction that eliminates the problem you raise.
Consider the attached EPS file.

Cheers,
Alan

%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: 71 49 313 149
%%Pages: 1
%%EndComments
%%Page: 1 1
%%BeginDocument: C:/temp.ps
%!PS
/Helvetica 20 selectfont
72 120 moveto
(Which line do I point to?)show
72 72 moveto
288 72 lineto
72 100 moveto
288 100 lineto
6 setlinewidth
stroke
288 72 moveto
0 setgray
gsave
currentpoint translate
0 -12 lineto
24 0 0 12 4 arct
0 12 lineto
closepath
fill
grestore
288 100 moveto
0 -12 rlineto
24 12 rlineto
-24 12 rlineto
closepath
fill
312 50 moveto
0 100 rlineto
307.2 50 moveto
0 100 rlineto
305.5 50 moveto
0 100 rlineto
0.1 setlinewidth
0.5 setgray
[3 2] 0 setdash
stroke
showpage
%%EndDocument
%%Trailer

Re: arrowheads too long in PostScript terminal

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

Alan G Isaac wrote:

>On Wed, 22 Oct 2003, Daniel J Sebald apparently wrote:
>  
>
>> user expectations
>>are something to consider.  But also you should weigh
>>in any preceding standards.  My guess is that there
>>have been long discussions amongst graphics people
>>about the topic and some standard may have emerged
>>over the years.  I would consider using that as a guide.
>>    
>>
>
>
>I have not been able to find an answer at this 
>level, so I took a different approach: I looked
>in a number of nicely done math books to see
>how arrows are drawn.
>

Actually, this is probably just as good.  Quality publishers hire out
work to professional graphics companies who, I assume, know
appropriate conventions.

I think i and ii below are preferrable to the current arrowhead.  When
I find some time, I could draw the vector relationships and come up
with the formula for compensenting for pen width at the arrow tip.
(Perhaps digitize the drawing and make it available in a PDF file.)

Dan

>I found two widespread conventions:
>i. The arrowhead ink ends right at the point the arrow is
>drawn to.  This is the convention that I have been pushing
>for.
>ii. The arrowhead ink ends right at the edge of a filled
>circle, the center of which is the point that the arrow
>is drawn "to".  I find this odd conceptually, but I confess
>it does produce some nice looking graphics.
>
>I did *not* find cases where the arrowhead ink extends
>beyond the point the arrow is drawn to, which is the current
>gnuplot convention.  So I not only remain convinced that
>current gnuplot practice is wrong at the conceptual level,
>it also does not appear to be a common practice (based on my
>limited "survey").
>
>So I still think that the right thing for gnuplot to do is
>ensure that the very tip of the arrowhead ink is at the
>point that the arrow is drawn to.  As I have argued, it is
>what the user expects, and based on a little looking around,
>it seems this user expectation is in line with established
>practice.
>
>However due to case (ii) above---a case that Ethan first
>drew my attention to---it seems it would also be useful to
>introduce a new option for set arrow: "point", which would
>work like similarly to how it does for label.  Specifically,
>it would place a point and then allow for a single number
>"offset" (interpreted as a shortening of the arrowlength)
>which would be specified in pointsize units.  (I guess one
>might be wanted at each end, in which case there could also
>be an option "points" that accepts two numbers an offset,
>one for each end.)
>
>fwiw,
>Alan
>  
>

Re: show palette palette <n> savergb

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

On Saturday 01 November 2003 09:11 am, Hans-Bernhard Broeker wrote:
> On Fri, 31 Oct 2003, Petr Mikulik wrote:
> > Therefore, now I would propose the syntax
> >
> > 	show palette palette <n> {float | int}
> >
> > Without the float|int option, it would print the complete table as it
> > prints now. With the option, it would print table of <n> rgb triplets
> > either in range 0..1 or 0..255. The output would be sent to the file
> > given by 'set print'.

If output is to go to the 'set print' device, then why not use a 
print command, rather than a show command?
Functionally it would appear as if there were an internally
defined function palette(n), although in practice I think we 
would have to catch the keyword "palette" explicitly in the
command parser rather than trying to actually implement it
as a function that prints its output.  So the command sequence
would become
	set print '<palettefile>'
	print palette(n)

As to the float/int option, can't we just write both into the file?
Each line would have an integer triplet and a float triplet.
Very similar to the current output of 'show palette palette <n>'
but less wordy. I don't see anything to be gained by splitting
this into two separate output options.

So output of 'print palette(n)' would be 8 numbers per line:
<index> <grey value> <r> <g> <b> <ir> <ig> <ib>

Actually, I'd suggest emitting a comment line first that
states the generating function used to create the palette.

> > Considering the option 'palette' of 'show palette', it's there for
> > years.

There are many examples in gnuplot of the output of 'show'
not matching the output of 'print'.  So I don't think it would 
introduce any new confusion to have both show and print
exist for palette output.


-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re[3]: arrowheads too long in PostScript terminal

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

On Sat, 1 Nov 2003, Alan G Isaac wrote:

> > On Fri, 31 Oct 2003, Alan G Isaac wrote:
> >> I found two widespread conventions:
> >> i. The arrowhead ink ends right at the point the arrow is
> >> drawn to.  This is the convention that I have been pushing
> >> for.
> >> ii. The arrowhead ink ends right at the edge of a filled
> >> circle, the center of which is the point that the arrow
> >> is drawn "to".  I find this odd conceptually, but I confess
> >> it does produce some nice looking graphics.
>
> On Sat, 01 Nov 2003, () Hans-Bernhard Broeker apparently wrote:
> > These two conventions aren't necessarily all that different as they
> > appear.  Think of the first as a special case of the second, with the
> > curve radius of the tip reduced to zero --- or more precisely to some
> > value too small to be visible as a round tip, so it appears sharp.
> > Obviously, this also requires to interpret the tip radius as a feature
> > independent of the arrow linewidth.
>
> You appear to be describing a 3rd case, that I didn't come
> across.  Here is what I hear you saying:
> iii. arrowhead has a rounded rather than sharp tip.

Sort of.  The tip is *always* rounded, because truly sharp objects
don't exist in the real world.  The only question is the radius of
the rounded tip.  In your listing:

(i)   radius << linewidth, and too small to be visible
(ii)  radius == linewidth
(iii) radius somewhere in between

> If (iii) is what you meant, I would still expect the ink not
> to pass the point the arrow is drawn "to" (in the direction
> of the arrow).

I don't think so.  The question is why you drew an arrow, and how the
average reader would read the resulting plot.  If the tip is visibly
rounded, the most obvious position to be read out of it would indeed be
the center of that arc, not some point on it, because it'd be hard to tell
where on the arc that should be.

> What I meant by (ii) is perhaps better captured by:
> (ii') a filled circle with radius 'r' centered on the "to"
> point 'ptB' is drawn, and then the arrow from ptA to ptB is
> drawn so that its very tip ends at the edge of the filled
> circle.

I don't think I've seen anything like that, nor did I understand your
earlier description to mean this.  Rather like this: draw the arrowhead as
two wide lines with a round join vertex at the 'to' position, i.e. the
outer flanks of the arrowhead end tangentially on the arc that forms the
very tip, and connects the two flanks.

> I agree with this principle, but of course on
> terminals that do not support filling one can
> still draw thick lines but then shorten the arrow
> by the miter length.

Odds are such simplistic terminal drivers would *still* get it wrong ---
Esp. if they don't really support polylines at all, and thus cannot
possible create a miter join.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re[3]: arrowheads too long in PostScript terminal

[Alan G I. <ai...@am...>]

> On Fri, 31 Oct 2003, Alan G Isaac wrote:
>> I found two widespread conventions:
>> i. The arrowhead ink ends right at the point the arrow is
>> drawn to.  This is the convention that I have been pushing
>> for.
>> ii. The arrowhead ink ends right at the edge of a filled
>> circle, the center of which is the point that the arrow
>> is drawn "to".  I find this odd conceptually, but I confess
>> it does produce some nice looking graphics.

On Sat, 01 Nov 2003, () Hans-Bernhard Broeker apparently wrote:
> These two conventions aren't necessarily all that different as they
> appear.  Think of the first as a special case of the second, with the
> curve radius of the tip reduced to zero --- or more precisely to some
> value too small to be visible as a round tip, so it appears sharp.
> Obviously, this also requires to interpret the tip radius as a feature
> independent of the arrow linewidth.

You appear to be describing a 3rd case, that I didn't come
across.  Here is what I hear you saying:
iii. arrowhead has a rounded rather than sharp tip.

If (iii) is what you meant, I would still expect the ink not
to pass the point the arrow is drawn "to" (in the direction
of the arrow).

What I meant by (ii) is perhaps better captured by:
(ii') a filled circle with radius 'r' centered on the "to"
point 'ptB' is drawn, and then the arrow from ptA to ptB is
drawn so that its very tip ends at the edge of the filled
circle.  Thus the arrow length will be 'r' less than the
distance from ptA to ptB.

As I said, I personally find the practice a bit odd, bit it
appears reasonably common.  (I also came across this
practice for headless arrows.  E.g., construct a line
segment between two points.)

It is still the case that (i) is a special case of (ii')
with r=0.

> Summing it up, the core problem all around is that arrows
> shouldn't ever have been drawn using wide lines in the
> first place.

I agree with this principle, but of course on
terminals that do not support filling one can
still draw thick lines but then shorten the arrow
by the miter length.

One odd thing about the current PostScript terminal is that
it draws a filled head and then "outlines" it with a thick
line, and it is only the superfluous outline that causes
ink to extend past the "to" point.  If this is true of
all terminals supporting filling, then filled arrowheads
at least will be simple to fix.  (Of course, as you have
indicated, on such terminals *all* arrowheads could be
drawn as filled outlines.)

Cheers,
Alan

PS One last thing I just want to mention again since I do not
recall any discussion of it: the 'vectors' plotting style
will only produce sensible results if the ink for each
vector starts and stops at exactly the specified points.
I suppose this is currently addressed to a certain extent
by refusing to honor 'linewidth' for plots in the
'vectors' style.  (But shouldn't 'linetype' be allowed
for color selection?)

Re[2]: arrowheads too long in PostScript terminal

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

On Fri, 31 Oct 2003, Alan G Isaac wrote:

> I found two widespread conventions:
> i. The arrowhead ink ends right at the point the arrow is
> drawn to.  This is the convention that I have been pushing
> for.
> ii. The arrowhead ink ends right at the edge of a filled
> circle, the center of which is the point that the arrow
> is drawn "to".  I find this odd conceptually, but I confess
> it does produce some nice looking graphics.

These two conventions aren't necessarily all that different as they
appear.  Think of the first as a special case of the second, with the
curve radius of the tip reduced to zero --- or more precisely to some
value too small to be visible as a round tip, so it appears sharp.
Obviously, this also requires to interpret the tip radius as a feature
independent of the arrow linewidth.

Summing it up, the core problem all around is that arrows shouldn't ever
have been drawn using wide lines in the first place.

> However due to case (ii) above---a case that Ethan first
> drew my attention to---it seems it would also be useful to
> introduce a new option for set arrow: "point", which would
> work like similarly to how it does for label.

Or, more generally, consider a global terminal-wide option like the
postscript one for mitered vs. rounded joins of polyline, and work from
there onward.  Note that quite a collection of terminal drivers don't
even offer a choice like that.  IOW: we're looking at a pile of work
here.

> "offset" (interpreted as a shortening of the arrowlength)
> which would be specified in pointsize units.

That offset would be to specific.
>  (I guess one
> might be wanted at each end, in which case there could also
> be an option "points" that accepts two numbers an offset,
> one for each end.)
>
> fwiw,
> Alan
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: unlimited windows patch

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

On Fri, 31 Oct 2003, Petr Mikulik wrote:

> It would need a routine like strlen_enhanced_text(char*) which would
> estimate the width of the label. Additionally, it would be of great use for
> gnuplot's auto sizing of margins et al, where it counts all characters of
> "/Symbol ...".

This has been a problem ever since the enhance postscript driver was added
to the program.  Its integration with the terminal-independant core engine
of gnuplot is so weak as to be effectively non-existant.  It's similar
for the TeX terminals, but there the task would be hopeless anyway, and we
do offer a possiblity to at least lay off the task of centering texts to
the TeX engine.

For PostScript-Enhanced (and the other terminals who learned the same
syntax, since) it's gnuplot that does the positioning, but it's being left
dangling in the air regarding support by the actual driver.  At the
minimum, there should be an addition to the term API that lets the core
request the actual size of a given string, in terminal units.

Possibly even better, the whole 'enhanced' stuff should be moved into the
core, where other terminals could benefit from it more easily without
needing to reinvent wheels.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: show palette palette <n> savergb

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

On Fri, 31 Oct 2003, Petr Mikulik wrote:

> > However, logically if you can
> >     'save rgbpalette <filename>'
> > you would expect to be able to restore it later using
> >     'load <filename>'

That's a pretty strong point against my "save" proposal.  I'm hereby
retracting that proposal.

Given the way this would be used (write info to file with that can be
plotted later), it's more similar to what the table terminal does, really,
than to 'save'.

That is, unless you're prepared to save it in a format that's cleverly
designed to be usable both as a 'load'able script to restore that palette,
and as a plottable datafile (e.g. by having a pair of blank lines after
the 'load'able commands end with an 'exit' command, and then the actual
data.)  Not entirely impossible, I guess, but could be tricky to
explain to users...

> Therefore, now I would propose the syntax
>
> 	show palette palette <n> {float | int}
>
> Without the float|int option, it would print the complete table as it prints
> now. With the option, it would print table of <n> rgb triplets either in
> range 0..1 or 0..255. The output would be sent to the file given by 'set
> print'.

In that case, the outline above wouldn't quite match the actual syntax.
It'd have to read one of these ways, instead:

	show palette palette <n> { | float | int }
	show palette palette <n> {{float | int}}

to indicate that {float|int} is optional.

Otherwise (and unless we follow through on that crazy idea I outlined
above....) I think this is a good way to proceed.

> Considering the option 'palette' of 'show palette', it's there for
> years.

Well, I guess what this shows is mostly that I haven't exactly spent large
amounts of time inspecting the whole pm3d subsystem.  I'd have spotted
that earlier, otherwise ;->

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re[2]: arrowheads too long in PostScript terminal

[Alan G I. <ai...@am...>]

On Wed, 22 Oct 2003, Daniel J Sebald apparently wrote:
>  user expectations
> are something to consider.  But also you should weigh
> in any preceding standards.  My guess is that there
> have been long discussions amongst graphics people
> about the topic and some standard may have emerged
> over the years.  I would consider using that as a guide.


I have not been able to find an answer at this 
level, so I took a different approach: I looked
in a number of nicely done math books to see
how arrows are drawn.

I found two widespread conventions:
i. The arrowhead ink ends right at the point the arrow is
drawn to.  This is the convention that I have been pushing
for.
ii. The arrowhead ink ends right at the edge of a filled
circle, the center of which is the point that the arrow
is drawn "to".  I find this odd conceptually, but I confess
it does produce some nice looking graphics.

I did *not* find cases where the arrowhead ink extends
beyond the point the arrow is drawn to, which is the current
gnuplot convention.  So I not only remain convinced that
current gnuplot practice is wrong at the conceptual level,
it also does not appear to be a common practice (based on my
limited "survey").

So I still think that the right thing for gnuplot to do is
ensure that the very tip of the arrowhead ink is at the
point that the arrow is drawn to.  As I have argued, it is
what the user expects, and based on a little looking around,
it seems this user expectation is in line with established
practice.

However due to case (ii) above---a case that Ethan first
drew my attention to---it seems it would also be useful to
introduce a new option for set arrow: "point", which would
work like similarly to how it does for label.  Specifically,
it would place a point and then allow for a single number
"offset" (interpreted as a shortening of the arrowlength)
which would be specified in pointsize units.  (I guess one
might be wanted at each end, in which case there could also
be an option "points" that accepts two numbers an offset,
one for each end.)

fwiw,
Alan

Re: unlimited windows patch

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

> > BTW, I've noticed that there is a bug visible on some enhanced terminals
> > (PM and gd enhanced patch by Ethan): all text is flushed left instead of right.
>
> What is PM?

OS/2 Presentation Manager terminal (set term pm)

> Text justification in gd+enhanced would be difficult, although I think it

The bug is somewhere else -- it looks like *all* text is wrongly justified,
even when using no enhanced features in any text.

> is possible with some work.   It is much harder than in PostScript because
> libgd does not provide equivalent operators such as gsave/grestore.
> A lot more would have to be done in software.

It would need a routine like strlen_enhanced_text(char*) which would
estimate the width of the label. Additionally, it would be of great use for
gnuplot's auto sizing of margins et al, where it counts all characters of
"/Symbol ...".

---
Petr Mikulik

Re: unlimited windows patch

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

On Friday 31 October 2003 02:50, Petr Mikulik wrote:
> > So, in summary, the structure of 16 plots has been replaced by a
> > linked list.
>
> I propose to add this patch into current cvs. (That limit of 16 windows
> is considered as a bug by some people, mainly when using it with
> Octave's figure(n) function.)

So far it works here also, but I have not tested it very thoroughly.


> BTW, I've noticed that there is a bug visible on some enhanced terminal=
s
> (PM and gd enhanced patch by Ethan): all text is flushed left instead o=
f right.

What is PM?

Text justification in gd+enhanced would be difficult, although I think it
is possible with some work.   It is much harder than in PostScript becaus=
e
libgd does not provide equivalent operators such as gsave/grestore.
A lot more would have to be done in software.   But I did block out the
code in principle.   A bigger problem is that libgd is still not handling
symbol fonts correctly.  I have mailed patches toTom Boutell, but they ha=
ve
not yet made it into a released version.


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

Re: show palette palette <n> savergb

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

> > And if you really suspect confusion, you could still use a different
> > name than 'palette' to distinguish it from 'show palette'.  Say 'save
> > rgbpalette'.

Then docs would have to be like

       save {<option>} '<filename>'
       save rgbpalette '<filename>' <n> {scale <scale> {int}}

> However, logically if you can
>     'save rgbpalette <filename>'
> you would expect to be able to restore it later using
>     'load <filename>'
> This suggests to me that the output of the save command
> should be formatted such that it is acceptable to 'load'.

No, it is to be loaded as
	set palette file 'blabla.dat'

Thus, it is not very coherent with other save/load commands.

Therefore, now I would propose the syntax

	show palette palette <n> {float | int}

Without the float|int option, it would print the complete table as it prints
now. With the option, it would print table of <n> rgb triplets either in
range 0..1 or 0..255. The output would be sent to the file given by 'set
print'.

What do you think about this?


Considering the option 'palette' of 'show palette', it's there for years.
But that's just showing command, thus obviously not used in scripts. It
could be renamed to 'show palette rgbpalette' or 'show palette rgbtable' if
there are some votes for this change, or for any other better name.


> Also, would it not be equally (or even more) useful to have a
>     'test rgbpalette'
> that displays in the plot window an indexed array of the
> palette colors?

That would be really nice. It could be done most easily like that:
  - save rgb table with 256 samples into a temporary file
  - plot it by a call to "do_string"

---
Petr Mikulik

Re: unlimited windows patch

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

> So, in summary, the structure of 16 plots has been replaced by a linked
> list.

I propose to add this patch into current cvs. (That limit of 16 windows is
considered as a bug by some people, mainly when using it with Octave's
figure(n) function.)

The patch works for me fine on OS/2-X11, Linux and Windows/Cygwin-X11.

> set term x11 145 title "Hello World"

This "title" option is cool as well (OS/2 terminal had this for years).


BTW, I've noticed that there is a bug visible on some enhanced terminals (PM
and gd enhanced patch by Ethan): all text is flushed left instead of right.

---
Petr Mikulik

image and binary data file

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

The second patch is a major redo of the image and binary data file
support code:

694789 New plotstyle "with pixels"
[Now called "with image"]

with_image_103003.diff.gz
datafiles.tar:
     blutux.rgb
     scatter2.bin
     sine.bin
     using.bin
     demo.edf

The gzip file is the actual patch.  The datafiles.tar file is several
binary data files required for the "image.dem" demo program
within the patch.

Petr and I really winnowed the features, syntax, etc. on this one.
I think we have a nice set of commands and capabilities.
Discussion is always welcome, of course.

Some significant changes are that it is now 'with image' and
'with rgbimage' as opposed 'with pixels".  Also, the variable
'pixelplanes' is defunct.  No longer is there the ability to control
the individual size of pixels.  I thought that would find very little
use, and there are other ways of doing this.  Instead the image
plotting routine has been generalized for any orientation and
skew of image grid.  It will use the efficient term->image function
if appropriate.  Images can be used in both `plot` and `splot`.  But
RGB images cannot be used in `splot`.  [Perhaps a future
discussion item.]

 From Petr's original discussion list submission about binary
data file syntax, I've done some major changes that make the
use of such files much easier.  A concept of "inherent sampling
array" has emerged to make things easy to remember and no
longer is there the arcane use of 0, -1 and -2 in the `using` string.
Instead, associated with `binary` is `array=1024x1024`.  There
are similar options for controlling data position, spacing, translation,
etc. which include `origin, center,  dx, dy, dz, flipx, flipy, flipz,
transpose, flip, scan, rotation, perpendicular, endian, filetype`.  It
may all seem like a lot to digest, but if you try the patch and
look through the demo commands, I think you will find it makes
a great deal of sense.

Petr has written some code for reading EDF files which
we've incorporated into the code and demo script.  The general
strategy is that the binary feature has a structure describing
details about the binary file in question.  (Of course,
that is what is filled in by options like 'origin, center`, etc.)  The
EDF file function looks at a file's header and fills in the necessary
variables of the structure and lets Gnuplot continue onward.

The binary data seems to work fine through a pipe, i.e., `-`.
(One of the original reasons for the patch.)  Actually, I just tried
it one day and it worked without alteration.

I guess it doesn't pay to go into more on this until people have
had a chance to look at the patch.  I suggest some of the developers
give the demo `image.dem` a try.  (I think you will like some of the
capabilities.)  Then generate some discussion about integration
into CVS.  I'm sure many people will have comments and suggestions
about syntax, etc.  But I think that is better tackled through all
developers having the ability to modify code.  It has become a bit
unwieldy for me to make modifications.  My supporting utilities
are becoming out of date and I think most things that need fine tuning
aren't worth addressing until there is some discussion and agreement
on details.  I'm certainly willing to help with changes down the road,
of course.  I've tried not touching the current behavior of Gnuplot, e.g.
`binary` without a <binary list> still behaves like Gnuplot's current
binary mode.

Dan


-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/