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

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/

unlimited windows patch

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

Folks,

I've updated some patches on SourceForge (with much of Petr's help)
that I'd like people to test and consider for integration into Gnuplot.  One
is a moderate length patch for unlimited X11 windows.  The other is the
longer patch for image and binary data file support.  I will briefly discuss
the two in separate emails...

Patch 774822 Unlimited plot windows for X11 terminals.

linked_list_103003.diff

The unlimited X11 windows patch consists of the one file listed above.
The strategy here was to take the large table containing information
about the window and add a few pointers for a doubly-linked list and
an identifier (the window #).  Then there is a large chunk of code to
support the linked list.  It actually is fairly straightforward with a few
short routines like "Add_To_List", "Remove_From_List", etc.  The only
tricky part was robustly cleaning up plots that are deleted via the OS,
e.g., pressing the close button of the window.  That requires a queue
for deleting plots because otherwise the OS error handler could delete
a plot that gnuplot_x11 is currently accessing.  In any case, it has been
very robust and I can't recall ever seeing gnuplot_x11 go defunct with
this strategy.  I've also run this through Octave to generate a couple
hundred plots on the screen and it works fine.

So, in summary, the structure of 16 plots has been replaced by a linked
list.  Petr has tested the patch and also gave some good suggestions
for additions.  Also, the issue of closing a window has come up on the
list, so I added a "close", although there may be an issue with the
different pipes.  (Try it, see if it suitable.)  The X11_options() routine
has been cleaned up to do reasonable sanity checks and to not change
anything unless a valid "set term" command is entered.  This is more
in line with the manner in which "plot" and "splot" behave.

There is documentation in Gnuplot, but some examples are

set term x11 145 title "Hello World"
plot sin(x)
set term x11 close

Dan


-- 

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

Re: show palette palette <n> savergb

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

On Thursday 30 October 2003 01:07, Hans-Bernhard Broeker wrote:
> On Thu, 30 Oct 2003, Petr Mikulik wrote:
>
> And if you really suspect confusion, you could still use a different
> name than 'palette' to distinguish it from 'show palette'.  Say 'save
> rgbpalette'.

I like that option best of the ones mentioned so far.
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'.

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?

--=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 Thu, 30 Oct 2003, Petr Mikulik wrote:

> > If you're going to 'save' it to a file, wouldn't the most sensible place
> > be a sub-option of the 'save' command?  So IMHO it should be something
> > like
> >
> > 	save palette '<filename>' ncolors <n>
>
> That could confuse user whether it is saving "set palette" or the discrete
> r,g,b values of the current palette.

I strongly doubt it'll be less confusing than breaking the existing
tradition that 'show' shows, and 'save' writes to file.

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

> I find it more logic to be able to save
> the rgb table to a file at the same place it can write it to screen.

But the problem is you're planning to write to screen something different
than what you would save to file, anyway.  If you want the actual
'show' output in a file, there's always 'set print' for that, right?

> > > show palette palette <n> {savergb {<scale> {int}} 'filename'}
> >
> > The doubling of 'palette' in there feels wrong, to me.
>
> It's OK -- there are more "show palette" print options, see "help palette".

Sure --- but that still doesn't make 'palette' a good sub-option name. If
you worry about confusing the user, this should have you pretty worried,
IMHO.

> > I seriously doubt that all that scaling is worth the hassle.  Either write
> > out floats, or ints scaled up to the usual 8-bit range.
>
> I think it is worth it: some apps loading rgb palettes require integer range
> 0..255, others float range 0..1.

Exactly --- and those are the *only* ones I've ever seen anybody use.
Which means there's hardly any point offering a selection much more
general than that.  A simple option {int | float} would be sufficient.
For plotting the colour profiles from gnuplot, you wouldn't need it all,
of course...

-- 
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...>]

> > Currently gnuplot can print colour palette table on screen by 'show
> > palette palette <n>'. I made a patch which can save it to a file, just 3
> > columns of r,g,b, to be easily plotted by gnuplot as colour profiles.
> > The syntax proposed is below. Does somebody propose any other addition?
> > (E.g. how to save lut files?)
>
> If you're going to 'save' it to a file, wouldn't the most sensible place
> be a sub-option of the 'save' command?  So IMHO it should be something
> like
>
> 	save palette '<filename>' ncolors <n>

That could confuse user whether it is saving "set palette" or the discrete
r,g,b values of the current palette. I find it more logic to be able to save
the rgb table to a file at the same place it can write it to screen.

> > show palette palette <n> {savergb {<scale> {int}} 'filename'}
>
> The doubling of 'palette' in there feels wrong, to me.

It's OK -- there are more "show palette" print options, see "help palette".

> I seriously doubt that all that scaling is worth the hassle.  Either write
> out floats, or ints scaled up to the usual 8-bit range.

I think it is worth it: some apps loading rgb palettes require integer range
0..255, others float range 0..1.

---
Petr Mikulik

Re: show palette palette <n> savergb

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

On Wed, 29 Oct 2003, Petr Mikulik wrote:

> Currently gnuplot can print colour palette table on screen by 'show
> palette palette <n>'. I made a patch which can save it to a file, just 3
> columns of r,g,b, to be easily plotted by gnuplot as colour profiles.
> The syntax proposed is below. Does somebody propose any other addition?
> (E.g. how to save lut files?)

If you're going to 'save' it to a file, wouldn't the most sensible place
be a sub-option of the 'save' command?  So IMHO it should be something
like

	save palette '<filename>' ncolors <n>

> show palette palette <n> {savergb {<scale> {int}} 'filename'}
[...]

The doubling of 'palette' in there feels wrong, to me.

I seriously doubt that all that scaling is worth the hassle.  Either write
out floats, or ints scaled up to the usual 8-bit range.

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

show palette palette <n> savergb

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

Currently gnuplot can print colour palette table on screen by 'show palette
palette <n>'. I made a patch which can save it to a file, just 3 columns of
r,g,b, to be easily plotted by gnuplot as colour profiles. The syntax
proposed is below. Does somebody propose any other addition? (E.g. how to
save lut files?)


show palette palette <n> {savergb {<scale> {int}} 'filename'}

`show palette palette <n>` shows RGB triplets for the current settings and a
palette having <n> discrete colors. This table can be saved into a
`filename` (accepting also '-' and '|pipe_command'), optionally scaled by
'<scale>' and rounded to integer values.


---
Petr Mikulik

Re: again: x11 is eating one character from stdin pipe

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

> So now we have a problem:  octave scripts only work with the call
> to setvbuf(), while awk scripts only work without it.  Octave is likely the
> more important application, and anyway people have been using the
> setvbuf() version for almost 2 years now.  So we should leave the
> default the way it is.

I.e., there are some applications which call setvbuf(gp,NULL,_IOLBF,0); or
do fflush(gp) after each command, and those which don't. Fortunately,
interactive programs should not be affected unless they "set mouse"
explicitly. However, this applies only to X11 terminal.


I think it would be worth to add some text about the necessity of using
	setvbuf(f,NULL,_IOLBF,0); /* set unbuffered output */
into "help x11_mouse".


> However, in case someone does want to use an awk script,
> perhaps there could be an option
> 	set mouse [no]buffered
> The default would be nobuffered, implemented by the existing call
> to setvbuf(). Specifying 'set mouse buffered' instead would bypass
> the call to setvbuf() and allow awk to work.
>
> Would that be an acceptable work-around?

Isn't this just X11 specific? Does it set both stdin/stdout to application
and to terminal to non-buffer, or only for one end?


Maybe, in the next fool-proof reincarnation of X11 terminal, it would be
worth to do it like in gnuplot for OS/2 -- named pipe terminal->gnuplot,
with gnuplot having a thread waiting for pipe events (or semaphores +
shared memory).

---
Petr Mikulik

Re: demos

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

On Tuesday 21 October 2003 03:21, Petr Mikulik wrote:
>
> There are still many *.dem which use "set no" instead of "unset", and
> "set data/func style" instead of "set style data/func". Could somebody
> have a look, update and test *.dem for the new 3.8 syntax?

Done.
I used:
sed -e 's/unset key/set key off/' \
       -e 's/set no/unset /' \
       -e 's/^set key *$/set key on/' \
       -e 's/set data style/set style data/' \
       -e 's/set function style/set style function/'
--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: again: x11 is eating one character from stdin pipe

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

Ethan Merritt wrote:

>Daniel J Sebald <dan...@ie...> wrote>
>  
>
>>That is some strange code, however.  
>>    
>>
>
>I will choose to take that as a compliment :-)
>

Why, of course I meant it that way.  :-)

>>Maybe a handshaking scheme is needed.  Perhaps x11.trm
>>    
>>
>
>Handshaking didn't help.
>

Yes, sometimes it just pushes the problem to some other
obscure location.

Dan

-- 

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

Re: again: x11 is eating one character from stdin pipe

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

On Monday 27 October 2003 07:04, Petr Mikulik wrote:
> I'd a look to the patch of June 21 which made the break; even though I
> don't understand it, I've found that commenting out the
> "X11_waitforinput();" call does not produce the forgetting-pipe error:
>
>    /* Force default font at start of plot */
> #ifdef USE_MOUSE
>     /* EAM June 2003 - Flush the set font command through the pipe */
>     /* to gnuplot_x11, then wait for it to return the resulting    */
>     /* font size information (v_char and h_char).                  */
>     if (!default_font_size_known) {
>         X11_set_default_font();
>         FFLUSH();
>         X11_waitforinput();
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         default_font_size_known =3D TRUE;
>     }
> #else
>     X11_set_default_font();
> #endif
>     X11_set_font("");
> }
>
>
> Does that command have to be there?

Well yes.  That is the whole point of the excercise.
The idea is to give X11 a chance to initialize the window data
structure and send back sizing and font information before
proceeding.  That way the plot can be laid out correctly.

Daniel J Sebald <dan...@ie...> wrote>
>That is some strange code, however. =20

I will choose to take that as a compliment :-)

>Does anyone know what the basic concept is here?

See above.=20

> Maybe a handshaking scheme is needed.  Perhaps x11.trm

Handshaking didn't help.  What was needed was an interlock.
I added that to CVS on 23 Oct.  You should not (I hope!!) be
seeing problems with Octave any more.   If you are then=20
please send me another sample script that generates the
error.

As I previously noted, there is a separate problem with
buffered/unbuffered input streams.   Awk is not happy=20
with the unbuffered stream.  I don't know why, and I don't
know what other scripting environments might suffer from
the same problem.

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

Re: again: x11 is eating one character from stdin pipe

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

Petr Mikulik wrote:

>I'd a look to the patch of June 21 which made the break; even though I don't
>understand it, I've found that commenting out the "X11_waitforinput();" call
>does not produce the forgetting-pipe error:
>
>
>   /* Force default font at start of plot */
>#ifdef USE_MOUSE
>    /* EAM June 2003 - Flush the set font command through the pipe */
>    /* to gnuplot_x11, then wait for it to return the resulting    */
>    /* font size information (v_char and h_char).                  */
>    if (!default_font_size_known) {
>        X11_set_default_font();
>        FFLUSH();
>        X11_waitforinput();
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        default_font_size_known = TRUE;
>    }
>#else
>    X11_set_default_font();
>#endif
>    X11_set_font("");
>}
>
>
>Does that command have to be there?
>

My guess would be "yes" if the size of the font is to be correct
when used in Gnuplot formatting.

That is some strange code, however.  Does anyone know what
the basic concept is here?  Is this using a single pipe to have
traffic in both directions?  If so, I might speculate that x11.trm
is sending information through the pipe then looking to get
something back perhaps grabbing characters that it just sent
into the pipe because gplt_x11 hasn't yet pulled them out.(????)

Maybe a handshaking scheme is needed.  Perhaps x11.trm
should send a command through the pipe.  The gplt_x11
font command doesn't send stuff immediately but waits for
another special character to be sent.  On the other end,
x11.trm first sits waiting for the pipe to be completely empty.
Then it knows that gplt_x11 has received the font command
and is waiting to send something back.  x11.trm then sends
the special character.  But still that doesn't seem fool proof,
unless there is some way for x11.trm to know the pipe has
grown bigger than the one character it sent, say.  That might
be a way of knowing that what is in the pipe came from
gplt_x11 and not its own self.

Dan

-- 

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

Re: again: x11 is eating one character from stdin pipe

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

> > > With the setvbuf() in place, running the awk script causes the
> > > first 120+ plot commands to be lost in transit!!!!!!
> > >
> > > Without the setvbuf() command, only a single character is
> > > dropped - the first one following the first plot command.
> >
> > I've tried it with Octave, but there is no change with or without
> > setvbuf. Gnuplot mostly looses the first character.
>
> Last night I built Octave 2.1.50 so that I could test this
> myself. What I found is that the Octave problem and the awk
> problem are not the same.
>
> The Octave problem can, I believe, be solved with the first
> patch attached below (ipc_lock.patch).  This one causes
> X11_waitforinput() to refuse to read any more characters
> using getc(stdin) while it is waiting for a response from the
> mousing pipe.
>
> This still leaves awk losing many lines of input, which is
> fixed only if I also remove the call to setvbuf() as in the
> second patch below (setvbuf.patch).
>
> Applying these two patches makes both the awk and octave
> test scripts run on my usual desktop machine under linux.
>
> I've tested both with gnu libreadline and with the builtin
> readline. But I have not yet tested on other machines, and
> I would not like to commit either patch to CVS without more
> extensive testing.
>
> In particular I am concerned that if the response from the
> mouse pipe is lost altogether, then the first patch will cause
> gnuplot will hang.  I need to add some sort of timeout or
> upper limit of attempts to read from the mouse pipe.


I'd a look to the patch of June 21 which made the break; even though I don't
understand it, I've found that commenting out the "X11_waitforinput();" call
does not produce the forgetting-pipe error:


   /* Force default font at start of plot */
#ifdef USE_MOUSE
    /* EAM June 2003 - Flush the set font command through the pipe */
    /* to gnuplot_x11, then wait for it to return the resulting    */
    /* font size information (v_char and h_char).                  */
    if (!default_font_size_known) {
        X11_set_default_font();
        FFLUSH();
        X11_waitforinput();
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        default_font_size_known = TRUE;
    }
#else
    X11_set_default_font();
#endif
    X11_set_font("");
}


Does that command have to be there?

Petr