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

Re: compiling on 32-bit mingw

[Bastian M. <bma...@we...>]

Am 03.10.2016 um 10:53 schrieb Mojca Miklavec:
> On 3 October 2016 at 10:37, Bastian Märkisch wrote:
>> Sigh. MinGW32 is falling behind rather seriously. IPrintDialogCallback
>> and friends have been part of the API since Windows 2000 Pro according
>> to MSDN. Mingw32 is currently also lacking support for several other
>> "modern" APIs like Direct2D, DirectWrite and touch, which gnuplot might
>> use in the near future. This is also not the only development
>> environment with that problem: OpenWatcom's library is seriously out of
>> date, too.
>>
>> To fix compilation with MinGW32 for now, we could add the old code back
>> along with a number of #ifdef's, or extract the missing definitions from
>> MSDN and add them to the our code (easily around 100 lines), or #ifdef
>> out the affected code and functionality.
>>
>> Btw. Mingw64 and MSVC2015 compile gnuplot just fine.
>
> This is not my area of expertise, but isn't MinGW-w64 a suitable
> replacement for MinGW32?
>
> I kind-of gave up on the original MinGW32, in particular in the area
> of cross-compiling. MinGW-w64 seems much better supported and more
> up-to-date (not to even mention the ability to create 64-bit
> binaries).
>
> It would be one thing to exclude everyone without MSVC. That would be
> a bit sad. But I don't find it problematic to ask *developers* (the
> few people who actually know how to compile under Windows and how to
> get all the dependencies working) to switch to a different OpenSource
> toolchain, in particular if supporting the "old" toolchain causes
> additional headaches and more ugly code.
>
> If gnuplot compiles fine under MinGW-w64, I don't see any reason to
> use ugly workarounds in the code just for the sake of supporting an
> alternative tool that lags behind.
>
> Mojca
>

Agreed. Except that MinGW32 was the recommended toolchain until 
recently. So we shouldn't give up too quickly.
Allin, aren't you using Mingw64 for 64bit builds already?

   Bastian

Re: compiling on 32-bit mingw

[Mojca M. <moj...@gm...>]

On 3 October 2016 at 10:37, Bastian Märkisch wrote:
> Sigh. MinGW32 is falling behind rather seriously. IPrintDialogCallback
> and friends have been part of the API since Windows 2000 Pro according
> to MSDN. Mingw32 is currently also lacking support for several other
> "modern" APIs like Direct2D, DirectWrite and touch, which gnuplot might
> use in the near future. This is also not the only development
> environment with that problem: OpenWatcom's library is seriously out of
> date, too.
>
> To fix compilation with MinGW32 for now, we could add the old code back
> along with a number of #ifdef's, or extract the missing definitions from
> MSDN and add them to the our code (easily around 100 lines), or #ifdef
> out the affected code and functionality.
>
> Btw. Mingw64 and MSVC2015 compile gnuplot just fine.

This is not my area of expertise, but isn't MinGW-w64 a suitable
replacement for MinGW32?

I kind-of gave up on the original MinGW32, in particular in the area
of cross-compiling. MinGW-w64 seems much better supported and more
up-to-date (not to even mention the ability to create 64-bit
binaries).

It would be one thing to exclude everyone without MSVC. That would be
a bit sad. But I don't find it problematic to ask *developers* (the
few people who actually know how to compile under Windows and how to
get all the dependencies working) to switch to a different OpenSource
toolchain, in particular if supporting the "old" toolchain causes
additional headaches and more ugly code.

If gnuplot compiles fine under MinGW-w64, I don't see any reason to
use ugly workarounds in the code just for the sake of supporting an
alternative tool that lags behind.

Mojca

Re: compiling on 32-bit mingw

[Bastian M. <bma...@we...>]

Sigh. MinGW32 is falling behind rather seriously. IPrintDialogCallback 
and friends have been part of the API since Windows 2000 Pro according 
to MSDN. Mingw32 is currently also lacking support for several other 
"modern" APIs like Direct2D, DirectWrite and touch, which gnuplot might 
use in the near future. This is also not the only development 
environment with that problem: OpenWatcom's library is seriously out of 
date, too.

To fix compilation with MinGW32 for now, we could add the old code back 
along with a number of #ifdef's, or extract the missing definitions from 
MSDN and add them to the our code (easily around 100 lines), or #ifdef 
out the affected code and functionality.

Btw. Mingw64 and MSVC2015 compile gnuplot just fine.

   Bastian


Am 02.10.2016 um 22:00 schrieb Allin Cottrell:
> I just tried (cross-)compiling current CVS gnuplot using 32-bit
> mingw (something that has worked fine for me in the past), and I see
> that recent changes under src/win have made this problematic:
>
> - building wgraph.o fails for lack of the symbols PBS_MARQUEE and
> PBM_SETMARQUEE
>
> - building wprinter.o fails for lack of IPrintDialogCallback and
> associated stuff
>
> The first of these issues -- as I found by googling -- is fairly
> easily solved. It suffices to insert
>
> #ifndef PBS_MARQUEE
> # define PBS_MARQUEE 0x08
> # define PBM_SETMARQUEE (WM_USER+10)
> #endif
>
> before the function CopyPrint() in wgraph.c. But I haven't yet found
> a comparable workaround for IPrintDialogCallback and friends.
>
> Allin Cottrell
>

compiling on 32-bit mingw

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

I just tried (cross-)compiling current CVS gnuplot using 32-bit 
mingw (something that has worked fine for me in the past), and I see 
that recent changes under src/win have made this problematic:

- building wgraph.o fails for lack of the symbols PBS_MARQUEE and 
PBM_SETMARQUEE

- building wprinter.o fails for lack of IPrintDialogCallback and 
associated stuff

The first of these issues -- as I found by googling -- is fairly 
easily solved. It suffices to insert

#ifndef PBS_MARQUEE
# define PBS_MARQUEE 0x08
# define PBM_SETMARQUEE (WM_USER+10)
#endif

before the function CopyPrint() in wgraph.c. But I haven't yet found 
a comparable workaround for IPrintDialogCallback and friends.

Allin Cottrell




-- 
Allin Cottrell
Department of Economics
Wake Forest University

pre-release Testing tarball for version 5.0.5

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

If no last-minute problems are found, I plan to release gnuplot 5.0.5
(version 5.0 patchlevel 5) in a week or so.

I have uploaded a source tarball for testing.
You can find it in the "testing" file folder on SourceForge:

      https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/

This patchlevel 5.0.5 incremental release includes
==================================================

* NEW allow filename completion for system commands and pipes (backport from 5.1)
* NEW option to plot with labels {rotate variable}
* NEW command "set minussign"
* NEW stats command "name" option now accepts "columnheader" or "columnheader(N)"
* NEW command option "set colorbox invert"
* CHANGE qt terminal force selection of outline font rather than bitmap font
* CHANGE post terminal simplex/duplex output depends on PostScript level setting
* CHANGE improved autoscaling of plot "with boxes"
* CHANGE qt terminal sets TERM_POLYGON_PIXELS to avoid aliasing artifacts
* CHANGE all stats and fit commands skip header records if "autotitle columnhead"
* FIX various bugs affecting matrix data plotted "with image"
* FIX Do not confuse EOF with 8-bit character 0x177 (E.g. in Cyrillic encodings).
* FIX use blank line rather than 'u' flag in "set table" output of smoothed data
* FIX regression in rendering 'plot ... matrix every ... with image'
* FIX order dependence of "fillcolor" keyword in plot commands
* FIX svg - better vertical justification of rotated text
* FIX wxt - file export widget correctly handles inactive plots
* FIX qt - preserve leading and trailing whitespace in enhanced text strings

	Ethan

Re: Inability to change color of individual substrings

[Per B. <pe...@bo...>]

On 09/29/2016 11:28 PM, Daniel J Sebald wrote:
  
> set term qt enhanced
> load 'enhanced_utf8.dem'

Interesting.  For what it's worth, the 'domterm' terminal type
handles enhanced_utf8.dem with only one glitch that I noticed:
The Overprint "v should be centred over d" test is not working.
This bug is shared with the svg driver (as expected, since the
domterm driver is just a mode of the svg driver).
-- 
	--Per Bothner
pe...@bo...   http://per.bothner.com/

Re: Inability to change color of individual substrings

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

On 09/30/2016 11:00 AM, pl...@pi... wrote:
> On 30/09/16 07:28, Daniel J Sebald wrote:
[snip]
>> The only way I could get the proper spacing with the Qt terminal is by
>> adding '|', e.g., "&{{/:Bold Bold} and|} {/:Italic Italic}"
>>
>> Dan
>>
>>
>
> I was not aware of this &{} syntax.  Looks very useful.
>
> Where can I find the relevant documentation? What is this feature
> called, for example, in help?
>
> TIA. Peter.

See "help enhanced".  Also, there is the file ./docs/psdoc/ps_guide.ps.

I just noticed that under "help enhanced" there is a subtopic "text". 
Entering that subtopic "text" displays the contents for enhanced again 
rather than something different.

Dan

Re: Inability to change color of individual substrings

[Ethan A M. <sf...@us...>]

On Friday, 30 September, 2016 17:00:34 pl...@pi... wrote:
> On 30/09/16 07:28, Daniel J Sebald wrote:
> > On 09/30/2016 12:24 AM, sfeam wrote:
> >> On Thursday, 29 September 2016 10:21:13 PM Daniel J Sebald wrote:
> >>> I've noticed that enhanced text mode cannot control the color of a
> >>> substring.  Just as a brainstorming exercise, has anyone thought of
> >>> adding such a thing in some way?  In principle it's pretty
> >>> straightforward: just change terminal color at various points when
> >>> processing the string.  But I've a feeling implementation may not be so
> >>> easy.  Approaches might be:
> >>>
> >>> 1) Add some color code extension to the enhanced text processing.  The
> >>> code word may not agree with some "standard" described in ps_guide.ps,
> >>> but I don't see why that should be a problem.  The problem is that all
> >>> terminal drivers would need to be modified to process that code word.
> >>>
> >>> 2) Create a tex-processing feature, which is similar to enhanced text
> >>> (and could use much of the same code), but it would allow using things
> >>> like "{\color[rgb]{.3 .7 .3}Hello} World".  Of course, this is no simple
> >>> task, but I'm just thinking long term wish if there is no better
> >>> approach.
> >>>
> >>> 3) If there were some way of getting the position at which one
> >>> label/string ends, then one could concatenate strings.  I've a feeling
> >>> this isn't possible.  I mean, one has to effective do the plot to get
> >>> the string-end position, which would be clumsy.
> >>>
> >>> 4) However, #3 in theory could be implemented as "not lifting pen".
> >>> Does gnuplot core code have knowledge of this?  That is, can it do one
> >>> label, not lift the pen, then continue with another label?  If so, the
> >>> following concept might work:
> >>>
> >>> set label 1 "{/Times:Bold hello}" textcolor "red" at 1,2
> >>> set label 2 "world^3" textcolor "blue" after label 1
> >>>
> >>> Or, maybe just allow multiple substring specifications, but only a
> >>> single "at x,y":
> >>>
> >>> set label 1 "{/Times:Bold hello}" textcolor "red" "world^3" textcolor
> >>> "blue" at 1,2
> >>>
> >>> Would that work easily internally?  Or is there still a problem as far
> >>> as laying out string alignment?
> >>>
> >>> Dan
> >>
> >> Always been there:
> >>
> >> # enhanced text occupy-space-but-don't-print mode
> >> #
> >> set label 1 at 0,0 "I am a &{red} word in blue"
> >> set label 2 at 0,0 "&{I am a} red &{word in blue}"
> >> set label 1 tc "blue"
> >> set label 2 tc "red"
> >>
> >>     Ethan
> >
> > Aaaaah, creative.  The use of &{} is already present in
> > enhanced_utf8.dem, but adding a bit of code for this idea to that demo
> > might be helpful.  Attached is a diff to illustrate.
> >
> > I think there may be a bug in Qt terminal with regard to the space
> > between &{} and what follows it when there is a space-character
> > immediately after.  I tried explicitly using a \040, but that too was
> > dropped.  After applying the attached patch, try
> >
> > set term x11 enhanced
> > load 'enhanced_utf8.dem'
> >
> > and
> >
> > set term qt enhanced
> > load 'enhanced_utf8.dem'
> >
> > The only way I could get the proper spacing with the Qt terminal is by
> > adding '|', e.g., "&{{/:Bold Bold} and|} {/:Italic Italic}"
> >
> > Dan
> >
> >
> 
> I was not aware of this &{} syntax.  Looks very useful.
> 
> Where can I find the relevant documentation? What is this feature 
> called, for example, in help?

gnuplot> help enhanced text

 Many terminal types support an enhanced text mode in which additional
 formatting information is embedded in the text string.  For example, "x^2"
 will write x-squared as we are used to seeing it, with a superscript 2.
 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".

  Control      Examples        Explanation
   ^           a^x             superscript
   _           a_x             subscript
   @           @x or a@^b_{cd} phantom box (occupies no width)
   &           &{space}        inserts space of specified length
   ~           ~a{.8-}         overprints '-' on 'a', raised by .8
                               times the current fontsize
   {/Times abc}                print abc in font Times at current size
   {/Times*2 abc}              print abc in font Times at twice current size
   {/Times:Italic abc}         print abc in font Times with style italic
   {/Arial:Bold=20 abc}        print abc in boldface Arial font size 20 

 [...]

Re: Inability to change color of individual substrings

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

On 30/09/16 07:28, Daniel J Sebald wrote:
> On 09/30/2016 12:24 AM, sfeam wrote:
>> On Thursday, 29 September 2016 10:21:13 PM Daniel J Sebald wrote:
>>> I've noticed that enhanced text mode cannot control the color of a
>>> substring.  Just as a brainstorming exercise, has anyone thought of
>>> adding such a thing in some way?  In principle it's pretty
>>> straightforward: just change terminal color at various points when
>>> processing the string.  But I've a feeling implementation may not be so
>>> easy.  Approaches might be:
>>>
>>> 1) Add some color code extension to the enhanced text processing.  The
>>> code word may not agree with some "standard" described in ps_guide.ps,
>>> but I don't see why that should be a problem.  The problem is that all
>>> terminal drivers would need to be modified to process that code word.
>>>
>>> 2) Create a tex-processing feature, which is similar to enhanced text
>>> (and could use much of the same code), but it would allow using things
>>> like "{\color[rgb]{.3 .7 .3}Hello} World".  Of course, this is no simple
>>> task, but I'm just thinking long term wish if there is no better
>>> approach.
>>>
>>> 3) If there were some way of getting the position at which one
>>> label/string ends, then one could concatenate strings.  I've a feeling
>>> this isn't possible.  I mean, one has to effective do the plot to get
>>> the string-end position, which would be clumsy.
>>>
>>> 4) However, #3 in theory could be implemented as "not lifting pen".
>>> Does gnuplot core code have knowledge of this?  That is, can it do one
>>> label, not lift the pen, then continue with another label?  If so, the
>>> following concept might work:
>>>
>>> set label 1 "{/Times:Bold hello}" textcolor "red" at 1,2
>>> set label 2 "world^3" textcolor "blue" after label 1
>>>
>>> Or, maybe just allow multiple substring specifications, but only a
>>> single "at x,y":
>>>
>>> set label 1 "{/Times:Bold hello}" textcolor "red" "world^3" textcolor
>>> "blue" at 1,2
>>>
>>> Would that work easily internally?  Or is there still a problem as far
>>> as laying out string alignment?
>>>
>>> Dan
>>
>> Always been there:
>>
>> # enhanced text occupy-space-but-don't-print mode
>> #
>> set label 1 at 0,0 "I am a &{red} word in blue"
>> set label 2 at 0,0 "&{I am a} red &{word in blue}"
>> set label 1 tc "blue"
>> set label 2 tc "red"
>>
>>     Ethan
>
> Aaaaah, creative.  The use of &{} is already present in
> enhanced_utf8.dem, but adding a bit of code for this idea to that demo
> might be helpful.  Attached is a diff to illustrate.
>
> I think there may be a bug in Qt terminal with regard to the space
> between &{} and what follows it when there is a space-character
> immediately after.  I tried explicitly using a \040, but that too was
> dropped.  After applying the attached patch, try
>
> set term x11 enhanced
> load 'enhanced_utf8.dem'
>
> and
>
> set term qt enhanced
> load 'enhanced_utf8.dem'
>
> The only way I could get the proper spacing with the Qt terminal is by
> adding '|', e.g., "&{{/:Bold Bold} and|} {/:Italic Italic}"
>
> Dan
>
>

I was not aware of this &{} syntax.  Looks very useful.

Where can I find the relevant documentation? What is this feature 
called, for example, in help?

TIA. Peter.

Re: Inability to change color of individual substrings

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

On 09/30/2016 12:24 AM, sfeam wrote:
> On Thursday, 29 September 2016 10:21:13 PM Daniel J Sebald wrote:
>> I've noticed that enhanced text mode cannot control the color of a
>> substring.  Just as a brainstorming exercise, has anyone thought of
>> adding such a thing in some way?  In principle it's pretty
>> straightforward: just change terminal color at various points when
>> processing the string.  But I've a feeling implementation may not be so
>> easy.  Approaches might be:
>>
>> 1) Add some color code extension to the enhanced text processing.  The
>> code word may not agree with some "standard" described in ps_guide.ps,
>> but I don't see why that should be a problem.  The problem is that all
>> terminal drivers would need to be modified to process that code word.
>>
>> 2) Create a tex-processing feature, which is similar to enhanced text
>> (and could use much of the same code), but it would allow using things
>> like "{\color[rgb]{.3 .7 .3}Hello} World".  Of course, this is no simple
>> task, but I'm just thinking long term wish if there is no better approach.
>>
>> 3) If there were some way of getting the position at which one
>> label/string ends, then one could concatenate strings.  I've a feeling
>> this isn't possible.  I mean, one has to effective do the plot to get
>> the string-end position, which would be clumsy.
>>
>> 4) However, #3 in theory could be implemented as "not lifting pen".
>> Does gnuplot core code have knowledge of this?  That is, can it do one
>> label, not lift the pen, then continue with another label?  If so, the
>> following concept might work:
>>
>> set label 1 "{/Times:Bold hello}" textcolor "red" at 1,2
>> set label 2 "world^3" textcolor "blue" after label 1
>>
>> Or, maybe just allow multiple substring specifications, but only a
>> single "at x,y":
>>
>> set label 1 "{/Times:Bold hello}" textcolor "red" "world^3" textcolor
>> "blue" at 1,2
>>
>> Would that work easily internally?  Or is there still a problem as far
>> as laying out string alignment?
>>
>> Dan
>
> Always been there:
>
> # enhanced text occupy-space-but-don't-print mode
> #
> set label 1 at 0,0 "I am a &{red} word in blue"
> set label 2 at 0,0 "&{I am a} red &{word in blue}"
> set label 1 tc "blue"
> set label 2 tc "red"
>
> 	Ethan

Aaaaah, creative.  The use of &{} is already present in 
enhanced_utf8.dem, but adding a bit of code for this idea to that demo 
might be helpful.  Attached is a diff to illustrate.

I think there may be a bug in Qt terminal with regard to the space 
between &{} and what follows it when there is a space-character 
immediately after.  I tried explicitly using a \040, but that too was 
dropped.  After applying the attached patch, try

set term x11 enhanced
load 'enhanced_utf8.dem'

and

set term qt enhanced
load 'enhanced_utf8.dem'

The only way I could get the proper spacing with the Qt terminal is by 
adding '|', e.g., "&{{/:Bold Bold} and|} {/:Italic Italic}"

Dan

Re: Inability to change color of individual substrings

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

On Thursday, 29 September 2016 10:21:13 PM Daniel J Sebald wrote:
> I've noticed that enhanced text mode cannot control the color of a 
> substring.  Just as a brainstorming exercise, has anyone thought of 
> adding such a thing in some way?  In principle it's pretty 
> straightforward: just change terminal color at various points when 
> processing the string.  But I've a feeling implementation may not be so 
> easy.  Approaches might be:
> 
> 1) Add some color code extension to the enhanced text processing.  The 
> code word may not agree with some "standard" described in ps_guide.ps, 
> but I don't see why that should be a problem.  The problem is that all 
> terminal drivers would need to be modified to process that code word.
> 
> 2) Create a tex-processing feature, which is similar to enhanced text 
> (and could use much of the same code), but it would allow using things 
> like "{\color[rgb]{.3 .7 .3}Hello} World".  Of course, this is no simple 
> task, but I'm just thinking long term wish if there is no better approach.
> 
> 3) If there were some way of getting the position at which one 
> label/string ends, then one could concatenate strings.  I've a feeling 
> this isn't possible.  I mean, one has to effective do the plot to get 
> the string-end position, which would be clumsy.
> 
> 4) However, #3 in theory could be implemented as "not lifting pen". 
> Does gnuplot core code have knowledge of this?  That is, can it do one 
> label, not lift the pen, then continue with another label?  If so, the 
> following concept might work:
> 
> set label 1 "{/Times:Bold hello}" textcolor "red" at 1,2
> set label 2 "world^3" textcolor "blue" after label 1
> 
> Or, maybe just allow multiple substring specifications, but only a 
> single "at x,y":
> 
> set label 1 "{/Times:Bold hello}" textcolor "red" "world^3" textcolor 
> "blue" at 1,2
> 
> Would that work easily internally?  Or is there still a problem as far 
> as laying out string alignment?
> 
> Dan

Always been there:

# enhanced text occupy-space-but-don't-print mode
#
set label 1 at 0,0 "I am a &{red} word in blue"
set label 2 at 0,0 "&{I am a} red &{word in blue}"
set label 1 tc "blue"
set label 2 tc "red"

	Ethan

Inability to change color of individual substrings

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

I've noticed that enhanced text mode cannot control the color of a 
substring.  Just as a brainstorming exercise, has anyone thought of 
adding such a thing in some way?  In principle it's pretty 
straightforward: just change terminal color at various points when 
processing the string.  But I've a feeling implementation may not be so 
easy.  Approaches might be:

1) Add some color code extension to the enhanced text processing.  The 
code word may not agree with some "standard" described in ps_guide.ps, 
but I don't see why that should be a problem.  The problem is that all 
terminal drivers would need to be modified to process that code word.

2) Create a tex-processing feature, which is similar to enhanced text 
(and could use much of the same code), but it would allow using things 
like "{\color[rgb]{.3 .7 .3}Hello} World".  Of course, this is no simple 
task, but I'm just thinking long term wish if there is no better approach.

3) If there were some way of getting the position at which one 
label/string ends, then one could concatenate strings.  I've a feeling 
this isn't possible.  I mean, one has to effective do the plot to get 
the string-end position, which would be clumsy.

4) However, #3 in theory could be implemented as "not lifting pen". 
Does gnuplot core code have knowledge of this?  That is, can it do one 
label, not lift the pen, then continue with another label?  If so, the 
following concept might work:

set label 1 "{/Times:Bold hello}" textcolor "red" at 1,2
set label 2 "world^3" textcolor "blue" after label 1

Or, maybe just allow multiple substring specifications, but only a 
single "at x,y":

set label 1 "{/Times:Bold hello}" textcolor "red" "world^3" textcolor 
"blue" at 1,2

Would that work easily internally?  Or is there still a problem as far 
as laying out string alignment?

Dan

domterm terminal supports embedded graphics

[Per B. <pe...@bo...>]

The development version of gnuplot supports the 'domterm' terminal type,
which allows direct "printing" of the output plots in the terminal output.
Here is blog article with screenshot:
http://per.bothner.com/blog/2016/gnuplot-in-domterm/

DomTerm is a general-purpose mostly-xterm-compatible terminal emulator
that uses Web technologies, which means you can embed images including SVN and PNG.
(Actually there are a number DomTerm-based terminal emulators, from the
standalone qtdomterm to just using a window of your favorite modern browser.)
The 'domterm' terminal type is basically the 'svg' terminal type with some tweaks.

I hope you will try it out; let me know if you have any problems or requests.
-- 
	--Per Bothner
pe...@bo...   http://per.bothner.com/

Re: "fc palette frac" does not always work for objects

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

On Monday, 26 September 2016 10:04:26 AM Petr Mikulik wrote:
> >> I suppose the routine set_plot_with_palette() could be taught to check
> >> for object colors also, but I wonder if the better question is why should
> >> we not always initialize the palette even if no one is going to use it?
> >
> > Yes, that could work. This would also automatically alleviate the
> > question of any other plot element we might have forgot that potentially
> > needs the palette but doesn't trigger it on its own.
> >
> > I wonder, though, if there are any careless assumptions about the
> > palette in the code, for example "palette is initialized => draw the
> > colorbox", or in other words, initializing it all the time might expose
> > some unwanted side effects.
> 
> There is some overhead with the palette code in terminals - they need more 
> init data (sending the palette, allocate more colours, write larger postscript 
> header, ...), as well as switching on the colorbox. Thus searching all objects 
> for their requirements is a prefered way.

OK. 
Can you think of any additional cases where the current checks in
set_plot_with_palette() fail to notice that a palette will be referenced?

	Ethan

Re: "fc palette frac" does not always work for objects

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

>> I suppose the routine set_plot_with_palette() could be taught to check
>> for object colors also, but I wonder if the better question is why should
>> we not always initialize the palette even if no one is going to use it?
>
> Yes, that could work. This would also automatically alleviate the
> question of any other plot element we might have forgot that potentially
> needs the palette but doesn't trigger it on its own.
>
> I wonder, though, if there are any careless assumptions about the
> palette in the code, for example "palette is initialized => draw the
> colorbox", or in other words, initializing it all the time might expose
> some unwanted side effects.

There is some overhead with the palette code in terminals - they need more 
init data (sending the palette, allocate more colours, write larger postscript 
header, ...), as well as switching on the colorbox. Thus searching all objects 
for their requirements is a prefered way.

---
PM

Re: "fc palette frac" does not always work for objects

[Juhász P. <pet...@gm...>]

On Sat, 2016-09-24 at 21:36 -0700, sfeam wrote:
> On Saturday, 24 September 2016 12:51:56 PM Peter Juhasz wrote:
> > Dear gnuplot developers,
> > 
> > consider the following commands:
> > 
> > set obj 1 rect from 1,1 to 2,2 fc palette frac 0.5
> > plot x
> > 
> > The documentation says that the fillcolor part of the set object command
> > accepts a generic colorspec directive, which in turn should allow a "fc
> > palette frac" declaration.
> > Given the default palette I'd expect the above commands to produce a red
> > rectangle on the plot, however, it comes out black.
> > 
> > However, if I change the plot command to
> > 
> > plot x lc palette frac 0.1
> > 
> > The rectangle suddenly gets the expected color. I also get a color bar next
> > to the plot.
> > 
> > All of this suggests that in the first example some of the palette-related
> > data structures are not initialized correctly, while in the second example
> > they are, only because the palette is used with the function plot as well,
> > and that plot triggers the necessary initialization sequence.
> > 
> > Peter Juhasz
> 
> The program tries to figure out if a given plot requires the palette or not.
> It looks through the plot style and various line and text properties, but it
> does not look through the set of all defined objects.
> A work-around, if you care, is to issue the command "set pm3d implicit".
> 
> I suppose the routine set_plot_with_palette() could be taught to check
> for object colors also, but I wonder if the better question is why should 
> we not always initialize the palette even if no one is going to use it?
> 

Yes, that could work. This would also automatically alleviate the
question of any other plot element we might have forgot that potentially
needs the palette but doesn't trigger it on its own.

I wonder, though, if there are any careless assumptions about the
palette in the code, for example "palette is initialized => draw the
colorbox", or in other words, initializing it all the time might expose
some unwanted side effects.  

> 	Ethan
> 

Peter

Re: "fc palette frac" does not always work for objects

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

On Saturday, 24 September 2016 12:51:56 PM Peter Juhasz wrote:
> Dear gnuplot developers,
> 
> consider the following commands:
> 
> set obj 1 rect from 1,1 to 2,2 fc palette frac 0.5
> plot x
> 
> The documentation says that the fillcolor part of the set object command
> accepts a generic colorspec directive, which in turn should allow a "fc
> palette frac" declaration.
> Given the default palette I'd expect the above commands to produce a red
> rectangle on the plot, however, it comes out black.
> 
> However, if I change the plot command to
> 
> plot x lc palette frac 0.1
> 
> The rectangle suddenly gets the expected color. I also get a color bar next
> to the plot.
> 
> All of this suggests that in the first example some of the palette-related
> data structures are not initialized correctly, while in the second example
> they are, only because the palette is used with the function plot as well,
> and that plot triggers the necessary initialization sequence.
> 
> Peter Juhasz

The program tries to figure out if a given plot requires the palette or not.
It looks through the plot style and various line and text properties, but it
does not look through the set of all defined objects.
A work-around, if you care, is to issue the command "set pm3d implicit".

I suppose the routine set_plot_with_palette() could be taught to check
for object colors also, but I wonder if the better question is why should 
we not always initialize the palette even if no one is going to use it?

	Ethan

"fc palette frac" does not always work for objects

[Peter J. <pet...@gm...>]

Dear gnuplot developers,

consider the following commands:

set obj 1 rect from 1,1 to 2,2 fc palette frac 0.5
plot x

The documentation says that the fillcolor part of the set object command
accepts a generic colorspec directive, which in turn should allow a "fc
palette frac" declaration.
Given the default palette I'd expect the above commands to produce a red
rectangle on the plot, however, it comes out black.

However, if I change the plot command to

plot x lc palette frac 0.1

The rectangle suddenly gets the expected color. I also get a color bar next
to the plot.

All of this suggests that in the first example some of the palette-related
data structures are not initialized correctly, while in the second example
they are, only because the palette is used with the function plot as well,
and that plot triggers the necessary initialization sequence.

Peter Juhasz

Re: Documentation for "set style line" missing "dashtype" option

[Ethan A M. <sf...@us...>]

On Monday, 19 September, 2016 14:17:19 Daniel J Sebald wrote:
> Also, I just want to confirm that prior to the introduction of 
> "dashtype" as a valid option, the dash pattern was terminal specific and 
> not selectable but at the driver level, i.e., the 8 cyclic patterns. 
> Correct?

Correct.  Not all terminals that had a "dashed" mode provided
as many as 8 patterns.  It varied from 4 to some large number.

mouse cursor text placement

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

Hi,

There is a good deal of flexibility for specifying the format of the 
mouse cursor read-out. This is excellent.

However, I don't see a means of determining its placement in relation to 
the cursor cross-hairs.  This is limiting since if we need to use the 
cursor click to paste cursor read-out on a graph, this does not work 
well for a trough in the data.

The text ends up obscuring the graph exactly at the point we are trying 
draw attention to.

It would be useful , as well as specifying the content and numeric 
format ( which is powerful ) to be able to at least say which quadrant 
of the cross-hairs to align to. A more general method may be worth 
considering.

Ideally we need to place the cross-hair on the line ( to get correct 
cursor values ) but ensure the text is below, in the case of a trough , 
not above and thus on top of the plotted line.

A simple  clockwise quadrant could be specified, default being existing 
Q1.  Q2 would be underneath, left-justified ; Q3 under, right-justified 
, etc.

This would make this excellent feature more generally applicable.

Regards, Peter.

Re: Documentation for "set style line" missing "dashtype" option

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

Also, I just want to confirm that prior to the introduction of 
"dashtype" as a valid option, the dash pattern was terminal specific and 
not selectable but at the driver level, i.e., the 8 cyclic patterns. 
Correct?

Dan

Documentation for "set style line" missing "dashtype" option

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

The documentation for "set style line" is currently:

  Syntax:
        set style line <index> default
        set style line <index> {{linetype  | lt} <line_type> | <colorspec>}
                               {{linecolor | lc} <colorspec>}
                               {{linewidth | lw} <line_width>}
                               {{pointtype | pt} <point_type>}
                               {{pointsize | ps} <point_size>}
                               {{pointinterval | pi} <interval>}
                               {palette}
        unset style line
        show style line

"dashtype | dt" is also an acceptable option.  E.g.,

set style line 1 dashtype "..-"
plot x ls 1

Dan

Re: Is there any reason why it can not take a list of numbers ?

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

On Saturday, 17 September 2016 08:09:09 PM pl...@pi... wrote:
> On 17/09/16 18:12, sfeam wrote:
> > gnuplot> set for [a in "11 13 17"] arrow from a,0 to a,1
> 
> 
> Many thanks Ethan. , I have to admit I did not try that since I consult 
> the doc when I don't know syntax and do not waste time doing other 
> things than what is documented  in the wild  hope of discovering 
> undocumented features.
> 
> So we have a documentation bug , that syntax is not proposed for intvar 
> and apparently it should be.

Not exactly.  It's more of an unintended (but useful) consequence of 
promotion from string to integer wherever the program knows that a 
number is expected.

In the above example a is a string variable not an integer variable.
But the "set arrow" command is looking for a number, not a string,
so it does the conversion silently.   Just as the following both work
    plot foo lt 2
    plot foo lt "2"

This does _not_ work for floating point number however.
That's why I think it might be a good idea to allow iteration over
the elements in an array.  Then you could have something like
array value[3] = [1.11, 2.22, 3.33]

  plot for [V in value] f(V)

> I did do a fair bit of searching trying to find a work around or a trick 
> and did  not find anything. So it looks like most people like me believe 
> what they read and are not profiting form this excellent feature.
> 
> Regards.  Peter.

Re: Is there any reason why it can not take a list of numbers ?

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

On 17/09/16 18:12, sfeam wrote:
> gnuplot> set for [a in "11 13 17"] arrow from a,0 to a,1


Many thanks Ethan. , I have to admit I did not try that since I consult 
the doc when I don't know syntax and do not waste time doing other 
things than what is documented  in the wild  hope of discovering 
undocumented features.

So we have a documentation bug , that syntax is not proposed for intvar 
and apparently it should be.

I did do a fair bit of searching trying to find a work around or a trick 
and did  not find anything. So it looks like most people like me believe 
what they read and are not profiting form this excellent feature.

Regards.  Peter.

Re: Is there any reason why it can not take a list of numbers ?

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

On Saturday, 17 September 2016 10:52:20 AM pl...@pi... wrote:
> Hi,
> 
> 
> the iteration in gnupllot is an excellent feature but can not take an 
> irregular sequence of numerical variables.
> 
> it's either a straight integer series or a list of _string_ variables.
> 
> 
> Is there any reason why it can not take a list of numbers ?
> 
> eg. if I want vertical arrows  at  x= 11,13,17  it does not seem 
> possible with the existing iteration.
> 
> 
> help tells me:
> 
> Two forms of iteration clause are currently supported:
> 
>         for [intvar = start:end{:increment}]
>         for [stringvar in "A B C D"]
> 
> 
> 
> 
> why not for [intvar = 11,13,17]   ?
> 
> 
> is there a trick to a string value in set arrow ?
> 
> set     for [stringvar in "11 13 17"]  arrow  from  ???, 0 to ???,1

Works for me:

gnuplot> set for [a in "11 13 17"] arrow from a,0 to a,1
gnuplot> show arrow

        arrow 1, head nofilled back lt black linewidth 1.000 dashtype solid
          from (11.0000, 0.00000, 0.00000) to (11.0000, 1.00000, 0.00000)
        arrow 2, head nofilled back lt black linewidth 1.000 dashtype solid
          from (13.0000, 0.00000, 0.00000) to (13.0000, 1.00000, 0.00000)
        arrow 3, head nofilled back lt black linewidth 1.000 dashtype solid
          from (17.0000, 0.00000, 0.00000) to (17.0000, 1.00000, 0.00000)


> Is there a problem to specify intvar with a list of values instead of a 
> regular series?

In the development version you could use an array:

    array list[3] = [11, 13, 17];
    set for [i=1:3] arrow from list[i],0 to list[i],1
 
This could probably be extended a bit.
For example:
  cleanly handling empty array slots, 
  allowing [1:*] to represent the full array,
  promoting the array name into the iterator:   for [i indexing array] ...

	Ethan