gnuplot development

> 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

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

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.

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

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.

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

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@...
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

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

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

> 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

> 	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

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

--- Daniel J Sebald <daniel.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,
> >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

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

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

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

| From: Ethan Merritt <merritt@...>
| To: Shigeharu TAKENO <shige@...>
| Subject: Re: tgif.trm patch for linewidth and monochrome mode
| Date: Sun, 28 Nov 2004 14:31:56 -0800
| Cc: gnuplot-beta@...
=====
| 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
 shige@...   TEL(&FAX): +81-257-22-8161
+========================================================+

>  As some of you are probably aware, I have created a fortran95 interface to
> Gnuplot. Please add the following URL :
>
>  http://gnuplotfortran.sourceforge.net/
>
>  to the Gnuplot webpage at :
>
>  http://gnuplot.sourceforge.net/links.html
>
>  under Programming Interfaces.

Done.

---
PM

On Tuesday 23 November 2004 03:46, Petr Mikulik wrote:

> >  As some of you are probably aware, I have created a fortran95 interface
> > to Gnuplot. Please add the following URL :
> >
> >  http://gnuplotfortran.sourceforge.net/
> >
> >  to the Gnuplot webpage at :
> >
> >  http://gnuplot.sourceforge.net/links.html
> >
> >  under Programming Interfaces.
>
> Done.
>

Thanks !!