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

Re: Tango color names

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

On Thursday 14 August 2008 13:24:37 Petr Mikulik wrote:
> > > There a patch "Tango color palette support" which adds the following "Tango 
> > > colornames" into the list of color names in gnuplot:
> > >
> > > The patch is here:
> > > 	https://bugzilla.redhat.com/show_bug.cgi?id=458525
> > > 
> > > Does it make sense to add more color names (see "show palette colornames")?
> > 
> > Rather than adding specifically this small set (or any other small set)
> > of color names, I think it would make more sense to add a general mechanism.
> > 
> > For example, all x11-based systems should have a file equivalent to
> > /usr/share/X11/rgb.txt, which contains entries of the form:
> >   250 235 215             antique white
> >   250 235 215             AntiqueWhite
> >   255 239 213             papaya whip
> >   255 239 213             PapayaWhip
> >   255 235 205             blanched almond
> > We could add a check for an environmental variable GNUPLOT_COLORNAMES,
> > default it to /usr/share/X11/rgb.txt, and write a corresponding parser routine.
> > Local customization is easy; just point GNUPLOT_COLORNAMES to a customized
> > file.
> 
> I think this would be handy as well:
> 
> 	set palette colornames add "white" "#FFFFFF"
> 	set palette colornames add "white" "#FFFFFF" "black" "#FFFFFF"
> 	set palette colornames from "/usr/share/X11/rgb.txt"
> 
> It would overwrite and add new colours into the currently defined list of 
> colours.

I've just noticed that internal lists are kept in two places, which is
just asking for conflicts.

src/bitmap.c 
struct rgb web_color_rgbs[] =
{
    { 0xff, 0xff, 0xff },               /* background: white         */
    { 0x00, 0x00, 0x00 },               /*    borders: black         */
    ...  99 names total

src/tables.c
/* fixed RGB color names for 'set palette defined' */
const struct gen_table pm3d_color_names_tbl[] =
{
    /* black, white and gray/grey */
    { "white"           , 255*(1<<16) + 255*(1<<8) + 255 },
    { "black"           ,   0*(1<<16) +   0*(1<<8) +   0 },
    ...  81 names total


The first step should somehow consolidate these into a single list,
which could then be made extensible.


-- 
Ethan A Merritt

Re: Tango color names

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

> > There a patch "Tango color palette support" which adds the following "Tango 
> > colornames" into the list of color names in gnuplot:
> >
> > The patch is here:
> > 	https://bugzilla.redhat.com/show_bug.cgi?id=458525
> > 
> > Does it make sense to add more color names (see "show palette colornames")?
> 
> Rather than adding specifically this small set (or any other small set)
> of color names, I think it would make more sense to add a general mechanism.
> 
> For example, all x11-based systems should have a file equivalent to
> /usr/share/X11/rgb.txt, which contains entries of the form:
>   250 235 215             antique white
>   250 235 215             AntiqueWhite
>   255 239 213             papaya whip
>   255 239 213             PapayaWhip
>   255 235 205             blanched almond
> We could add a check for an environmental variable GNUPLOT_COLORNAMES,
> default it to /usr/share/X11/rgb.txt, and write a corresponding parser routine.
> Local customization is easy; just point GNUPLOT_COLORNAMES to a customized
> file.

I think this would be handy as well:

	set palette colornames add "white" "#FFFFFF"
	set palette colornames add "white" "#FFFFFF" "black" "#FFFFFF"
	set palette colornames from "/usr/share/X11/rgb.txt"

It would overwrite and add new colours into the currently defined list of 
colours.

---
PM

Re: Tango color names

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

On Thursday 14 August 2008 07:09:05 Petr Mikulik wrote:
> There a patch "Tango color palette support" which adds the following "Tango 
> colornames" into the list of color names in gnuplot:
> 
> tango-butter-1 ... tango-butter-3
> tango-chameleon-1 ... tango-chameleon-3
> tango-orange-1 ...
> tango-sky-blue-1 ... 
> tango-sky-plum-1 ... 
> tango-chocolate-1 ... 3
> tango-scarlet-red-1 ... 3
> tango-aluminium-1 ... 6
> 
> The patch is here:
> 	https://bugzilla.redhat.com/show_bug.cgi?id=458525
> 
> Does it make sense to add more color names (see "show palette colornames")?

Rather than adding specifically this small set (or any other small set)
of color names, I think it would make more sense to add a general mechanism.

For example, all x11-based systems should have a file equivalent to
/usr/share/X11/rgb.txt, which contains entries of the form:
  250 235 215             antique white
  250 235 215             AntiqueWhite
  255 239 213             papaya whip
  255 239 213             PapayaWhip
  255 235 205             blanched almond
We could add a check for an environmental variable GNUPLOT_COLORNAMES,
default it to /usr/share/X11/rgb.txt, and write a corresponding parser routine.
Local customization is easy; just point GNUPLOT_COLORNAMES to a customized
file.


With specific regard to the Tango color scheme, I think the patch kind of misses
the point.  Tango is designed as a scheme for desktop icons and widgets.
At least under KDE you can set this at the level of the desktop manager, and
applications like gnuplot will inherit them.  I suspect other desktop systems
behave similarly.  If I pick the Tango scheme on my desktop, I get those
colors for foreground/background/icons/etc on my gnuplot x11 windows already.

Another point:  this is exactly the sort of customized user preference that
motivated patchset   #2004590    "mechanism to redefine base linetypes"
The user can select from the Tango colors (there really are not very many of
them) to set the default sequence of linetypes in ~/.gnuplot


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

Tango color names

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

There a patch "Tango color palette support" which adds the following "Tango 
colornames" into the list of color names in gnuplot:

tango-butter-1 ... tango-butter-3
tango-chameleon-1 ... tango-chameleon-3
tango-orange-1 ...
tango-sky-blue-1 ... 
tango-sky-plum-1 ... 
tango-chocolate-1 ... 3
tango-scarlet-red-1 ... 3
tango-aluminium-1 ... 6

The patch is here:
	https://bugzilla.redhat.com/show_bug.cgi?id=458525

Does it make sense to add more color names (see "show palette colornames")?

---
PM

Meeting in Osaka

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

Congress of the International Union of Crystallography takes place in Osaka 
(Japan) from August 23-31, see www.iucr2008.jp . Since some of the gnuplot 
developers and users work/worked in the field of crystallography and 
diffraction physics, there is a chance they will participate there. At least 
Ethan Merritt and me are going there. Some other people could be nearby as 
well.

The idea is to meet, go for lunch/dinner, etc.

There will be a Czech kiosk in the 1st floor of the congress centrum because 
it's a candidate for congress in 2014. Please let us know you are interested 
to meet by e-mail or by a message let in the kiosk.

See you,
  Petr

Re: core dump for lack data of xticlabels()

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

shige 08/01 2008
----------------

Ethan A Merritt <merritt@u.washington.edu> wrote:
| > Rather than storing a NULL label and having to test for NULL every time
| > the list of labels is scanned, I think it would be better not to store a
| > NULL label at all.
| 
| Now I see there is a difference in the two fixes.  
| One way writes a tic mark even if there is no label;
| the other way writes neither a tic mark nor a label.
| 
| Normally I'd say that the user could catch the missing label and replace
| it with "" if they wanted a tic mark. But unfortunately you can't trap the 
| missing tic label from the command line.
| 
| gnuplot> plot 'xtic.dat' using 1:2:xtic(strcol(3)?strcol(3):"")
|          non-integer passed to boolean operator
| 
| various other attempts at this cause various other error messages.
| 
| So it seems we have to choose either no tic, or a tic but no label.
| I don't know which is likely to please more users.

I think your solution that the tic mark is also vanished is 
better.

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

Re: core dump for lack data of xticlabels()

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

On Thursday 31 July 2008, Ethan A Merritt wrote:
> On Thursday 31 July 2008, Shigeharu TAKENO wrote:
> > shige 08/01 2008
> > ----------------
> > 
> > The gnuplot of current CVS version may make core dump by the 
> > following script which includes the lack data of xticlabels(), 
> > but gnuplot-4.2.3 may not:
> > 
> >  plot '-' using 1:2:xtic(3) w l
> >  1 2 tic1
> >  2 3 tic2
> >  3 6 
> >  4 4 tic4
> >  5 5 tic5
> >  e
> 
> Thank you for the bug report.
> 
> Rather than storing a NULL label and having to test for NULL every time
> the list of labels is scanned, I think it would be better not to store a
> NULL label at all.

Now I see there is a difference in the two fixes.  
One way writes a tic mark even if there is no label;
the other way writes neither a tic mark nor a label.

Normally I'd say that the user could catch the missing label and replace
it with "" if they wanted a tic mark. But unfortunately you can't trap the 
missing tic label from the command line.

gnuplot> plot 'xtic.dat' using 1:2:xtic(strcol(3)?strcol(3):"")
         non-integer passed to boolean operator

various other attempts at this cause various other error messages.

So it seems we have to choose either no tic, or a tic but no label.
I don't know which is likely to please more users.

[or I suppose we could teach the boolean operators that a NULL string
 is to be treated as FALSE].

	Ethan

> Something like this (not tested thorougly, but seems foolproof):
> 
> --- ../../gnuplot/src/axis.c	2008-06-05 21:15:58.000000000 -0700
> +++ ./axis.c	2008-07-31 21:39:09.000000000 -0700
> @@ -1618,6 +1618,9 @@ add_tic_user(AXIS_INDEX axis, char *label
>      struct ticmark *tic, *newtic;
>      struct ticmark listhead;
>  
> +    if (!label)
> +	return;
> +
>      /* Mark this axis as user-generated ticmarks only, unless the */
>      /* mix flag indicates that both user- and auto- tics are OK.  */
>      if (!axis_array[axis].ticdef.def.mix)
> 
> 
> 
> 
> >  OS: Solaris 9 (sparc)
> >  compiler: gcc-3.4.3 
> > 
> > The following patch seems to fix it.
> > 
> > ----- From here -----
> > --- axis.c.ORG	Fri Aug  1 12:20:48 2008
> > +++ axis.c	Fri Aug  1 13:03:09 2008
> > @@ -872,8 +872,12 @@
> >  	    if (!inrange(internal, internal_min, internal_max))
> >  		continue;
> >  
> > -	    if (mark->level < 0) /* label read from data file */
> > -		strncpy(label, mark->label, sizeof(label));
> > +	    if (mark->level < 0) {/* label read from data file */
> > +		if (mark->label != NULL) 
> > +		  strncpy(label, mark->label, sizeof(label));
> > +		else 
> > +		  label[0]='\0';
> > +	    }
> >  	    else if (axis_array[axis].is_timedata)
> >  		gstrftime(label, 24, mark->label ? mark->label : ticfmt[axis], mark->position);
> >  	    else
> > ----- To here -----
> > 
> > +========================================================+
> >  Shigeharu TAKENO     NIigata Institute of Technology
> >                        kashiwazaki,Niigata 945-1195 JAPAN
> >  sh...@ie...   TEL(&FAX): +81-257-22-8161
> > +========================================================+
> > 

-- 
Ethan A Merritt

Re: core dump for lack data of xticlabels()

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

On Thursday 31 July 2008, Shigeharu TAKENO wrote:
> shige 08/01 2008
> ----------------
> 
> The gnuplot of current CVS version may make core dump by the 
> following script which includes the lack data of xticlabels(), 
> but gnuplot-4.2.3 may not:
> 
>  plot '-' using 1:2:xtic(3) w l
>  1 2 tic1
>  2 3 tic2
>  3 6 
>  4 4 tic4
>  5 5 tic5
>  e

Thank you for the bug report.

Rather than storing a NULL label and having to test for NULL every time
the list of labels is scanned, I think it would be better not to store a
NULL label at all.

Something like this (not tested thorougly, but seems foolproof):

--- ../../gnuplot/src/axis.c	2008-06-05 21:15:58.000000000 -0700
+++ ./axis.c	2008-07-31 21:39:09.000000000 -0700
@@ -1618,6 +1618,9 @@ add_tic_user(AXIS_INDEX axis, char *label
     struct ticmark *tic, *newtic;
     struct ticmark listhead;
 
+    if (!label)
+	return;
+
     /* Mark this axis as user-generated ticmarks only, unless the */
     /* mix flag indicates that both user- and auto- tics are OK.  */
     if (!axis_array[axis].ticdef.def.mix)




>  OS: Solaris 9 (sparc)
>  compiler: gcc-3.4.3 
> 
> The following patch seems to fix it.
> 
> ----- From here -----
> --- axis.c.ORG	Fri Aug  1 12:20:48 2008
> +++ axis.c	Fri Aug  1 13:03:09 2008
> @@ -872,8 +872,12 @@
>  	    if (!inrange(internal, internal_min, internal_max))
>  		continue;
>  
> -	    if (mark->level < 0) /* label read from data file */
> -		strncpy(label, mark->label, sizeof(label));
> +	    if (mark->level < 0) {/* label read from data file */
> +		if (mark->label != NULL) 
> +		  strncpy(label, mark->label, sizeof(label));
> +		else 
> +		  label[0]='\0';
> +	    }
>  	    else if (axis_array[axis].is_timedata)
>  		gstrftime(label, 24, mark->label ? mark->label : ticfmt[axis], mark->position);
>  	    else
> ----- To here -----
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



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

core dump for lack data of xticlabels()

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

shige 08/01 2008
----------------

The gnuplot of current CVS version may make core dump by the 
following script which includes the lack data of xticlabels(), 
but gnuplot-4.2.3 may not:

 plot '-' using 1:2:xtic(3) w l
 1 2 tic1
 2 3 tic2
 3 6 
 4 4 tic4
 5 5 tic5
 e

 OS: Solaris 9 (sparc)
 compiler: gcc-3.4.3 

The following patch seems to fix it.

----- From here -----
--- axis.c.ORG	Fri Aug  1 12:20:48 2008
+++ axis.c	Fri Aug  1 13:03:09 2008
@@ -872,8 +872,12 @@
 	    if (!inrange(internal, internal_min, internal_max))
 		continue;
 
-	    if (mark->level < 0) /* label read from data file */
-		strncpy(label, mark->label, sizeof(label));
+	    if (mark->level < 0) {/* label read from data file */
+		if (mark->label != NULL) 
+		  strncpy(label, mark->label, sizeof(label));
+		else 
+		  label[0]='\0';
+	    }
 	    else if (axis_array[axis].is_timedata)
 		gstrftime(label, 24, mark->label ? mark->label : ticfmt[axis], mark->position);
 	    else
----- To here -----

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

Re: Histograms with fill solid and monochrome Postscript

[Philipp K. J. <ja...@ie...>]

I meant colors and densities. Not patterns.
(That would be a nightmare, for sure.)

On Wednesday 30 July 2008 23:22, you wrote:
> On Wednesday 30 July 2008, Ethan A Merritt wrote:
> > Adding a mechanism to re-map the order of existing fill patterns would be
> > easy. What seems well-nigh impossible is to provide a
> > terminal-independent way of defining new fill styles.
>
>                   ^^^^^^^^^^^
>
> By which I meant "new fill patterns".  If you just want to use colors +
> density, then it would be possible.

Re: The wxt terminal with compiz under Linux

[Michael M. <mur...@gm...>]

2008/7/30 Ethan Merritt <merritt@u.washington.edu>:
> On Wednesday 30 July 2008 04:16:37 Michael Murphy wrote:
>> Hi,
>>
>> When I am using the wxt terminal together with the Compiz window manager under
>> Ubuntu Linux, whenever the display refreshes (or even in the case of 3d plots
>> when I do a rotation) the window jumps about 20 pixels down and to the right.
>
> This is being tracked as bug #2025914  on gnuplot's SourceForge site.
>
> A similar problem was reported earlier for fvwm (bug #1575751),
> so it is likely that compiz is not the problem.   In that earlier case the
> problem was fixed by upgrading from  wxWidgets 2.6.3 to something newer
> (current wxWidgets version is 2.8.4).   So try that first.

I updated wxWidgets and this indeed fixed the problem.

>> Obviously, in the case of visualising 3dplots, this is rather inconvenient.
>>
>> Any ideas? (Apart from disabling compiz, that is...)
>
> Does disabling compiz fix it?   That would contradict my hypothesis above.

Disabling compiz does fix it, but perhaps it's just a peculiarity of
the metacity window manager (which is the default).

Michael.

> --
> Ethan A Merritt
>

Re: Postscript and color map

[Juergen W. <wie...@fr...>]

> (Supplying a Postscript prolog requires me to
> understand more Postscript than I want to know.)

I don't think so.  The current prologue.ps is quite well documented.
Just copy it and redefine the RGB values in the /LC* lines.  Even
simple adjustments on the line types can be done to the /LT* lines.

Juergen

Re: Histograms with fill solid and monochrome Postscript

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

On Wednesday 30 July 2008, Ethan A Merritt wrote:

> Adding a mechanism to re-map the order of existing fill patterns would be easy.
> What seems well-nigh impossible is to provide a terminal-independent way
> of defining new fill styles.  
                  ^^^^^^^^^^^

By which I meant "new fill patterns".  If you just want to use colors + density,
then it would be possible.

Re: Histograms with fill solid and monochrome Postscript

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

On Wednesday 30 July 2008, Philipp K. Janert wrote:
> 
> Ok, apparently we really misunderstood each other.
> Let me try again.
> 
> If I say:
> 	set style fill pattern
> 	set style histogram clustered
> 	set style data histogram
> 	plot "data" u 1, "" u 2, "" u 3
> 
> gnuplot will iterate through the available patterns
> for data in column 1, 2, and 3.
> 
> If instead I say
> 	set style fill solid
> 	...
> gnuplot will iterate through the available colors
> (red, green, blue, ...)
> 
> But what if I want a monochrome output? I can't 
> use red, green, blue, .... Instead I must use shades
> of gray

But isn't that exactly what you are saying you want?

> What I therefore want is for gnuplot to iterate through 
> densities:  not patterns, not colors. Just a single color, 
> but different densities of that color.

Color, or grey?  I guess I'm still confused about whether you
really care about density, or if that's just a convenient stand-in
for a monochrome greyscale.  The example I showed used grey partly
because there are pre-defined names for the incremental grey values.
It would work just as well for arbitrary color densities, but you'd
have to give them in the form "lc rgb '#RRGGBB'"

Unfortunately, not that many terminals support a uniform density
setting or a uniform transparency setting.  And even if they did,
it would end up with the same grayscale values as in the example
I gave.  So I don't think this would actually add anything to the
set of capabilities.

It happens that there are a few terminals that implement pattern
fill as a cycle of greyscale settings because they don't really 
offer patterns.  You could experiment with the emf terminal, say,
and see what you think of it.  I suppose we could offer this as
an optional alternative to pattern-fill on other terminal types. 

 
> I wonder whether there is currently support for that.
> 
> Best,
> 
> 		Ph.
> 
> 
> 
> On Wednesday 30 July 2008 22:03, you wrote:
> > On Wednesday 30 July 2008, Philipp K. Janert wrote:
> > > What I hear you say here is this, I think:
> > >
> > > Gnuplot has a way to automatically select
> > > different fill patterns (which will work in B&W),
> > > and different fill colors (which require a color
> > > terminal).
> >
> > Both, actually. It's your choice whether to use colors
> > or fill-patterns or both.
> >
> > > But gnuplot does NOT have a way to automatically
> > > select different monochrome fill densities. To
> > > achieve such an effect, I have to start hacking
> > > Postscript.
> >
> > No, I didn't intend to say that at all.
> > I may have misunderstood your question.
> > I thought you were asking about how you might print a
> > previously-created PostScript file on a monochrome printer
> > even though it was originally created using color.  I explained
> > one wasy to do this.
> >
> > If you are asking instead how you could create halftone output in
> > the first place, that's a different question.  What exactly are
> > you trying to do?  There may well be several alternatives available.
> >
> > > What we really would want is something that cycles
> > > through fill densities, in the same way that gnuplot
> > > cycles through line types.
> >
> > I think that is possible now, although perhaps not as conveniently
> > as you would like.
> >
> >   # Define a set of sequential gray values
> >   set style line 101 lc rgb "grey10"
> >   set style line 102 lc rgb "grey70"
> >   set style line 103 lc rgb "grey20"
> >   set style line 104 lc rgb "grey80"
> >   ...
> >   set style increment user # horrible syntax, but it's what we've got
> >
> >   set style histogram cluster
> >   set style fill solid 1 noborder
> >
> >   plot newhistogram lt 101, for [i=1:10] 'datafile' using i with histogram
> >
> > > Alternatively, we could have user-defined "fill styles",
> > > and then gnuplot could cycle through those. This way,
> > > users can define either a set of color fill styles, or
> > > monochrome density fill styles (or any combination
> > > thereof), and gnuplot would cycle through those. (I
> > > have no idea how hard that would be, and I would not
> > > think it is high priority, though.)
> >
> > Adding a mechanism to re-map the order of existing fill patterns would be
> > easy. What seems well-nigh impossible is to provide a terminal-independent
> > way of defining new fill styles.
> >
> > 	Ethan
> >
> > > On Wednesday 30 July 2008 19:05, you wrote:
> > > > On Wednesday 30 July 2008, Philipp K. Janert wrote:
> > > > > Let's say I am trying to generate histograms
> > > > > like this:
> > > > >
> > > > > set style fill solid
> > > > > set style histogram clustered
> > > > > set style data histogram
> > > > > plot "data" u 1, "" u 2, "" u 3
> > > > >
> > > > > I get a plot of histograms, with each "bin"
> > > > > in a different color (red, green, blue).
> > > > >
> > > > > Now, I would like to export this to a monochrome
> > > > > Postscript terminal. I would expect that the colors
> > > > > are mapped to different levels of grayscale.
> > > > >
> > > > > Instead, all colors seem to be mapped to black
> > > > > (or very nearly black).
> > > > >
> > > > > Is there a way to achieve the kind of automatic
> > > > > color-to-grayscale mapping I envision, or is this
> > > > > currently not supported?
> > > >
> > > > The issue is that there are two uses of color.
> > > >
> > > > One is to create a palette that captures a continuous quantity.
> > > > To convert this to a monochrome plot you want a greyscale mapping,
> > > > and that's what the postscript terminals do if you select "mono".
> > > >
> > > > The other use of color is simply to differentiate object A from
> > > > object B.  Here a greyscale is irrelevant, and you instead want
> > > > some mapping that makes the common colors maximally distinct from
> > > > each other.
> > > >
> > > > I suggest that a clever way to achieve the latter goal is to
> > > > in this case redefine the PostScript  setrgbcolor operator so
> > > > that you get an NTSC (black-and-white TV) mapping of the colors.
> > > > One line in the PostScript prolog suffices for this, so local
> > > > modification without touching the gnuplot executable is very
> > > > easy.  I've posted complete instructions several times, but
> > > > I don't seem to have saved a copy on my local disk.
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



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

Re: Histograms with fill solid and monochrome Postscript

[Philipp K. J. <ja...@ie...>]

Ok, apparently we really misunderstood each other.
Let me try again.

If I say:
	set style fill pattern
	set style histogram clustered
	set style data histogram
	plot "data" u 1, "" u 2, "" u 3

gnuplot will iterate through the available patterns
for data in column 1, 2, and 3.

If instead I say
	set style fill solid
	...
gnuplot will iterate through the available colors
(red, green, blue, ...)

But what if I want a monochrome output? I can't 
use red, green, blue, .... Instead I must use shades
of gray. 

What I therefore want is for gnuplot to iterate through 
densities:  not patterns, not colors. Just a single color, 
but different densities of that color.

I wonder whether there is currently support for that.

Best,

		Ph.



On Wednesday 30 July 2008 22:03, you wrote:
> On Wednesday 30 July 2008, Philipp K. Janert wrote:
> > What I hear you say here is this, I think:
> >
> > Gnuplot has a way to automatically select
> > different fill patterns (which will work in B&W),
> > and different fill colors (which require a color
> > terminal).
>
> Both, actually. It's your choice whether to use colors
> or fill-patterns or both.
>
> > But gnuplot does NOT have a way to automatically
> > select different monochrome fill densities. To
> > achieve such an effect, I have to start hacking
> > Postscript.
>
> No, I didn't intend to say that at all.
> I may have misunderstood your question.
> I thought you were asking about how you might print a
> previously-created PostScript file on a monochrome printer
> even though it was originally created using color.  I explained
> one wasy to do this.
>
> If you are asking instead how you could create halftone output in
> the first place, that's a different question.  What exactly are
> you trying to do?  There may well be several alternatives available.
>
> > What we really would want is something that cycles
> > through fill densities, in the same way that gnuplot
> > cycles through line types.
>
> I think that is possible now, although perhaps not as conveniently
> as you would like.
>
>   # Define a set of sequential gray values
>   set style line 101 lc rgb "grey10"
>   set style line 102 lc rgb "grey70"
>   set style line 103 lc rgb "grey20"
>   set style line 104 lc rgb "grey80"
>   ...
>   set style increment user # horrible syntax, but it's what we've got
>
>   set style histogram cluster
>   set style fill solid 1 noborder
>
>   plot newhistogram lt 101, for [i=1:10] 'datafile' using i with histogram
>
> > Alternatively, we could have user-defined "fill styles",
> > and then gnuplot could cycle through those. This way,
> > users can define either a set of color fill styles, or
> > monochrome density fill styles (or any combination
> > thereof), and gnuplot would cycle through those. (I
> > have no idea how hard that would be, and I would not
> > think it is high priority, though.)
>
> Adding a mechanism to re-map the order of existing fill patterns would be
> easy. What seems well-nigh impossible is to provide a terminal-independent
> way of defining new fill styles.
>
> 	Ethan
>
> > On Wednesday 30 July 2008 19:05, you wrote:
> > > On Wednesday 30 July 2008, Philipp K. Janert wrote:
> > > > Let's say I am trying to generate histograms
> > > > like this:
> > > >
> > > > set style fill solid
> > > > set style histogram clustered
> > > > set style data histogram
> > > > plot "data" u 1, "" u 2, "" u 3
> > > >
> > > > I get a plot of histograms, with each "bin"
> > > > in a different color (red, green, blue).
> > > >
> > > > Now, I would like to export this to a monochrome
> > > > Postscript terminal. I would expect that the colors
> > > > are mapped to different levels of grayscale.
> > > >
> > > > Instead, all colors seem to be mapped to black
> > > > (or very nearly black).
> > > >
> > > > Is there a way to achieve the kind of automatic
> > > > color-to-grayscale mapping I envision, or is this
> > > > currently not supported?
> > >
> > > The issue is that there are two uses of color.
> > >
> > > One is to create a palette that captures a continuous quantity.
> > > To convert this to a monochrome plot you want a greyscale mapping,
> > > and that's what the postscript terminals do if you select "mono".
> > >
> > > The other use of color is simply to differentiate object A from
> > > object B.  Here a greyscale is irrelevant, and you instead want
> > > some mapping that makes the common colors maximally distinct from
> > > each other.
> > >
> > > I suggest that a clever way to achieve the latter goal is to
> > > in this case redefine the PostScript  setrgbcolor operator so
> > > that you get an NTSC (black-and-white TV) mapping of the colors.
> > > One line in the PostScript prolog suffices for this, so local
> > > modification without touching the gnuplot executable is very
> > > easy.  I've posted complete instructions several times, but
> > > I don't seem to have saved a copy on my local disk.

Re: Histograms with fill solid and monochrome Postscript

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

On Wednesday 30 July 2008, Philipp K. Janert wrote:
> 
> What I hear you say here is this, I think:
> 
> Gnuplot has a way to automatically select 
> different fill patterns (which will work in B&W), 
> and different fill colors (which require a color
> terminal).

Both, actually. It's your choice whether to use colors
or fill-patterns or both.
 
> But gnuplot does NOT have a way to automatically
> select different monochrome fill densities. To 
> achieve such an effect, I have to start hacking
> Postscript.

No, I didn't intend to say that at all.  
I may have misunderstood your question.
I thought you were asking about how you might print a
previously-created PostScript file on a monochrome printer
even though it was originally created using color.  I explained
one wasy to do this.  

If you are asking instead how you could create halftone output in
the first place, that's a different question.  What exactly are
you trying to do?  There may well be several alternatives available.

> What we really would want is something that cycles
> through fill densities, in the same way that gnuplot
> cycles through line types.

I think that is possible now, although perhaps not as conveniently
as you would like.

  # Define a set of sequential gray values
  set style line 101 lc rgb "grey10"
  set style line 102 lc rgb "grey70"
  set style line 103 lc rgb "grey20"
  set style line 104 lc rgb "grey80"
  ...
  set style increment user # horrible syntax, but it's what we've got

  set style histogram cluster
  set style fill solid 1 noborder

  plot newhistogram lt 101, for [i=1:10] 'datafile' using i with histogram

 
> Alternatively, we could have user-defined "fill styles",
> and then gnuplot could cycle through those. This way,
> users can define either a set of color fill styles, or 
> monochrome density fill styles (or any combination
> thereof), and gnuplot would cycle through those. (I
> have no idea how hard that would be, and I would not
> think it is high priority, though.)

Adding a mechanism to re-map the order of existing fill patterns would be easy.
What seems well-nigh impossible is to provide a terminal-independent way
of defining new fill styles.  

	Ethan

> 
> On Wednesday 30 July 2008 19:05, you wrote:
> > On Wednesday 30 July 2008, Philipp K. Janert wrote:
> > > Let's say I am trying to generate histograms
> > > like this:
> > >
> > > set style fill solid
> > > set style histogram clustered
> > > set style data histogram
> > > plot "data" u 1, "" u 2, "" u 3
> > >
> > > I get a plot of histograms, with each "bin"
> > > in a different color (red, green, blue).
> > >
> > > Now, I would like to export this to a monochrome
> > > Postscript terminal. I would expect that the colors
> > > are mapped to different levels of grayscale.
> > >
> > > Instead, all colors seem to be mapped to black
> > > (or very nearly black).
> > >
> > > Is there a way to achieve the kind of automatic
> > > color-to-grayscale mapping I envision, or is this
> > > currently not supported?
> >
> > The issue is that there are two uses of color.
> >
> > One is to create a palette that captures a continuous quantity.
> > To convert this to a monochrome plot you want a greyscale mapping,
> > and that's what the postscript terminals do if you select "mono".
> >
> > The other use of color is simply to differentiate object A from
> > object B.  Here a greyscale is irrelevant, and you instead want
> > some mapping that makes the common colors maximally distinct from
> > each other.
> >
> > I suggest that a clever way to achieve the latter goal is to
> > in this case redefine the PostScript  setrgbcolor operator so
> > that you get an NTSC (black-and-white TV) mapping of the colors.
> > One line in the PostScript prolog suffices for this, so local
> > modification without touching the gnuplot executable is very
> > easy.  I've posted complete instructions several times, but
> > I don't seem to have saved a copy on my local disk.
> 


-- 
Ethan A Merritt

Re: Histograms with fill solid and monochrome Postscript

[Philipp K. J. <ja...@ie...>]

Thanks for your reply.

What I hear you say here is this, I think:

Gnuplot has a way to automatically select 
different fill patterns (which will work in B&W), 
and different fill colors (which require a color
terminal).

But gnuplot does NOT have a way to automatically
select different monochrome fill densities. To 
achieve such an effect, I have to start hacking
Postscript.

I am not sure that an NTSC mapping is ideal, though.
What we really would want is something that cycles
through fill densities, in the same way that gnuplot
cycles through line types.

Alternatively, we could have user-defined "fill styles",
and then gnuplot could cycle through those. This way,
users can define either a set of color fill styles, or 
monochrome density fill styles (or any combination
thereof), and gnuplot would cycle through those. (I
have no idea how hard that would be, and I would not
think it is high priority, though.)

Best,

		Ph.



On Wednesday 30 July 2008 19:05, you wrote:
> On Wednesday 30 July 2008, Philipp K. Janert wrote:
> > Let's say I am trying to generate histograms
> > like this:
> >
> > set style fill solid
> > set style histogram clustered
> > set style data histogram
> > plot "data" u 1, "" u 2, "" u 3
> >
> > I get a plot of histograms, with each "bin"
> > in a different color (red, green, blue).
> >
> > Now, I would like to export this to a monochrome
> > Postscript terminal. I would expect that the colors
> > are mapped to different levels of grayscale.
> >
> > Instead, all colors seem to be mapped to black
> > (or very nearly black).
> >
> > Is there a way to achieve the kind of automatic
> > color-to-grayscale mapping I envision, or is this
> > currently not supported?
>
> The issue is that there are two uses of color.
>
> One is to create a palette that captures a continuous quantity.
> To convert this to a monochrome plot you want a greyscale mapping,
> and that's what the postscript terminals do if you select "mono".
>
> The other use of color is simply to differentiate object A from
> object B.  Here a greyscale is irrelevant, and you instead want
> some mapping that makes the common colors maximally distinct from
> each other.
>
> I suggest that a clever way to achieve the latter goal is to
> in this case redefine the PostScript  setrgbcolor operator so
> that you get an NTSC (black-and-white TV) mapping of the colors.
> One line in the PostScript prolog suffices for this, so local
> modification without touching the gnuplot executable is very
> easy.  I've posted complete instructions several times, but
> I don't seem to have saved a copy on my local disk.

Re: Postscript and color map

[Philipp K. J. <ja...@ie...>]

Ok, that's a good thought: to define a bunch of
user-defined line styles, and let the Postscript
terminal use them. (I was stuck on finding a way
to specify the image color map, the way you can
do with GIF, so that I did not even think of this
possibility.)

(Supplying a Postscript prolog requires me to 
understand more Postscript than I want to know.)

I saw the discussion regarding this patch set a
while back on the mailing list, but must admit
that I have not checked it out myself. It's one of
those things where the defaults are almost always
good enough, so the urgency is not high.

On the other hand, I think that a unification of the
entire style/type distinction would be highly welcome.

Best,

		Ph.



On Wednesday 30 July 2008 19:11, you wrote:
> On Wednesday 30 July 2008, Philipp K. Janert wrote:
> > For libgd terminals, I can supply my own color
> > map, and gnuplot will choose from this color
> > map for subsequent lines, etc.
> >
> > Is there a similar functionality for Postscript?
>
> You can supply a local postscript prolog file customized to whatever
> color scheme you like.  You can place it in any convenient directory
> and trigger it by "set loadpath <preferred-location>".
>
> There is also a mechanism
> 	set style line N  ....
> 	set style increment user
> in version 4.2
>
> This will probably be replaced/supplemented by a more general
> mechanism in whatever the next major release is.
> See preliminary CVS patchset
> 	[ 2004590 ] mechanism to redefine base linetypes
> I haven't received much feedback about this implementation,
> but so many people have requested the ability to redefine the
> default sequence of line types that I think some variant of this
> should get high priority for the next release.

Re: Postscript and color map

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

On Wednesday 30 July 2008, Philipp K. Janert wrote:
> 
> For libgd terminals, I can supply my own color
> map, and gnuplot will choose from this color 
> map for subsequent lines, etc.
> 
> Is there a similar functionality for Postscript?

You can supply a local postscript prolog file customized to whatever
color scheme you like.  You can place it in any convenient directory
and trigger it by "set loadpath <preferred-location>".

There is also a mechanism
	set style line N  ....
	set style increment user
in version 4.2

This will probably be replaced/supplemented by a more general
mechanism in whatever the next major release is.
See preliminary CVS patchset 
	[ 2004590 ] mechanism to redefine base linetypes 
I haven't received much feedback about this implementation,
but so many people have requested the ability to redefine the
default sequence of line types that I think some variant of this
should get high priority for the next release.

-- 
Ethan A Merritt

Re: Histograms with fill solid and monochrome Postscript

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

On Wednesday 30 July 2008, Philipp K. Janert wrote:
> 
> Let's say I am trying to generate histograms
> like this:
> 
> set style fill solid
> set style histogram clustered
> set style data histogram
> plot "data" u 1, "" u 2, "" u 3
> 
> I get a plot of histograms, with each "bin"
> in a different color (red, green, blue).
> 
> Now, I would like to export this to a monochrome
> Postscript terminal. I would expect that the colors
> are mapped to different levels of grayscale.
> 
> Instead, all colors seem to be mapped to black
> (or very nearly black).
> 
> Is there a way to achieve the kind of automatic
> color-to-grayscale mapping I envision, or is this
> currently not supported?

The issue is that there are two uses of color.

One is to create a palette that captures a continuous quantity.
To convert this to a monochrome plot you want a greyscale mapping,
and that's what the postscript terminals do if you select "mono".

The other use of color is simply to differentiate object A from
object B.  Here a greyscale is irrelevant, and you instead want
some mapping that makes the common colors maximally distinct from
each other.

I suggest that a clever way to achieve the latter goal is to 
in this case redefine the PostScript  setrgbcolor operator so
that you get an NTSC (black-and-white TV) mapping of the colors.
One line in the PostScript prolog suffices for this, so local
modification without touching the gnuplot executable is very
easy.  I've posted complete instructions several times, but
I don't seem to have saved a copy on my local disk. 


-- 
Ethan A Merritt

Postscript and color map

[Philipp K. J. <ja...@ie...>]

For libgd terminals, I can supply my own color
map, and gnuplot will choose from this color 
map for subsequent lines, etc.

Is there a similar functionality for Postscript?

Best,

		Ph.

Histograms with fill solid and monochrome Postscript

[Philipp K. J. <ja...@ie...>]

Let's say I am trying to generate histograms
like this:

set style fill solid
set style histogram clustered
set style data histogram
plot "data" u 1, "" u 2, "" u 3

I get a plot of histograms, with each "bin"
in a different color (red, green, blue).

Now, I would like to export this to a monochrome
Postscript terminal. I would expect that the colors
are mapped to different levels of grayscale.

Instead, all colors seem to be mapped to black
(or very nearly black).

Is there a way to achieve the kind of automatic
color-to-grayscale mapping I envision, or is this
currently not supported?

Best,

		Ph.

Re: The wxt terminal with compiz under Linux

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

On Wednesday 30 July 2008 04:16:37 Michael Murphy wrote:
> Hi,
> 
> When I am using the wxt terminal together with the Compiz window manager under
> Ubuntu Linux, whenever the display refreshes (or even in the case of 3d plots
> when I do a rotation) the window jumps about 20 pixels down and to the right.

This is being tracked as bug #2025914  on gnuplot's SourceForge site.

A similar problem was reported earlier for fvwm (bug #1575751),
so it is likely that compiz is not the problem.   In that earlier case the
problem was fixed by upgrading from  wxWidgets 2.6.3 to something newer
(current wxWidgets version is 2.8.4).   So try that first.


> Obviously, in the case of visualising 3dplots, this is rather inconvenient.
> 
> Any ideas? (Apart from disabling compiz, that is...)

Does disabling compiz fix it?   That would contradict my hypothesis above.

-- 
Ethan A Merritt

Re: Format "%5f" vs. "%5g"

[Hans-Bernhard B. <HBB...@t-...>]

Theo Hopman wrote:
> Hi all. Why does `set format y "%5f"` not work like `set format y 
> "%5g"`? 

Because it doesn't.  Nor is it supposed to.

It would be rather silly to have commands be different if they did the 
exact same thing, wouldn't it?

> I'm dealing with numbers between 0 and 5, so I would expect both 
> to produce tic labels with right justified floating point numbers in a 
> field of five characters, with no trailing zeros. %5g does, but %5f 
> doesn't: it produces tic labels with six decimal places and trailing zeros.

I'm afraid your expectation is based on reading the wrong documentation. 
  First of all, the '5' in %5f doesn't mean that the output should be 
exactly 5 characters wide.  It says that it shall be *at least* 5.  And 
it did that.

Second, if you wanted the output to fit into exactly 5 chars, you would 
have to fix the precision, too.  As is, you left that choice to the C 
compiler that made your version of gnuplot.  It picked 6, but you want 2:

	set format '% 5.2f'  # keep that ' ' after the '%'!

The wxt terminal with compiz under Linux

[Michael M. <mur...@gm...>]

Hi,

When I am using the wxt terminal together with the Compiz window manager under
Ubuntu Linux, whenever the display refreshes (or even in the case of 3d plots
when I do a rotation) the window jumps about 20 pixels down and to the right.
Obviously, in the case of visualising 3dplots, this is rather inconvenient.

Any ideas? (Apart from disabling compiz, that is...)