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

Re: Problems with Enhanced mode and Postscript

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

I see. Thanks. 

This does not just affect {}, though, but seems
to be a problem with the escape-mechanism.

Stuff, like \~etc also does not work as expected.

Has this been introduced relatively recently? E.g.
as consequence of including support for multibyte
char sets?

Best,

		Ph.

On Sunday 06 July 2008 17:29, you wrote:
> On Sunday 06 July 2008, Philipp K. Janert wrote:
> > There seem to be some inconsistencies regarding
> > the behaviour of "escape" characters when using
> > enhanced text mode with Postscript terminals.
> >
> > According to the documentation, backslashes
> > escape control characters. Furthermore, single
> > backslashes should be used with single-quoted
> > strings, but double backslashes with double-quoted
> > strings.
> >
> > Here are the commands:
> > 	set label 1 at 0,0 "f\\{x\\}"
> > 	set label 2 at 0,1 'f\{x\}'
> > 	plot [-1:1][-1:2] 3
>
> This is a known bug.
> # 1968636  	  incorrect treatment of '\{' and '\}' in postscript
>
> It would be easy to fix, except that it may have bad side effects for
> multibyte encodings, in particular SJIS and EUC.  Shige Takeno was
> kind enough to investigate the earlier escape sequences.
> Perhaps he could do the same for this pair as well.
>
> 	Ethan
>
> > This should create two labels, looking like:
> > 	f{x}
> >
> > Everything looks good (as expected) using
> > wxt enhanced.
> >
> > But when using Postscript, I find output that
> > looks like this:
> > 	f\x\
> > for both labels.
> >
> > Is this a known issue?
> >
> > Best,
> >
> > 		Ph.

Re: Problems with Enhanced mode and Postscript

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

On Sunday 06 July 2008, Philipp K. Janert wrote:
> 
> There seem to be some inconsistencies regarding
> the behaviour of "escape" characters when using
> enhanced text mode with Postscript terminals.
> 
> According to the documentation, backslashes
> escape control characters. Furthermore, single
> backslashes should be used with single-quoted
> strings, but double backslashes with double-quoted
> strings.
> 
> Here are the commands:
> 	set label 1 at 0,0 "f\\{x\\}"
> 	set label 2 at 0,1 'f\{x\}'
> 	plot [-1:1][-1:2] 3

This is a known bug.
# 1968636  	  incorrect treatment of '\{' and '\}' in postscript

It would be easy to fix, except that it may have bad side effects for
multibyte encodings, in particular SJIS and EUC.  Shige Takeno was
kind enough to investigate the earlier escape sequences.
Perhaps he could do the same for this pair as well.

	Ethan


> This should create two labels, looking like:
> 	f{x}
> 
> Everything looks good (as expected) using
> wxt enhanced.
> 
> But when using Postscript, I find output that
> looks like this:
> 	f\x\
> for both labels.
> 
> Is this a known issue?
> 
> Best,
> 
> 		Ph.

Re: Global style directives

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

On Sunday 06 July 2008, Philipp K. Janert wrote:
> 
> The command
> 	set data style points
> sets the default style for data to points.
> 
> Is it somehow possible to include a point
> type in the global setting? Such as:
> 	set data style points pointtype 3

That wouldn't make any sense.
If the data sets are to be plotted as points, then the points
must be different in order to distinguish which data set each
is from.

> The command line as written does not work -
> is there some other syntax I am not aware of?

What are you trying to accomplish, exactly?

-- 
Ethan A Merritt

Problems with Enhanced mode and Postscript

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

There seem to be some inconsistencies regarding
the behaviour of "escape" characters when using
enhanced text mode with Postscript terminals.

According to the documentation, backslashes
escape control characters. Furthermore, single
backslashes should be used with single-quoted
strings, but double backslashes with double-quoted
strings.

Here are the commands:
	set label 1 at 0,0 "f\\{x\\}"
	set label 2 at 0,1 'f\{x\}'
	plot [-1:1][-1:2] 3

This should create two labels, looking like:
	f{x}

Everything looks good (as expected) using
wxt enhanced.

But when using Postscript, I find output that
looks like this:
	f\x\
for both labels.

Is this a known issue?

Best,

		Ph.

Global style directives

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

The command
	set data style points
sets the default style for data to points.

Is it somehow possible to include a point
type in the global setting? Such as:
	set data style points pointtype 3

The command line as written does not work -
is there some other syntax I am not aware of?

Re: new GPVAL_ variables

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

> > As an alternative suggestion, how about providing a string 
> > variable
> >   GPVAL_LAST_PLOT
> > that points to the same string reported by "show plot"?
> > One could inspect that string to see if the previous command
> > was 'plot' or 'splot'.

I've added to SF also a patch for GPVAL_TERMINALS, which contains names of 
all terminals compiled-in. I guess it might be useful as well.

Example:
gnuplot> print GPVAL_TERMINALS
 cgm corel dpu414 dumb dxf eepic emf emtex epslatex epson_180dpi epson_60dpi 
epson_lx800 fig gif gpic hp2623A hp2648 hp500c hpdj hpgl hpljii hppj imagen 
jpeg latex mf mif mp nec_cp6 okidata pbm pcl5 pdfcairo png pngcairo 
postscript pslatex pstex pstricks qms regis starc svg tandy_60dpi tek40xx 
tek410x texdraw tgif tkcanvas tpic unknown vttek wxt x11 xlib

gnuplot> print strstrt(GPVAL_TERMINALS, " png ")
208

---
PM

Re: new GPVAL_ variables

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

> > GPVAL_MULTIPLOT={0|1}
> 
> Maybe.  But if multiplot mode is involved then all the other settings
> are probably valid only for the final plot in the set.

I intended it mainly for the case when a script fails inside set multiplot.

> > GPVAL_PLOT={0|1}
> > GPVAL_SPLOT={0|1}
> 
> But I do not understand how one could use these.  They are only
> true inside a plot, and inside the plot how can you query them?

For binding hotkeys. Left and right arrows could have different bindings in 
plot and splot, e.g.
bind 'Left' if (GPVAL_PLOT) shift xrange left; replot; \
	else builtin_rotate_left

> As an alternative suggestion, how about providing a string 
> variable
>   GPVAL_LAST_PLOT
> that points to the same string reported by "show plot"?
> One could inspect that string to see if the previous command
> was 'plot' or 'splot'.

Good idea, I'm adding it. Having GPVAL_{S}PLOT is necessary anyway, since 
the plot command can start with "p ", "plo ", "sp ", ...

> > Does somebody find use for (need) other variables?
> 
> There was a question on the newsgroup, I think, about querying the
> information from a "show" command from a script.  For instance,
> I think there is no way for a script to check the name of the current
> output file.  Could we have another string variable GP_VAL_SHOW
> that always contains the result of the last "show" command? 

This would be nice. I guess it would need printing the "show output" into a 
text buffer.

---
PM

Re: new GPVAL_ variables

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

On Wednesday 02 July 2008 14:51:44 Petr Mikulik wrote:
> I've just updated 
> 
> Subject: [ gnuplot-Feature Requests-1939687 ] GPVAL_PLOT, _VIEW_X
> https://sourceforge.net/tracker/?func=detail&atid=352055&aid=1939687&group_id=2055
> 
> which adds new GPVAL_ automatic variables:
> 
> GPVAL_VIEW_ROT_X=double
> GPVAL_VIEW_ROT_Z=double
> GPVAL_VIEW_SCALE=double
> GPVAL_VIEW_SCALE_Z=double

These make sense to me.

> GPVAL_MULTIPLOT={0|1}
> GPVAL_VIEW_MAP={0|1}

Maybe.  But if multiplot mode is involved then all the other settings
are probably valid only for the final plot in the set.

> GPVAL_PLOT={0|1}
> GPVAL_SPLOT={0|1}

But I do not understand how one could use these.  They are only
true inside a plot, and inside the plot how can you query them?

As an alternative suggestion, how about providing a string 
variable
  GPVAL_LAST_PLOT
that points to the same string reported by "show plot"?
One could inspect that string to see if the previous command
was 'plot' or 'splot'.  Better yet....

> Does somebody find use for (need) other variables?

There was a question on the newsgroup, I think, about querying the
information from a "show" command from a script.  For instance,
I think there is no way for a script to check the name of the current
output file.  Could we have another string variable GP_VAL_SHOW
that always contains the result of the last "show" command? 

-- 
Ethan A Merritt

new GPVAL_ variables

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

I've just updated 

Subject: [ gnuplot-Feature Requests-1939687 ] GPVAL_PLOT, _VIEW_X
https://sourceforge.net/tracker/?func=detail&atid=352055&aid=1939687&group_id=2055

which adds new GPVAL_ automatic variables:

GPVAL_PLOT={0|1}
GPVAL_SPLOT={0|1}
GPVAL_VIEW_MAP={0|1}
GPVAL_VIEW_ROT_X=double
GPVAL_VIEW_ROT_Z=double
GPVAL_VIEW_SCALE=double
GPVAL_VIEW_SCALE_Z=double
GPVAL_MULTIPLOT={0|1}

Does somebody find use for (need) other variables?

---
PM

Re: Command line way to prevent unbuffered?

[Jim K. <je...@kl...>]

Ethan Merritt wrote:
> On Monday 10 January 2005 10:46 pm, Ethan Merritt wrote:
>>> diff -u -r1.72 plot.c
>>> --- plot.c    25 Aug 2004 22:33:16 -0000    1.72
>>> +++ plot.c    11 Jan 2005 05:26:21 -0000
>>> @@ -422,7 +422,9 @@
>>>       * Do any non-X platforms suffer from the same problem?
>>>       * EAM - Jan 2004.
>>>       */
>>> -    setvbuf(stdin, (char *) NULL, _IONBF, 0);
>>> +    if (isatty(fileno(stdin))) {
>>> +        setvbuf(stdin, (char *) NULL, _IONBF, 0);
>>> +    }
>>>  #endif
>>
>> I see why you want this.  But speed is no good if the program
>> does not function properly, and previous experience showed that
>> unbuffering the input stream was needed for at least some 
>> implementations of piped input.
> 
> I have changed my mind.  The behavior is not likely to differ
> from user to user, only from one platform to another. So it should
> be a configuration option for building on that platform, not a
> run-time option on the command line.
> 
> How about we wrap the code as follows:
> 
> #ifndef UNBUFFERED_STDIN
>     setvbuf(stdin, (char *) NULL, _IONBF, 0);
> #endif
> 
> and you can provide a brief set of instructions for how to set
> this conditional compilation flag during the cygwin configuration setup.
> I have not used cygwin, so I don't know exactly how that is done.
> 
> It would be nice if you also checked that this doesn't interfere
> with correct execution of "pause" commands, however, since as I
> recall that was one of the original problems this was supposed to fix.
> For instance, please check that "mousevariables.dem" works properly with 
> buffered input under cygwin. 


The attached patch achieves the speedup and works
properly with mousevariables.dem.

The use of __CYGWIN__ makes it specific to that platform.

I suspect this would also help other platforms.

Please consider for upstream inclusion.

Thanks - Jim

Re: Issues with wx temrinal

[MortenMacFly <ma...@gm...>]

Ethan Merritt wrote:
> 
> Is this a recent breakage, or has it always been like this?
> 
To be honest:; I don't know. I never used other than the default settings.
Just as of now I have so many data points that they get lost visually if I
use Antialiasing. that's why I tried switching it off.
I wonder if I am the only person that experiences the crashes...?!
-- 
View this message in context: http://www.nabble.com/Issues-with-wx-temrinal-tp18149773p18169610.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: Issues with wx temrinal

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

On Friday 27 June 2008 12:38:55 am MortenMacFly wrote:
> 
> Dear all,
> I am using the wx terminal and experienced strange issues on Windows (wx
> 2.87, compiled using MinGW, Gnuplot sources from CVS as of today).

Is this a recent breakage, or has it always been like this?





> 1.) The only setup working for the rendering method is Antialiasing and
> oversampling.
> If I choose any other method the dots (I am plotting measurement data as
> dots) are not visible and in addition the axis number got screwed up to ugly
> boxes.
> 
> 2.) If I choose the "don't quit" option (persist) then the Gnuplot window
> remains open (that's OK). But any command I am issuing than causes Gnuplot
> to crash badly.
> 
> I switched to the "usual" terminal again but just for the devs to notice.
> 
> With best regards, Morten.
> -- 
> View this message in context: http://www.nabble.com/Issues-with-wx-temrinal-tp18149773p18149773.html
> Sent from the Gnuplot - Dev mailing list archive at Nabble.com.
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> 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

Issues with wx temrinal

[MortenMacFly <ma...@gm...>]

Dear all,
I am using the wx terminal and experienced strange issues on Windows (wx
2.87, compiled using MinGW, Gnuplot sources from CVS as of today).

1.) The only setup working for the rendering method is Antialiasing and
oversampling.
If I choose any other method the dots (I am plotting measurement data as
dots) are not visible and in addition the axis number got screwed up to ugly
boxes.

2.) If I choose the "don't quit" option (persist) then the Gnuplot window
remains open (that's OK). But any command I am issuing than causes Gnuplot
to crash badly.

I switched to the "usual" terminal again but just for the devs to notice.

With best regards, Morten.
-- 
View this message in context: http://www.nabble.com/Issues-with-wx-temrinal-tp18149773p18149773.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

wxt not working in gnuplot 4.2

[seliv <sel...@ub...>]

Gnuplot 4.2 sets wxt terminal by default. However it does not work in my Dell
vostro 1510 with Linux ubuntu 8.04. When I plot something it shows the first
plot in wxt window, but then it is freezed, if I click on it, I see a
message that window does not respond and suggest to force quit. x11 and
other terminals work good.
If you know the reason why wxt does not work, let me know please.
-- 
View this message in context: http://www.nabble.com/wxt-not-working-in-gnuplot-4.2-tp18132011p18132011.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

wxt not working in gnuplot 4.2

[seliv <sel...@ub...>]

I have another puzzle with wxt in gnuplot 4.2, which sets wxt terminal by
default.
When I plot something it shows the first plot in wxt window, but then it is
freezed, if I click on it, I see a message that window does not respond and
suggest to force quit. x11 and other terminals work good. I have Dell vostro
1510 with Linux ubuntu 8.04.
If you know the reason why wxt does not work, let me know please.

-- 
View this message in context: http://www.nabble.com/No-redraw-with-wxt-and-%27noraise%27-tp15150329p18130950.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: Revised: Smooth Histograms

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

On Monday 23 June 2008 09:39:35 pm Philipp K. Janert wrote:
> 
> Based on some of the comments I have received,
> I have revised my code for smooth histograms
> using kernel density estimates and updated the
> examples at:
> 	http://www.philipp-janert.com/kdensity/
> 
> Please take another look.

Those example plots look very nice.
I might even use this feature :-)

	Ethan

Revised: Smooth Histograms

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

Based on some of the comments I have received,
I have revised my code for smooth histograms
using kernel density estimates and updated the
examples at:
	http://www.philipp-janert.com/kdensity/

Please take another look.

Best,

		Ph.

Re: AutoIncrement with Monochrome Solid Fill Patterns

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

Agreed. 

Sometimes a gray-palette would be nice to have
though, simply because it looks nice (less jagged
than cross-hatch patterns).

Cross-hatch has the advantage on grayscale
that it reproduces much better under Xeroxing,
of course.

Best,

		Ph.



On Sunday 22 June 2008 22:50, you wrote:
> On Sunday 22 June 2008 19:26, Philipp K. Janert wrote:
> > Imagine I use a style that makes use of fill patterns,
> > such as one of the histogram styles.
> >
> > Let's also assume I am using a fill style "solid".
> > Using a color terminal, each new data set gets a
> > new color and everything is good.
> >
> > But if I try to export the result to a monochrome
> > terminal (eg. EPS), all distinction is of course lost.
> >
> > Is it possible to convince gnuplot not to change
> > color from data set to data set, but instead increase
> > the density (thus giving an appearance of gray scales)?
>
> No, but if you choose a pattern fill it will cycle through
> successive patterns.  See histogram2.dem
> Some terminals substitute density variation for patterns because
> they are not good at pattern-fill.

Re: Line type for fill style "pattern"

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

Thanks. That's what I was looking for.

	set terminal ... solid

;-)

Best,

		Ph.


On Monday 23 June 2008 02:45, Thomas Sefzick wrote:
> what's about
> set terminal postscript eps monochrome solid
> ?
>
> > When using gnuplot 4.2 and using fill style "pattern"
> > and exporting to monochrome EPS,
> > the line type used for the pattern increases with the
> > pattern, so that the fill pattern 2 is drawn with dashed
> > lines, and fill pattern 3 is drawn with dotted lines, etc
> >
> > This does not look that great - it would be better if
> > the patterns were all drawn with solid lines.

Re: Line type for fill style "pattern"

[Thomas S. <t.s...@fz...>]

what's about
set terminal postscript eps monochrome solid
?

> When using gnuplot 4.2 and using fill style "pattern"
> and exporting to monochrome EPS, 
> the line type used for the pattern increases with the
> pattern, so that the fill pattern 2 is drawn with dashed
> lines, and fill pattern 3 is drawn with dotted lines, etc
>
> This does not look that great - it would be better if
> the patterns were all drawn with solid lines.

-- 
View this message in context: http://www.nabble.com/Line-type-for-fill-style-%22pattern%22-tp18061584p18065879.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: AutoIncrement with Monochrome Solid Fill Patterns

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

On Sunday 22 June 2008 19:26, Philipp K. Janert wrote:
> 
> Imagine I use a style that makes use of fill patterns,
> such as one of the histogram styles.
> 
> Let's also assume I am using a fill style "solid".
> Using a color terminal, each new data set gets a
> new color and everything is good.
> 
> But if I try to export the result to a monochrome 
> terminal (eg. EPS), all distinction is of course lost.
> 
> Is it possible to convince gnuplot not to change 
> color from data set to data set, but instead increase
> the density (thus giving an appearance of gray scales)?

No, but if you choose a pattern fill it will cycle through
successive patterns.  See histogram2.dem
Some terminals substitute density variation for patterns because
they are not good at pattern-fill.

-- 
Ethan A Merritt

Line type for fill style "pattern"

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

When using gnuplot 4.2 and using fill style "pattern"
and exporting to monochrome EPS, 
the line type used for the pattern increases with the
pattern, so that the fill pattern 2 is drawn with dashed
lines, and fill pattern 3 is drawn with dotted lines, etc

This does not look that great - it would be better if
the patterns were all drawn with solid lines.

Is this desired behavior or a bug? Is there a way to
let gnuplot autoincrement the fill pattern, but keep
with linestyle 1?

("set style fill pattern border 1" will not do it.)

Best,

		Ph.

AutoIncrement with Monochrome Solid Fill Patterns

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

Imagine I use a style that makes use of fill patterns,
such as one of the histogram styles.

Let's also assume I am using a fill style "solid".
Using a color terminal, each new data set gets a
new color and everything is good.

But if I try to export the result to a monochrome 
terminal (eg. EPS), all distinction is of course lost.

Is it possible to convince gnuplot not to change 
color from data set to data set, but instead increase
the density (thus giving an appearance of gray scales)?

Best,

		Ph.

Reference for acsplines algorithm?

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

Could somebody point me to a reference for
the weighted splines approximation used by
gnuplot's "acsplines" algorithm?

Best,

		Ph.

Re: Compilation instructions for Windows and Mac OS X

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

On Wednesday 18 June 2008 10:36:16 am Ethan Merritt wrote:

> The aquaterm version on http://aquaterm.darwinports.com/
> is newer than the one on SourceForge.  I think (not sure) that you
> need the newer one if you are using Leopard.
>
> Development of aquaterm seems to have stagnated.
> Gnuplot actually supports aquaterm features (e.g. transparency)
> that never made it into the aquaterm version on SourceForge.
> I have not checked the Darwin port.
> 

I must correct that. I see that support for transparency was added to
the core aquaterm source about a year ago, and was tagged for release 1.1
But there is no pre-built binary package for version 1.1 on the SourceForge site.
The newest is 1.0.1 from two years ago. 

If I can figure out how to test for the aquaterm version number in ./configure,
I will try conditionally enabling the transparency in aquaterm.trm
and try to rebuild aquaterm itself from the 1.1 source.
Of course, I'll have to borrow another Mac for this...

	Ethan