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

Re: using gnuplot as a filter

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

On Thursday 13 December 2007 05:17, P=C3=A1draig Brady wrote:
> If you write the data to stdin after the plot command, then it works:
> (cat ./plot.gpi; seq 10) | gnuplot > plot.png
>=20
> Ethan's variant here is not as general as it hardcodes the
> source of the data within the script
>=20
> echo 'plot "< seq 10"' | GNUTERM=3Dpng gnuplot > plot.png

You are trying to use gnuplot in a mode it was not designed for.
If it works for you, OK.  But I think that in general this is not
something we should try to support. =20

As I pointed out before, you are assuming that "stdin" is exactly
the same as "current input stream". But it is not the same. =20
Consider the gnuplot commands "load" and "reread", for example.
If either of these is in effect, then  plot '-' will read from
the current command file rather than from stdin. =20

My advice is to write a small perl/python/whatever wrapper to=20
manage the input and output streams.


=2D-=20
Ethan A Merritt

Re: Can gnuplot do this?

[Tatsuro M. <tma...@ya...>]

Hello

--- Daniel Farrell <boy...@gm...> wrote:
> How can I tell gnuplot make all the contour lines black and have a  
> solid colour appear between contour lines in the attached plot
> (http://www.boyfarrell.com/forums/contour-lines.png)? 
>   It might be that this isn't possible?

Perhaps you can do what you want after carefully reading the term pen help.

Tatsuro

******* Help of png term
Subtopic of term: png
 Syntax:
       set terminal png
              {{no}transparent} {{no}interlace}
              {{no}truecolor} {rounded|butt}
              {linewidth <lw>} {dashlength <dl>}
              {tiny | small | medium | large | giant}
              {font <face> {<pointsize>}}
              {size <x>,<y>} {{no}crop}
              {{no}enhanced}
              {<color0> <color1> <color2> ...}

 PNG images are created using libgd, with optional support for TrueType
 and Adobe Type 1 fonts via libfreetype. Version 1.8 or greater of libgd
 is required.

 `transparent` instructs the driver to generate transparent PNGs.  The first
 color will be the transparent one. Default is `notransparent`.

 `interlace` instructs the driver to generate interlaced PNGs.
 Default is `nointerlace`.

 By default a 256-color png image is produced. The `truecolor` option instead
Press return for more:
 creates a TrueColor output image with 24 bits of color information per pixel.
 The use of transparent fill areas requires use of the `truecolor` option.
 A transparent background is possible in either indexed or TrueColor images.

 `butt` instructs the driver to use a line drawing method that does
 not overshoot the desired end point of a line.  This setting is only
 applicable for line widths greater than 1.  This setting is most useful when
 drawing horizontal or vertical lines.  Default is `rounded`.
 Version 2.0 or greater of libgd is required.

 PNG plots may be conveniently viewed by piping the output to the
 'display' program from the ImageMagick package as follows:
                set term png
                set output '| display png:-'

 View the output from successive plot commands interactively by hitting
 <space> in the display window.  To save a particular one to disk, left
 click in the display window and choose `save`.

 Five basic fonts are supported directly by the gd library. These are
 `tiny` (5x8 pixels), `small` (6x12 pixels), `medium`, (7x13 Bold),
 `large` (8x16) or `giant` (9x15 pixels). These fonts cannot be scaled
Press return for more:
 or rotated (pure horizontal or vertical text only).

 If gnuplot was built with support for TrueType (*.ttf) or Adobe Type 1
 (*.pfa) fonts, they may be selected using the 'font <face> {<pointsize>}'
 option. <face> is either the full pathname to the font file, or a font
 face name that is assumed to be the first part of a filename in one of the
 directories listed in the GDFONTPATH environmental variable. That is,
 'set term png font "Face"' will look for a font file named either
 <somedirectory>/Face.ttf or <somedirectory>/Face.pfa. Both TrueType and
 Adobe Type 1 fonts are fully scalable and may be rotated through any angle.
 If no font is specified, gnuplot checks the environmental variable
 GNUPLOT_DEFAULT_GDFONT to see if there is a preferred default font.

 `enhanced` enables the enhanced text processing features, (subscripts,
 superscripts and mixed fonts). See `enhanced` for more information.
 The full enhanced mode syntax is supported by the PNG/JPEG driver itself,
 but some of these features are dependent on which version of the
 underlying libgd library is present, and which fonts are available.

 The size <x,y> is given in pixels---it defaults to 640x480.  The number of
 pixels can be also modified by scaling with the `set size` command.
 `crop` trims blank space from the edges of the completed plot, resulting
Press return for more:
 in a smaller final image size. Default is `nocrop`.

 Each color must be of the form 'xrrggbb', where x is the literal character
 'x' and 'rrggbb' are the red, green and blue components in hex.  For example,
 'x00ff00' is green.  The background color is set first, then the border
 colors, then the X & Y axis colors, then the plotting colors.  The maximum
 number of colors that can be set is 256.

 Examples:
       set terminal png medium size 640,480 \
                        xffffff x000000 x404040 \
                        xff0000 xffa500 x66cdaa xcdb5cd \
                        xadd8e6 x0000ff xdda0dd x9500d3    # defaults

 which uses white for the non-transparent background, black for borders, gray
 for the axes, and red, orange, medium aquamarine, thistle 3, light blue, blue,
 plum and dark violet for eight plotting colors.

       set terminal png font arial 14 size 800,600

 which searches for a TrueType font with face name 'arial' in the directory
 specified by the environment variable GDFONTPATH and 14pt font size.
Press return for more:

       set terminal png transparent xffffff \
                        x000000 x202020 x404040 x606060 \
                        x808080 xA0A0A0 xC0C0C0 xE0E0E0

 which uses white for the transparent background, black for borders, dark
 gray for axes, and a gray-scale for the six plotting colors.

--------------------------------------
New Design Yahoo! JAPAN  2008/01/01
http://pr.mail.yahoo.co.jp/newdesign/

Re: Can gnuplot do this?

[Tatsuro M. <tma...@ya...>]

Hello

--- Daniel Farrell <boy...@gm...> wrote:
> How can I tell gnuplot make all the contour lines black and have a  
> solid colour appear between contour lines in the attached plot
> (http://www.boyfarrell.com/forums/contour-lines.png)? 
>   It might be that this isn't possible?

Perhaps you can do what you want after carefully reading the term pen help.

Tatsuro

******* Help of png term
Subtopic of term: png
 Syntax:
       set terminal png
              {{no}transparent} {{no}interlace}
              {{no}truecolor} {rounded|butt}
              {linewidth <lw>} {dashlength <dl>}
              {tiny | small | medium | large | giant}
              {font <face> {<pointsize>}}
              {size <x>,<y>} {{no}crop}
              {{no}enhanced}
              {<color0> <color1> <color2> ...}

 PNG images are created using libgd, with optional support for TrueType
 and Adobe Type 1 fonts via libfreetype. Version 1.8 or greater of libgd
 is required.

 `transparent` instructs the driver to generate transparent PNGs.  The first
 color will be the transparent one. Default is `notransparent`.

 `interlace` instructs the driver to generate interlaced PNGs.
 Default is `nointerlace`.

 By default a 256-color png image is produced. The `truecolor` option instead
Press return for more:
 creates a TrueColor output image with 24 bits of color information per pixel.
 The use of transparent fill areas requires use of the `truecolor` option.
 A transparent background is possible in either indexed or TrueColor images.

 `butt` instructs the driver to use a line drawing method that does
 not overshoot the desired end point of a line.  This setting is only
 applicable for line widths greater than 1.  This setting is most useful when
 drawing horizontal or vertical lines.  Default is `rounded`.
 Version 2.0 or greater of libgd is required.

 PNG plots may be conveniently viewed by piping the output to the
 'display' program from the ImageMagick package as follows:
                set term png
                set output '| display png:-'

 View the output from successive plot commands interactively by hitting
 <space> in the display window.  To save a particular one to disk, left
 click in the display window and choose `save`.

 Five basic fonts are supported directly by the gd library. These are
 `tiny` (5x8 pixels), `small` (6x12 pixels), `medium`, (7x13 Bold),
 `large` (8x16) or `giant` (9x15 pixels). These fonts cannot be scaled
Press return for more:
 or rotated (pure horizontal or vertical text only).

 If gnuplot was built with support for TrueType (*.ttf) or Adobe Type 1
 (*.pfa) fonts, they may be selected using the 'font <face> {<pointsize>}'
 option. <face> is either the full pathname to the font file, or a font
 face name that is assumed to be the first part of a filename in one of the
 directories listed in the GDFONTPATH environmental variable. That is,
 'set term png font "Face"' will look for a font file named either
 <somedirectory>/Face.ttf or <somedirectory>/Face.pfa. Both TrueType and
 Adobe Type 1 fonts are fully scalable and may be rotated through any angle.
 If no font is specified, gnuplot checks the environmental variable
 GNUPLOT_DEFAULT_GDFONT to see if there is a preferred default font.

 `enhanced` enables the enhanced text processing features, (subscripts,
 superscripts and mixed fonts). See `enhanced` for more information.
 The full enhanced mode syntax is supported by the PNG/JPEG driver itself,
 but some of these features are dependent on which version of the
 underlying libgd library is present, and which fonts are available.

 The size <x,y> is given in pixels---it defaults to 640x480.  The number of
 pixels can be also modified by scaling with the `set size` command.
 `crop` trims blank space from the edges of the completed plot, resulting
Press return for more:
 in a smaller final image size. Default is `nocrop`.

 Each color must be of the form 'xrrggbb', where x is the literal character
 'x' and 'rrggbb' are the red, green and blue components in hex.  For example,
 'x00ff00' is green.  The background color is set first, then the border
 colors, then the X & Y axis colors, then the plotting colors.  The maximum
 number of colors that can be set is 256.

 Examples:
       set terminal png medium size 640,480 \
                        xffffff x000000 x404040 \
                        xff0000 xffa500 x66cdaa xcdb5cd \
                        xadd8e6 x0000ff xdda0dd x9500d3    # defaults

 which uses white for the non-transparent background, black for borders, gray
 for the axes, and red, orange, medium aquamarine, thistle 3, light blue, blue,
 plum and dark violet for eight plotting colors.

       set terminal png font arial 14 size 800,600

 which searches for a TrueType font with face name 'arial' in the directory
 specified by the environment variable GDFONTPATH and 14pt font size.
Press return for more:

       set terminal png transparent xffffff \
                        x000000 x202020 x404040 x606060 \
                        x808080 xA0A0A0 xC0C0C0 xE0E0E0

 which uses white for the transparent background, black for borders, dark
 gray for axes, and a gray-scale for the six plotting colors.

--------------------------------------
New Design Yahoo! JAPAN  2008/01/01
http://pr.mail.yahoo.co.jp/newdesign/

Mixing Dashed and Solid lines in AquaTerm

[Daniel F. <boy...@gm...>]

Hello,

I was following the dash and colour example on the gnuplot gallery, http://gnuplot.sourceforge.net/demo/dashcolor.html 
. It seems that the aquaterm is one of the terminals that doesn't  
support this. Is there a way around this? I have changed to the  
postscript terminal, but I have all my defaults set up for aquaterm.

Regards,

Dan.

Re: bug in x tic number placement

[Allin C. <cot...@wf...>]

On Thu, 13 Dec 2007, Ethan Merritt wrote:

> On Thursday 13 December 2007 06:48, Allin Cottrell wrote:
> > But things have regressed in this respect since 4.2.  This script
> > 
> > set term png font Vera 8
> > set output 'foo.png'
> > set xrange [-100000:100000]
> > plot x
> > 
> > produces correct output with 4.2 (i.e. the "100000" marker is 
> > fully visible) but shows truncated output with current CVS.  
> 
> Somehow the word "else" went missing in one clause of the
> boundary calculation.   Fixed in CVS.

Excellent.  Thanks.

Allin Cottrell

Re: bug in x tic number placement

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

On Thursday 13 December 2007 06:48, Allin Cottrell wrote:
> But things have regressed in this respect since 4.2.  This script
> 
> set term png font Vera 8
> set output 'foo.png'
> set xrange [-100000:100000]
> plot x
> 
> produces correct output with 4.2 (i.e. the "100000" marker is 
> fully visible) but shows truncated output with current CVS.  

Somehow the word "else" went missing in one clause of the
boundary calculation.   Fixed in CVS.

-- 
Ethan A Merritt

Can gnuplot do this?

[Daniel F. <boy...@gm...>]

Hello,

How can I tell gnuplot make all the contour lines black and have a  
solid colour appear between contour lines in the attached plot (http://www.boyfarrell.com/forums/contour-lines.png)? 
  It might be that this isn't possible?

Regards,

Dan.

Can gnuplot do this?

[Daniel J F. <dan...@im...>]

Hello,

How can I tell gnuplot make all the contour lines black and have a  
solid colour appear between contour lines in the attached plot (www.boyfarrell.com/forums/contour-lines.png)? 
  It might be that this isn't possible?

Regards,

Dan.

Re: bug in x tic number placement

[Allin C. <cot...@wf...>]

On Mon, 10 Dec 2007, Ethan Merritt wrote:

> On Monday 10 December 2007 04:50, Allin Cottrell wrote:
> > set xrange [-100000:100000]
> > plot x
> > 
> > Using term pngcairo font "Vera,8" (just for example) the last 
> > x-axis value is displayed as (almost) "10000".  Part of the last 
> > printed zero is off the edge of the graph, and the final zero is 
> > entirely missing.
> 
> You are correct. Gnuplot does not pay any attention to tick labels
> when allocating space for the plot.  That would be quite difficult,
> since the precise space taken up by a text string is terminal- and
> font- dependent.  It is particularly problematic for text strings
> placed at an angle other than 0.  But I suppose it could make at
> least a rough guess.

OK, I understand this is quite tricky in general.  But things have 
regressed in this respect since 4.2.  This script

set term png font Vera 8
set output 'foo.png'
set xrange [-100000:100000]
plot x

produces correct output with 4.2 (i.e. the "100000" marker is 
fully visible) but shows truncated output with current CVS.  
Comparing the two plot files, the margin between the right-hand 
vertical border line and the edge of the PNG image was greater by 
a few pixels in 4.2, hence allowing the full marker string to come 
through.  

The contrast remains the same if you bump up the font 
size to something that's really "too big", e.g. Vera 16.  Ah, and 
at that scale you can see something else: the trouble seems to be 
that all of the "data ink" is displaced to the right in CVS 
relative to 4.2: the right-hand margin is too small, and the 
left-hand margin is too big (a lot of pixels of white space).

I'd be happy to try patching, but it seems to me that 
someone who's more familiar with gnuplot development might have a 
better idea where to look for the source of this change in 
behavior.

Allin Cottrell

Re: using gnuplot as a filter

[<P...@dr...>]

Hans-Bernhard Br=C3=B6ker wrote:
> P=C3=A1draig Brady wrote:
>> I tried to get a gnuplot script to read
>> from stdin like a normal linux filter using plot '-'
>=20
>> I know how to work around this but it's a horrible hack.
>> I.E. rather than:
>>   gen_data | ./plot.gp > file.png
>=20
> Without seeing what's in plot.gp, it's quite unclear what you're trying
> to do here.  What's wrong with the more conventional
>=20
>     gen_data | gnuplot plot.gp > file.png

I want to read data on stdin and write png to stdout.
I.E. behave like a standard unix filter which has lots of advantages.
Here is an example plot.gpi script to do that:

#!/usr/bin/env gnuplot
set term png
plot '-'

However it doesn't work as shown below, as gnuplot drains its stdin on st=
artup
as detailed previously. It should not do that if possible. At least it sh=
ould
be a runtime rather than a compile time decision. Your variation above is=
 equivalent.

$ seq 10 | ./plot.gpi > plot.png
plot '-'
"./plot.gpi", line 3: warning: Skipping data file with no valid points

If you write the data to stdin after the plot command, then it works:
(cat ./plot.gpi; seq 10) | gnuplot > plot.png

Ethan's variant here is not as general as it hardcodes the
source of the data within the script

echo 'plot "< seq 10"' | GNUTERM=3Dpng gnuplot > plot.png

thanks,
P=C3=A1draig.

Re: using gnuplot as a filter

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

On Wednesday 12 December 2007 12:43, Ethan Merritt wrote:
> That command makes no sense to me.  Maybe you want this?
> 
> file plot.gp contains:
>    set term png
>    system "gen_data > temp.dat"
>    plot "temp.dat"
> 
> gnuplot plot.gp > file.png


Or maybe even:

   setenv GNUTERM png
   echo 'plot "< gen_data"' | gnuplot > file.png

-- 
Ethan A Merritt

Re: using gnuplot as a filter

[<HBB...@t-...>]

Pádraig Brady wrote:
> I tried to get a gnuplot script to read
> from stdin like a normal linux filter using plot '-'

> I know how to work around this but it's a horrible hack.
> I.E. rather than:
>   gen_data | ./plot.gp > file.png

Without seeing what's in plot.gp, it's quite unclear what you're trying 
to do here.  What's wrong with the more conventional

     gen_data | gnuplot plot.gp > file.png

?

Re: Comunication between Gnuplot and Java

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

On Tuesday 11 December 2007 06:25, Nicolas Pouvesle wrote:
> 
> 	I just put on line an example of communication
> bidirectional between Gnuplot and Java:
> 
> http://nicolas.pouvesle.fr/gnuplot/jgnuplot.html
> 
> 	Feel free to diffuse the link if it could be helpful ...

I added this link to the set of examples on 
	http://gnuplot.sourceforge.net/links.html


		thanks!


-- 
Ethan A Merritt

Re: using gnuplot as a filter

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

On Tuesday 11 December 2007 02:32, P=C3=A1draig Brady wrote:
> I tried to get a gnuplot script to read
> from stdin like a normal linux filter using plot '-'

It certainly works in general.  Consider the following trivial example,
which draws a big red triangle:
    plot '-' with filledcurve
      1 1
      2 3
      3 2
      e

Could you please provide a specific example in which it doesn't work?


> I know how to work around this but it's a horrible hack.
> I.E. rather than:
>   gen_data | ./plot.gp > file.png

Erk.  What is that supposed to be doing?


I suspect that the gnuplot command
       plot '-'
doesn't mean what you think it does.
It does not mean "read from original stdin of parent process";
it means "read from the current input stream".
Assuming that the file ./plot.gp calls gnuplot, that means that
plot '-' will read from the file plot.gp.

Please explain exactly what you are trying to do, so that we can
suggest alternatives.

> one needs to do:
>   (cat plot.gp; gen_data) | gnuplot > file.png

That command makes no sense to me.  Maybe you want this?

file plot.gp contains:
   set term png
   system "gen_data > temp.dat"
   plot "temp.dat"

gnuplot plot.gp > file.png




=2D-=20
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Comunication between Gnuplot and Java

[Nicolas P. <ni...@po...>]

	Hi,

	I just put on line an example of communication
bidirectional between Gnuplot and Java:

http://nicolas.pouvesle.fr/gnuplot/jgnuplot.html

	Feel free to diffuse the link if it could be helpful ...


	Nico

using gnuplot as a filter

[<P...@dr...>]

I tried to get a gnuplot script to read
from stdin like a normal linux filter using plot '-'

However gnuplot doesn't support this because it
clears it's stdin on startup, as the following
code from plot.c shows:

#ifdef X11
    /* This call used to be in x11.trm, with the following comment:
     *   Multi-character inputs like escape sequences but also mouse-past=
ed
     *   text got buffered and therefore didn't trigger the select() func=
tion
     *   in X11_waitforinput(). Switching to unbuffered input solved this=
.
     *   23 Jan 2002 (joze)
     * But switching to unbuffered mode causes all characters in the inpu=
t
     * buffer to be lost. So the only safe time to do it is on program en=
try.
     * The #ifdef X11 is probably unnecessary, but makes the change minim=
al.
     * Do any non-X platforms suffer from the same problem?
     * EAM - Jan 2004.
     */
    setvbuf(stdin, (char *) NULL, _IONBF, 0);
#endif

As you can see it's hardcoded, so even if one selects
a different terminal, stdin is still cleared.

I know how to work around this but it's a horrible hack.
I.E. rather than:
  gen_data | ./plot.gp > file.png
one needs to do:
  (cat plot.gp; gen_data) | gnuplot > file.png
Perhaps FAQ 1.4 could be updated with this info.

Also, can we determine if we're using X11 are runtime,
so that this issue can be worked around using GNUTERM environment
variable for example?

What's the X issue exactly. Does it really need to read from stdin?

thanks,
P=C3=A1draig.

Re: wxterm

[Daniel F. <boy...@gm...>]

Hi everybody,

Okay thanks of the list of info I will give it a go on linux.

Cheers,

Dan.

Re: bug in x tic number placement

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

On Monday 10 December 2007 04:50, Allin Cottrell wrote:
> There seems to be a bug in the placement of x tic numbers in 
> current CVS (or perhaps, in the placement of the right edge of the 
> plot relative to the background): if the maximum x value is large, 
> the last numerical tic value gets truncated.  This seems to happen 
> with all terminals (at least all I've tried).  Simple test case:
> 
> set xrange [-100000:100000]
> plot x
> 
> Using term pngcairo font "Vera,8" (just for example) the last 
> x-axis value is displayed as (almost) "10000".  Part of the last 
> printed zero is off the edge of the graph, and the final zero is 
> entirely missing.

You are correct. Gnuplot does not pay any attention to tick labels
when allocating space for the plot.  That would be quite difficult,
since the precise space taken up by a text string is terminal- and
font- dependent.  It is particularly problematic for text strings
placed at an angle other than 0.  But I suppose it could make at
least a rough guess.

How about filing this as a Feature Request?
Or, if you are so inspired, working on a patch to implement it?
 

-- 
Ethan A Merritt

Re: wxterm

[<tim...@lp...>]

Ethan A Merritt a écrit :
> On Sunday 09 December 2007 14:14, Daniel Farrell wrote:
>   
>> Hello.
>>
>> Are there any instructions to follow to get wxterm working on either
>> Linux or MacOS 10.5.
>>     
>
> linux
> -----
> No special instructions. Normal ./configure and build, but it requires
> that you have already installed the development packages for
> 	libcairo
> 	libpango
> 	libpangocairo
> 	libwx-gtk2
> 	wxgtk2
> and these may drag in other dependencies.  The actual package names
> will differ from one linux distro to another.
>
>
> MacOS 10.5
> -----------
> I have heard that pango/cairo is broken on 10.5 for most 3rd party
> apps.  Check google for more details.  The Gnome project announced
> intentions to provide a complete set of rebuilt libraries for OSX,
> but I'm not sure that has happened yet.
>
>   
I'm not sure if pango and cairo are broken on MacOS X, since I have not 
tried it. But I can assure that wxt will not work, because of GUI events 
loop issues. I am working on them, but it's not finished yet. However, 
the pdfcairo and pngcairo that current CVS contains should work as they 
do an Linux.

Best regards,

Timothée

bug in x tic number placement

[Allin C. <cot...@wf...>]

There seems to be a bug in the placement of x tic numbers in 
current CVS (or perhaps, in the placement of the right edge of the 
plot relative to the background): if the maximum x value is large, 
the last numerical tic value gets truncated.  This seems to happen 
with all terminals (at least all I've tried).  Simple test case:

set xrange [-100000:100000]
plot x

Using term pngcairo font "Vera,8" (just for example) the last 
x-axis value is displayed as (almost) "10000".  Part of the last 
printed zero is off the edge of the graph, and the final zero is 
entirely missing.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: wxterm

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

On Sunday 09 December 2007 14:14, Daniel Farrell wrote:
> Hello.
> 
> Are there any instructions to follow to get wxterm working on either
> Linux or MacOS 10.5.

linux
-----
No special instructions. Normal ./configure and build, but it requires
that you have already installed the development packages for
	libcairo
	libpango
	libpangocairo
	libwx-gtk2
	wxgtk2
and these may drag in other dependencies.  The actual package names
will differ from one linux distro to another.


MacOS 10.5
-----------
I have heard that pango/cairo is broken on 10.5 for most 3rd party
apps.  Check google for more details.  The Gnome project announced
intentions to provide a complete set of rebuilt libraries for OSX,
but I'm not sure that has happened yet.


-- 
Ethan A Merritt

Re: x11: border lw 0 vs lw 1 for lt -1

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

On Sunday 09 December 2007 13:27, Petr Mikulik wrote:
> > A related possibility is to add a global linewidth multiplier in the
> > core driver:
> > 	set term x11 linewidth LW
> > That way if you want all the lines to be thicker, you can set this from 
> > inside gnuplot rather than having to use xrdb to change the values of
> > gnuplot*linewidthN in the XResource database.
> > Many other drivers already work like this.
> 
> Yes, this option is nicer.

OK. I'll put that in CVS.  It's a trivial change, and has no issues
with backward compatibility.
 
> I've found this issue by testing the latest release of Octave 2.9.18 and I 
> was wondering why the border lines are so thick (compared to Matlab). Then 
> I've found it was only a problem at X11, but I couldn't find how to fix it.

Several ways, now that I have fixed the typos in gplt_x11.c

1) In Gnuplot.app-defaults,  change the line
     gnuplot*borderWidth: 2

2) same thing, only in your ~/.Xdefaults file

3) same thing, but dynamically for this X session
     echo "gnuplot*borderWidth: 1" | xrdb -merge

4) gnuplot -bw 1

5) gnuplot -borderwidth 1

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

wxterm

[Daniel F. <boy...@gm...>]

Hello.

Are there any instructions to follow to get wxterm working on either
Linux or MacOS 10.5. I would like to see what it is like. Can anybody
suggest links to the packages and or source and tell me any special
compilation instructions if the deviate from the usual configure, make
and sudo make install.

Regards,

Dan

Re: x11: border lw 0 vs lw 1 for lt -1

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

> > > Not in the core. All the XResource interpretation is done in gnuplot_x11.
> > > The routine that manages linewidths is pr_width().
> > > 
> > > > Further it seems that this is actually a multiplicate constant, not a line
> > > > width in pixels as  "help x11 line" describes. Is this right?
> > > 
> > > Yes, that has always annoyed me.  But if you set all the XResource linewidths
> > > to 1.0, then the multiplicative constant is effectively the true linewidth.
> > > So most people probably don't notice.
> > > 
> > > I would be in favor changing it so that
> > >     'set term x11; plot foo lt 3 lw 5'
> > > really does use a linewidth of 5 pixels rather than using
> > > (5 * getR(db,"linewidth3"))
> > 
> > I like prefer this as well.
> 
> Unfortunately it turns out that this doesn't work.
> If we change the code to use the linewidths passed by the core driver
> directly, then the default linewidths are never used.  That makes the
> XResource values for default linewidths useless.
> 
> A related possibility is to add a global linewidth multiplier in the
> core driver:
> 	set term x11 linewidth LW
> That way if you want all the lines to be thicker, you can set this from 
> inside gnuplot rather than having to use xrdb to change the values of
> gnuplot*linewidthN in the XResource database.
> Many other drivers already work like this.

Yes, this option is nicer.

The trouble is that the value of 2 for
	gnuplot*borderWidth:
is the default, so it is hard to find and change.

I've found this issue by testing the latest release of Octave 2.9.18 and I 
was wondering why the border lines are so thick (compared to Matlab). Then 
I've found it was only a problem at X11, but I couldn't find how to fix it.

I would propose to use
	set border lw 0
but the wxt produces no line at all.
Would
	set border lw 0.5
be save for all terminals for the current gnuplot version?

---
PM

Re: bug in wx terminal for linewidth 0

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

> > I think the limit should be "lw 1" -- thus, all linewidths < 1 should be 
> > equivalent to linewidth 1. I seems that all terminals work this way.
> 
> This is not true for PostScript or PDF.
> 
> PostScript (the language, not the terminal driver) has the rule
> "0 linewidth means as thin as the device supports".
> So on a 1200dpi printer, linewidth 0 produces  about the same as
> linewidth 0.06  

Yes; however, if you look at the same file on screen by ghostscript, you see 
all these lines very well.

wxt is a screen terminal, so the limit is one pixel.

---
PM