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

Re: set style increment user

[sfeam <sf...@us...>]

On Wednesday, 02 July 2014 04:54:08 PM Allin Cottrell wrote:
> On Wed, 2 Jul 2014, Christoph Bersch wrote:
> 
> > Am 02.07.2014 16:50, schrieb Allin Cottrell:
> >> The above-noted "set" option is one that is gone in 5.0. I'm not sure what
> >> is the recommended replacement. I'm thinking of this sort of thing in
> >> gnuplot 4:
> >>
> >> set style line 1 <whatever>
> >> set style line 2 <whatever>
> >> set style line 3 <whatever>
> >> set style increment user
> >> plot <data1> w l, <data2> w l, <data3> w l
> >>
> >> and the 3 lines would come out in the respective 3 user-defined styles.
> >> Now admittedly the "increment user" thing seemed a bit odd; you might
> >> expect the user-defined line-styles to apply automatically. However, it
> >> did the job. Now that it's gone, is there a compact alternative way of
> >> telling gnuplot to use user-defined styles in sequence?
> >
> > Now you can directly change the linetypes with
> >
> > set linetype 1 <whatever>
> > set linetype 2 <whatever>
> > set linetype 3 <whatever>
> > plot x w l, x**2 w l, x**3 w l
> >
> > Note, that these settings cannot be reverted by `reset`, but you must
> > use `reset session`.
> 
> Thanks. The new design is an improvement in its own right (use "set 
> linetype" and you don't have to bother with the "increment" switch). 
> But if the "increment" thing is gone this will break a lot of 
> existing gnuplot scripts that use "set style line" -- and also a 
> fair amount of third-party code that generates such scripts.
> 
> I notice that the current doc for 5.0 just says that "set style 
> increment user" is "deprecated". However, it's actually _gone_ 
> unless you explicitly configure with
> 
> --enable-backwards-compatibility
> 
> I have no problem with deprecating it in favour of the new approach, 
> but trashing it at this point seems extreme.

It was already deprecated in 4.6, so it's not as if this is coming
out of the blue.

Furthermore, it is still available along with other deprecated 
syntax features if you do 
  ./configure --enable-backwards-compatibility

Nevertheless, several people have requested that "set style increment"
be included by default in 5.0 even if it is deprecated.
So I think it will come back in -rc2

	Ethan

Re: set style increment user

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

On Wed, 2 Jul 2014, Christoph Bersch wrote:

> Am 02.07.2014 16:50, schrieb Allin Cottrell:
>> The above-noted "set" option is one that is gone in 5.0. I'm not sure what
>> is the recommended replacement. I'm thinking of this sort of thing in
>> gnuplot 4:
>>
>> set style line 1 <whatever>
>> set style line 2 <whatever>
>> set style line 3 <whatever>
>> set style increment user
>> plot <data1> w l, <data2> w l, <data3> w l
>>
>> and the 3 lines would come out in the respective 3 user-defined styles.
>> Now admittedly the "increment user" thing seemed a bit odd; you might
>> expect the user-defined line-styles to apply automatically. However, it
>> did the job. Now that it's gone, is there a compact alternative way of
>> telling gnuplot to use user-defined styles in sequence?
>
> Now you can directly change the linetypes with
>
> set linetype 1 <whatever>
> set linetype 2 <whatever>
> set linetype 3 <whatever>
> plot x w l, x**2 w l, x**3 w l
>
> Note, that these settings cannot be reverted by `reset`, but you must
> use `reset session`.

Thanks. The new design is an improvement in its own right (use "set 
linetype" and you don't have to bother with the "increment" switch). 
But if the "increment" thing is gone this will break a lot of 
existing gnuplot scripts that use "set style line" -- and also a 
fair amount of third-party code that generates such scripts.

I notice that the current doc for 5.0 just says that "set style 
increment user" is "deprecated". However, it's actually _gone_ 
unless you explicitly configure with

--enable-backwards-compatibility

I have no problem with deprecating it in favour of the new approach, 
but trashing it at this point seems extreme.

Allin Cottrell

Re: set style increment user

[Christoph B. <us...@be...>]

Am 02.07.2014 16:50, schrieb Allin Cottrell:
> The above-noted "set" option is one that is gone in 5.0. I'm not sure what
> is the recommended replacement. I'm thinking of this sort of thing in
> gnuplot 4:
>
> set style line 1 <whatever>
> set style line 2 <whatever>
> set style line 3 <whatever>
> set style increment user
> plot <data1> w l, <data2> w l, <data3> w l
>
> and the 3 lines would come out in the respective 3 user-defined styles.
> Now admittedly the "increment user" thing seemed a bit odd; you might
> expect the user-defined line-styles to apply automatically. However, it
> did the job. Now that it's gone, is there a compact alternative way of
> telling gnuplot to use user-defined styles in sequence?

Now you can directly change the linetypes with

set linetype 1 <whatever>
set linetype 2 <whatever>
set linetype 3 <whatever>
plot x w l, x**2 w l, x**3 w l

Note, that these settings cannot be reverted by `reset`, but you must 
use `reset session`.

Christoph

scroll redraw bug

[<pl...@pi...>]

Hi,

a minor defect I just noticed :

I have a multi-line plot in wxt. I toggle two of the four lines off 
using the mouse in the legend.


If I scroll x-axis slowly using shift key it works fine . If I do it 
quickly it redraws with all lines visible.

         G N U P L O T
         Version 5.0 patchlevel alpha    last modified 2014-05-10


Peter.

set style increment user

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

The above-noted "set" option is one that is gone in 5.0. I'm not sure what 
is the recommended replacement. I'm thinking of this sort of thing in 
gnuplot 4:

set style line 1 <whatever>
set style line 2 <whatever>
set style line 3 <whatever>
set style increment user
plot <data1> w l, <data2> w l, <data3> w l

and the 3 lines would come out in the respective 3 user-defined styles. 
Now admittedly the "increment user" thing seemed a bit odd; you might
expect the user-defined line-styles to apply automatically. However, it 
did the job. Now that it's gone, is there a compact alternative way of 
telling gnuplot to use user-defined styles in sequence?

If I simply comment out the "increment user" line above in gnuplot 5.0, 
the user-styles are ignored in favor of the default ones. I can get them 
to be used by doing

plot <data1> ls 1 w l, <data2> ls 2 w l, <data3> ls 3 w l

But this is "more work," and creates more opportunity for error, than 
arranging just once for the styles to be used sequentially.

Allin Cottrell

Re: terminal quirks, wxt vs qt

[sfeam <sf...@us...>]

On Sunday, June 29, 2014 10:21:53 AM Allin Cottrell wrote:
 With the qt term I'm seeing different behavior in gnuplot 4.6.5
> versus the 5.0 rc. In 5.0 it works very nicely with "pause mouse close",
> but in 4.6.5 it's a bit odd: I can't "ungrab" the image -- that is, any
> mouse motion rotates the image, regardless of buttons pressed or not --
> and then closing the plot window doesn't cause gnuplot to exit.
> 
> Allin Cottrell

That bug, qt terminal failure to recognize "unclick", is fixed in CVS for 4.6.
The fix will be in 4.6.6

	Ethan   

Re: press 'q' in plot window does not close window on windows terminal

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

----- Original Message -----

> From: Petr Mikulik
> To: Tatsuro MATSUOKA 
> Cc: gnuplot-beta
> Date: 2014/7/1, Tue 20:50
> Subject: Re: press 'q' in plot window does not close window on windows terminal
> 
>>  I have noticed that press 'q' in plot window does not close window 
> on windows terminal.
> 
> Yes, it never did. Obviously everbody is usng Alt-F4 instead. But it should be 
> easy to add.
> 
>>  The pressing 'q' behavior on windows terminal is not mentioned in 
> the section
>>  of windows terminal in the gnuplot manual.
>>  Therefore this is not a bug.
> 
> But it is mentioned in the help you get by pressing "h".


Indeed! It is better to implement close plot windows feature by pressing 'q'.


>>  I do not know other platform dependent interactive terminal like aqua or 
> pm.
> 
> pm accepts "q".

Thanks!

Tatsuro

Re: press 'q' in plot window does not close window on windows terminal

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

> I have noticed that press 'q' in plot window does not close window on windows terminal.

Yes, it never did. Obviously everbody is usng Alt-F4 instead. But it should be 
easy to add.

> The pressing 'q' behavior on windows terminal is not mentioned in the section
> of windows terminal in the gnuplot manual.
> Therefore this is not a bug.

But it is mentioned in the help you get by pressing "h".

> I do not know other platform dependent interactive terminal like aqua or pm.

pm accepts "q".

---
PM

Re: gnuplot 4.8?

[<pl...@pi...>]

On 07/01/14 10:03, Karl Ratzsch wrote:
>
> Am 01.07.2014 06:39, schrieb Tatsuro MATSUOKA:
>
>>>
>> I have lost the record or memory how to access stable branch on the cvs repository.
>> I will appreciate if you show me the way
>>
>> Tatsuro
>>
>
>    export
> CVSROOT=:pserver:ano...@gn...:/cvsroot/gnuplot
>    cvs login
>    cvs -z3 checkout -r branch-4-6-stable -d gnuplot46 gnuplot
>
> This really should be mentioned somewhere on the gnuplot.info homepage.
>
>    Karl
>

I did point out about a month ago that it was not particularly easy to 
find cvs instruction.

/Peter.

press 'q' in plot window does not close window on windows terminal

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

I have noticed that press 'q' in plot window does not close window on windows terminal.
For wxt, qt, caca, and x11, pressing 'q' causes the close of the plot window.

The pressing 'q' behavior on windows terminal is not mentioned in the section
of windows terminal in the gnuplot manual.
Therefore this is not a bug.

But the behavior is hopefully unified.

I do not know other platform dependent interactive terminal like aqua or pm.

Regards

Tatsuro

Re: How to get key information from qt terminal to gnuplot

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

In the gnuplot manual for 4.6 and 5.0rc-1, the below is described in the qt terminal subsection.

By default, the window is raised to the top of your desktop when a plot is drawn. This can be controlled
with the keyword "raise". The keyword "persist" will prevent gnuplot from exiting before you explicitely
close all the plot windows. Finally, by default the key <space> raises the gnuplot console window, and 'q'
closes the plot window. The keyword "ctrl" allows you to replace those bindings by <ctrl>+<space> and
<ctrl>+'q', respectively.

However, no codes are described for "key <space> raises the gnuplot console window" so far.
I have tried to revise mouse.c for qt (only for windows) as Ethan was suggested. 

I build patched binary with debug option and traced with gdb. The space key code is trasfered to mouse.c 
by pressing space key on plot windows and WinRaiseConsole() is executed.
But without break, pressing space key on plot windows did not raise console.

Perhaps I have misled but I cannot find where is wrong.

Anyway, I think that the situation is not much with the manual for qt terminal concerning raise console feature.
If I am misleading the situation, please pointed it out.

Tatsuro

Re: gnuplot 4.8?

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

----- Original Message -----
> From: Karl Ratzsch 
> To: gnuplot-beta
> Cc: 
> Date: 2014/7/1, Tue 17:03
> Subject: Re: gnuplot 4.8?
> 
> Am 01.07.2014 06:39, schrieb Tatsuro MATSUOKA:
> 
>>> 
>>  I have lost the record or memory how to access stable branch on the cvs 
> repository.
>>  I will appreciate if you show me the way
>> 
>>  Tatsuro 
>> 
> 
>   export
> CVSROOT=:pserver:ano...@gn...:/cvsroot/gnuplot
>   cvs login
>   cvs -z3 checkout -r branch-4-6-stable -d gnuplot46 gnuplot
> 
> This really should be mentioned somewhere on the gnuplot.info homepage.
> 
>   Karl


Thanks Karl
I could check out the branch-4-6-stable source.

> This really should be mentioned somewhere on the gnuplot.info homepage.

It will be nice to try recent fixed stable source.

Re: gnuplot 4.8?

[Karl R. <ra...@un...>]

Am 01.07.2014 06:39, schrieb Tatsuro MATSUOKA:

>>
> I have lost the record or memory how to access stable branch on the cvs repository.
> I will appreciate if you show me the way
> 
> Tatsuro 
> 

  export
CVSROOT=:pserver:ano...@gn...:/cvsroot/gnuplot
  cvs login
  cvs -z3 checkout -r branch-4-6-stable -d gnuplot46 gnuplot

This really should be mentioned somewhere on the gnuplot.info homepage.

  Karl

-- 
Karl-Friedrich Ratzsch (Dipl. Chem.)
Freiburger Materialforschungszentrum / Universität Freiburg
Stefan-Meier-Straße 21, 79104 Freiburg im Breisgau
Tel. 0761/203-4748 Fax:-4701
ra...@un...

Re: gnuplot 4.8?

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

----- Original Message -----
> From: Tatsuro MATSUOKA
> To: Merritt Ethan 
> Cc: gnuplot-beta Allin Cottrell
> Date: 2014/7/1, Tue 04:21
> Subject: Re: gnuplot 4.8?
> 
> 
> 
> 
> 
> ----- Original Message -----
>>  From: sfeam 
>>  To: Tatsuro MATSUOKA 
>>  Cc: gnuplot-beta Allin Cottrell
>>  Date: 2014/6/30, Mon 23:25
>>  Subject: Re: gnuplot 4.8?
>> 
>>  On Monday, June 30, 2014 06:10:24 PM Tatsuro MATSUOKA wrote:
>>>   ----- Original Message -----
>>> 
>>>   > From: sfeam 
>>>   > To: gnuplot-beta
>>>   > Cc: Allin Cottrell 
>>>   > Date: 2014/6/30, Mon 05:16
>>>   > Subject: Re: gnuplot 4.8?
>>>   > 
>>>   > On Sunday, June 29, 2014 03:44:23 PM Allin Cottrell wrote:
>>>   >>  I understand that 5.0 is supposed to be the release where 
> the
>>>   >>  gnuplot developers are free to make some 
> backward-incompatible
>>>   >>  changes. I've no problem with that, but I wonder if 
>>  there's any
>>>   >>  thought to produce a gnuplot 4.8?
>>>   > 
>>>   > The 4.6 development source is a separate branch in CVS.
>>>   > The 4.7 (later 5.0) branch split off from it and gradually 
> diverged.
>>>   > Most bugfixes have been applied to both branches, but they have
>>>   > diverged enough that in some cases the "fix" for a 
> problem 
>>  in 4.6
>>>   > is limited to the existence of a better implementation in 5.0.
>>>   > 
>>>   > There will be at least one more patchlevel release 4.6.6.
>>>   > My crystal ball does not tell me at what rate fixable bugs will 
>>  continue
>>>   > to be reported againt 4.6 as opposed to 5.0.  Other incremental
>>>   > releases could eventually appear, but I don't see a good 
> rationale 
>>  for
>>>   > starting a 4.8  series.   If a fix/change is compatible then it 
> could 
>>  go
>>>   > into 4.6; if not then it belongs in 5.0.
>>>   > 
>>>   > A brief listing of changes accumulated since the last release is
>>>   > kept at the top of the NEWS files:
>>>   > 
>>>   > NEWS
>>>   > New features, changes and fixes in gnuplot version 4.6.6
>>>   > ========================================================
>>>   > 
>>>   > * NEW linetype keyword "nodraw" can be used to draw 
> only the 
>>  points in
>>>   > "with lp"
>>>   > * NEW plot option to "skip N" lines at start of an 
> ascii 
>>  data file
>>>   > * NEW 'set fit prescale' normalized fit parameters before 
> M-L 
>>  refinement
>>>   > * NEW update svg terminal to grey out the key entry when a plot 
> is 
>>  toggled
>>>   > off * CHANGE Accept "with image pixels" as a synonym 
> for 
>>  "with image
>>>   > failsafe"
>>>   > * CHANGE return NaN if a requested numerical data value fins a 
> string
>>>   > instead * CHANGE Consume only one space following the font name 
> in an
>>>   > enhanced test string
>>>   > * FIX Faster recovery from outboard server gnuplot_qt being 
> killed
>>>   > * FIX get rid of O(N^2) memory allocation for string data in long 
> 
>>  input
>>>   > lines * FIX large integers in iteration spec could cause overflow 
> end
>>>   > condition check * FIX object fillcolors should be consistent with 
> the
>>>   > color of current linetypes * FIX LFS support on 64bit platforms 
> (not
>>>   > backported for 32bit platforms) * FIX timecolumn() applied to 
> non-axis
>>>   > data reports an error rather than faulting
>>>   > * FIX clipping could fail on integer overflow
>>>   > * FIX segfault resulting from strcol(N) applied to empty field in 
> a 
>>  *.csv
>>>   > file * FIX adjustment of key size to accommodate long key title
>>>   > * FIX treat data value read as "NaN" the same as we 
> would
>>>   > "1/0"
>>>   > * FIX handling of events triggered by closing the qt plot window
>>>   > * FIX iteration failure due to integer overflow
>>>   > * FIX clip r axis tics to current plot boundary
>>>   > * FIX logscale cb axis with volatile data
>>>   > 
>>>   >     Ethan
>>> 
>>>   Do you really make package of gnuplot-4.6.6?
>>>   If it will be upload on the web, I can prepare windows and Cygwin 
> binaries
>>>   both for 32 and 64 bit.
>> 
>>  I have shown the NEWS file from the 4.6 CVS repository.
>>  Each PATCHLEVEL release is basically a snapshot of the repository.
>>  4.6.5 was a snapshot from February 2014.
>>  Some time later this year we will take another snapshot and this will
>>  be release 4.6.6.   It will contain the changes listed above and any
>>  other changes made between now and the tie of release.
>> 
>>      Ethan
> 
> 
> OK.Thanks!
> 
> Tatsuro
> 
I have lost the record or memory how to access stable branch on the cvs repository.
I will appreciate if you show me the way

Tatsuro 

Re: enhanced text default in 5.0

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

On 06/30/2014 09:30 PM, Allin Cottrell wrote:
> On Mon, 30 Jun 2014, Daniel J Sebald wrote:
>
>> On 06/30/2014 08:45 PM, Daniel J Sebald wrote:
>>> On 06/30/2014 08:32 PM, Allin Cottrell wrote:
>>>> Is there any way you could provide a global switch to turn off the
>>>> "enhanced text" default in gnuplot 5.0? I'm afraid it's a pain to
>>>> have to guard against underscores coming out as subscript markers.
>>>
>>> Allin,
>>>
>>> You may set whatever parameters you like via the startup script. See
>>> "help startup".
>>
>> I guess I should give an example seeing as you used "set termoption" to
>> change the value. Place the following in a startup script:
>>
>> set term pngcairo noenhanced
>> set term qt noenhanced
>> set term wxt noenhanced
>
> Thanks. I tried just putting
>
> set termoption noenhanced
>
> into ~/.gnuplot. This works OK for wxt but not for pngcairo,

Yes, "set termoption" only works for the current terminal.  It is not a 
global setting.


> although
> oddly enough it suppresses the printing of "enhanced" in "show term":
>
> <gnuplot-startup>
> Terminal type set to 'wxt'
> gnuplot> show term
>
> terminal type is wxt 0 noenhanced
>
> gnuplot> set term pngcairo
> Terminal type set to 'pngcairo'
> Options are ' background "#ffffff" fontscale 1.0 size 640, 480 '
> </gnuplot>
>
> No "enhanced" shown for pngcairo (as in my previous post) but
> underscores become subscripts all the same.
>
> Actually, although the start-up file approach is certainly useful it
> doesn't fully meet the case I'm thinking of. That way I can tweak the
> appearance of gnuplot for myself, but not necessarily for other users of
> "my" econometric software that uses gnuplot as plotting engine: I
> wouldn't want to trample on a ~/.gnuplot file they might already have,
> whereas I'd be fine with setting a per-session global preference if it
> were available.

I don't see what the problem is with asking the user to change their 
settings to "noenhanced".  (What if they want enhanced?)  There might be 
another approach.  Try

gnuplot> set term push
    pushed terminal qt 0 font "Sans,9"
gnuplot> set termoption noenhanced
gnuplot> show term

    terminal type is qt 0 noenhanced font "Sans,9"

gnuplot> set term pop
    restored terminal is qt 0 font "Sans,9"

Dan

Re: enhanced text default in 5.0

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

On 06/30/2014 10:10 PM, Allin Cottrell wrote:
> On Mon, 30 Jun 2014, Daniel J Sebald wrote:
[snip]
>> I don't see what the problem is with asking the user to change their
>> settings to "noenhanced". (What if they want enhanced?)
>
> It's not really a matter of preference: I'm thinking of, for example,
> printing the name of a variable which includes one or more underscores
> in a key, title or label of some sort. It's just broken if that turns
> into a subscript.

gnuplot> help enhanced
[snip]
  This mode is selected by default when you set the terminal, but may be
  toggled afterward using "set termoption [no]enhanced", or by marking
  individual strings as in "set label 'x_2' noenhanced".

Something I didn't know about.  It works here.

Dan

Re: enhanced text default in 5.0

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

On Mon, 30 Jun 2014, Daniel J Sebald wrote:

> On 06/30/2014 09:30 PM, Allin Cottrell wrote:
>> On Mon, 30 Jun 2014, Daniel J Sebald wrote:
>> 
>>> On 06/30/2014 08:45 PM, Daniel J Sebald wrote:
>>>> On 06/30/2014 08:32 PM, Allin Cottrell wrote:
>>>>> Is there any way you could provide a global switch to turn off the
>>>>> "enhanced text" default in gnuplot 5.0? I'm afraid it's a pain to
>>>>> have to guard against underscores coming out as subscript markers.
>>>> 
>>>> Allin,
>>>> 
>>>> You may set whatever parameters you like via the startup script. See
>>>> "help startup".
>>> 
>>> I guess I should give an example seeing as you used "set termoption" to
>>> change the value. Place the following in a startup script:
>>> 
>>> set term pngcairo noenhanced
>>> set term qt noenhanced
>>> set term wxt noenhanced
>> 
>> Thanks. I tried just putting
>> 
>> set termoption noenhanced
>> 
>> into ~/.gnuplot. This works OK for wxt but not for pngcairo,
>
> Yes, "set termoption" only works for the current terminal.  It is not a 
> global setting.

OK, fair enough. Though it does seem to be having _some_ 
quasi-global effect, in that it influences what the cairo terminal 
prints in reponse to "show term"...

>> although
>> oddly enough it suppresses the printing of "enhanced" in "show term":
>> 
>> <gnuplot-startup>
>> Terminal type set to 'wxt'
>> gnuplot> show term
>> 
>> terminal type is wxt 0 noenhanced
>> 
>> gnuplot> set term pngcairo
>> Terminal type set to 'pngcairo'
>> Options are ' background "#ffffff" fontscale 1.0 size 640, 480 '
>> </gnuplot>
>> 
>> No "enhanced" shown for pngcairo (as in my previous post) but
>> underscores become subscripts all the same.
>> 
>> Actually, although the start-up file approach is certainly useful it
>> doesn't fully meet the case I'm thinking of. That way I can tweak the
>> appearance of gnuplot for myself, but not necessarily for other users of
>> "my" econometric software that uses gnuplot as plotting engine: I
>> wouldn't want to trample on a ~/.gnuplot file they might already have,
>> whereas I'd be fine with setting a per-session global preference if it
>> were available.
>
> I don't see what the problem is with asking the user to change their settings 
> to "noenhanced".  (What if they want enhanced?)

It's not really a matter of preference: I'm thinking of, for 
example, printing the name of a variable which includes one or more 
underscores in a key, title or label of some sort. It's just broken 
if that turns into a subscript.

Allin Cottrell

Re: enhanced text default in 5.0

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

On Mon, 30 Jun 2014, Daniel J Sebald wrote:

> On 06/30/2014 08:45 PM, Daniel J Sebald wrote:
>> On 06/30/2014 08:32 PM, Allin Cottrell wrote:
>>> Is there any way you could provide a global switch to turn off the
>>> "enhanced text" default in gnuplot 5.0? I'm afraid it's a pain to
>>> have to guard against underscores coming out as subscript markers.
>>
>> Allin,
>>
>> You may set whatever parameters you like via the startup script.  See
>> "help startup".
>
> I guess I should give an example seeing as you used "set termoption" to
> change the value.  Place the following in a startup script:
>
> set term pngcairo noenhanced
> set term qt noenhanced
> set term wxt noenhanced

Thanks. I tried just putting

set termoption noenhanced

into ~/.gnuplot. This works OK for wxt but not for pngcairo, 
although oddly enough it suppresses the printing of "enhanced" in 
"show term":

<gnuplot-startup>
Terminal type set to 'wxt'
gnuplot> show term

    terminal type is wxt 0 noenhanced

gnuplot> set term pngcairo
Terminal type set to 'pngcairo'
Options are ' background "#ffffff" fontscale 1.0 size 640, 480 '
</gnuplot>

No "enhanced" shown for pngcairo (as in my previous post) but 
underscores become subscripts all the same.

Actually, although the start-up file approach is certainly useful it 
doesn't fully meet the case I'm thinking of. That way I can tweak 
the appearance of gnuplot for myself, but not necessarily for other 
users of "my" econometric software that uses gnuplot as plotting 
engine: I wouldn't want to trample on a ~/.gnuplot file they might 
already have, whereas I'd be fine with setting a per-session global 
preference if it were available.

Allin Cottrell

Re: enhanced text default in 5.0

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

On Mon, 30 Jun 2014, Daniel J Sebald wrote:

> On 06/30/2014 08:32 PM, Allin Cottrell wrote:
>> Is there any way you could provide a global switch to turn off the
>> "enhanced text" default in gnuplot 5.0? I'm afraid it's a pain to
>> have to guard against underscores coming out as subscript markers.
>
> Allin,
>
> You may set whatever parameters you like via the startup script.  See
> "help startup".

Thanks, that does indeed do the trick. Sorry I missed it.

Allin Cottrell

Re: enhanced text default in 5.0

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

On 06/30/2014 08:45 PM, Daniel J Sebald wrote:
> On 06/30/2014 08:32 PM, Allin Cottrell wrote:
>> Is there any way you could provide a global switch to turn off the
>> "enhanced text" default in gnuplot 5.0? I'm afraid it's a pain to
>> have to guard against underscores coming out as subscript markers.
>
> Allin,
>
> You may set whatever parameters you like via the startup script.  See
> "help startup".

I guess I should give an example seeing as you used "set termoption" to 
change the value.  Place the following in a startup script:

set term pngcairo noenhanced
set term qt noenhanced
set term wxt noenhanced

The terminal options are persistent across changes.  I suppose if one 
expects to use a lot of terminals, then the list gets long, but there's 
no typing upon startup so not cumbersome.  Maybe a global option somehow 
would be good, but if I recall correctly there never was any consistency 
of options across terminals.  Each terminal can have it's unique options.

Dan

Re: enhanced text default in 5.0

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

On 06/30/2014 08:32 PM, Allin Cottrell wrote:
> Is there any way you could provide a global switch to turn off the
> "enhanced text" default in gnuplot 5.0? I'm afraid it's a pain to
> have to guard against underscores coming out as subscript markers.

Allin,

You may set whatever parameters you like via the startup script.  See 
"help startup".


> BTW, this isn't very nice:
>
> myrtle:~$ /opt/gnuplot/bin/gnuplot
>
>           G N U P L O T
>           Version 5.0 patchlevel rc1    last modified 2014-06-24
>
>           Copyright (C) 1986-1993, 1998, 2004, 2007-2014
>           Thomas Williams, Colin Kelley and many others
>
>           gnuplot home:     http://www.gnuplot.info
>           mailing list:     gnu...@li...
>           faq, bugs, etc:   type "help FAQ"
>           immediate help:   type "help"  (plot window: hit 'h')
>
> Terminal type set to 'wxt'
> gnuplot>  set term pngcairo noenhanced
> Terminal type set to 'pngcairo'
> Options are ' background "#ffffff" enhanced fontscale 1.0 size 640, 480 '
> gnuplot>  set termoption noenhanced
> gnuplot>  show term
>
>      terminal type is pngcairo  background "#ffffff" enhanced
> fontscale 1.0 size 640, 480
>
> After the "set termoption" command, at least, it seems that
> "enhanced" is in fact turned off, but that's not what's shown. The
> guest that won't leave!

Looks like a bug in pngcairo terminal, shouldn't be too difficult to 
come up with a patch file.  The "noenhanced" setting/display works here 
on x11 and on qt.  I would say there is some inconsistency the way this 
info is displayed.  For example, for x11 enhanced is "enhanced" and 
noenhanced is absence of "enhanced" while for qt enhanced is absence of 
"noenhanced" and noenhanced is "noenhanced".  I.e.:

gnuplot> set term x11
Terminal type set to 'x11'
Options are ' nopersist enhanced'
gnuplot> set term x11 noenhanced
Terminal type set to 'x11'
Options are ' nopersist'
gnuplot> set term qt
Terminal type set to 'qt'
Options are '0 font "Sans,9"'
gnuplot> set term qt noenhanced
Terminal type set to 'qt'
Options are '0 noenhanced font "Sans,9"'

Not that important.  Not that confusing.  Just consistency.

Dan

enhanced text default in 5.0

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

Is there any way you could provide a global switch to turn off the 
"enhanced text" default in gnuplot 5.0? I'm afraid it's a pain to 
have to guard against underscores coming out as subscript markers.

BTW, this isn't very nice:

myrtle:~$ /opt/gnuplot/bin/gnuplot

         G N U P L O T
         Version 5.0 patchlevel rc1    last modified 2014-06-24

         Copyright (C) 1986-1993, 1998, 2004, 2007-2014
         Thomas Williams, Colin Kelley and many others

         gnuplot home:     http://www.gnuplot.info
         mailing list:     gnu...@li...
         faq, bugs, etc:   type "help FAQ"
         immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to 'wxt'
gnuplot> set term pngcairo noenhanced
Terminal type set to 'pngcairo'
Options are ' background "#ffffff" enhanced fontscale 1.0 size 640, 480 '
gnuplot> set termoption noenhanced
gnuplot> show term

    terminal type is pngcairo  background "#ffffff" enhanced 
fontscale 1.0 size 640, 480

After the "set termoption" command, at least, it seems that 
"enhanced" is in fact turned off, but that's not what's shown. The 
guest that won't leave!

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: configure: pdflib, pdf

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

----- Original Message -----
> From: Petr Mikulik 
> To: gnuplot-beta 
> Cc: 
> Date: 2014/7/1, Tue 06:08
> Subject: configure: pdflib, pdf
> 
> Currently ./configure says at the end:
> 
>    jpeg terminal: yes
>    gif terminal: yes (with animated gif)
>    png terminal: yes
>      (jpeg, gif and png terminals can use TTF fonts)
>    pdf terminal: no (requires libpdf)
>    ... linux, vgagl, ggi, ...
>    cairo-based pdf and png terminals: yes
> 
> I propose to change the last sentence to
>    pdf and png terminals based on cairo: yes
> and move it above below the pdf terminal.
> 
> Actually, is the pdflib still supported? It seems that this library is 
> commercial, so are there any gnuplot users?
> 
> 
> I would propose this ordering:
> 
> Standalone terminals: yes (always builtin)
> ...
> dot-matrix terminals: no
> ...
> Other file terminals:
>    jpeg terminal: yes
>    gif terminal: yes (with animated gif)
>    png terminal: yes
>      (jpeg, gif and png terminals can use TTF fonts)
>    pdf terminal: no (requires libpdf)
>    ... linux, vgagl, ggi, ...
>    pdf and png terminals based on cairo: yes
>    lua/tikz ...
> 
> Screen terminals:
>    ...
> 
> (and then maybe Other terminals if there are some remaining).
> 
> ---
> Petr


There is also epscairo.

Tatsuro

configure: pdflib, pdf

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

Currently ./configure says at the end:

   jpeg terminal: yes
   gif terminal: yes (with animated gif)
   png terminal: yes
     (jpeg, gif and png terminals can use TTF fonts)
   pdf terminal: no (requires libpdf)
   ... linux, vgagl, ggi, ...
   cairo-based pdf and png terminals: yes

I propose to change the last sentence to
   pdf and png terminals based on cairo: yes
and move it above below the pdf terminal.

Actually, is the pdflib still supported? It seems that this library is 
commercial, so are there any gnuplot users?


I would propose this ordering:

Standalone terminals: yes (always builtin)
...
dot-matrix terminals: no
...
Other file terminals:
   jpeg terminal: yes
   gif terminal: yes (with animated gif)
   png terminal: yes
     (jpeg, gif and png terminals can use TTF fonts)
   pdf terminal: no (requires libpdf)
   ... linux, vgagl, ggi, ...
   pdf and png terminals based on cairo: yes
   lua/tikz ...

Screen terminals:
   ...

(and then maybe Other terminals if there are some remaining).

---
Petr

Re: gnuplot 4.8?

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

----- Original Message -----
> From: sfeam 
> To: Tatsuro MATSUOKA 
> Cc: gnuplot-beta Allin Cottrell
> Date: 2014/6/30, Mon 23:25
> Subject: Re: gnuplot 4.8?
> 
> On Monday, June 30, 2014 06:10:24 PM Tatsuro MATSUOKA wrote:
>>  ----- Original Message -----
>> 
>>  > From: sfeam 
>>  > To: gnuplot-beta
>>  > Cc: Allin Cottrell 
>>  > Date: 2014/6/30, Mon 05:16
>>  > Subject: Re: gnuplot 4.8?
>>  > 
>>  > On Sunday, June 29, 2014 03:44:23 PM Allin Cottrell wrote:
>>  >>  I understand that 5.0 is supposed to be the release where the
>>  >>  gnuplot developers are free to make some backward-incompatible
>>  >>  changes. I've no problem with that, but I wonder if 
> there's any
>>  >>  thought to produce a gnuplot 4.8?
>>  > 
>>  > The 4.6 development source is a separate branch in CVS.
>>  > The 4.7 (later 5.0) branch split off from it and gradually diverged.
>>  > Most bugfixes have been applied to both branches, but they have
>>  > diverged enough that in some cases the "fix" for a problem 
> in 4.6
>>  > is limited to the existence of a better implementation in 5.0.
>>  > 
>>  > There will be at least one more patchlevel release 4.6.6.
>>  > My crystal ball does not tell me at what rate fixable bugs will 
> continue
>>  > to be reported againt 4.6 as opposed to 5.0.  Other incremental
>>  > releases could eventually appear, but I don't see a good rationale 
> for
>>  > starting a 4.8  series.   If a fix/change is compatible then it could 
> go
>>  > into 4.6; if not then it belongs in 5.0.
>>  > 
>>  > A brief listing of changes accumulated since the last release is
>>  > kept at the top of the NEWS files:
>>  > 
>>  > NEWS
>>  > New features, changes and fixes in gnuplot version 4.6.6
>>  > ========================================================
>>  > 
>>  > * NEW linetype keyword "nodraw" can be used to draw only the 
> points in
>>  > "with lp"
>>  > * NEW plot option to "skip N" lines at start of an ascii 
> data file
>>  > * NEW 'set fit prescale' normalized fit parameters before M-L 
> refinement
>>  > * NEW update svg terminal to grey out the key entry when a plot is 
> toggled
>>  > off * CHANGE Accept "with image pixels" as a synonym for 
> "with image
>>  > failsafe"
>>  > * CHANGE return NaN if a requested numerical data value fins a string
>>  > instead * CHANGE Consume only one space following the font name in an
>>  > enhanced test string
>>  > * FIX Faster recovery from outboard server gnuplot_qt being killed
>>  > * FIX get rid of O(N^2) memory allocation for string data in long 
> input
>>  > lines * FIX large integers in iteration spec could cause overflow end
>>  > condition check * FIX object fillcolors should be consistent with the
>>  > color of current linetypes * FIX LFS support on 64bit platforms (not
>>  > backported for 32bit platforms) * FIX timecolumn() applied to non-axis
>>  > data reports an error rather than faulting
>>  > * FIX clipping could fail on integer overflow
>>  > * FIX segfault resulting from strcol(N) applied to empty field in a 
> *.csv
>>  > file * FIX adjustment of key size to accommodate long key title
>>  > * FIX treat data value read as "NaN" the same as we would
>>  > "1/0"
>>  > * FIX handling of events triggered by closing the qt plot window
>>  > * FIX iteration failure due to integer overflow
>>  > * FIX clip r axis tics to current plot boundary
>>  > * FIX logscale cb axis with volatile data
>>  > 
>>  >     Ethan
>> 
>>  Do you really make package of gnuplot-4.6.6?
>>  If it will be upload on the web, I can prepare windows and Cygwin binaries
>>  both for 32 and 64 bit.
> 
> I have shown the NEWS file from the 4.6 CVS repository.
> Each PATCHLEVEL release is basically a snapshot of the repository.
> 4.6.5 was a snapshot from February 2014.
> Some time later this year we will take another snapshot and this will
> be release 4.6.6.   It will contain the changes listed above and any
> other changes made between now and the tie of release.
> 
>     Ethan


OK.Thanks!

Tatsuro