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

Re: What's left for a 4.2 release? [drivers]

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

On Sunday 16 April 2006 03:13 pm, Per Persson wrote:
> >
> > Several other terminals implement colored fill patterns as differing
> > intensity.  E.g. (from emf.trm):
> >         case FS_PATTERN: /* pattern fill implemented as partial  
> > density */
> >                 fillpar *= 12;
> > 		/* Fall through to ...*/
> >         case FS_SOLID: /* solid fill */
> >                 if (fillpar >= 0 && fillpar < 100) {
> >                     double density = (double)fillpar / 100.;
> 
> That's how its done in aqua too, but for B/W patterns make sense.

Except that so far as I can tell from the code, aqua is cycling
through different colors rather than cycling the same color
through different fill intensities.  If I'm reading that
right, it means that 
	plot <foo> with boxes lt 1 fillstyle pattern 2
and
	plot <foo> with boxes lt 2 fillstyle pattern 1
produce the same output, which is a surprising result.

> > Other:	hot keys ("bind" command)
> 
> Since it seems to be tied to mousing, I've never implemented it. If  
> the actual binding is done in gnuplot core, then it would just be a  
> matter of passing key-down events to gnuplot, right?

Yes.

> > It looks like  AQUA_set_color is missing TC_LT from
> > its case statement, for example.  That is probably a trivial fix, but
> > there may be other places that bits are missing.
> 
> Like I said before, I haven't paid close attention lately and I  
> probably have missed adding upport for new features.
> Pointers to docs/examples?

Hmm. See equivalent routine in other terminals; pdf.trm seems like
a good example.  The demos "rainbow.dem" and "dashcolor.dem" should
give the code a code test.  I think what is needed is this (untested) patch

--- gnuplot/term/aquaterm.trm   2006-04-16 14:22:09.000000000 -0700
+++ gnuplot-cvs/term/aquaterm.trm       2006-04-16 15:48:10.000000000 -0700
@@ -625,17 +625,21 @@
 AQUA_set_color(t_colorspec *colorspec)
 {
   rgb_color color;
-
-  if (colorspec->type == TC_FRAC)
+
+  if (colorspec->type == TC_LT) {
+    int linetype = colorspec->lt;
+    [adapter takeColorFromColormapEntry:(linetype%CYCLIC_COLORS)+SPECIAL_COLORS];
+  } else if (colorspec->type == TC_FRAC) {
     rgb1maxcolors_from_gray(colorspec->value, &color);
-  else if (colorspec->type == TC_RGB) {
+    [adapter setColorRed:color.r green:color.g blue:color.b];
+  } else if (colorspec->type == TC_RGB) {
     color.r = (double)((colorspec->lt >> 16 ) & 255) / 255.;
     color.g = (double)((colorspec->lt >> 8 ) & 255) / 255.;
     color.b = (double)(colorspec->lt & 255) / 255.;
+    [adapter setColorRed:color.r green:color.g blue:color.b];
   } else
     return;

-  [adapter setColorRed:color.r green:color.g blue:color.b];
   AQUA_LineType = LT_UNDEFINED;
 }




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

Re: What's left for a 4.2 release? [drivers]

[Per P. <per...@ma...>]

On Apr 16, 2006, at 20:48, Ethan A Merritt wrote:

> On Sunday 16 April 2006 10:19 am, Per Persson wrote:
>>
>> I have the following (mostly finished) stuff sitting in my local  
>> copy:
>> * Monochrome (B/W) option
>>
>> * Fill patterns
>> I think that unless the plot is monochrome, filling with solid colors
>> are a better option than fill patterns, since patterns can cause
>> disturbing effects to the visual apperance ("leaning" bars etc.). So
>> my plan is to use fill patterns only in the case when the user
>> requests a B/W plot.
>
> Several other terminals implement colored fill patterns as differing
> intensity.  E.g. (from emf.trm):
>         case FS_PATTERN: /* pattern fill implemented as partial  
> density */
>                 fillpar *= 12;
> 		/* Fall through to ...*/
>         case FS_SOLID: /* solid fill */
>                 if (fillpar >= 0 && fillpar < 100) {
>                     double density = (double)fillpar / 100.;

That's how its done in aqua too, but for B/W patterns make sense.

>
>> When you say that it doesn't support all the features of the x11
>> terminal, I take it that you refer to mouse interaction?
>
> Mousing:  coord tracking, zoom, 3D interactive manipulation of view

> Other:	hot keys ("bind" command)

Since it seems to be tied to mousing, I've never implemented it. If  
the actual binding is done in gnuplot core, then it would just be a  
matter of passing key-down events to gnuplot, right?

> 	{no}persist

Default is persist, but persist/nopersist behaviour is controlled  
from within AquaTerm (preferences).
(Update after check) Hmmm, works with other backends, but gnuplot  
windows are always persistent. I'll have a look at that later.

> 	UTF-8 and other multibyte font support

UTF-8 should be trivial (famous last words...)	

>
> I'm not sure whether the full range of user-specified color options
> are supported.  It looks like  AQUA_set_color is missing TC_LT from
> its case statement, for example.  That is probably a trivial fix, but
> there may be other places that bits are missing.

Like I said before, I haven't paid close attention lately and I  
probably have missed adding upport for new features.
Pointers to docs/examples?

>
> Another minor issue is that we're trying to make the syntax for
> "set termoption", work for as many terminals as possible, particularly
> screen terminals. That requires the (term->set_font)() routines to
> accept strings of the form "fontname,fontsize".
> I can't quite work out what AQUA_set_font is doing, but it seems to
> expect an '@' rather than a comma as separator?

No, it expects "fontname,fontsize", what you see is probably the  
Objective-C syntax for a static string object, e.g. @"Hello, World!"

> 	
>> I haven't been paying close attention lately, but there was a
>> discussion on closing of paths which would be nice to be able to
>> implement. What was the outcome? Was there any change/addition to the
>> term API to support it? In that case I'll add that to aquaterm too.
>
> Yes. There is a new terminal API entry  (term->path)(int i)
> 	i = 0  means start new path
> 	i = 1  means close path
> Either or both of these may be a no-op, depending on what the
> terminal needs.  So far only the postscript and svg terminals
> actually use this mechanism, but it should probably be implemented
> for pdf and maybe others as well.

Great news. Will definitely by implemented in aqua driver (at some  
point in time).

/Per

Re: What's left for a 4.2 release? [core code]

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

On Sunday 16 April 2006 12:59 pm, Petr Mikulik wrote:
> Ethan: gnuplot crashes for "set object 1" .. can you please have a look?

  Well, I said the rectangles code was still EXPERIMENTAL :-)

(fixed in cvs)


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

Re: wxgnuplot and the screen terminal

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

> I was under the impression that 'set term push/pop' was a stack,
> but I see that I was wrong.

It is one level deep, but allows for any number of pop's.

>> I see you've added it ... I tried it ... However, this variable is undef if
>> user doesn't use GNUTERM env. variable. I think gnuplot's GNUTERM should
>> contain the name of the startup terminal then -- otherwise this variable
>> does not make any sense.
>
> OK. But then the name "GNUTERM" is slightly misleading.
> Should it rather be "DEFAULT_TERMINAL" or something like that?

STARTUP_TERMINAL?

---
PM

Re: GPGET('terminal')

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

On Sunday 16 April 2006 12:33 pm, Petr Mikulik wrote:

> a = GPGET("terminal")   =>  return "x11"
> a = GPGET("termoptions")   =>  return "enhanced noraise"
> xmin = GPGET("xmin")    =>  return min of xrange of the last plot
> ... GPGET("xmax"), "y2min", "cbmin", etc.

> Only few variables, the most important, should be availabe now -- others 
> could be added on user's request any later, without poluting the user 
> space with new var/funcs.

I'm not convinced that polluting the name space is a problem.
We could simply agree to use only variables beginning with
MOUSE_ or GPVAL_ or FIT_ or whatever, and document that users should
avoid creating private variables starting with these character strings.

Exporting a new internal variable as a user-visible one requires only
3 lines of code. Parsing for your proposed GPGET option would be more
cumbersome, I think, and would require making all exportable variables
global.

	struct udvt_entry *name = add_udv_by_name("GPVAL_XMIN");
	Ginteger(&name->udv_value, xmin);
	name->udv_undef = FALSE;
> 
> What do you think about GPGET("xmin") et al?
> Or putting the plot ranges into XMIN, XMAX, etc?

I think we should export internal values as user-visible variables
with a fixed naming scheme.  See also feature request 

	#1117724 [fit] access to resulting chisquare


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

Re: wxgnuplot and the screen terminal

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

On Sunday 16 April 2006 12:21 pm, Petr Mikulik wrote:
 
> BTW, "set term pop" for those things will fail if your "set term push"ed 
> terminal is postscript, for example.

I was under the impression that 'set term push/pop' was a stack,
but I see that I was wrong.
The truth is that I have never used this mechanism.

> > But yes, we could also copy it into a udv called GNUTERM.
> > That is so easy that I might as well just go ahead and add it :-)
> 
> I see you've added it ... I tried it ... However, this variable is undef if 
> user doesn't use GNUTERM env. variable. I think gnuplot's GNUTERM should 
> contain the name of the startup terminal then -- otherwise this variable 
> does not make any sense.

OK. But then the name "GNUTERM" is slightly misleading.
Should it rather be "DEFAULT_TERMINAL" or something like that?

By the way, saving the value of GNUTERM internally allows this
rather neat trick, where the terminal options are kept also:

[1] setenv GNUTERM "post eps solid color lw 2"
[2] gnuplot
...
gnuplot>   set term <something_else>
gnuplot>   [... do a bunch of stuff ...]
gnuplot>   set macros
gnuplot>   set term @GNUTERM
gnuplot>   show term
Terminal type set to 'postscript'
Options are 'eps noenhanced defaultplex \
   leveldefault color colortext \
   solid dashlength 1.0 linewidth 2.0 butt \
   palfuncparam 2000,0.003 \
   "Helvetica" 14 '



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

something within 'make install'

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

When I do "make install", then gnuplot is executing also this:

Creating texinfo
Loading /usr/lib/emacs/21.3/i586-suse-linux/fns-21.3.1.el (source)...
Inserting help for terminals ...
Analyzing doc file ...
Converting to texinfo ...
Menus, nodes, xrefs ...
Loading texinfo...
Making texinfo nodes ...

Updating node: Top ...
Updating node: gnuplot ...
Updating node: Copyright ...
Updating node: Introduction ...
Updating node: Seeking-assistance ...
Updating node: New_Features ...
Updating node: New_plot_styles ...
Updating node: Histogram ...
Updating node: Label_plots ...
...

Isn't this something which should have been done during normal "make"?

---
PM

Re: What's left for a 4.2 release? [core code]

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

>>> 1206823         Boxed text labels
>>
>>     Closed - nobody liked it but me :-(
>
> I don't remember this one.  Boxed text (and generally placed with possible 
> pointing arrows) sounds useful to me.

Same for me.
Can you specify space between the text and the border?
Well, as you have added "set object rectangle " ... can the rectangle size 
be specified in char units? Oh yes:

gnuplot> set object 1 rect center 0,0 size char strlen("hello world")+2,3 
gnuplot> set label 1 "hello world" at 0,0 c
gnuplot> plot x

=> so you can close this issue, and consider adding the above example into 
docs for label and for rectangle.

Ethan: gnuplot crashes for "set object 1" .. can you please have a look?

---
PM

Re: What's left for a 4.2 release? [drivers]

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

Thanks for these reports ...

>>  - Obsolete drivers (any machine that can run these has a better
>>    alternative driver). Should we remove them from the tree altogether?
>>    + openstep/next
>>    + ggi
>>    + iris4d
>
>    I propose to remove these from the cvs source tree

I agree ... I think that ggi was not used by anyone else than Johannes?

>> Bugs:
>>
>> windows:
>> #1232950        -persist option does not work in Version 4.0.0 (Windows)
>    Fixed
>> #1413021        [Wgnuplot] pause 1;reread; blocks interaction
>> #982293         can't print color in win32 gnuplot 4.0
>> #561418         (MS Windows) 100% CPU Usage during pause
>> #233405         WGNUPL32.EXE crashes when printing directly (Win 95)
>    I don't have any idea about the state of these.
>    Still bugs? Fixed?

Bastian, you are working actively on the Windows, can you please try and 
comment on these bugs, so that these reports can be closed?

>> #1305877        x11: cursor position in clipboard N/A in Qt/KDE applications
>    Fixed

I've just tried it .. yes, it seems to be fixed.

---
PM

Re: wxgnuplot and the screen terminal

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

> I would prefer to see a new entry in the term table, for term->close(),
> which could probably go along with new term->raise(), term->lower()
> instead of the way these two calls are currently implemented directly in
> command.c

I had a proposal for
 	term->interactive(command)
flying around for some longer time, but I had never time to work on it. That 
would be useful for actions like:
 	term->interactive("disable q hotkey")
 	term->interactive("make mousing menus disabled")
 	term->interactive("make mousing menus enabled")
 	term->interactive("raise 5")
 	term->interactive("close")
 	term->interactive("put ruler")
 	term->interactive("change cursor")
etc.

---
PM

GPGET('terminal')

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

It seems that are some request how to get some gnuplot internal variables 
into the user space. For example, the current x and y ranges or the current 
terminal name. Thus, the following could be helpful:

a = GPGET("terminal")   =>  return "x11"
a = GPGET("termoptions")   =>  return "enhanced noraise"
xmin = GPGET("xmin")    =>  return min of xrange of the last plot
... GPGET("xmax"), "y2min", "cbmin", etc.

Only few variables, the most important, should be availabe now -- others 
could be added on user's request any later, without poluting the user 
space with new var/funcs.

That would solve this major problem (necessary before 4.2): Do you know 
"gzoom" in Matlab/Octave? This command asks user to zoom-in the region of 
interest. However, in gnuplot, you cannot access this range by 
functions/variables -- it can only by printed to screen by "show xrange".

What do you think about GPGET("xmin") et al?
Or putting the plot ranges into XMIN, XMAX, etc?

---
PM

Re: wxgnuplot and the screen terminal

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

>>> perhaps "set term screen <num>",  where "screen" is taken from
>>> GNUTERM, and <num> is ignored for terminals that don't support multiple windows.
>
> exactly
>
>> Screen terminals should be unified so that they are capable of
>>     set terminal screen {<n>}
>>                         {title "<string>"}
>>                         {{no}enhanced}
>>                         {font <fontspec>}
>>                         {{no}persist}
>>  		       {{no}raise}
>>                         {close}
>
> I agree with this, but the mechanism is already in place:
> 	set term pop
> 	set termoption enhance font "Times,11" ...

I think it is much more logical to write
 	set term screen title "hello"
then doing those setting as
 	set term pop; set termoptions ...

BTW, "set term pop" for those things will fail if your "set term push"ed 
terminal is postscript, for example. These commands are intended for saving 
the *current* terminal e.g. before printing, not for restoring the default 
screen terminal (yes it is available as "set term pop" would be undefined 
otherwise).

Thus I propose, at the startup point of gnuplot, where the initial "set term 
pop/push" is pushed, to "link" the "screen" terminal. Would a simple strcpy 
suffice or how to associate them?

>> supports new  string function getenv('GNUTERM')?
> What do you mean "available"?
> The value of GNUTERM is stored as the terminal name on entry.
> So if you immediately do a "set term push", then you have
> saved whatever the GNUTERM default was and can recover it
> later with "set term pop".
> But yes, we could also copy it into a udv called GNUTERM.
> That is so easy that I might as well just go ahead and add it :-)

I see you've added it ... I tried it ... However, this variable is undef if 
user doesn't use GNUTERM env. variable. I think gnuplot's GNUTERM should 
contain the name of the startup terminal then -- otherwise this variable 
does not make any sense.

---
PM

Re: gnuplot-beta digest, Vol 1 #770 - 7 msgs

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

On Sunday 16 April 2006 10:19 am, Per Persson wrote:
> 
> I have the following (mostly finished) stuff sitting in my local copy:
> * Monochrome (B/W) option
> 
> * Fill patterns
> I think that unless the plot is monochrome, filling with solid colors  
> are a better option than fill patterns, since patterns can cause  
> disturbing effects to the visual apperance ("leaning" bars etc.). So  
> my plan is to use fill patterns only in the case when the user  
> requests a B/W plot.

Several other terminals implement colored fill patterns as differing
intensity.  E.g. (from emf.trm):
        case FS_PATTERN: /* pattern fill implemented as partial density */
                fillpar *= 12;
		/* Fall through to ...*/
        case FS_SOLID: /* solid fill */
                if (fillpar >= 0 && fillpar < 100) {
                    double density = (double)fillpar / 100.;

> When you say that it doesn't support all the features of the x11  
> terminal, I take it that you refer to mouse interaction?

Mousing:  coord tracking, zoom, 3D interactive manipulation of view
Other:	hot keys ("bind" command)
	{no}persist
	UTF-8 and other multibyte font support

I'm not sure whether the full range of user-specified color options
are supported.  It looks like  AQUA_set_color is missing TC_LT from
its case statement, for example.  That is probably a trivial fix, but
there may be other places that bits are missing.

Another minor issue is that we're trying to make the syntax for
"set termoption", work for as many terminals as possible, particularly
screen terminals. That requires the (term->set_font)() routines to
accept strings of the form "fontname,fontsize".
I can't quite work out what AQUA_set_font is doing, but it seems to
expect an '@' rather than a comma as separator?
	 
> I haven't been paying close attention lately, but there was a  
> discussion on closing of paths which would be nice to be able to  
> implement. What was the outcome? Was there any change/addition to the  
> term API to support it? In that case I'll add that to aquaterm too.

Yes. There is a new terminal API entry  (term->path)(int i)
	i = 0  means start new path
	i = 1  means close path
Either or both of these may be a no-op, depending on what the
terminal needs.  So far only the postscript and svg terminals
actually use this mechanism, but it should probably be implemented
for pdf and maybe others as well.

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

Re: gnuplot-beta digest, Vol 1 #770 - 7 msgs

[Per P. <per...@ma...>]

On Apr 16, 2006, at 05:06, gnu...@li...  
wrote:

>
>>    + aquaterm is already in cvs.  I have some reservations about
>>      making it a default, however, because it does not support all
>>      the features of the x11 terminal.  IMHO either the remaining
>>      features should be added, or x11 should remain the default
>>      terminal even on systems that support aqua.
>
>     No change. Per?

I have the following (mostly finished) stuff sitting in my local copy:
* Monochrome (B/W) option

* Fill patterns
I think that unless the plot is monochrome, filling with solid colors  
are a better option than fill patterns, since patterns can cause  
disturbing effects to the visual apperance ("leaning" bars etc.). So  
my plan is to use fill patterns only in the case when the user  
requests a B/W plot.

* Documentation update
The doc entry for dashed lines is missing.

I'll try to add these ASAP, but I'm short of time these days  
(unfortunately not likely to change any time soon...)

As for making X11 the default instead of AquaTerm, I don't have any  
strong feelings. In the case that AquaTerm is installed but not X11,  
aqua should definitely be the default though...
When you say that it doesn't support all the features of the x11  
terminal, I take it that you refer to mouse interaction? In the long  
run it would be a nice addition to the aqua driver, but I really  
can't set aside that much time for gnuplot for now. Shouldn't be very  
hard to implement though.

I haven't been paying close attention lately, but there was a  
discussion on closing of paths which would be nice to be able to  
implement. What was the outcome? Was there any change/addition to the  
term API to support it? In that case I'll add that to aquaterm too.

I think that sort of sums up what I have in the pipe, all minor  
changes. In case anyone running OS X should read this and feel like  
implementing mouse support for the aqua driver, I'm prepared to  
kickstart any takers and provide support.

Regards,
Per

Re: Problem accessing the CVS for checking out gnuplot 4.1

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

rajiv ranjan wrote:

> I have not been able to checkout the latest development
>  version Gnuplot 4.1 due
> to this error.

Ethan said something about SF being fixed in May.  :-(

Dan

Re: wxt terminal - questions

[Chris K <gnu...@li...>]

Ethan A Merritt wrote:
> Two questions
> 
> (1) 
> I've been poking about in the code, and so far as I can
> see the code assumes that character strings passed to Pango
> will be interpreted as UTF-8.  E.g. the following comment:
> 
>   /* pango needs a string encoded in utf-8. We use g_convert from glib.
>    * gp_cairo_get_encoding() gives the encoding set via 'set enconding'
>    * memory allocated for enhanced_text_utf8 is freed at the end of 
>    * gp_cairo_enhanced_flush */
>   string_utf8 = g_convert(string, -1, "UTF-8", gp_cairo_get_encoding(plot), NULL, NULL, NULL);
> 
> But this doesn't happen. My machines are normally set to a UTF-8 locale,
> and all characters I type into gnuplot are UTF-8 encoded.  
> But the multibyte characters are mangled when displayed in the wxt plot window.
> The same strings are properly displayed in x11 (when set to multibyte mode)
> and in gd (which by default uses UTF-8).  So I know they are correctly
> stored inside gnuplot. What's going wrong in wxt?
> 
> (2)
> I happened across a page of sample plots from another plotting program,
> and was struck by how useful transparency can be in some cases.
> In particular in the case of overlapping histograms
>    http://sourceforge.net/project/screenshots.php?group_id=15494
> I think it would be possible to support this in gd.trm and svg.trm,
> but I'm not sure about any other terminals.   Do the Cairo graphics
> primitives support an alpha channel, so that wxt.trm could use this also?
> 
> 

The filled example here
http://sourceforge.net/project/screenshots.php?group_id=15494&ssid=8404
does look good.

Yes, Cairo is very very happy with RGBA for Alpha channel transparency
information. ( http://cairographics.org/samples/operator_atop.html )

I assume the trick is : how do you specify transparency with gnuplot?

-- 
Chris
#292 http://highclearing.com/index.php/archives/2006/04/07/4991#comment-8388

Problem accessing the CVS for checking out gnuplot 4.1

[rajiv r. <rr...@cs...>]

Dear all,

I get the following error when executing the command

command :  cvs -d:pserver:ano...@cv...:/cvsroot/gnuplot login

for password prompt: Enter key

The terminal hangs on for a while , 
then prints the error -- connection timeout...

I have not been able to checkout the latest development
 version Gnuplot 4.1 due
to this error.

thanx in advance
Rajiv

wxt terminal - questions

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

Two questions

(1) 
I've been poking about in the code, and so far as I can
see the code assumes that character strings passed to Pango
will be interpreted as UTF-8.  E.g. the following comment:

  /* pango needs a string encoded in utf-8. We use g_convert from glib.
   * gp_cairo_get_encoding() gives the encoding set via 'set enconding'
   * memory allocated for enhanced_text_utf8 is freed at the end of 
   * gp_cairo_enhanced_flush */
  string_utf8 = g_convert(string, -1, "UTF-8", gp_cairo_get_encoding(plot), NULL, NULL, NULL);

But this doesn't happen. My machines are normally set to a UTF-8 locale,
and all characters I type into gnuplot are UTF-8 encoded.  
But the multibyte characters are mangled when displayed in the wxt plot window.
The same strings are properly displayed in x11 (when set to multibyte mode)
and in gd (which by default uses UTF-8).  So I know they are correctly
stored inside gnuplot. What's going wrong in wxt?

(2)
I happened across a page of sample plots from another plotting program,
and was struck by how useful transparency can be in some cases.
In particular in the case of overlapping histograms
   http://sourceforge.net/project/screenshots.php?group_id=15494
I think it would be possible to support this in gd.trm and svg.trm,
but I'm not sure about any other terminals.   Do the Cairo graphics
primitives support an alpha channel, so that wxt.trm could use this also?


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

Re: What's left for a 4.2 release? [drivers]

[V. <gae...@no...>]

On Fri, Apr 14, 2006 at 09:55:46PM -0700, Ethan A Merritt wrote:
> On Sunday 29 January 2006 08:55 pm, Ethan A Merritt wrote:
> >    + I'm glad to see there is ongoing work on an OpenGL terminal,
> >      but I don't see much chance anything will be ready for 4.2

>     No response. Let's drop this one from consideration for 4.2

    I had a look at implementing full 3D drivers back when I was
thinking of adding a povray terminal driver. Before any of these 3D
drivers can be implemented we need a full rework of the plotting code to
work in 3D until the last moment and then project.

    I have a few ideas on what needs to be done (although it has been so
long since I looked at that that I forgot most of what I had learnt) but
I am far from having enough time to do it myself. Anyhow, this a big
change that should not be considered before next release.

	Good luck with the 4.2 release, it will be much appreciated in
the labs (some features like plotting with images, or rgb colours are
really usefull).

--=20
    Ga=EBl

Re: What's left for a 4.2 release? [core code]

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

Ethan A Merritt wrote:
> On Sunday 29 January 2006 08:54 pm, Ethan A Merritt wrote:
> 
>>Here is my evaluation of the state of the code base, and the
>>collection of bugs/patches/feature-requests on SourceForge.
> 
> 
> Updated 14 Apr 2006
> 
> 
>>Core code
>>===========
>>
>>Issues:
>>
>> - How many of the new options should be enabled by default?
>>   Should any of them continue to be marked EXPERIMENTAL?
> 
> 
>   Here's my scorecard from recent discussion on the list
>   
>    rectangles and other objects		keep as EXPERIMENTAL
>    plot style image			remove warning
>    verify every pixel coordinate	back out of cvs altogether
>    general binary data file reading	mixed opinions
>    X11 polygon info in binary		remove warning
>    string variables			remove warning
>    command line macros			remoce warning
> 
> 
>> - Can we confirm that the code builds and runs on amiga?  VMS?
> 
> 
>    I successfully built recent cvs on VMS.  No word from any amiga fans.
>    I propose we drop any claims of amiga support for gnuplot
>    versions > 3.7 
>    The code can stay, but no one knows if it works.
> 
> 
>>Known bugs:
>>
>> - Clipping, particularly of arrows and filled polygons
>>   This is the only known bug that I consider release-critical.
> 
> 
>     Arrow clipping is now done in the core code.
>     Filled rectangles are also clipped in the core (mostly).
>     There are known problems with external libraries supporting 
>     specific drivers (gd, pdf) but we may not be able to fix those.    
> 
> 
>> - Treatment of "missing" data as opposed to "invalid" data.
>>   I think this is more a matter of poor documentation than an actual
>>   bug, but I could be wrong.  In any event, it's not fixable until
>>   someone can point to an unambiguous statement of what *should*
>>   happen in both cases, and a reproducible example that doesn't act
>>   that way. SF bugs #775810 #918793 #969322 #1403945
> 
> 
>     No change
>  
> 
>> - Miscellaneous open bug reports on SourceForge
> 
> 
>>   #1184989        set key below noautotitles; plot x -- crash

I can't reproduce this.  Could this be an old version the person is using and the bug fixed in the mean time?  (I think the "key" patch is from after 4.1, is it not?... 2005-07-29)

Dan

"Using gnuplot 4.1 patch level 0 under either windows
2000 or Red Hat 9, the following lines cause gnuplot to
crash,

set key below noautotitles
plot x"

Re: What's left for a 4.2 release? [core code]

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

Ethan A Merritt wrote:
> On Sunday 29 January 2006 08:54 pm, Ethan A Merritt wrote:
> 
>>Here is my evaluation of the state of the code base, and the
>>collection of bugs/patches/feature-requests on SourceForge.

>    verify every pixel coordinate	back out of cvs altogether

I've got this one.  Will have to wait until after I get back from a conference at the end of the month.

>>1206823         Boxed text labels
> 
>     Closed - nobody liked it but me :-(

I don't remember this one.  Boxed text (and generally placed with possible pointing arrows) sounds useful to me.

Dan

Re: What's left for a 4.2 release? [patches]

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

On Sunday 29 January 2006 08:59 pm, Ethan A Merritt wrote:
> 
> Here is my evaluation of the state of the code base, and the
> collection of bugs/patches/feature-requests on SourceForge.

   Updated 14 Apr 2006

> Patchsets
> =========
> 
> I'm willing to spend time to get it into 4.2
> ==================================================
> 1267434         wxWidgets terminal
    Will add to cvs when SourceForge recovers
> 1218873         Change text rotating angle from int to float
    Will add to cvs when SourceForge recovers
    (or maybe sooner, given that recovery is now projected for May)
> 908040          Break PostScript prologue file out of post.trm
    Added to cvs

> Maybe, if someone else does the work :-)
> ==================================================
> 1244775         Isolines optional on datafile splots
> 1199186         strftime and strptime
> 1077726         true depth ordering for pm3d plots
    No change

> Good idea, but not for 4.2
> ==================================================
> 1143563         Place arbitrary objects in plots
    Added to cvs as EXPERIMENTAL (Petr talked me into it)
> 1252232         Allow UTF-8 input for normal postscript Type1 fonts
> 1252215         Font kerning in postscript terminal
> 1196485         OpenGL terminal driver
> 1105717         Add '=' special file to reread '-' inline data
    No change

> I cannot judge these
> =================================================
> 1384525         Small fixes to gd terminals
    Added to cvs
> 1398474         a driver for GD.pm
> 1294507         Fitting using CERN Minuit routines
> 1248308         Rexx scripting support
> 1233137         Font control in tkcanvas
> 1289725         handling double quotes in gnuplot-mode
    No change

> Reject for now; revisit later
> =============================
> 1318546         Add 'offset' and 'backhead' to 'set arrow'
    Added "backhead" (only) to cvs

> 1364114         Extension of Ethans patch: Clipping in Postscript terminal
> 1353539         Fix clipping for plots with canvas size != 1,1
> 1329098         New clipping code
> 1328103         Fix BoundingBox for large postscript plots
> 1104264         Fix buggy clipping of arrows in large splots
    Closed - made obsolete by clipping and 'set term post size'

> 1206823         Boxed text labels
    Closed - nobody liked it but me :-(

> 1030055         add user-specified colors to emf.trm
> 1024305         pie graphs (work in progress)
> 982765          Patch for AI (Adobe Illustrator) term
    Closed - made obsolete by various features in current cvs

> 1027032         Connect gnuplot_x11 to exterior application window
    Being re-worked by Daniel

> 1356114         set term ... size <foo>,<baz>
> 1321476         Draw zeroaxis at specified positions
> 1262281         Povray terminal driver
> 1251204         Real 3d perspectivic look to splot
> 1193448         Use allterm.h for texinfo documentation
> 1185346         Autoscaling with constraint on final range.
> 1123355         Support a header file in epslatex terminal
> 1052938         Fix incorrect alignment of rotated multiline text
> 1044573         change density of generated tics
> 936695          Some new logos
> 760421          plot smooth, with set log y
> 633724          new terminals:Python/Tk and Ruby/Tk
> 632289          new dgrid3d options: scaling and range
> 588805          external functions via plugins
> 551439          plot ... index by name instead of number
    No change

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

Re: What's left for a 4.2 release? [drivers]

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

On Sunday 29 January 2006 08:55 pm, Ethan A Merritt wrote:
>=20
> Here is my evaluation of the state of the code base, and the
> collection of bugs/patches/feature-requests on SourceForge.

  Updated 14 Apr 2006

> Drivers
> =3D=3D=3D=3D=3D=3D=3D
>=20
> Summary:
> I think we made a mistake in leaving old drivers in the 4.0 release,
> and should aim for simply removing obsolete drivers in 4.2.=20
> Consider how many queries on the newsgroup=20
> turn out to be from people whose gnuplot 4.0 was built with the
> 1995-era png driver rather than with libgd.
=20
> Issues:

>    + aquaterm is already in cvs.  I have some reservations about
>      making it a default, however, because it does not support all
>      the features of the x11 terminal.  IMHO either the remaining
>      features should be added, or x11 should remain the default
>      terminal even on systems that support aqua.

    No change. Per?

>    + Timoth=C3=A9e's wxWidgets driver

    Will go into cvs when SourceForge gets their servers working,
    which is now projected at next month sometime. Yuck.

>    + I'm glad to see there is ongoing work on an OpenGL terminal,
>      but I don't see much chance anything will be ready for 4.2

    No response. Let's drop this one from consideration for 4.2

>  - Old but not obsolete drivers
>    + Windows is the 800 pound gorilla here.

    Major upgrades from Bastian Maerkisch recently added to cvs.
    No bug reports yet.

>  - Obsolete drivers (any machine that can run these has a better
>    alternative driver). Should we remove them from the tree altogether?
>    + openstep/next
>    + ggi
>    + iris4d

    I propose to remove these from the cvs source tree

    + eepic
	Another candidate for obsolescence. The most recent comment
	on SourceForge (#528909) is a 2002 suggestion from Lars that it
	be dropped or disabled.

> Other dubious drivers:
>    + svgalib
> 	I have never managed to get this one to work right, and it's
> 	a blatant security hole. But I know that some people use it
>    + ai
> 	So far as I know, "set term post level1" is sufficient to=20
> 	generate output compatible with Adobe Illustrator (ai).

    No change.

> Bugs:
>=20
> windows:
> #1232950        -persist option does not work in Version 4.0.0 (Windows)
    Fixed
> #1413021        [Wgnuplot] pause 1;reread; blocks interaction
> #982293         can't print color in win32 gnuplot 4.0
> #561418         (MS Windows) 100% CPU Usage during pause
> #233405         WGNUPL32.EXE crashes when printing directly (Win 95)
    I don't have any idea about the state of these.=20
    Still bugs? Fixed?

 > x11:
> #1376604        misleading "noraise" resource; resource list in doc
    on my TODO list
> #1305877        x11: cursor position in clipboard N/A in Qt/KDE applicati=
ons
    Fixed
> #997481         [autoconf] name transformation of gnuplot_x11
    No idea. Lars?  Hans?

> TeX:
> #1377786        kpsexpand/kpsewhich from tetex are called unconditionally
> #1367060        epslatex generates ambiguous TeX code
> #1356987        erroneous eepic output for ylabel
    I think these can be marked "won't fix". =20
> #1355374        term tkcanvas perltk broken
    This one even comes with a patch to fix it.
    Can anyone confirm that the patch works?

> other:
> #1224391        Linux console corrupt screen after switch
> #1039296        PDFlib Lite 6 output is broken for pipes, stdout
> #596701         tkcanvas perltk problem
    No change


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: What's left for a 4.2 release? [core code]

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

On Sunday 29 January 2006 08:54 pm, Ethan A Merritt wrote:
> 
> Here is my evaluation of the state of the code base, and the
> collection of bugs/patches/feature-requests on SourceForge.

Updated 14 Apr 2006

> Core code
> ===========
> 
> Issues:
> 
>  - How many of the new options should be enabled by default?
>    Should any of them continue to be marked EXPERIMENTAL?

  Here's my scorecard from recent discussion on the list
  
   rectangles and other objects		keep as EXPERIMENTAL
   plot style image			remove warning
   verify every pixel coordinate	back out of cvs altogether
   general binary data file reading	mixed opinions
   X11 polygon info in binary		remove warning
   string variables			remove warning
   command line macros			remoce warning

>  - Can we confirm that the code builds and runs on amiga?  VMS?

   I successfully built recent cvs on VMS.  No word from any amiga fans.
   I propose we drop any claims of amiga support for gnuplot
   versions > 3.7 
   The code can stay, but no one knows if it works.

> Known bugs:
> 
>  - Clipping, particularly of arrows and filled polygons
>    This is the only known bug that I consider release-critical.

    Arrow clipping is now done in the core code.
    Filled rectangles are also clipped in the core (mostly).
    There are known problems with external libraries supporting 
    specific drivers (gd, pdf) but we may not be able to fix those.    

>  - Treatment of "missing" data as opposed to "invalid" data.
>    I think this is more a matter of poor documentation than an actual
>    bug, but I could be wrong.  In any event, it's not fixable until
>    someone can point to an unambiguous statement of what *should*
>    happen in both cases, and a reproducible example that doesn't act
>    that way. SF bugs #775810 #918793 #969322 #1403945

    No change
 
>  - Miscellaneous open bug reports on SourceForge

>    #1184989        set key below noautotitles; plot x -- crash
>    #1182499        set terminal doesn't automatically close output
>    #1058117        Legend Disappears on Some Plots
>    #1024394        bug on time/data format

    These are marked as assigned to broeker
    I believe they can be closed. Can you confirm this?  

>    #1346814        cannot unset mxtics for time data

    I think this one is user error rather than a bug.
    
>    #1408955        ytics have wrong date with ydata time and "using 2"
>    #1363641        dgrid3d / xrange interaction
>    #1158281        plotting a ternary function with undefined values
>    #1107709        plot [-1:1] x is plotted with asymmetric y-axis
>    #1042785        reversed axis range breaks filled curves
>    #1039309        Strange xtics on 'time' plot
>    #1004754        Tics and grid slightly outside border.
>     #992528        `set offset` can break `with filledcurves`
>     #634506        plotting a subrange of a contour plot

    No change


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

Re: wxgnuplot and the screen terminal

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

Ethan Merritt wrote:
> On Friday 14 April 2006 03:32 pm, Daniel J Sebald wrote:
> 
>>In the case of Linux, putting the terminal code into individual 
>>driver files (object files) might be nice.
> 
> 
> But the screen terminal drivers are small, so you would not
> gain much (remember that gnuplot_x11 is a separate executable).
> 
> The big terminals are hpglxxx and postscript.
> That is why I originally wanted to pull the prolog text out
> out of post.trm.

Oh yeah, I remember that now.  Not worth it.
> 
> Figure from last year attached.

Consider putting this figure on the web page.  Maybe a "statistics" subpage or something.

Dan