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

Re: pm3d and parametric function surface plots

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

On Thursday 02 December 2004 09:27 am, Johannes Zellner wrote:
> 
> I just thought that coloring parametric surface plots according to the
> computed z-Value is not reasonable or obvious at all.

I agree. 
Then again, I have never needed to plot such a surface at all,
so maybe I am failing to imagine a reasonable use.

> It would be 
> reasonable to color it according to any function which depends on u and
> v (the parametric variables).

Yes, that sounds much more reasonable.  It gives you the same sort
of "4th dimension" that is available for plotting data from a file.
 
>     gnuplot> unset parametric
>     gnuplot> splot f(x, y), color(x, y) w pm3d
> 
> But this time, the specification is ambigous.

I don't like the use of commas at all.
Any syntax that uses commas to mean more than one thing
is intrinsically ambiguous.
By analogy to the existing syntax for data files,
I think the above should instead be

      gnuplot> splot using (x):(y):f(x,y):color(x,y) 

which it may or may not be possible to shorten to

      gnuplot> splot using f(x,y):color(x,y)

> Introducing an option which forces function plots to have a color
> function would solve the ambiguity.

To me it seems more logical to extend "using" to function plots,
and allow explicit assignment of either real or formal parameters
to the various columns.  Since the syntax "splot using ..."
is not currently valid, it will not break existing scripts.

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

pm3d and parametric function surface plots

[Johannes Z. <joh...@ze...>]

Hello,

I just thought that coloring parametric surface plots according to the
computed z-Value is not reasonable or obvious at all. It would be
reasonable to color it according to any function which depends on u and
v (the parametric variables).

Thinking about the syntax, currently parametric surface plots expect
3 functions like

    gnuplot> splot u, v, u*v

Would it make sense to allow a fourth /OPTIONAL/ function like (where
color(u, v) is any user-defined function which computes gray values):

    gnuplot> set parametric
    gnuplot> splot u, v, u*v, color(u, v) w pm3d

if pm3d is selected explicitely like above? I belive this wouldn't break
any existing scripts, would it?

On the other hand, to be consistent with non-parametric plots, one would
expect there the syntax

    gnuplot> unset parametric
    gnuplot> splot f(x, y), color(x, y) w pm3d

But this time, the specification is ambigous. It could mean:

    1) plot f(x, y) and color the surface according to color(x, y)
    2) plot f(x, y) and then plot a second surface color(x, y), which
       is colored according to it's z-Value

Introducing an option which forces function plots to have a color
function would solve the ambiguity.

Or something like

    gnuplot> set parametric
    gnuplot> splot u, v, u*v w pm3d color(u, v)

And in the non-parametric case:

    gnuplot> unset parametric
    gnuplot> splot f(x, y) w pm3d color(x, y)

What do you think about this syntax?

Feedback is welcome!

-- 
Johannes

Re: pm3d true depth ordering

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

> I just hacked true depth ordering for pm3d plots. The syntax is
>
>     set pm3d depth
>
> which overrides 'scans(backward|forward|automatic)'.
>
> This is pretty useful for parametric plots for example. You might
> want to try it with a parametric torus or the glass.dat example
> of the demo directory.
>
> The patch is attached. Should I commit this to CVS?

No to cvs, but please put it to source forge: Patches. Also, add a demo
which shows the difference.

>     set pm3d depth
Maybe "depth$ordering" ?

---
PM

pm3d true depth ordering

[Johannes Z. <joh...@ze...>]

Hello,

I just hacked true depth ordering for pm3d plots. The syntax is

    set pm3d depth

which overrides 'scans(backward|forward|automatic)'.

This is pretty useful for parametric plots for example. You might
want to try it with a parametric torus or the glass.dat example
of the demo directory.

The patch is attached. Should I commit this to CVS?

Comments are welcome.

-- 
Johannes

Re: New patch allows 2d plots to use PM3D palette colors - please test

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

> 	plot "foo" with lines lt rgb "#DDFF00"
> 	plot "bar" with lines lt rgb "goldenrod"

There could be a new built-in routine
	hsv2rgb(h,s,v)

that would do the RGB string by the given h,s,v by means of
getcolor.c:HSV_2_RGB().

Similarly,
	cmy2rgb(c,m,y)
	ciexyz2rgb()
	yiq2rgb()

Additionally, these routines could be used for testing the conversion
employed via various 'set palette' models.

---
PM

Re: New patch allows 2d plots to use PM3D palette colors - please test

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

> I've been wondering about plot background colors, too.  I often see
> plots with slightly off-white backgrounds.  There is the X11 background
> color, but nothing for controlling background color for, say, png or
> PostScript.  I know it has little to do with the "scientific" leanings
> of gnuplot.  It would require something like "set background" (whole
> area including axes and labels), "set plotground" (area only inside the
> axes).  This might then require some color such as "none" or "clear",
> which have obvious meanings in terminals like PostScript.

Yet another background is that of the graph (easy for 2D and 'view map',
more intriguing for 3D), and for the key.

What about some new syntax for that?

set key ... background rgb "gray10"
set border ... background rgb "gray10"
set size ... background rgb "cyan"

or

set style background {key | border | graph | paper} .... ?

---
PM

Re: New patch allows 2d plots to use PM3D palette colors - please test

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

> > You might wish to consider making the leading character in the colorspec
> > and 'x' to be consistent with your work on the GD-related drivers, or to
> > make the GD-drivers consistent with this work and allow either a leading
> > 'x' or the leading '#'.
>
> The color specs in the gd driver pre-date my involvement.
> I had forgotten about them, although coincidentally I looked them up
> yesterday because Dan Sebald was asking how to set the background
> color.

That syntax in for gif/png is because # denotes a comment.

An idea would be to use the strings, allowing for colornames as well:
	set terminal png "red" "green" "blue" "#123456"
or maybe with a new keyword
	set terminal png colors "red" "green" "blue" "#123456"

--
PM

Re: New patch allows 2d plots to use PM3D palette colors - please test

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

> > However, it is not flexible for using "red", "white", etc colors in splots.
> > I would prefer an approach that would itself be able to extract a
> > color matching to e.g. "red".
>
> Done. Revised patchset on SourceForge.
>
> names in gnuplot's internal table.  See "show palette colornames".
>
> 	plot "foo" with lines lt rgb "#DDFF00"
> 	plot "bar" with lines lt rgb "goldenrod"
>
> Anyway, the direct RGB request method works much better.

That's a great solution!


(*)
gnuplot> plot x w l lt pal
         2D plots cannot color by Z value; please use splot instead

It should say sth like "plot: argument for palette is always required" or
"the syntax is 'lt pal' for splot (z-coloring), or 'lt pal <color>' for
plot"


(*)
'help linestyle': please add help for the rgb


Otherwise, the patch is fine.

---
PM

Re: New patch allows 2d plots to use PM3D palette colors - please test

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

On Monday 29 November 2004 09:38 am, Mike wrote:
> 
> You might wish to consider making the leading character in the colorspec 
> and 'x' to be consistent with your work on the GD-related drivers, or to 
> make the GD-drivers consistent with this work and allow either a leading 
> 'x' or the leading '#'.

The color specs in the gd driver pre-date my involvement.
I had forgotten about them, although coincidentally I looked them up
yesterday because Dan Sebald was asking how to set the background
color.

Anyhow, I chose the #rrggbb syntax because that is how the colors
are given to  'set palette defined', and the discussion of color
names and hexadecimal representations applies perfectly to this new
case also.  So if I were to change anything, I think it would be gd.trm.

thanks for the feedback.

	Ethan

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

Re: Suggestions for info documentation

[Axel B. <axe...@ya...>]

--- Daniel J Sebald <dan...@ie...> wrote:

> Axel Boldt wrote:

> >Now in the "Plotting" node, there is the even more helpful hint that
> >everything about the axes can be configured with the set commands,
> >but
> >again there's no link to the relevant node discussing those set
> >commands. As is, this information is very hard to find.
> 
> "help set" is a rather broad category.  Would "set axes" and "set
> axis" 
> help nodes be beneficial (i.e., a list and overview of all the
> commands 
> for controling the axes--xtics, etc.)?  Or would that start leading
> to 
> confusion in the sense that seeing "axes" in the subcategory of "set"
> might make people think "axes" is a valid keyword?

I don't think a new node about axes is necessary.

Maybe something like this in the plotting node: "Many features of the
final plot (such as axes, border, title etc.) can be adjusted with the
various set commands (see help set)."

Axel


		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 

Re: Suggestions for info documentation

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

Hans-Bernhard Broeker wrote:

>>"help set" is a rather broad category.  Would "set axes" and "set axis" 
>>help nodes be beneficial (i.e., a list and overview of all the commands 
>>for controling the axes--xtics, etc.)?  Or would that start leading to 
>>confusion in the sense that seeing "axes" in the subcategory of "set" 
>>might make people think "axes" is a valid keyword?
>>    
>>
>
>It probably would, so we had better avoid doing that.  If we find we need 
>a general overview node describing all settings relevant to individual 
>axes, that node belongs to a different part of the documentation (i.e. as 
>a sub-node of 'plotting' or 'introduction', not under 
>'commands->set/show'.
>  
>

Yes, that's a more appropriate place.

Dan

Re: Suggestions for info documentation

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

On Sun, 28 Nov 2004, Daniel J Sebald wrote:
> Axel Boldt wrote:

> >Now in the "Plotting" node, there is the even more helpful hint that
> >everything about the axes can be configured with the set commands,

Well, that hint is slightly wrong --- at least one very central aspect
of the axis (how they're actually used by the plot command) is not 
controlled by any 'set' command.

> "help set" is a rather broad category.  Would "set axes" and "set axis" 
> help nodes be beneficial (i.e., a list and overview of all the commands 
> for controling the axes--xtics, etc.)?  Or would that start leading to 
> confusion in the sense that seeing "axes" in the subcategory of "set" 
> might make people think "axes" is a valid keyword?

It probably would, so we had better avoid doing that.  If we find we need 
a general overview node describing all settings relevant to individual 
axes, that node belongs to a different part of the documentation (i.e. as 
a sub-node of 'plotting' or 'introduction', not under 
'commands->set/show'.

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

Re: tgif.trm patch for linewidth and monochrome mode

[Shigeharu T. <sh...@ie...>]

shige 11/29 2004
----------------

| From: Ethan Merritt <merritt@u.washington.edu>
| To: Shigeharu TAKENO <sh...@ie...>
| Subject: Re: tgif.trm patch for linewidth and monochrome mode
| Date: Sun, 28 Nov 2004 14:31:56 -0800
| Cc: gnu...@li...
=====
| It looks OK.
| 
| But I wonder if you want to also add a terminal option,
| as in the some other terminals (post pdf svg ...), that sets
| a constant multiplier for all line widths?
| 
|         set term tgif linewidth 2.0

Thank you for your suggestion. To accepts it I widely rewrite 
TGIF_options() to some modern form. I send new unified diff file
of tgif.trm (rev. 1.28).

----- From here -----
--- term/tgif.trm.ORG	Thu Oct 28 16:12:12 2004
+++ term/tgif.trm	Mon Nov 29 19:59:42 2004
@@ -74,6 +74,9 @@
 register_term(tgif)
 #endif
 
+#define USE_LINEWIDTH
+#define USE_MONO_MODE
+
 #ifdef TERM_PROTO
 TERM_PUBLIC void TGIF_options __PROTO((void));
 TERM_PUBLIC void TGIF_init __PROTO((void));
@@ -90,6 +93,9 @@
 TERM_PUBLIC void TGIF_arrow __PROTO((unsigned int sx, unsigned int sy, unsigned int ex, unsigned int ey, int head));
 TERM_PUBLIC int TGIF_set_font __PROTO((const char *font));
 TERM_PUBLIC void TGIF_set_pointsize __PROTO((double size));
+#ifdef USE_LINEWIDTH
+TERM_PUBLIC void TGIF_set_linewidth __PROTO((double size));
+#endif
 #ifdef PM3D
 TERM_PUBLIC int TGIF_make_palette (t_sm_palette *);
 /* TERM_PUBLIC void TGIF_previous_palette (void); */
@@ -147,7 +153,7 @@
 
 static unsigned int uActNr;	/* current elementnumber                   */
 static unsigned int uActPage;	/* current pagenumber                      */
-static unsigned int uActResolution;	/* resolution in percent           */
+static unsigned int uActResolution=100;	/* resolution in percent           */
 static unsigned int uActZoom;	/* zoom factor                             */
 static unsigned int uActAngle;	/* current textangle                       */
 static unsigned int uActThick;	/* actual linethickness                    */
@@ -157,16 +163,24 @@
 static unsigned int uXshift;	/* actual shift x                          */
 static unsigned int uYshift;	/* actual shift y                          */
 static unsigned int uTgifPlotCount;	/* counts number of plots          */
-static unsigned int uTgifPlotRow, uTgifPlotCol;		/* actual plot row and col   */
-static unsigned int uTgif_win_horiz, /* number of plots in x and  */ uTgif_win_verti;	/*      y direction [x,y]         */
+static unsigned int uTgifPlotRow=1, uTgifPlotCol=1;		/* actual plot row and col   */
+static unsigned int uTgif_win_horiz=1, /* number of plots in x and  */ 
+    uTgif_win_verti=1;	/*      y direction [x,y]         */
 
 
+#ifdef USE_LINEWIDTH
+static double uActThick_factor=1.0;
+static double uActThick_default=1.0;
+#endif
+#ifdef USE_MONO_MODE
+static TBOOLEAN TgifUseColor = TRUE;
+#endif
 
 static char sActColor[TGIF_STRLEN_MAX];		/* current color         */
-static unsigned int uDefaultFontSize;	/* default font size         */
-static unsigned int uActFontSize;	/* current font size         */
-static char sDefaultFont[TGIF_STRLEN_MAX];	/* default font          */
-static char sActFont[TGIF_STRLEN_MAX];	/* current font          */
+static unsigned int uDefaultFontSize = 18;	/* default font size         */
+static unsigned int uActFontSize = 18;	/* current font size         */
+static char sDefaultFont[TGIF_STRLEN_MAX] = "Helvetica";	/* default font          */
+static char sActFont[TGIF_STRLEN_MAX] = "Helvetica";	/* current font          */
 /* static char          sActPointString[TGIF_STRLEN_MAX]; HBB: unused */
 
 static TBOOLEAN TgifSolid = FALSE;
@@ -241,6 +255,35 @@
 }				/* TGIF_flush_poly */
 /*}}}  */
 /***************************************************************************/
+
+enum TGIF_id {
+    TGIF_MONOCHROME, TGIF_COLOR,
+    TGIF_LINEWIDTH,
+    TGIF_PORTRAIT, TGIF_LANDSCAPE,
+    TGIF_GRAPHS,
+    TGIF_SOLID, TGIF_DASHED,
+    TGIF_FONT,
+    TGIF_OTHER,
+    TGIF_DEFAULT
+};
+
+static struct gen_table TGIF_opts[] =
+{
+    {"mo$nochrome", TGIF_MONOCHROME},
+    {"c$olor", TGIF_COLOR},
+    {"c$olour", TGIF_COLOR},
+    {"linew$idth", TGIF_LINEWIDTH},
+    {"lw", TGIF_LINEWIDTH},
+    {"p$ortrait", TGIF_PORTRAIT},
+    {"l$andscape", TGIF_LANDSCAPE},
+    {"[", TGIF_GRAPHS},
+    {"s$olid", TGIF_SOLID},
+    {"d$ashed", TGIF_DASHED},
+    {"font", TGIF_FONT},
+    {"default", TGIF_DEFAULT},
+    {NULL, TGIF_OTHER}
+};
+
 TERM_PUBLIC void
 TGIF_options()
 {
@@ -248,39 +291,67 @@
     struct value a, b;
     double dscaleH, dscaleV;
 
+    while (!END_OF_COMMAND) {
+	switch(lookup_table(&TGIF_opts[0],c_token)) {
+	case TGIF_DEFAULT:
+	    strcpy(sActFont, "Helvetica");
+	    strcpy(sDefaultFont, "Helvetica");
+	    uActFontSize = 18;
+	    uDefaultFontSize = 18;
+	    term->v_char = (unsigned int) (uActFontSize);
+	    term->h_char = (unsigned int) (uActFontSize * 6 / 10);
 
-    strcpy(sActFont, "Helvetica");
-    strcpy(sDefaultFont, "Helvetica");
-    uActFontSize = 18;
-    uDefaultFontSize = 18;
-    term->v_char = (unsigned int) (uActFontSize);
-    term->h_char = (unsigned int) (uActFontSize * 6 / 10);
-
-    TgifPortrait = TRUE;
-    uTgifPlotsPerPage = 1;
-    uTgifPlotRow = 1;
-    uTgifPlotCol = 1;
-    uTgif_win_horiz = 1;
-    uTgif_win_verti = 1;
-    uActResolution = 100;
-
-
-/*}}}  */
-
-    if (!END_OF_COMMAND) {
-	if (almost_equals(c_token, "p$ortrait")) {
 	    TgifPortrait = TRUE;
+#ifdef USE_MONO_MODE
+	    TgifUseColor = TRUE;
+#endif
+	    TgifSolid = FALSE;
+	    uTgifPlotsPerPage = 1;
+	    uTgifPlotRow = 1;
+	    uTgifPlotCol = 1;
+	    uTgif_win_horiz = 1;
+	    uTgif_win_verti = 1;
+	    uActResolution = 100;
+#ifdef USE_LINEWIDTH
+	    uActThick_factor = 1.0;
+	    uActThick_default = 1.0;
+#endif
+	    c_token++;
+	    break;
+#ifdef USE_MONO_MODE
+	case TGIF_MONOCHROME:
+	    TgifUseColor = FALSE;
+	    c_token++;
+	    break;
+	case TGIF_COLOR:
+	    TgifUseColor = TRUE;
 	    c_token++;
-	} else if (almost_equals(c_token, "l$andscape")) {
+	    break;
+#endif
+#ifdef USE_LINEWIDTH
+	case TGIF_LINEWIDTH:
+	    c_token++;
+	    if (END_OF_COMMAND) {
+		int_error(c_token, "linewidth: width is not specified.");
+	    } else {
+		if((uActThick_default = real(const_express(&a)))<=0.0){
+		    int_error(c_token-1,"linewidth: out of range");
+		    uActThick_default = 1.0;
+		}
+	    }
+	    break;
+#endif
+	case TGIF_PORTRAIT:
+	    TgifPortrait = TRUE;
+	    c_token++;
+	    break;
+	case TGIF_LANDSCAPE:
 	    TgifPortrait = FALSE;
-	    uActResolution = 140;
+	    /* uActResolution = 140; 
+	    */
 	    c_token++;
-	}
-    }
-/*}}}  */
-
-    if (!END_OF_COMMAND) {
-	if (equals(c_token, "[")) {	/* windows specified */
+	    break;
+	case TGIF_GRAPHS:
 	    c_token++;
 	    if (END_OF_COMMAND) {
 		int_error(c_token, "no. windows: [horizontal,vertical] expected");
@@ -296,39 +367,33 @@
 	    if (!equals(c_token, "]"))
 		int_error(c_token, "expecting ']'");
 	    c_token++;
-
 	    uTgifPlotsPerPage = uTgif_win_verti * uTgif_win_horiz;
-
-
-	}
-    }
-/*}}}  */
-
-    if (!END_OF_COMMAND) {
-	if (almost_equals(c_token, "s$olid")) {
+	    break;
+	case TGIF_SOLID:
 	    TgifSolid = TRUE;
 	    c_token++;
-	} else if (almost_equals(c_token, "d$ashed")) {
+	    break;
+	case TGIF_DASHED:
 	    TgifSolid = FALSE;
 	    c_token++;
+	    break;
+	case TGIF_FONT:
+	case TGIF_OTHER:
+	default:
+	    if (isstring(c_token)) {
+		quote_str(sActFont, c_token, MAX_LINE_LEN);
+		strcpy(sDefaultFont, sActFont);
+		c_token++;
+	    } else {
+		/* We have font size specified */
+		uActFontSize = (unsigned int) real(const_express(&b));
+		uDefaultFontSize = uActFontSize;
+		term->v_char = (unsigned int) (uActFontSize);
+		term->h_char = (unsigned int) (uActFontSize * 6 / 10);
+	    }
+	    break;
 	}
     }
-/*}}}  */
-
-    if (!END_OF_COMMAND && isstring(c_token)) {
-	quote_str(sActFont, c_token, MAX_LINE_LEN);
-	strcpy(sDefaultFont, sActFont);
-	c_token++;
-    }
-    if (!END_OF_COMMAND) {
-	/* We have font size specified */
-	uActFontSize = (unsigned int) real(const_express(&b));
-	uDefaultFontSize = uActFontSize;
-	term->v_char = (unsigned int) (uActFontSize);
-	term->h_char = (unsigned int) (uActFontSize * 6 / 10);
-    }
-/*}}}  */
-
     if (TgifPortrait) {
 	dscaleH = (double) 100.0 *(TGIF_XTOT) / (xsize * (TGIF_XMAX + (uTgif_win_horiz - 1) * TGIF_XSHIFT));
 	dscaleV = (double) 100.0 *(TGIF_YTOT) / (ysize * (TGIF_YMAX + (uTgif_win_verti - 1) * TGIF_YSHIFT));
@@ -366,11 +431,22 @@
 	}
     }
 
-/*}}}  */
-
-    sprintf(term_options, "%s [%u,%u] %s \"%s\" %u",
+    sprintf(term_options, "%s%s%s [%u,%u]",
+	    term_options, term_options[0]!='\0' ? " ":"",
 	    TgifPortrait ? "portrait" : "landscape",
-	    uTgif_win_horiz, uTgif_win_verti,
+	    uTgif_win_horiz, uTgif_win_verti);
+#ifdef USE_MONO_MODE
+    sprintf(term_options, "%s%s%s",
+	    term_options, term_options[0]!='\0' ? " ":"",
+	    TgifUseColor ? "color" : "monochrome");
+#endif
+#ifdef USE_LINEWIDTH
+    sprintf(term_options, "%s%s%s %f",
+	    term_options, term_options[0]!='\0' ? " ":"",
+	    "linewidth",uActThick_default);
+#endif
+    sprintf(term_options, "%s%s%s \"%s\" %u",
+	    term_options, term_options[0]!='\0' ? " ":"",
 	    TgifSolid ? "solid" : "dashed",
 	    sActFont, uActFontSize);
 }
@@ -461,8 +537,12 @@
     uActThick = 1;
     uActStyle = 0;
     uActJust = LEFT;
+#ifndef USE_MONO_MODE
     strcpy(sActColor, psColors[0]);
-
+#else
+    if(TgifUseColor == FALSE) strcpy(sActColor,"black");
+    else strcpy(sActColor, psColors[0]);
+#endif
 
 }				/* TGIF_graphics */
 /*}}}  */
@@ -507,8 +587,17 @@
     else
 	ult = linetype + 2;
 
+#ifndef USE_MONO_MODE
     strcpy(sActColor, psColors[ult]);
+#else
+    if(TgifUseColor == FALSE) strcpy(sActColor,"black");
+    else strcpy(sActColor, psColors[ult]);
+#endif
+#ifndef USE_LINEWIDTH
     uActThick = uLineThick[ult];
+#else
+    uActThick = uActThick_factor * uActThick_default * uLineThick[ult]+0.5;
+#endif
     if (!TgifSolid)
 	uActStyle = uLineStyle[ult];
     else {
@@ -1481,6 +1570,14 @@
     uActPointSize = size < 0. ? 1. : size;
 }
 
+#ifdef USE_LINEWIDTH
+TERM_PUBLIC void
+TGIF_set_linewidth(double size)
+{
+    uActThick_factor = size < 0. ? 1. : size;
+}
+#endif
+
 /*}}}  */
 /***************************************************************************/
 TERM_PUBLIC int
@@ -1509,6 +1606,21 @@
     TGIF_flush_poly(); /* Clean up current data */
 
     if (TGIF_palette_set == FALSE) {
+#ifdef USE_MONO_MODE
+	if (TgifUseColor == FALSE 
+	    || sm_palette.colorMode == SMPAL_COLOR_MODE_GRAY) {
+            /* Gray palette */
+	    if (TgifUseColor == FALSE 
+		&& sm_palette.colorMode == SMPAL_COLOR_MODE_RGB){
+		fprintf(stderr, "Monochrome Tgif file: ");
+		fprintf(stderr, "using gray palette instead of color\n");
+	    }
+            for (i = 0; i < sm_palette.colors; i++) {
+                int j = (int)(i * 255.0 / (sm_palette.colors-1) + 0.5);
+                sprintf(TGIF_colours[i],"#%.2x%.2x%.2x",j,j,j);
+            }
+	} else {
+#endif    
 	/* Create new palette */
 	for (i = 0; i < sm_palette.colors; i++) {
 	    sprintf(TGIF_colours[i],"#%.2x%.2x%.2x",
@@ -1516,6 +1628,9 @@
 		(int)( palette->color[i].g * 255 + 0.5 ),
 		(int)( palette->color[i].b * 255 + 0.5 ) );
 	}
+#ifdef USE_MONO_MODE
+	}
+#endif
 	TGIF_palette_set = TRUE;
     } else {
 	fprintf(stderr, "Attempt to set palette twice\n");
@@ -1578,7 +1693,11 @@
     TGIF_text, null_scale, TGIF_graphics, TGIF_move, TGIF_vector,
     TGIF_linetype, TGIF_put_text, TGIF_text_angle,
     TGIF_justify_text, TGIF_point, TGIF_arrow, TGIF_set_font,
+#ifndef USE_LINEWIDTH
     TGIF_set_pointsize, TERM_CAN_MULTIPLOT, 0, 0, 0, 0
+#else
+    TGIF_set_pointsize, TERM_CAN_MULTIPLOT, 0, 0, 0, TGIF_set_linewidth
+#endif
 #ifdef USE_MOUSE
     ,0, 0, 0, 0, 0 /* no mouse support for the tgif terminal */
 #endif
@@ -1611,14 +1730,18 @@
 " axes are not changed.",
 "",
 " Syntax:",
-"       set terminal tgif {portrait | landscape} {<[x,y]>}",
+"       set terminal tgif {portrait | landscape | default} {<[x,y]>}",
+"                         {monochrome | color}",
+"                         {{linewidth | lw} <LW>}",
 "                         {solid | dashed}",
 "                         {\"<fontname>\"} {<fontsize>}",
 "",
 " where <[x,y]> specifies the number of graphs in the x and y directions on the",
-" page, \"<fontname>\" is the name of a valid PostScript font, and <fontsize>",
-" specifies the size of the PostScript font.  Defaults are `portrait`, `[1,1]`,",
-" `dashed`, `\"Helvetica\"`, and `18`.",
+" page, `color` enables color, `linewidth` scales all linewidths by <LW>,",
+" \"<fontname>\" is the name of a valid PostScript font, and <fontsize>",
+" specifies the size of the PostScript font.",
+" `defaults` sets all options to their defaults: `portrait`, `[1,1]`, `color`,",
+" `linwidth 1.0`, `dashed`, `\"Helvetica\"`, and `18`.",
 "",
 " The `solid` option is usually prefered if lines are colored, as they often",
 " are in the editor.  Hardcopy will be black-and-white, so `dashed` should be",
----- To here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: background colors

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

Ethan Merritt wrote:

>On Sunday 28 November 2004 08:02 pm, Daniel Sebald wrote:
>  
>
>>I've been wondering about plot background colors, too.  I often see
>>plots with slightly off-white backgrounds.  There is the X11 background
>>color, but nothing for controlling background color for, say, png 
>>    
>>
>
>You have not been looking very hard.  Here is part of the output 
>from 'help set term png'
>
> set term png ...  {<color0> <color1> <color2> ...}
> ...
> The background color is set first, then the border colors, then
> the X & Y axis colors, then the plotting colors.
>  
>

OK.  This works, thanks.  I experimented with the first couple colors.  
A keyword level solution with demo would be nicer to work with, I 
think.  However, that might be a bit too much work given lack of 
consistency across terminals... and the fact that 2D/3D plotting and 
layout are slightly different.  (I still think combining 2D/3D as much 
as possible would be a worthwhile step sooner than later... In 
January/February I will propose removing the BINARY_DATA_FILE switch to 
make plot.c and plot3d.c more similar.)

Dan

background colors

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

On Sunday 28 November 2004 08:02 pm, Daniel Sebald wrote:
> I've been wondering about plot background colors, too.  I often see
> plots with slightly off-white backgrounds.  There is the X11 background
> color, but nothing for controlling background color for, say, png 

You have not been looking very hard.  Here is part of the output 
from 'help set term png'

 set term png ...  {<color0> <color1> <color2> ...}
 ...
 The background color is set first, then the border colors, then
 the X & Y axis colors, then the plotting colors.

> or PostScript.  

The PostScript output has no background color. It is intended to print on
whatever piece of paper you like, including a colored piece of paper.
Same thing if you import it into an electronic document - it gets the
background of whatever style sheet you import it into.

If you really need a solid background in a stand-along PostScript file
for some reason, it's a 1 or 2 line edit:

1) Find the line at the top of the file that says something like
    %%BoundingBox: 50 50 554 770

2) Find the line that says
    %%EndProlog

3) Just before the EndProlog line, add a command to fill the bounding box
with a color of your choice:
    1 .4 1 setrgbcolor newpath
    50 50 moveto 50 770 lineto 554 770 lineto 554 50 lineto closepath fill

Now your plot has a nice purple background.

> Just a thought.

I don't think it makes much sense, except maybe for bitmap output modes
that do not support transparency.  For all other output formats, the
background is controlled by the document/webpage/paper/etc that the
plot is imported into.

Re: New patch allows 2d plots to use PM3D palette colors - please test

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

Petr Mikulik wrote:

>>I have just uploaded to SourceForge a new patchset #1072284 that allows all
>>plot elements, 2D or 3D, to use PM3D palette coloring options.
>>Please have a look at it.
>>
>>Output from a demo script is here:
>>    http://www.bmsc.washington.edu/people/merritt/gnuplot/demo/palette_2D.html
>>    
>>
>
>That's nice!
>  
>

That does look rather slick.

I've been wondering about plot background colors, too.  I often see 
plots with slightly off-white backgrounds.  There is the X11 background 
color, but nothing for controlling background color for, say, png or 
PostScript.  I know it has little to do with the "scientific" leanings 
of gnuplot.  It would require something like "set background" (whole 
area including axes and labels), "set plotground" (area only inside the 
axes).  This might then require some color such as "none" or "clear", 
which have obvious meanings in terminals like PostScript.

Just a thought.

Dan

Re: Suggestions for info documentation

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

Axel Boldt wrote:

>Hi,
>
>the info/html documentation gives the helpful hint that new users
>should start with reading about 'plotting', however the term "plotting"
>is not a link, so it's unclear what the new user is supposed to read.
>
>Now in the "Plotting" node, there is the even more helpful hint that
>everything about the axes can be configured with the set commands, but
>again there's no link to the relevant node discussing those set
>commands. As is, this information is very hard to find.
>  
>

"help set" is a rather broad category.  Would "set axes" and "set axis" 
help nodes be beneficial (i.e., a list and overview of all the commands 
for controling the axes--xtics, etc.)?  Or would that start leading to 
confusion in the sense that seeing "axes" in the subcategory of "set" 
might make people think "axes" is a valid keyword?

Dan

Re: New patch allows 2d plots to use PM3D palette colors - please test

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

On Thursday 25 November 2004 12:30 am, Petr Mikulik wrote:
>
> However, it is not flexible for using "red", "white", etc colors in splots.
> I would prefer an approach that would itself be able to extract a
> color matching to e.g. "red".

Done. Revised patchset on SourceForge.

I have added a suboption keyword "rgbcolor" (shorthand "rgb") to the
linetype specifier.  It accepts a string parameter which is either a
hexadecimal RGB triple in the form "#RRGGBB" or  one of the color
names in gnuplot's internal table.  See "show palette colornames".

	plot "foo" with lines lt rgb "#DDFF00"
	plot "bar" with lines lt rgb "goldenrod"

It is up to the individual drivers how to provide these colors, and of
course it only works for terminal types that support RGB color.

> If you look to show.c:show_palette_fit2rgbformulae(), there is a method to
> calculate distance between given (rgb) color and any other color.

I tried that first, but it turns out not to work very well.  The problem is 
that it only knows about colors in the current palette, and most "pure"
colors do not appear in the palette at all.  So for example, the default
palette has no greens.  Requesting anything green or greenish by this
mechanism returns black.  It is of course possible to define a palette
that contains a comprehensive sampling of colors, but then you are 
right back to the problem that the color selection method only works
with certain specific palettes.

Anyway, the direct RGB request method works much better.
Have a look.

Re: tgif.trm patch for linewidth and monochrome mode

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

On Saturday 27 November 2004 12:52 am, Shigeharu TAKENO wrote:
>
> I tested the following simple patch for linewidth and monochrome
> mode for term/tgif.trm (rev. 1.28). It seems to work fine.

It looks OK.

But I wonder if you want to also add a terminal option,
as in the some other terminals (post pdf svg ...), that sets
a constant multiplier for all line widths?

	set term tgif linewidth 2.0

tgif.trm patch for linewidth and monochrome mode

[Shigeharu T. <sh...@ie...>]

shige 11/27 2004
----------------

I tested the following simple patch for linewidth and monochrome
mode for term/tgif.trm (rev. 1.28). It seems to work fine.

----- From here -----
*** term/tgif.trm.ORG	Thu Oct 28 16:12:12 2004
--- term/tgif.trm	Sat Nov 27 17:49:55 2004
***************
*** 74,79 ****
--- 74,82 ----
  register_term(tgif)
  #endif
  
+ #define USE_LINEWIDTH
+ #define USE_MONO_MODE
+ 
  #ifdef TERM_PROTO
  TERM_PUBLIC void TGIF_options __PROTO((void));
  TERM_PUBLIC void TGIF_init __PROTO((void));
***************
*** 90,95 ****
--- 93,101 ----
  TERM_PUBLIC void TGIF_arrow __PROTO((unsigned int sx, unsigned int sy, unsigned int ex, unsigned int ey, int head));
  TERM_PUBLIC int TGIF_set_font __PROTO((const char *font));
  TERM_PUBLIC void TGIF_set_pointsize __PROTO((double size));
+ #ifdef USE_LINEWIDTH
+ TERM_PUBLIC void TGIF_set_linewidth __PROTO((double size));
+ #endif
  #ifdef PM3D
  TERM_PUBLIC int TGIF_make_palette (t_sm_palette *);
  /* TERM_PUBLIC void TGIF_previous_palette (void); */
***************
*** 161,166 ****
--- 167,178 ----
  static unsigned int uTgif_win_horiz, /* number of plots in x and  */ uTgif_win_verti;	/*      y direction [x,y]         */
  
  
+ #ifdef USE_LINEWIDTH
+ static double uActThick_factor;
+ #endif
+ #ifdef USE_MONO_MODE
+ static TBOOLEAN TgifUseColor = TRUE;
+ #endif
  
  static char sActColor[TGIF_STRLEN_MAX];		/* current color         */
  static unsigned int uDefaultFontSize;	/* default font size         */
***************
*** 267,272 ****
--- 279,297 ----
  
  /*}}}  */
  
+ #ifdef USE_MONO_MODE
+     if (!END_OF_COMMAND) {
+ 	if (almost_equals(c_token, "m$onochrome")) {
+ 	    TgifUseColor = FALSE;
+ 	    c_token++;
+ 	} else if (almost_equals(c_token, "c$olor") 
+ 		   || almost_equals(c_token, "c$olour") ) {
+ 	    TgifUseColor = TRUE;
+ 	    c_token++;
+ 	}
+     }
+ #endif
+ 
      if (!END_OF_COMMAND) {
  	if (almost_equals(c_token, "p$ortrait")) {
  	    TgifPortrait = TRUE;
***************
*** 368,374 ****
--- 393,404 ----
  
  /*}}}  */
  
+ #ifndef USE_MONO_MODE
      sprintf(term_options, "%s [%u,%u] %s \"%s\" %u",
+ #else
+     sprintf(term_options, "%s %s [%u,%u] %s \"%s\" %u",
+ 	    TgifUseColor ? "color" : "monochrome",
+ #endif
  	    TgifPortrait ? "portrait" : "landscape",
  	    uTgif_win_horiz, uTgif_win_verti,
  	    TgifSolid ? "solid" : "dashed",
***************
*** 461,467 ****
--- 491,505 ----
      uActThick = 1;
      uActStyle = 0;
      uActJust = LEFT;
+ #ifndef USE_MONO_MODE
      strcpy(sActColor, psColors[0]);
+ #else
+     if(TgifUseColor == FALSE) strcpy(sActColor,"black");
+     else strcpy(sActColor, psColors[0]);
+ #endif
+ #ifdef USE_LINEWIDTH
+     uActThick_factor = 1.0;
+ #endif
  
  
  }				/* TGIF_graphics */
***************
*** 507,514 ****
--- 545,561 ----
      else
  	ult = linetype + 2;
  
+ #ifndef USE_MONO_MODE
      strcpy(sActColor, psColors[ult]);
+ #else
+     if(TgifUseColor == FALSE) strcpy(sActColor,"black");
+     else strcpy(sActColor, psColors[ult]);
+ #endif
+ #ifndef USE_LINEWIDTH
      uActThick = uLineThick[ult];
+ #else
+     uActThick = uActThick_factor * uLineThick[ult]+0.5;
+ #endif
      if (!TgifSolid)
  	uActStyle = uLineStyle[ult];
      else {
***************
*** 1481,1486 ****
--- 1528,1541 ----
      uActPointSize = size < 0. ? 1. : size;
  }
  
+ #ifdef USE_LINEWIDTH
+ TERM_PUBLIC void
+ TGIF_set_linewidth(double size)
+ {
+     uActThick_factor = size < 0. ? 1. : size;
+ }
+ #endif
+ 
  /*}}}  */
  /***************************************************************************/
  TERM_PUBLIC int
***************
*** 1509,1514 ****
--- 1564,1584 ----
      TGIF_flush_poly(); /* Clean up current data */
  
      if (TGIF_palette_set == FALSE) {
+ #ifdef USE_MONO_MODE
+ 	if (TgifUseColor == FALSE 
+ 	    || sm_palette.colorMode == SMPAL_COLOR_MODE_GRAY) {
+             /* Gray palette */
+ 	    if (TgifUseColor == FALSE 
+ 		&& sm_palette.colorMode == SMPAL_COLOR_MODE_RGB){
+ 		fprintf(stderr, "Monochrome Tgif file: ");
+ 		fprintf(stderr, "using gray palette instead of color\n");
+ 	    }
+             for (i = 0; i < sm_palette.colors; i++) {
+                 int j = (int)(i * 255.0 / (sm_palette.colors-1) + 0.5);
+                 sprintf(TGIF_colours[i],"#%.2x%.2x%.2x",j,j,j);
+             }
+ 	} else {
+ #endif    
  	/* Create new palette */
  	for (i = 0; i < sm_palette.colors; i++) {
  	    sprintf(TGIF_colours[i],"#%.2x%.2x%.2x",
***************
*** 1516,1521 ****
--- 1586,1594 ----
  		(int)( palette->color[i].g * 255 + 0.5 ),
  		(int)( palette->color[i].b * 255 + 0.5 ) );
  	}
+ #ifdef USE_MONO_MODE
+ 	}
+ #endif
  	TGIF_palette_set = TRUE;
      } else {
  	fprintf(stderr, "Attempt to set palette twice\n");
***************
*** 1578,1584 ****
--- 1651,1661 ----
      TGIF_text, null_scale, TGIF_graphics, TGIF_move, TGIF_vector,
      TGIF_linetype, TGIF_put_text, TGIF_text_angle,
      TGIF_justify_text, TGIF_point, TGIF_arrow, TGIF_set_font,
+ #ifndef USE_LINEWIDTH
      TGIF_set_pointsize, TERM_CAN_MULTIPLOT, 0, 0, 0, 0
+ #else
+     TGIF_set_pointsize, TERM_CAN_MULTIPLOT, 0, 0, 0, TGIF_set_linewidth
+ #endif
  #ifdef USE_MOUSE
      ,0, 0, 0, 0, 0 /* no mouse support for the tgif terminal */
  #endif
----- To here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: New patch allows 2d plots to use PM3D palette colors - please test

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

On Thursday 25 November 2004 12:30 am, Petr Mikulik wrote:
> > I have just uploaded to SourceForge a new patchset #1072284 that allows
> > all plot elements, 2D or 3D, to use PM3D palette coloring options.
>
> Isn't there white and black missing in the color wheel?

The color wheel in the demo is a standard HSV colorwheel with
Saturation and Value both set to 1.  That is, it maps the fractional
gray value onto a fully saturated Hue.  White would correspond to
S=0; Black would correspond to V=0.  These are not in the wheel,
but you don't need a color wheel to specify black or white
(actually foreground/background) since these are already available
as lt -1 and lt -2.

> However, it is not flexible for using "red", "white", etc colors in splots.
> I would prefer an approach that would itself be able to extract a
> color matching to e.g. "red".

The colorwheel demo shows one possible use of this feature for
2D plots.  I agree that the use of a specific color wheel is not compatible
with 3D plots that require a different palette function.  

> If you look to show.c:show_palette_fit2rgbformulae(), there is a method to
> calculate distance between given (rgb) color and any other color.
>    MyLightRed = getcolor(0.9,0.01,0.01)
>

That's a good idea. It would still be a problem that if you change
the palette, any existing *constant* color assignments would become
invalid.  In order to make such definitions independent of the
current palette, they would have to themselves be functions that
are evaluated at plot time.   So I think it would have to be:
    MyLightRed() = sprintf("%3.1f",getcolor(0.9,0.01,0.01))
    plot sin(x) lt palette frac MyLightRed()

(yes, I know it is not currently possible to define a function with
no arguments)

or maybe
    MyLightRed = 'lt palette frac sprintf("%3.1f",getcolor(.9,.1,.1))'
    plot sin(x) @MyLightRed

We could leave this choice up to the user, however. Both become
possible if we introduce a user-callable function getcolor(r,g,b).

> > PM3D palette
>
> I would rather call it "palette of smooth continuous colors" or like that,

OK. 
The required configuration option is ./configure --enable-pm3d,
and the documentation uses this term in many places.  I agree that it
would be better to distinguish between the palette to choose specific
colors and the use of a palette to map colors onto 3D surfaces (=pm3d).

Re: New patch allows 2d plots to use PM3D palette colors - please test

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

> I have just uploaded to SourceForge a new patchset #1072284 that allows all
> plot elements, 2D or 3D, to use PM3D palette coloring options.
> Please have a look at it.
>
> Output from a demo script is here:
>     http://www.bmsc.washington.edu/people/merritt/gnuplot/demo/palette_2D.html

That's nice!

Isn't there white and black missing in the color wheel?


However, it is not flexible for using "red", "white", etc colors in splots.
I would prefer an approach that would itself be able to extract a
color matching to e.g. "red".
If you look to show.c:show_palette_fit2rgbformulae(), there is a method to
calculate distance between given (rgb) color and any other color. File
tables.c contains color names and their RGBs. Thus user's

	plot sin(x) with line Red lw 2

where Red would be
   Red = getcolor("red")

or, for any rgb,
   MyLightRed = getcolor(0.9,0.01,0.01)

would search through the current palette and find the corresponding
"pal frac". Thus this could would work on all color tables, giving more or
less same results.

I have no clear idea what from the above should be constant, macro,
function.

Those palette having infinite number of colors would be sampled to e.g. 256
discrete colors during the search.


> 2) The "save" and "show" commands do not funnel printout of linetype
> properties through a shared routine. This means that there is no single place

save would work with the above method


> PM3D palette

I would rather call it "palette of smooth continuous colors" or like that,
as in 'help palette'

---
PM

Suggestions for info documentation

[Axel B. <axe...@ya...>]

Hi,

the info/html documentation gives the helpful hint that new users
should start with reading about 'plotting', however the term "plotting"
is not a link, so it's unclear what the new user is supposed to read.

Now in the "Plotting" node, there is the even more helpful hint that
everything about the axes can be configured with the set commands, but
again there's no link to the relevant node discussing those set
commands. As is, this information is very hard to find.

There is some broken HTML in the nodes "Seeking Assistance",
"Start-up", "Time/Date data", "Save", "Style", "set style arrow" etc.
It's always of the type ^ <a name="arrowtype"></a>

Best regards,
  Axel


	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

Gpcard.pdf: no paper size, right margin missing

[Axel B. <axe...@ya...>]

Hi,

I downloaded the reference card http://www.gnuplot.info/docs/gpcard.pdf
and tried to view it with xpdf version 3.00, gv version 3.5.8 and Adobe
acrobat reader 4.0. Neither program shows the right margin of the
reference card: in the Graphics Devices column, only the "s" of the
"set terminal" command is shown. Xpdf complains with 
  Error: No paper information available - using defaults

Cheers,
  Axel


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 

New patch allows 2d plots to use PM3D palette colors - please test

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

I have just uploaded to SourceForge a new patchset #1072284 that allows all 
plot elements, 2D or 3D, to use PM3D palette coloring options.  
Please have a look at it.

Output from a demo script is here:
    http://www.bmsc.washington.edu/people/merritt/gnuplot/demo/palette_2D.html

The code is very simple.  The generic linetype structure now contains a 
t_colorspec substructure.  This is parsed inside lp_parse() and applied 
inside term_apply_lp_properties().  These two chunks of code thus handle all 
plot elements that have an associated linetype.

Benefits:
1) plot elements can be assigned to have arbitrary colors (a frequent request)
2) these colors are terminal-independent (another frequent request)

What's still missing:
1) Pattern fill behavior is terminal-dependent. This is fixable, but probably 
not a high priority.
2) The "save" and "show" commands do not funnel printout of linetype
properties through a shared routine. This means that there is no single place 
I can change to correctly report the palette properties of all plot elements. 
This is only a problem if you want to save your session for later reloading. 
For now the work-around is to define and use explicit linestyles.
3) ???  Tell me if you find something else I missed.