gnuplot-info Mailing List for gnuplot

On Monday, 30 October 2017 00:18:31 theozh wrote:
> Thanks again for your patient explanations.
> 
> My (mis)understanding probably is that I thought you can place 
> either (i.e. XOR) a <definition> or a <function> or a <data source>
> 
>   plot-element:
>         {<iteration>}
>         <definition> | {sampling-range} <function> | <data source>
>         {axes <axes>} {<title-spec>}
>         {with <style>}

Your have a point.
The BNF syntax shown in the help text is not correct.
Probably it has been amended in parallel to changes in the plot code
and at some point the logic diverged.

I should probably go back to the source and work out a proper description
from the ground up.

	Ethan


> however, 
> plot n=n+1 sin(x*n)
> is a <definition> AND a <function>
> whereas <function> AND <data source> at the same time is not supposed to work.

Thanks again for your patient explanations.

My (mis)understanding probably is that I thought you can place 
either (i.e. XOR) a <definition> or a <function> or a <data source>

  plot-element:
        {<iteration>}
        <definition> | {sampling-range} <function> | <data source>
        {axes <axes>} {<title-spec>}
        {with <style>}

however, 
plot n=n+1 sin(x*n)
is a <definition> AND a <function>
whereas <function> AND <data source> at the same time is not supposed to work.

On Sunday, 29 October 2017 01:01:10 theozh wrote:
> Thank you again, Ethan, for the explanations and links.
> 
> What's still not clear to me why you can place the
> ysum=0 between two plot commands...

That part is explained by "help plot".
 Syntax:
       plot {<ranges>} <plot-element> {, <plot-element>, <plot-element>}

 Each plot element consists of a definition, a function, or a data source
 together with optional properties or modifiers:
       plot-element:
            {<iteration>}
            <definition> | {sampling-range} <function> | <data source>
            {axes <axes>} {<title-spec>}
            {with <style>}

the "ysum = 0" matches the <definition> template  "foo = <expression>".

> What else can you place in front of a plot command?
> For example:
> n=1
> plot n=n+1 sin(x*n) # works
> plot (n=1,n=n+1) sin(x*n) # doesn't work... why?

because "(n=1,n=n+1)" is not a definition.
You could make it one by adding a dummy assignment:

  plot   dummy=(n=1,n=n+1) sin(x*n)


	Ethan
 
> 
> Anyway, my original question is solved :-).
> Nevertheless, I played around a little further.
> If the portions in the stacked histogram are too small to fit a number,
> the following code shows a way to place those numbers on the side with a
> pointing arrow.
> Maybe some people also mind find this useful.
> 
> The following code was working on my system (Win7, gnuplot 5.2) and
> should be ready for copy&paste&plot. Be aware that the mail program
> might have "messed up" the line breaks.
> 
> ###### start gnuplot code
> reset
> $Data <<EOD
> XXX Header1 Header2
> one 10 50
> two 3 2
> three 30 15
> four 40 5
> five 0.5 0.5
> six 0.6 0.6
> seven 1 17
> EOD
> 
> set style data histogram
> set style histogram columnstacked
> set style fill solid border -1
> set boxwidth 0.6
> 
> YminSpace = 4
> YStep = 2
> YExtraDistance = -YStep
> XShift(n) = (n < YminSpace) ? 0.45 : 0
> YShift(n) = (n < YminSpace) ?
> (YExtraDistance=YExtraDistance+YStep,YExtraDistance) :
> (YExtraDistance=-YStep,0)
> 
> plot \
>   $Data u 2 ti col , '' u 3:key(1) ti col, \
>   ysum=0 '' skip 1 using (0+XShift($2)):((ysum = ysum + $2,
> ysum-$2/2+YShift($2))):2 with labels notitle, \
>   ysum=0 '' skip 1 using (1+XShift($3)):((ysum = ysum + $3,
> ysum-$3/2+YShift($3))):3 with labels notitle,\
>   ysum=0 '' skip 1 using ($2>YminSpace ? 1/0:(0+XShift($2)-0.05)):((ysum
> = ysum + $2, ysum-$2/2+YShift($2))):(-0.1):(-YExtraDistance) ls -1 with
> vectors not,\
>   ysum=0 '' skip 1 using ($3>YminSpace ? 1/0:(1+XShift($3)-0.05)):((ysum
> = ysum + $3, ysum-$3/2+YShift($3))):(-0.1):(-YExtraDistance) ls -1 with
> vectors not,\
> 
> ###### end gnuplot code

Thank you again, Ethan, for the explanations and links.

What's still not clear to me why you can place the
ysum=0 between two plot commands...
What else can you place in front of a plot command?
For example:
n=1
plot n=n+1 sin(x*n) # works
plot (n=1,n=n+1) sin(x*n) # doesn't work... why?


Anyway, my original question is solved :-).
Nevertheless, I played around a little further.
If the portions in the stacked histogram are too small to fit a number,
the following code shows a way to place those numbers on the side with a
pointing arrow.
Maybe some people also mind find this useful.

The following code was working on my system (Win7, gnuplot 5.2) and
should be ready for copy&paste&plot. Be aware that the mail program
might have "messed up" the line breaks.

###### start gnuplot code
reset
$Data <<EOD
XXX Header1 Header2
one 10 50
two 3 2
three 30 15
four 40 5
five 0.5 0.5
six 0.6 0.6
seven 1 17
EOD

set style data histogram
set style histogram columnstacked
set style fill solid border -1
set boxwidth 0.6

YminSpace = 4
YStep = 2
YExtraDistance = -YStep
XShift(n) = (n < YminSpace) ? 0.45 : 0
YShift(n) = (n < YminSpace) ?
(YExtraDistance=YExtraDistance+YStep,YExtraDistance) :
(YExtraDistance=-YStep,0)

plot \
  $Data u 2 ti col , '' u 3:key(1) ti col, \
  ysum=0 '' skip 1 using (0+XShift($2)):((ysum = ysum + $2,
ysum-$2/2+YShift($2))):2 with labels notitle, \
  ysum=0 '' skip 1 using (1+XShift($3)):((ysum = ysum + $3,
ysum-$3/2+YShift($3))):3 with labels notitle,\
  ysum=0 '' skip 1 using ($2>YminSpace ? 1/0:(0+XShift($2)-0.05)):((ysum
= ysum + $2, ysum-$2/2+YShift($2))):(-0.1):(-YExtraDistance) ls -1 with
vectors not,\
  ysum=0 '' skip 1 using ($3>YminSpace ? 1/0:(1+XShift($3)-0.05)):((ysum
= ysum + $3, ysum-$3/2+YShift($3))):(-0.1):(-YExtraDistance) ls -1 with
vectors not,\

###### end gnuplot code

On Saturday, 28 October 2017 10:23:40 theozh wrote:
> Thanks a lot Ethan,
> I'll never would have found this one.
> With the minor change "ysum-$2/2", the following seems to place the
> number in the center of the portion.
> 
> plot $Data u 2 ti col , '' u 3:key(1) ti col, \
>      ysum=0 '' skip 1 using (0):((ysum = ysum + $2, ysum-$2/2)):2 with
> labels notitle, \
>      ysum=0 '' skip 1 using (1):((ysum = ysum + $3, ysum-$3/2)):3 with
> labels notitle
> 
> However, if looking at the syntax in "help plot"
> plot-element:
>            {<iteration>}
>            <definition> | {sampling-range} <function> | <data source>
>            {axes <axes>} {<title-spec>}
>            {with <style>}
> 
> I still don't understand why and how ((ysum = ysum + $2, ysum-$2/2))
> works. 

The comma is a mathematical binary operator indicating
serial evaluation.   The operation
	A,B
signifies "first evaluate A, then evaluate B, return the latter result"

    https://en.wikipedia.org/wiki/Comma_operator

> So apparently, you can place an expression/function before the
> comma and the expression after the comma is actually plotted? Good to
> know, I didn't know that one can make such constructs. Would be nice to
> have an example in "plot help" or if you have a link where to find this
> documented, please let me know.

gnuplot>  help expression operators binary

      (4th from last in the long list of operators)
      Serial evaluation occurs only in parentheses and is guaranteed to proceed
      in left to right order.  The value of the rightmost subexpression is returned.

For a demo the makes good use of this operator see

   http://gnuplot.sourceforge.net/demo_cvs/running_avg.html

	Ethan
 

Thanks a lot Ethan,
I'll never would have found this one.
With the minor change "ysum-$2/2", the following seems to place the
number in the center of the portion.

plot $Data u 2 ti col , '' u 3:key(1) ti col, \
     ysum=0 '' skip 1 using (0):((ysum = ysum + $2, ysum-$2/2)):2 with
labels notitle, \
     ysum=0 '' skip 1 using (1):((ysum = ysum + $3, ysum-$3/2)):3 with
labels notitle

However, if looking at the syntax in "help plot"
plot-element:
           {<iteration>}
           <definition> | {sampling-range} <function> | <data source>
           {axes <axes>} {<title-spec>}
           {with <style>}

I still don't understand why and how ((ysum = ysum + $2, ysum-$2/2))
works. So apparently, you can place an expression/function before the
comma and the expression after the comma is actually plotted? Good to
know, I didn't know that one can make such constructs. Would be nice to
have an example in "plot help" or if you have a link where to find this
documented, please let me know.

This could maybe serve as a starting point.  The placement is not pretty
but it shows the basic principle.

plot $Data u 2 ti col , '' u 3:key(1) ti col, \
     ysum=0 '' skip 1 using (0):((ysum = ysum + $2, ysum-5)):2 with labels
notitle, \
     ysum=0 '' skip 1 using (1):((ysum = ysum + $3, ysum-5)):3 with labels
notitle


On Fri, Oct 27, 2017 at 2:24 PM, theozh <th...@gm...> wrote:

> Hi,
> Is there maybe a simple way to place the values on top of
> in a column stacked histogram?
> The following example does not place the labels at the right
> y-positions, i.e. ideally centered within the different portions.
> For this you would need to somehow sum up the previous values. I do not
> see how...
> Any hints are appreciated!
> Theo.
>
> ###### gnuplot code start
> reset
> $Data <<EOD
> XXX Header1 Header2
> one 10 50
> two 20 30
> three 30 15
> four 40 5
> EOD
>
> set style data histogram
> set style histogram columnstacked
> set style fill solid border -1
> set boxwidth 0.75
>
> plot $Data u 2 ti col , '' u 3:key(1) ti col, \
>       '' u (0):2:2 with labels notitle, '' u (1):3:2 with labels notitle
>
> ###### gnuplot code end
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/
> lists/listinfo/gnuplot-info
>

Hi,
Is there maybe a simple way to place the values on top of
in a column stacked histogram?
The following example does not place the labels at the right
y-positions, i.e. ideally centered within the different portions.
For this you would need to somehow sum up the previous values. I do not
see how...
Any hints are appreciated!
Theo.

###### gnuplot code start
reset
$Data <<EOD
XXX Header1 Header2
one 10 50
two 20 30
three 30 15
four 40 5
EOD

set style data histogram
set style histogram columnstacked
set style fill solid border -1
set boxwidth 0.75

plot $Data u 2 ti col , '' u 3:key(1) ti col, \
      '' u (0):2:2 with labels notitle, '' u (1):3:2 with labels notitle

###### gnuplot code end

Because of the current epslatex terminal's inability to draw dashed line
patterns in contours, I am in trouble.

Issue 1612 would indicate that temporarily saving contours to data may
help, but that apparently is only feasible when using the data with plot
(and thus a rectangular projection) rather than splot: for the following
fragment

set table $blobs
splot [-pi:pi][-3:3] 2*pi*Vm0m1(1,-1,0,pi/4,x,y) title "$2\\pi V_{1,-1}^{(0,\\pi/4)}(\\theta,p)$" nosurface
unset table
splot [-pi:pi][-3:3] 2*pi*Vm0m1(1,-1,0,pi/4,x,y) title "$2\\pi V_{1,-1}^{(0,\\pi/4)}(\\theta,p)$" nocontours, $blobs nosurface

I get

splot [-pi:pi][-3:3] 2*pi*Vm0m1(1,-1,0,pi/4,x,y) title "$2\\pi V_{1,-1}^{(0,\\pi/4)}(\\theta,p)$" nocontours, $blobs nosurface
                                                                                                               ^
"wigner4.gp", line 190: 2 columns only possible with explicit pm3d style (line 8)

Is there any expedient for reattaching exported contours into a full
splot command, allowing me to root around the current dash pattern
initialization bug?

-- 
David Kastrup

David Kastrup <da...@gn...> writes:

> Ethan Merritt <eam...@gm...> writes:

> My expectation is colored by current documentation that is supposed to
> reflect the change from 4.x to 5.x.  It is not like I didn't quote it.
> As it is, Gnuplot is useless for creating monochrome surface plots with
> contours because all contour lines will look the same.  This wasn't the
> case in Gnuplot 4.x, and the documented replacement for versions >= 5.0
> does not work.

And this was already noted in
<https://sourceforge.net/p/gnuplot/bugs/1612/#d961> in 2015 after which
the containing issue was closed without further comment.

There may be a backstory I am not aware of, but the resulting
discrepancy between documentation and code is not telling it.

-- 
David Kastrup

Ethan A Merritt <eam...@gm...> writes:

> On Tuesday, 17 October 2017 15:13:49 Ethan Merritt wrote:
>> You are now, as I understand it, advocating that both the linewidth and dashtype
>> properties should act as the linecolor does.  I'm fine with adding that as
>> a user-specified option, but it would be something new rather than a return to
>> what any previous gnuplot version did.
>
>
> It occurs to me that if we do add something of this sort,
> it might be more usable to assign the linewidth or dashpattern
> directly to a series of contour levels rather than indirectly by 
> counting out linetypes and tryiing to figure out which level is
> going to get which linetype.
>
> Something like we already do with axis tic labels
>
>   set cntrlabel onecolor
>   set cntrparam level discrete 0 dashtype '..'
>   set cntrparam level add incremental 10, 10 linewidth 2
>   set cntrparam level add incremental 2, 10 linewidth 0.5
>   set cntrparam level add incremental 4, 10 linewidth 0.5
>   set cntrparam level add incremental 6, 10 linewidth 0.5
>   set cntrparam level add incremental 8, 10 linewidth 0.5
>
> That would get you a dotted contour at 0, heavy lines every 10,
> and thin lines every 2 otherwise.  All the same color in this case.
>
> Thoughts?

Mostly useless for linetypes displayed in a key.  Both plot types and
contour line labels are usually listed in a key, so it does not make a
lot of sense to treat them differently in that respect.

-- 
David Kastrup

Ethan Merritt <eam...@gm...> writes:

> On Tue, Oct 17, 2017 at 6:38 AM, David Kastrup <da...@gn...> wrote:
>
>> Ethan A Merritt <eam...@gm...> writes:
>>
>> > On Sunday, 15 October 2017 10:53:08 Ethan A Merritt wrote:
>> >> On Sunday, 15 October 2017 13:06:50 David Kastrup wrote:
>> >> >
>> >> > So I now tried compiling 5.2.0.
>> >> >
>> >> > No change in the epslatex terminal: it would appear that _only_ the
>> >> > linewidth and the dash pattern for linestyle 1 are ever consulted and
>> >> > are used for _all_ lines.  Linecolor can be changed per line style,
>> but
>> >> > pretty much nothing else.
>> >>
>> >> Correct.  It steps through sequential line colors.
>> >>
>> >> > Anybody have a good idea for where to patch this up?
>> >>
>> >> The following 1-line change might or might not produce acceptable
>> >> results for you.   One problem is that the line segments making up
>> >> a contour are not necessarily drawn in order and some terminals
>> >> reset the dash pattern for each segment, leading to mostly solid
>> >> or mostly missing lines rather than the desired dash pattern.
>> >> For other terminal types this doesn't seem to be a problem.
>> >>
>> >> If this does work for you please report back.
>> >> We could make it an optional setting of some sort.
>>
>> I don't think following the documentation is "optional".
>>
>> [snip]
>
> I think I understand what you are expecting from the program, but honestly
> it has never worked that way.

Shrug.  Of course not: dash types as part of line style were a 5.0
thing.  Before one used

set terminal epslatex dashed

but dashed is now ignored, and the _documented_ replacement one is
supposed to be using does not work.  And now you state it shouldn't
work, documentation be damned.  But in a monochrome print, having all
contour lines look the same is not an option.

> You are now, as I understand it, advocating that both the linewidth
> and dashtype properties should act as the linecolor does.  I'm fine
> with adding that as a user-specified option, but it would be something
> new rather than a return to what any previous gnuplot version did.

Look, this isn't fun.

help dash

clearly states:

gnuplot> help dash

In gnuplot version 5 the dash pattern (`dashtype`) is a separate property 
 associated with each line, analogous to `linecolor` or `linewidth`.  It is not
 necessary to place the current terminal in a special mode just to draw dashed
 lines.  I.e. the command `set term <termname> {solid|dashed}` is now ignored.
 If backwards compatibility with old scripts written for version 4 is required,
 the following lines can be used instead:

      if (GPVAL_VERSION >= 5.0) set for [i=1:9] linetype i dashtype i
      if (GPVAL_VERSION < 5.0) set termoption dashed

So _of_ _course_ this worked differently before version 5.0.  The
problem is that it _worked_.  Now it doesn't work at all.  There is
absolutely no more way to get differently dashed contours in a
monochrome terminal since the documented replacement does not work, and
you state that you think it should be an optional feature to have it
work.

> Note: Your expectation may be colored by past behaviour of the
> postscript terminal driver.

My expectation is colored by current documentation that is supposed to
reflect the change from 4.x to 5.x.  It is not like I didn't quote it.
As it is, Gnuplot is useless for creating monochrome surface plots with
contours because all contour lines will look the same.  This wasn't the
case in Gnuplot 4.x, and the documented replacement for versions >= 5.0
does not work.

-- 
David Kastrup

On Tuesday, 17 October 2017 15:13:49 Ethan Merritt wrote:
> You are now, as I understand it, advocating that both the linewidth and dashtype
> properties should act as the linecolor does.  I'm fine with adding that as
> a user-specified option, but it would be something new rather than a return to
> what any previous gnuplot version did.


It occurs to me that if we do add something of this sort,
it might be more usable to assign the linewidth or dashpattern
directly to a series of contour levels rather than indirectly by 
counting out linetypes and tryiing to figure out which level is
going to get which linetype.

Something like we already do with axis tic labels

  set cntrlabel onecolor
  set cntrparam level discrete 0 dashtype '..'
  set cntrparam level add incremental 10, 10 linewidth 2
  set cntrparam level add incremental 2, 10 linewidth 0.5
  set cntrparam level add incremental 4, 10 linewidth 0.5
  set cntrparam level add incremental 6, 10 linewidth 0.5
  set cntrparam level add incremental 8, 10 linewidth 0.5

That would get you a dotted contour at 0, heavy lines every 10,
and thin lines every 2 otherwise.  All the same color in this case.

Thoughts?

	Ethan

On Tue, Oct 17, 2017 at 6:38 AM, David Kastrup <da...@gn...> wrote:

> Ethan A Merritt <eam...@gm...> writes:
>
> > On Sunday, 15 October 2017 10:53:08 Ethan A Merritt wrote:
> >> On Sunday, 15 October 2017 13:06:50 David Kastrup wrote:
> >> >
> >> > So I now tried compiling 5.2.0.
> >> >
> >> > No change in the epslatex terminal: it would appear that _only_ the
> >> > linewidth and the dash pattern for linestyle 1 are ever consulted and
> >> > are used for _all_ lines.  Linecolor can be changed per line style,
> but
> >> > pretty much nothing else.
> >>
> >> Correct.  It steps through sequential line colors.
> >>
> >> > Anybody have a good idea for where to patch this up?
> >>
> >> The following 1-line change might or might not produce acceptable
> >> results for you.   One problem is that the line segments making up
> >> a contour are not necessarily drawn in order and some terminals
> >> reset the dash pattern for each segment, leading to mostly solid
> >> or mostly missing lines rather than the desired dash pattern.
> >> For other terminal types this doesn't seem to be a problem.
> >>
> >> If this does work for you please report back.
> >> We could make it an optional setting of some sort.
>
> I don't think following the documentation is "optional".
>
> [snip]

I think I understand what you are expecting from the program, but honestly
it has never worked that way.  Prior to gnuplot version 5  linetypes did not
include a "dashtype" property, so the question of applying or not applying
it
to draw contours was moot.  Linetypes did have a "linewidth" property of
course, but just as now only one linewidth was used for all the contours in
a
plot.  I've gone back and confirmed that for versions 4.4 and 4.6.

When gnuplot version 5 introduced dashtypes, we had to choose whether
for the purposes of drawing contours they would follow the example of
the linecolor property (increment for each contour level) or linewidth
property (same for the entire plot).   There was no strong advocacy either
way
and we ended up choosing to treat it as analogous to linewidth.

You are now, as I understand it, advocating that both the linewidth and
dashtype
properties should act as the linecolor does.  I'm fine with adding that as
a user-specified option, but it would be something new rather than a return
to
what any previous gnuplot version did.

Note:  Your expectation may be colored by past behaviour of the postscript
terminal driver.  Prior to gnuplot version 5 the postscript terminal
acted differently from all other terminal types.  One of the goals set for
version
5 was to get all terminals to behave as consistently as possible, even at
the
cost of losing exact backwards compatibility.  Normally backwards
compatibility
has the highest priority, so the 4->5 transition was highly unusual in that
regard.

Ethan A Merritt <eam...@gm...> writes:

> On Sunday, 15 October 2017 10:53:08 Ethan A Merritt wrote:
>> On Sunday, 15 October 2017 13:06:50 David Kastrup wrote:
>> > 
>> > So I now tried compiling 5.2.0.
>> > 
>> > No change in the epslatex terminal: it would appear that _only_ the
>> > linewidth and the dash pattern for linestyle 1 are ever consulted and
>> > are used for _all_ lines.  Linecolor can be changed per line style, but
>> > pretty much nothing else.
>> 
>> Correct.  It steps through sequential line colors.
>> 
>> > Anybody have a good idea for where to patch this up?
>> 
>> The following 1-line change might or might not produce acceptable
>> results for you.   One problem is that the line segments making up
>> a contour are not necessarily drawn in order and some terminals
>> reset the dash pattern for each segment, leading to mostly solid
>> or mostly missing lines rather than the desired dash pattern.
>> For other terminal types this doesn't seem to be a problem.
>> 
>> If this does work for you please report back. 
>> We could make it an optional setting of some sort.

I don't think following the documentation is "optional".

>From help set cntrlabel:

 A contour label is placed in the plot key for each linetype used. By default
 each contour level is given its own linetype, so a separate label appears for
 each.  The command `set cntrlabel onecolor` causes all contours to be drawn
 using the same linetype, so only one label appears in the plot key.
 This command replaces an older command `unset clabel`.

>From help set linetype:

 The `set linetype` command allows you to redefine the basic linetypes used
 for plots.  The command options are identical to those for "set style line".
 Unlike line styles, redefinitions by `set linetype` are persistent;  they
 are not affected by `reset`.

>From help set style line:

 Each terminal has a default set of line and point types, which can be seen
 by using the command `test`.  `set style line` defines a set of line types
 and widths and point types and sizes so that you can refer to them later by
 an index instead of repeating all the information at each invocation.

 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>}
                              {{pointnumber | pn} <max_symbols>}
                              {{dashtype | dt} <dashtype>}
                              {palette}
       unset style line
       show style line

 `default` sets all line style parameters to those of the linetype with
 that same index.


>From help dashtype:

 In gnuplot version 5 the dash pattern (`dashtype`) is a separate property 
 associated with each line, analogous to `linecolor` or `linewidth`.  It is not
 necessary to place the current terminal in a special mode just to draw dashed
 lines.  I.e. the command `set term <termname> {solid|dashed}` is now ignored.
 If backwards compatibility with old scripts written for version 4 is required,
 the following lines can be used instead:

      if (GPVAL_VERSION >= 5.0) set for [i=1:9] linetype i dashtype i
      if (GPVAL_VERSION < 5.0) set termoption dashed

 All lines have the property `dashtype solid` unless you specify otherwise.
 You can change the default for a particular linetype using the command
 `set linetype` so that it affects all subsequent commands, or you can include
 the desired dashtype as part of the `plot` or other command.


>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%
>> --- gnuplot52/src/graph3d.c     2017-09-15 20:26:48.393406844 -0700
>> +++ test52/src/graph3d.c        2017-10-15 10:50:39.698779538 -0700
>> @@ -1265,6 +1265,8 @@ do_3dplot(
>>                                 /* otherwise the following would be sufficient */
>>                                 load_linetype(&ls, this_plot->hidden3d_top_linetype + ic);
>>                             }
>> +/* DEBUG */                /* increment dashtype also */
>> +/* DEBUG */                thiscontour_lp_properties.d_type = ic;
>
> probably better as
>
>   +/* DEBUG */                thiscontour_lp_properties.d_type = ls.d_type;

I can now set individual dash types.  The individual linewidths still do
not seem to get consulted for the contour lines: it seems like the
linewidth of line style 1 is applied everywhere.

-- 
David Kastrup

On Sunday, 15 October 2017 10:53:08 Ethan A Merritt wrote:
> On Sunday, 15 October 2017 13:06:50 David Kastrup wrote:
> > 
> > So I now tried compiling 5.2.0.
> > 
> > No change in the epslatex terminal: it would appear that _only_ the
> > linewidth and the dash pattern for linestyle 1 are ever consulted and
> > are used for _all_ lines.  Linecolor can be changed per line style, but
> > pretty much nothing else.
> 
> Correct.  It steps through sequential line colors.
> 
> > Anybody have a good idea for where to patch this up?
> 
> The following 1-line change might or might not produce acceptable
> results for you.   One problem is that the line segments making up
> a contour are not necessarily drawn in order and some terminals
> reset the dash pattern for each segment, leading to mostly solid
> or mostly missing lines rather than the desired dash pattern.
> For other terminal types this doesn't seem to be a problem.
> 
> If this does work for you please report back. 
> We could make it an optional setting of some sort.
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%
> --- gnuplot52/src/graph3d.c     2017-09-15 20:26:48.393406844 -0700
> +++ test52/src/graph3d.c        2017-10-15 10:50:39.698779538 -0700
> @@ -1265,6 +1265,8 @@ do_3dplot(
>                                 /* otherwise the following would be sufficient */
>                                 load_linetype(&ls, this_plot->hidden3d_top_linetype + ic);
>                             }
> +/* DEBUG */                /* increment dashtype also */
> +/* DEBUG */                thiscontour_lp_properties.d_type = ic;

probably better as

  +/* DEBUG */                thiscontour_lp_properties.d_type = ls.d_type;


>                             thiscontour_lp_properties.pm3d_color = ls.pm3d_color;
>                             term_apply_lp_properties(&thiscontour_lp_properties);
>                         }
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> 

-- 

On Sunday, 15 October 2017 13:06:50 David Kastrup wrote:
> 
> So I now tried compiling 5.2.0.
> 
> No change in the epslatex terminal: it would appear that _only_ the
> linewidth and the dash pattern for linestyle 1 are ever consulted and
> are used for _all_ lines.  Linecolor can be changed per line style, but
> pretty much nothing else.

Correct.  It steps through sequential line colors.

> Anybody have a good idea for where to patch this up?

The following 1-line change might or might not produce acceptable
results for you.   One problem is that the line segments making up
a contour are not necessarily drawn in order and some terminals
reset the dash pattern for each segment, leading to mostly solid
or mostly missing lines rather than the desired dash pattern.
For other terminal types this doesn't seem to be a problem.

If this does work for you please report back. 
We could make it an optional setting of some sort.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot52/src/graph3d.c     2017-09-15 20:26:48.393406844 -0700
+++ test52/src/graph3d.c        2017-10-15 10:50:39.698779538 -0700
@@ -1265,6 +1265,8 @@ do_3dplot(
                                /* otherwise the following would be sufficient */
                                load_linetype(&ls, this_plot->hidden3d_top_linetype + ic);
                            }
+/* DEBUG */                /* increment dashtype also */
+/* DEBUG */                thiscontour_lp_properties.d_type = ic;
                            thiscontour_lp_properties.pm3d_color = ls.pm3d_color;
                            term_apply_lp_properties(&thiscontour_lp_properties);
                        }
%%%%%%%%%%%%%%%%%%%%%%%%%%%%

So I now tried compiling 5.2.0.

No change in the epslatex terminal: it would appear that _only_ the
linewidth and the dash pattern for linestyle 1 are ever consulted and
are used for _all_ lines.  Linecolor can be changed per line style, but
pretty much nothing else.

Anybody have a good idea for where to patch this up?

-- 
David Kastrup

David Kastrup <da...@gn...> writes:

> On gnuplot 5.0.7 I am completely unable to get individually dashed
> contours for the epslatex terminal: all contour lines take their color
> from the individual line styles, but the dashing exclusively from line
> style 1 (which I need for the main plot anyway, even if equally dashed
> contour lines would not be pointless anyway).
>
> Here is my current file, I am out of my wits.  I am pretty sure that
> this is actually a bug, but I am under time pressure and would at least
> need a workaround.

Sigh, attachment scrubbed.  Let's try again as text/plain attachment.

I try explicitly to make linestyle 3 red and dotted, and try to give the
other linestyles >= 2 the appropriate dashstyle.  Red obviously works,
dashing doesn't.

On gnuplot 5.0.7 I am completely unable to get individually dashed
contours for the epslatex terminal: all contour lines take their color
from the individual line styles, but the dashing exclusively from line
style 1 (which I need for the main plot anyway, even if equally dashed
contour lines would not be pointless anyway).

Here is my current file, I am out of my wits.  I am pretty sure that
this is actually a bug, but I am under time pressure and would at least
need a workaround.