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

various observations (added to list)

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

OK, since SourceForge CVS seems to be working, somewhat, I'm trying the latest software and attempting some plot types I hadn't really used before.  Some observations:

1)  Is the CVS synched with what developers have checked in?  If so, there is still a problem with arrow style parsing, i.e., arrowstyle.dem fails:

turn to continue
plot '1.dat' using 1:2:(+1):(+1) with vectors lt 4 filled title 'filled',      '2.dat' using 1:2:(+1):(+1) with vectors lt 1 heads title 'double-headed',      '2.dat' using ($1):(2-$2/3):(+1):(+.5) with vectors lt -1 lw 3 nohead title 'no head'
                                                          ^
"arrowstyle.dem", line 91: ';' expected


2)  3D plot layout is definitely the thing most in need of work post 4.2.  The default colorbox seems too big and out of place.  The x-y plane position seems slightly limited.  Let me give an example to illustrate a few things.  The following is meant to show a zero mean, unit variance Gaussian r.v. density.  The contour is supposed to represent the variance in some way, and there are supposed to be a set of Gaussian samples with zero mean, unit variance.

set hidden3d
set contour
set isosamples 60
set view 68, 28, 1, 1
unset key
unset title
set cntrparam levels discrete 0.1
set style line 1 linecolor rgb "black"
set term x11 2
set parametric
set xrange [-5:5]
set yrange [-5:5]
set urange [-5:5]
set vrange [-5:5]
set xyplane at -0.2
splot u,v,( 1/(2*pi) * exp(-0.5 * (u**2 + v**2)) ) with line ls 1, \
  sqrt(-2*log(rand(0)))*cos(2*pi*rand(0)),sqrt(-2*log(rand(0)))*sin(2*pi*rand(0)),-0.2 with points pointtype 7 linecolor rgb "black"

My intent was to have the points on the x-y plane and drop the x-y plane to leave enough space that the surface plot doesn't obstruct the points.  Using the "set xyplane #" just didn't seem to get me there.  The axes would remain the same and the x-y plane would extend off the plot, which just seemed silly.

Then "set xyplane at -0.2" and setting the z-value of the points to -0.2 puts the points and x-y plane in the same plane, but notice that the line of the z-axis still extends down to where the xyplane used to be.  (That's a bug, isn't it?  Or am I missing something?)  Consequently, the plot isn't using the space efficiently.

3)  It sure is annoying going through the trouble of looking up in "test" (x11) the number of the symbol desired, and then the symbol comes out differently in the output file (png).  Regardless of the different symbols from one output terminal to another, I find it so confusing, because looking at "test" as a PNG output the "7" is actually a solid symbol, but not in this example (see attached "normal.png").  Also, is it OK to use "linecolor rgb "black" to control symbol color as I did?  Actually, I'd think that the "linecolor", "pointtype" is an extraneous syntax.  Couldn't it just be "points type 7 color rgb "black""?  Or in the case of lines, "lines type 1"?

4)  In a related category would be contours.  I wanted to force the contours to be all of the same color, in this case black.  That doesn't seem possible.

5)  In the example, I really only want about 25 samples.  IS THERE SOME WAY TO CONTROL THIS?  Setting the samples # doesn't seem to effect this.  Ethan has an example where he assigns a dozen or two random numbers but that is based off the number of samples in a data file, i.e., "using 1:2:rand(0)".

6)  Would anyone object to a patch for a math function "randn()" generating unit variance normal distribution random values using the Box-Mueller method?  The last line of the above example constitutes the polar method; it would just save a lot of typing in generating normal r.v.s.

7)  Anyone notice that the above example in the x11 terminal is rather slow refresh (even when the sample points are not included)?  I realize that it takes a while to create the rendering of hidden lines with so many iso-lines, but once it is drawn one would think the refresh in gnuplot-x11 would be fairly fresh.  Yes, it has a lot of lines; but still, drawing lines shouldn't be so slow.

Dan

various observations

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

OK, since SourceForge CVS seems to be working, somewhat, I'm trying the latest software and attempting some plot types I hadn't really used before.  Some observations:

1)  Is the CVS synched with what developers have checked in?  If so, there is still a problem with arrow style parsing, i.e., arrowstyle.dem fails:

turn to continue
plot '1.dat' using 1:2:(+1):(+1) with vectors lt 4 filled title 'filled',      '2.dat' using 1:2:(+1):(+1) with vectors lt 1 heads title 'double-headed',      '2.dat' using ($1):(2-$2/3):(+1):(+.5) with vectors lt -1 lw 3 nohead title 'no head'
                                                          ^
"arrowstyle.dem", line 91: ';' expected


2)  3D plot layout is definitely the thing most in need of work post 4.2.  The default colorbox seems too big and out of place.  The x-y plane position seems slightly limited.  Let me give an example to illustrate a few things.  The following is meant to show a zero mean, unit variance Gaussian r.v. density.  The contour is supposed to represent the variance in some way, and there are supposed to be a set of Gaussian samples with zero mean, unit variance.

set hidden3d
set contour
set isosamples 60
set view 68, 28, 1, 1
unset key
unset title
set cntrparam levels discrete 0.1
set style line 1 linecolor rgb "black"
set term x11 2
set parametric
set xrange [-5:5]
set yrange [-5:5]
set urange [-5:5]
set vrange [-5:5]
set xyplane at -0.2
splot u,v,( 1/(2*pi) * exp(-0.5 * (u**2 + v**2)) ) with line ls 1, \
  sqrt(-2*log(rand(0)))*cos(2*pi*rand(0)),sqrt(-2*log(rand(0)))*sin(2*pi*rand(0)),-0.2 with points pointtype 7 linecolor rgb "black"

My intent was to have the points on the x-y plane and drop the x-y plane to leave enough space that the surface plot doesn't obstruct the points.  Using the "set xyplane #" just didn't seem to get me there.  The axes would remain the same and the x-y plane would extend off the plot, which just seemed silly.

Then "set xyplane at -0.2" and setting the z-value of the points to -0.2 puts the points and x-y plane in the same plane, but notice that the line of the z-axis still extends down to where the xyplane used to be.  (That's a bug, isn't it?  Or am I missing something?)  Consequently, the plot isn't using the space efficiently.

3)  It sure is annoying going through the trouble of looking up in "test" (x11) the number of the symbol desired, and then the symbol comes out differently in the output file (png).  Regardless of the different symbols from one output terminal to another, I find it so confusing, because looking at "test" as a PNG output the "7" is actually a solid symbol, but not in this example (see attached "normal.png").  Also, is it OK to use "linecolor rgb "black" to control symbol color as I did?  Actually, I'd think that the "linecolor", "pointtype" is an extraneous syntax.  Couldn't it just be "points type 7 color rgb "black""?  Or in the case of lines, "lines type 1"?

4)  In a related category would be contours.  I wanted to force the contours to be all of the same color, in this case black.  That doesn't seem possible.

5)  In the example, I really only want about 25 samples.  IS THERE SOME WAY TO CONTROL THIS?  Setting the samples # doesn't seem to effect this.  Ethan has an example where he assigns a dozen or two random numbers but that is based off the number of samples in a data file, i.e., "using 1:2:rand(0)".

6)  Would anyone object to a patch for a math function "randn()" generating unit variance normal distribution random values using the Box-Mueller method?  The last line of the above example constitutes the polar method; it would just save a lot of typing in generating normal r.v.s.

Dan

Re: smooth shading & terminal specialities

[<tim...@en...>]

>> I don't quite understand what you mean by that.
>> How does a "vector graphic format" avoid having to draw filled
>> rectangles?  Do you mean there is native support for gradient fill?
>> In any case...
>
> Yes, native support for gradient fill.

Starting from Postscript level 3, which has been released in 1999
according to the date in the Adobe documentation. I don't know much about
the capabilities of printers regarding Postscript level 3.

However, the rendering is good for me with Ghostscript.

> OK. Let me try to explain, For drawing the "plotting area" in this
> image (http://gnuplot.sourceforge.net/demo_4.1/pm3d.8.png), which is
> nothing else but a bitmap image, gnuplot calls my terminal
>     term->set_color(...)
>     term->fillbox(...)
> 49 x 49 times. For bitmap teminal this doesn't really matter, but for
> my terminal it means constructing 49x49 paths and fill each one of
> them separately (bot at compile time of the image and when displaying
> it in GhostView or Acrobat), not to mention aliasing-artefacts (I
> don't know how they are called, but GhostView shows white stripes all
> over the plot).

This kind of artifacts due to antialiasing can sometimes be worked around
when you know that paths are adjacent. For the wxWidgets terminal which
uses Cairo to render, I had to use a different operator
(CAIRO_OPERATOR_SATURATE) to composite what you want to paint with what
already exists on the surface, so that the fill algorithm won't produce
white seams between adjacent polygons. There have been multiple threads i=
n
the cairo mailing list about that.
However, in postscript no such concept seem to exist, at least I can't
find any by looking quickly in the Adobe doc, but that may be worth
looking for.

By the way, the aquaterm terminal seems to have the same problem : see th=
e
pm3d plot on http://aquaterm.sourceforge.net/index.shtml?page=3Ds1

Finally, if gradient fills are to be used, Cairo can also do that, so it
should definitely go into a new terminal entry instead of a direct call.

Regards,

Timoth=E9e

Re: smooth shading & terminal specialities

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

On Tuesday 09 May 2006 03:52 pm, you wrote:
> I'm sending a sample .ps file with gradient fill for the default palette.
> 
> I calculated the values at 11 equally spaced points and converted them
> into hex numbers, now stored in /data. PostScript terminal currently
> draws 1024 single-color rectangles. Does anyone notice any difference
> in the palette produced by gradient fill and the one produced by 1024
> samples?

Aha.  You are using Level 3 extensions to PostScript.

They are not mentioned in the PostScript Language Reference Manual 
(2nd Edition) that I have on my shelf.
Your test file displays on my older machines, which surprises me,
but the result looks truly awful.  My new machines have a newer gs
installed that does indeed support these extensions.

I guess I should go out and buy a new copy of the Language
Reference Manual.

If we were to adopt this approach, we would have to wrap it in a test
for level capabilities so that Level 1/2/3 devices would all do 
something reasonable.  That is certainly possible, but could be done
more easily by an expert.  Harald Harders and I muddled our way 
through something similar for the pattern-fill support, which is a
Level 2 extension, but it was a struggle.

> > OK.  How about PDF, does that have more features like gradient fill than does P.S.?
> 
> PS *does have* gradient fill.

Sufficiently new versions of it [Level 3].

> OK. Let me try to explain, For drawing the "plotting area" in this
> image (http://gnuplot.sourceforge.net/demo_4.1/pm3d.8.png), which is
> nothing else but a bitmap image, gnuplot calls my terminal
>     term->set_color(...)
>     term->fillbox(...)
> 49 x 49 times. For bitmap teminal this doesn't really matter, but for
> my terminal it means constructing 49x49 paths and fill each one of
> them separately (bot at compile time of the image and when displaying
> it in GhostView or Acrobat), not to mention aliasing-artefacts (I
> don't know how they are called, but GhostView shows white stripes all
> over the plot). 

Yeah, we know.  That is the down-side of newer versions of gs/gv/ghostview.
They have a bad aliasing bug.  It's a known bug, but even if they fix it
there will be a lot of broken installations for a long time to come.

> This is extremely inefficient. It would be much better 
> if gnuplot would call a routine
>     term->image(49,49, ....)
> The result would be the visually the same (only better since no
> artefacts would occur) and both compiling and rendering would be more
> efficient. If the driver doesn't support "images", it can still draw
> 49 times 49 filled rectangles.

But how does the higher level code tell a driver what to put in those
49x49 boxes?  In the general case each one has a different color, so
I do not see how you end up saving anything.

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

Re: smooth shading & terminal specialities

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

I'm sending a sample .ps file with gradient fill for the default palette.

I calculated the values at 11 equally spaced points and converted them
into hex numbers, now stored in /data. PostScript terminal currently
draws 1024 single-color rectangles. Does anyone notice any difference
in the palette produced by gradient fill and the one produced by 1024
samples? (I've read that sinus can be represented using 10 samples
with only 1% of mistake.) Well, the number of samples for making
gradient fill can be increased, but defining the color in 20 points is
still far less than drawing 1024 rectangles, not counting the
inefficiency and antialiasing artefacts that arise in the current
approach.

I don't know enough about PostScript language to be able to tell how
/data can be calculated in the PostScript file itself, but I'm almost
sure that it is possible. In any case gnuplot can calculate those 11
(or more) values if needed.

Could someone with some more inspect into PS terminal implement such
gradient fills for draw_inside_color_smooth_box_postscript(...)? I can
explain the details if needed.


On 5/8/06, Ethan Merritt (and others) wrote:

> > I need my own version of drawing "smooth_box" (the terminal supports
> > vector graphic format, so drawing a whole lot of rectangles of single
> > color is extremely inefficient).
>
> I don't quite understand what you mean by that.
> How does a "vector graphic format" avoid having to draw filled
> rectangles?  Do you mean there is native support for gradient fill?
> In any case...

Yes, native support for gradient fill.

> PostScript? I know this could be done in SVG, but I am unaware
> of any way to do gradients in PostScript other than lots of little
> single-color boxes.

I'm attaching an example showing gradients in PS.

> You mis-understand the purpose of the demo.  It is not trying to
> show an efficient way of plotting a rectangular image. It is simply
> demonstrating different color schemes possible by changing the
> palette definition.

Sure, but that doesn;t mean that it couldn't be rendered more
efficiently. (One would loose the ability to manualy change the
palette in the PostScript file afterwards (since gnuplot should
calculate the colors before drawing an image as opposed to the current
situation where PostScript calculates the proper color), but I don't
think that this would be a serious reason for not implementing better
rendering. How many people are manual editin PostScript code and how
many are suffering from GhostScript antialiasing "bug"?)

> Thus you mean to automagically change "with pm3d" into "with image" witho=
ut
> knowing it to user? That's not a good idea I think.

The user shouldn't notice any difference.

> OK.  How about PDF, does that have more features like gradient fill than =
does P.S.?

PS *does have* gradient fill.

> ...  Forgot to mention desires for compression in images that have come u=
p.
> (That really has no significance to recent discussion about terminal comm=
ands.)
> And also the colorbox can be done with an image.

I wanted to implement that behaviour in my driver (if maxcolors>0 use
image instead of gradient fill), but I would be glad if gnuplot would
be clever enough to take care about that.


> >>Even the 4th and the 5th example could be simplified considerably,
> >>but the examples 6-12 are obvious examples of such inefficient graphic,
> >>which could be stored as a bitmap image.
> >
> >
> > You mis-understand the purpose of the demo.  It is not trying to
> > show an efficient way of plotting a rectangular image. It is simply
> > demonstrating different color schemes possible by changing the
> > palette definition.
>
> Mojca, could you explain a bit more about what you meant.  I think we're =
trying to guess here a bit too much.

OK. Let me try to explain, For drawing the "plotting area" in this
image (http://gnuplot.sourceforge.net/demo_4.1/pm3d.8.png), which is
nothing else but a bitmap image, gnuplot calls my terminal
    term->set_color(...)
    term->fillbox(...)
49 x 49 times. For bitmap teminal this doesn't really matter, but for
my terminal it means constructing 49x49 paths and fill each one of
them separately (bot at compile time of the image and when displaying
it in GhostView or Acrobat), not to mention aliasing-artefacts (I
don't know how they are called, but GhostView shows white stripes all
over the plot). This is extremely inefficient. It would be much better
if gnuplot would call a routine
    term->image(49,49, ....)
The result would be the visually the same (only better since no
artefacts would occur) and both compiling and rendering would be more
efficient. If the driver doesn't support "images", it can still draw
49 times 49 filled rectangles.

Mojca

Re: Problem with compiling on windows

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

Here is a patch for this problem, including a proposal for a ChangeLog
entry:

2006-05-09  Bastian Maerkisch  <bma...@we...>

	* config/makefile.nt: Make sure that the same (basic) compiler
	options are used for compiling wgnuplot and pgnuplot. This is
	necessary since they both contain version.c

Btw. for me cvs is still not working.
Bastian

Bastian Maerkisch wrote:
> Hi,
>=20
> it seems that that problem was introduced by me when I changed
> the options used to compile wgnuplot. Problem is that version.c
> and pgnuplot.c are compiled with different options and C libraries
> now. On my system pgnuplot still compiles, though. It just crashes :(
> I'll send a patch for that later today.
> Btw. wgnuplot should still compile fine.
>=20
> Bastian
>=20
>=20
> Mojca Miklavec wrote:
>> Hello,
>>
>> I'm glad that CVS is working again. But some days ago I noticed that
>> I'm not able to compile the code any more. I did a checkout into a
>> fresh folder, but the problem persists. I'm compiling on Windows, MS
>> Visual Studio 2005 with makefile.nt. Some time ago the files compiled
>> OK.
>>
>> Any ideas or suggestions?
>>
>> Thanks,
>>    Mojca

--=20
Bastian M=E4rkisch
Physikalisches Institut, Universit=E4t Heidelberg

Re: smooth shading & terminal specialities

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

>> driver to implement this so far is the postscript driver.  The test
>> "if (gppsfile)..." is a short way of testing for the driver; it might
>> be more proper to say
>>   if (!strcmp(term->name,"post") || !strcmp(term->name,"epslatex")
>>      || !strcmp(term->name,"pslatex") ....

if (gppsfile)  has replaced that strcmp(...->name,...) comparison which was 
there earlier. Thus, use (gppsfile) to test for an PS output stream.

---
PM

Re: Problem with compiling on windows

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

Hi,

it seems that that problem was introduced by me when I changed
the options used to compile wgnuplot. Problem is that version.c
and pgnuplot.c are compiled with different options and C libraries
now. On my system pgnuplot still compiles, though. It just crashes :(
I'll send a patch for that later today.
Btw. wgnuplot should still compile fine.

Bastian


Mojca Miklavec wrote:
> Hello,
> 
> I'm glad that CVS is working again. But some days ago I noticed that
> I'm not able to compile the code any more. I did a checkout into a
> fresh folder, but the problem persists. I'm compiling on Windows, MS
> Visual Studio 2005 with makefile.nt. Some time ago the files compiled
> OK.
> 
> Any ideas or suggestions?
> 
> Thanks,
>    Mojca
> 

Re: smooth shading & terminal specialities

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

On Monday 08 May 2006 08:16 pm, Daniel J Sebald wrote:
> > be more proper to say
> >   if (!strcmp(term->name,"post") || !strcmp(term->name,"epslatex")
> >      || !strcmp(term->name,"pslatex") ....
> 
> Really?  I thought we're supposed to keep terminal-specific code 
> out of the core and override terminal functions. 

Right. I already pointed out that we had discussed making this
a terminal entry point. But since the only terminal that would
actually use it is post.trm, there wasn't much motion to add the
entry to all terminals.
 
> Well, doing it as an image, one would think that the viewer driver 
> knows to do proper anti-aliasing.  

One would think. 
But there is a known rendering bug in ghostscript's anti-aliasing code.

> >  One recent request (# 1480115) is to add support for an alpha channel.
> 
> Oh yeah, I forgot all about that.
> Am I right that the alpha would be a depth of four, one of the channels
> being 0/nonzero?  

Alpha runs from 0->1 (or 0-255 if it's a 1-byte representation).

> So maybe the syntax should be something like "with rgbaimage",
> or "with argbimage"?

You already wrote code to support in on input -

    binary filetype=avs with rgbimage

AVS files contains 4 bytes per pixel, ARGB.
But right now the Alpha byte is thrown away on input.

Suppose you were to keep the alpha byte in parallel with the
RGB bytes.  A few drivers (gd, svg) can use it directly.
But we'd have to add custom code in order to get most drivers to
handle transparency.

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

Re: smooth shading & terminal specialities

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

Ethan Merritt wrote:
> On Sunday 07 May 2006 07:53 pm, Mojca Miklavec wrote:
>>Should I say 
>>
>>    if (gppsfile)
>>	draw_inside_color_smooth_box_postscript(out);
>>    else if(term->name == "my terminal")
>>        MY_TERMINAL_draw_inside_color_smooth_box();
>>    else
>>        ...
> 
> 
> Yes. 
> The idea is that there is a generic routine draw_inside_color_smooth_box_bitmap
> that can be used by any terminal.  However, some terminals may be able
> to do the job more efficiently using some private routine. The only
> driver to implement this so far is the postscript driver.  The test
> "if (gppsfile)..." is a short way of testing for the driver; it might
> be more proper to say
>   if (!strcmp(term->name,"post") || !strcmp(term->name,"epslatex")
>      || !strcmp(term->name,"pslatex") ....

Really?  I thought we're supposed to keep terminal-specific code out of the core and override terminal functions.


>>draw_inside_color_smooth_box_postscript could be rewritten as well to
>>produce smooth shading instead of 1000 single-color boxes (smooth
>>liear shading with a stitching function). I know exactly what has to
>>be done, but I would need some thinking to implement it properly. If
>>someone knows PostScript language better than I do, I'm ready to
>>describe the procedure more precisely. (A better and more efficient
>>code can be produced using a new approach.)
> 
> 
> That would be nice, particularly because the current PostScript
> implementation triggers anti-aliasing artifacts on some versions
> of ghostscript.  But are you sure there is a better way in
> PostScript? I know this could be done in SVG, but I am unaware
> of any way to do gradients in PostScript other than lots of little
> single-color boxes.

Well, doing it as an image, one would think that the viewer driver knows to do proper anti-aliasing.  (Recall PostScript isn't bitmap based... only in its last rendering does it do that.)


>>Even the 4th and the 5th example could be simplified considerably,
>>but the examples 6-12 are obvious examples of such inefficient graphic,
>>which could be stored as a bitmap image.
> 
> 
> You mis-understand the purpose of the demo.  It is not trying to
> show an efficient way of plotting a rectangular image. It is simply
> demonstrating different color schemes possible by changing the
> palette definition.

Mojca, could you explain a bit more about what you meant.  I think we're trying to guess here a bit too much.

> 
>>At which places in the source should  (colud?) this be improved?
> 
> 
> If I understand correctly what you want, it was already implemented
> by Dan Sebald and others as plot styles "with image" and
> "with rgbimage".  But there is probably room for improving the
> code. One recent request (# 1480115) is to add support for an
> alpha channel.

Oh yeah, I forgot all about that.  (Whoever oversees that may assign that request to me, user "sebald".  I can't seem to do that without having created it.)  Am I right that the alpha would be a depth of four, one of the channels being 0/nonzero?  So maybe the syntax should be something like "with rgbaimage", or "with argbimage"?  Or is there some trick where one of the rgb colors becomes a opaque?

Dan

Re: smooth shading & terminal specialities

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

On Monday 08 May 2006 12:26 pm, Daniel J Sebald wrote:
> 
> My opinion is that this "gppsfile" variable should be eliminated.  
> From what I understand, the purpose of this is a flag in the main 
> code that indicates a PostScript comment can be added to the file 
> for later use.  

Your understanding is wrong.  No post-processing is involved.
The gppsfile is the PostScript output stream itself.
If the current terminal driver is "post", this is only output
stream (gppsfile == gpoutfile).  But for epslatex, pslatex, etc,
it is a secondary output stream parallel to the TeX output.

> PostScript is the most feature rich language I'm aware of.  
> (The Adobe language reference should be consulted first.) 

It's beginning to show its age.  Poor support for UTF8 for
one thing, but more to the point in the present discussion --
it doesn't support gradient fill.  That puts it behind 
several of the other output drivers.

> I guess I've never completely understood the convention of 
> "default routine" in the terminal driver concept.  
> Someone will have to explain this.

Easy.  Some output devices have special requirements, or
special capabilities. So the corresponding terminal driver
needs a private routine to implement these requirements
or features.  But it would be silly to write a private
routine for every single driver, because most of them can
share a generic default routine.

For instance, some of the TeX variants support a "draw arrow"
command as a native operation, and can produce snazzier arrows
than gnuplot's generic do_arrow() routine.


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

Re: smooth shading & terminal specialities

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

On Sunday 07 May 2006 07:53 pm, Mojca Miklavec wrote:
> I need my own version of drawing "smooth_box" (the terminal supports
> vector graphic format, so drawing a whole lot of rectangles of single
> color is extremely inefficient). 

I don't quite understand what you mean by that. 
How does a "vector graphic format" avoid having to draw filled
rectangles?  Do you mean there is native support for gradient fill?
In any case...

> Should I say 
> 
>     if (gppsfile)
> 	draw_inside_color_smooth_box_postscript(out);
>     else if(term->name == "my terminal")
>         MY_TERMINAL_draw_inside_color_smooth_box();
>     else
>         ...

Yes. 
The idea is that there is a generic routine draw_inside_color_smooth_box_bitmap
that can be used by any terminal.  However, some terminals may be able
to do the job more efficiently using some private routine. The only
driver to implement this so far is the postscript driver.  The test
"if (gppsfile)..." is a short way of testing for the driver; it might
be more proper to say
  if (!strcmp(term->name,"post") || !strcmp(term->name,"epslatex")
     || !strcmp(term->name,"pslatex") ....

> or is there a better (more consistent) solution? I hate touching the
> code outside my own (new) terminal, but in this case I probably can't
> avoid it.

There was some small amount of discussion on the list about creating
a new terminal entry point that would draw an area (triangle? rectangle?)
with a gradient fill.  The above calls would then become

   if (term->gradient_fill_box)
       term->gradient_fill_box(  some set of parameters  );

> draw_inside_color_smooth_box_postscript could be rewritten as well to
> produce smooth shading instead of 1000 single-color boxes (smooth
> liear shading with a stitching function). I know exactly what has to
> be done, but I would need some thinking to implement it properly. If
> someone knows PostScript language better than I do, I'm ready to
> describe the procedure more precisely. (A better and more efficient
> code can be produced using a new approach.)

That would be nice, particularly because the current PostScript
implementation triggers anti-aliasing artifacts on some versions
of ghostscript.  But are you sure there is a better way in
PostScript? I know this could be done in SVG, but I am unaware
of any way to do gradients in PostScript other than lots of little
single-color boxes.

> Many plot on http://gnuplot.sourceforge.net/demo_4.1/pm3d.html could
> be drawn more efficiently if I knew in advance that I'm able to draw
> an NxM image as opposed to drawing NxM rectangles. 

If you know that, you maybe should be using "plot with image" instead.

> Even the 4th and the 5th example could be simplified considerably,
> but the examples 6-12 are obvious examples of such inefficient graphic,
> which could be stored as a bitmap image.

You mis-understand the purpose of the demo.  It is not trying to
show an efficient way of plotting a rectangular image. It is simply
demonstrating different color schemes possible by changing the
palette definition.

> At which places in the source should  (colud?) this be improved?

If I understand correctly what you want, it was already implemented
by Dan Sebald and others as plot styles "with image" and
"with rgbimage".  But there is probably room for improving the
code. One recent request (# 1480115) is to add support for an
alpha channel.


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

Re: smooth shading & terminal specialities

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

>   if (gppsfile)
> 	draw_inside_color_smooth_box_postscript(out);
>   else
> 	draw_inside_color_smooth_box_bitmap(out);
>
> I need my own version of drawing "smooth_box" (the terminal supports
> vector graphic format, so drawing a whole lot of rectangles of single
> color is extremely inefficient). Should I say

Use "plot .. with image" instead.

> draw_inside_color_smooth_box_postscript could be rewritten as well to
> produce smooth shading instead of 1000 single-color boxes (smooth
> liear shading with a stitching function).

this routine must respect "set palette maxcolors"; your proposal means 
adding a code just for the case maxcolors == 0.

> Many plot on http://gnuplot.sourceforge.net/demo_4.1/pm3d.html could
> be drawn more efficiently if I knew in advance that I'm able to draw
> an NxM image

I think you request that "with image" should support also functions and not 
only datafile as it currently does, e.g.
 	(s)plot x*x-y*y with image


Notice that "with pm3d" is optimized for non-matricial data; e.g., the 
following masked function would have troubles "with image":
 	set pm3d map
 	f(x,y)=(x*x+y*y>5) ? x*y : 1/0
 	splot f(x,y)

---
PM

Problem with compiling on windows

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

Hello,

I'm glad that CVS is working again. But some days ago I noticed that
I'm not able to compile the code any more. I did a checkout into a
fresh folder, but the problem persists. I'm compiling on Windows, MS
Visual Studio 2005 with makefile.nt. Some time ago the files compiled
OK.

Any ideas or suggestions?

Thanks,
    Mojca


LIBCMT.lib(invarg.obj) : error LNK2005: __invoke_watson already defined in =
MSVCR

... [lots of lines of the same message] ...

LIBCMT.lib(crt0init.obj) : error LNK2005: ___xc_a already defined in MSVCRT=
.lib(
cinitexe.obj)
LIBCMT.lib(crt0init.obj) : error LNK2005: ___xc_z already defined in MSVCRT=
.lib(
cinitexe.obj)
LIBCMT.lib(crt0.obj) : error LNK2005: _mainCRTStartup already defined in MS=
VCRT.
lib(crtexe.obj)
LIBCMT.lib(errmode.obj) : error LNK2005: ___set_app_type already defined in=
 MSVC
RT.lib(MSVCR80.dll)
LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other lib=
s; us
e /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other lib=
s; us
e /NODEFAULTLIB:library
pgnuplot.exe : fatal error LNK1169: one or more multiply defined symbols fo=
und
NMAKE : fatal error U1077: 'C:\Programi\MSVC\VC\BIN\cl.EXE' : return code '=
0x2'
Stop.

[ 1474309 ] Bind <space> to builtin_raise in mouse.c

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

Here's a modified version of Timoth=E9e latest patch
which fixes the OS/2 part.
Moreover it introduces a new define
WANT_X11_RAISE to be able to deactivate
the X11 dependant stuff. This will be defined
when X11 is defined, but is normally undefined
on OS/2 to avoid the linkage requirement againt
libX11.
I also removed some "%lu" formats left in a
printf statement when removin gnuplotXID.

I'll post it on the list since I cannot
attach files on sourceforge.

Bastian

Re: smooth shading & terminal specialities

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

Petr Mikulik wrote:
>>> Thus you mean to automagically change "with pm3d" into "with image" 
>>> without knowing it to user? That's not a good idea I think.
>>
>>
>> Well, yes and no.  The point is, there are several images where the 
>> underlying image routine can be used for the plots that pm3d creates 
>> but the image routine is a much more compact manner of representing 
>> that plot.  (For
>> HOWEVER, there is still a slight difference in behavior that can't be 
>> changed.  It has to do with that "original grid points" demo you 
>> created. The one that shows a 4x4 set of points results in a 3x3 set 
>> of colored rectangles.  I.e., the images on the pm3d.html page have to 
>> look exactly as
> 
> 
> The pm3d drawing routine would call image drawing routine with a 
> calculated matrix if the surface has_grid_topology. This would probably 
> be easy to implement.

Well, in prinicple easy.  Let me summarize as part of brainstorming.  We have a lower level terminal call:

		    (*term->image) (M, N, image, corners, pixel_planes);

and what need be done is put the data in the array image *in the correct orientation*.  If we were to use this, we'd probably have to put some work into finding the correct orientation, effectively repeating some work in the function below.  It isn't the simplest of routines when you think of all possible orientations.

And we also have a higher level routine:

plot_image_or_update_axes(void *plot, t_imagecolor pixel_planes, TBOOLEAN project_points, TBOOLEAN update_axes)

which looks at the grid point positions in the plot data and finds the correct orientation, bounding box, etc.  The plot pointer "plot" can be either surface points or curve points.  If somehow you collapse your K by L data down into a K-1 by L-1 data via "combining" (e.g., average, pick one of the four) corner locations and "combining" element values, that would avoid a lot of work.

Which do you think would be preferred?

Dan

Re: smooth shading & terminal specialities

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

>> Thus you mean to automagically change "with pm3d" into "with image" without 
>> knowing it to user? That's not a good idea I think.
>
> Well, yes and no.  The point is, there are several images where the 
> underlying image routine can be used for the plots that pm3d creates but the 
> image routine is a much more compact manner of representing that plot.  (For 
>
> HOWEVER, there is still a slight difference in behavior that can't be 
> changed.  It has to do with that "original grid points" demo you created. 
> The one that shows a 4x4 set of points results in a 3x3 set of colored 
> rectangles.  I.e., the images on the pm3d.html page have to look exactly as

The pm3d drawing routine would call image drawing routine with a calculated 
matrix if the surface has_grid_topology. This would probably be easy to 
implement.

---
PM

Re: smooth shading & terminal specialities

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

Ethan Merritt wrote:

> 
>>, i.e., 
>>    /* for pm3dCompress.awk */
>>    if (gppsfile)
>>	fputs("%pm3d_map_begin\n", gppsfile);
> 
> 
> Yeah, but that is just an added nicety.

:-)

>  The gppsfile
> mechanism is necessary in any case.
> 
> Getting back to the case at hand, the reason post.trm has a
> private routine for this is that we encode the color palette
> mapping equations into PostScript and include it in the output file.
> So the requisite colors can be generated at print time, taking
> into consideration the capabilities of the printer, without the
> core routines having to know anything about the eventual 
> printer properties.  

I see that now.

Dan

Re: smooth shading & terminal specialities

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

On Monday 08 May 2006 01:19 pm, you wrote:
> Ethan Merritt wrote:
> > The gppsfile is the PostScript output stream itself.
> > If the current terminal driver is "post", this is only output
> > stream (gppsfile == gpoutfile).  But for epslatex, pslatex, etc,
> > it is a secondary output stream parallel to the TeX output.
> 
> Well, that's true.  But ultimately, I think the purpose here is more one of being a flag

No. It *must* have a separate output file descriptor, because if you
were to send it to gpoutfile it would get intermingled with the TeX
output stream.

> , i.e., 
>     /* for pm3dCompress.awk */
>     if (gppsfile)
> 	fputs("%pm3d_map_begin\n", gppsfile);

Yeah, but that is just an added nicety.  The gppsfile
mechanism is necessary in any case.

Getting back to the case at hand, the reason post.trm has a
private routine for this is that we encode the color palette
mapping equations into PostScript and include it in the output file.
So the requisite colors can be generated at print time, taking
into consideration the capabilities of the printer, without the
core routines having to know anything about the eventual 
printer properties.  

> > Easy.  Some output devices have special requirements, or
> > special capabilities. So the corresponding terminal driver
> > needs a private routine to implement these requirements
> > or features.  But it would be silly to write a private
> > routine for every single driver, because most of them can
> > share a generic default routine.
> > 
> > For instance, some of the TeX variants support a "draw arrow"
> > command as a native operation, and can produce snazzier arrows
> > than gnuplot's generic do_arrow() routine.
> 
> Let's see if I can fit the image stuff into this context.

I'm not sure it makes any sense to have a generic fallback for
the image code.  You *could*  write a generic routine that draws
each pixel as a single dot, turning an HP2648 pen-plotter into
a latter day pointiliste successor to Seurat.  But I don't think
we need to go there :-)



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

Re: smooth shading & terminal specialities

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

Petr Mikulik wrote:
>> My opinion is that this "gppsfile" variable should be eliminated.  
>> From what I understand, the purpose of this is a flag in the main code 
>> that indicates a PostScript comment can be added to the file for later 
>> use.  This is for the purpose of later running an awk script to look 
>> for repeated postscript strings and redefine them as shorter strings 
>> for purposes of compression.
> 
> 
> No; the term_api.h says:
> 
> /* Output file where the PostScript output goes to.
>    In particular:
>     gppsfile == gpoutfile
>         for 'set term': postscript, pstex
>     gppsfile == PSLATEX_auxfile
>         for 'set term': pslatex
>     gppsfile == 0
>         for all other terminals
>    It is non-zero for for the family of postscript terminals, thus making
>    this a unique check for postscript output (pm3d has some code optimized
>    for PS, for instance).
> */

Oh, yeah.  The postscript/latex split.  Forgot about that.


>> That will pretty much accomplish this "substitute long string with 
>> short string" approach.
> 
> 
> This is a completely different topic (code produced by PS_filled_polygon).

Yes, I think so.  That is the code I'm wondering about.

> 
>> * somewhere in the pm3d code would be this test to check if the pm3d 
>> drawing constitutes a flat 2D surface.
>>
>> * if flat surface, call the "image" terminal routine having a new 
>> projection angle input
>>
>> * For those terminals not supporting projected images, they can 
>> callback the routine that draws projected images with individual 
>> rhombus-es (or rhombi?)
> 
> 
> Thus you mean to automagically change "with pm3d" into "with image" 
> without knowing it to user? That's not a good idea I think.

Well, yes and no.  The point is, there are several images where the underlying image routine can be used for the plots that pm3d creates but the image routine is a much more compact manner of representing that plot.  (For example, the 2D map mode with rectangular grid is the perfect example.)  From the standpoint of the user, what is the difference in how that is represented?  (I'm thinking if there is a difference, myself.)

HOWEVER, there is still a slight difference in behavior that can't be changed.  It has to do with that "original grid points" demo you created.  The one that shows a 4x4 set of points results in a 3x3 set of colored rectangles.  I.e., the images on the pm3d.html page have to look exactly as they are regardless of whether the underlying plot is an image or rhombuses.  The advantage of the image is that in most display scenarios, I think, there is no introduced aliasing effect where a line shows up.  (Recall that "bug" from a few years back?)

Dan

Re: smooth shading & terminal specialities

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

Ethan Merritt wrote:
> On Monday 08 May 2006 12:26 pm, Daniel J Sebald wrote:
> 
>>My opinion is that this "gppsfile" variable should be eliminated.  
>>From what I understand, the purpose of this is a flag in the main 
>>code that indicates a PostScript comment can be added to the file 
>>for later use.  
> 
> 
> Your understanding is wrong.  No post-processing is involved.
> The gppsfile is the PostScript output stream itself.
> If the current terminal driver is "post", this is only output
> stream (gppsfile == gpoutfile).  But for epslatex, pslatex, etc,
> it is a secondary output stream parallel to the TeX output.

Well, that's true.  But ultimately, I think the purpose here is more one of being a flag, i.e.,

    /* for pm3dCompress.awk */
    if (gppsfile)
	fputs("%pm3d_map_begin\n", gppsfile);

[snip]

    /* for pm3dCompress.awk */
    if (gppsfile)
	fputs("%pm3d_map_end\n", gppsfile);

> 
> 
>>PostScript is the most feature rich language I'm aware of.  
>>(The Adobe language reference should be consulted first.) 
> 
> 
> It's beginning to show its age.  Poor support for UTF8 for
> one thing, but more to the point in the present discussion --
> it doesn't support gradient fill.  That puts it behind 
> several of the other output drivers.

OK.  How about PDF, does that have more features like gradient fill than does P.S.?

...  Forgot to mention desires for compression in images that have come up.  (That really has no significance to recent discussion about terminal commands.)  And also the colorbox can be done with an image.

> 
> 
>>I guess I've never completely understood the convention of 
>>"default routine" in the terminal driver concept.  
>>Someone will have to explain this.
> 
> 
> Easy.  Some output devices have special requirements, or
> special capabilities. So the corresponding terminal driver
> needs a private routine to implement these requirements
> or features.  But it would be silly to write a private
> routine for every single driver, because most of them can
> share a generic default routine.
> 
> For instance, some of the TeX variants support a "draw arrow"
> command as a native operation, and can produce snazzier arrows
> than gnuplot's generic do_arrow() routine.

Let's see if I can fit the image stuff into this context.  The terminal specific driver is "image_for_term" in which we add some angle.  (We're still in "experimental stage", right?):

->image_for_term(<current vars>, angle_struct)

where <current vars> is the current list of variables.  Then I supply the routine in cases where a driver can't use projection:

generic_image_with_rhombus()
{

  /* If projection implies pixels will be rectangular then can use the terminal driver's image drawing routine, but how to now access this?

  if (<rectangular projection tests>)
    term->rectangular_image_for_term()  /* Some other terminal routine? */
  else
    <this code already exists in plot2d.c and would simply need repackaging in function form>

}

Then the terminal driver could put ->generic_image_with_rhombus() in place of ->image_for_term()?

My quandary is that the slot in the terminal driver list gets used by the generic function, but there is still some terminal specific code to come after that.  Then what?  The result would be two slightly different terminal image routines?

The alternative would be, as you say, each terminal driver has it's own test like "generic_image_with_rhombus()" does above.  It's a repetitive way of addressing that, but not too bad.  In fact, that <rectangular projection tests> code could be gathered as a simply routine and reused to make things more compact.

I have no strong opinion on how it should be; just not certain on how to go about this.

Dan

Re: smooth shading & terminal specialities

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

> My opinion is that this "gppsfile" variable should be eliminated.  From what 
> I understand, the purpose of this is a flag in the main code that indicates a 
> PostScript comment can be added to the file for later use.  This is for the 
> purpose of later running an awk script to look for repeated postscript 
> strings and redefine them as shorter strings for purposes of compression.

No; the term_api.h says:

/* Output file where the PostScript output goes to.
    In particular:
 	gppsfile == gpoutfile
 		for 'set term': postscript, pstex
 	gppsfile == PSLATEX_auxfile
 		for 'set term': pslatex
 	gppsfile == 0
 		for all other terminals
    It is non-zero for for the family of postscript terminals, thus making
    this a unique check for postscript output (pm3d has some code optimized
    for PS, for instance).
*/


> The goal is laudable, but oh how convoluted this is.  Not clean code.  Why 
> not just write the PostScript version of these "draw one" routines with short 
> definitions in the first place?  Plus, why would this have to be done at the 
> core code level?  Also, why couldn't someone just gzip the file in question 
> after the fact?

The code is clean and optimized for the postscript language. Current 
colorbox drawing takes 7 lines for any number of maxcolors, while otherwise 
it would be `maxcolors`lines.

> That will pretty much accomplish this "substitute long string with short 
> string" approach.

This is a completely different topic (code produced by PS_filled_polygon).

> * somewhere in the pm3d code would be this test to check if the pm3d drawing 
> constitutes a flat 2D surface.
>
> * if flat surface, call the "image" terminal routine having a new projection 
> angle input
>
> * For those terminals not supporting projected images, they can callback the 
> routine that draws projected images with individual rhombus-es (or rhombi?)

Thus you mean to automagically change "with pm3d" into "with image" without 
knowing it to user? That's not a good idea I think.

---
PM

Re: smooth shading & terminal specialities

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

Mojca Miklavec wrote:
> Hello,
> 
> 
> In color.c I noticed the following code:
> 
>    if (gppsfile)
>     draw_inside_color_smooth_box_postscript(out);
>    else
>     draw_inside_color_smooth_box_bitmap(out);
> 
> I need my own version of drawing "smooth_box" (the terminal supports
> vector graphic format, so drawing a whole lot of rectangles of single
> color is extremely inefficient). Should I say
> 
>    if (gppsfile)
>     draw_inside_color_smooth_box_postscript(out);
>    else if(term->name == "my terminal")
>        MY_TERMINAL_draw_inside_color_smooth_box();
>    else
>        ...

No.

> or is there a better (more consistent) solution?

Yes.  Your intuition is probably correct on this one.

My opinion is that this "gppsfile" variable should be eliminated.  From what I understand, the purpose of this is a flag in the main code that indicates a PostScript comment can be added to the file for later use.  This is for the purpose of later running an awk script to look for repeated postscript strings and redefine them as shorter strings for purposes of compression.

The goal is laudable, but oh how convoluted this is.  Not clean code.  Why not just write the PostScript version of these "draw one" routines with short definitions in the first place?  Plus, why would this have to be done at the core code level?  Also, why couldn't someone just gzip the file in question after the fact?  That will pretty much accomplish this "substitute long string with short string" approach.  (Files with greater repetition have better compression in general.)

It's OK, in my mind, to write routines in the C files that the "trm" files can "callback", and there certainly is some planning to do here.  For example, in the case of images, PostScript has a very nice feature in which images can have an angle in 3D space associated with them.  I didn't use that feature (not yet anyway).  Instead I wrote an image projection routine that constructs an image from little rhombus-es (rhombi?) for each pixel.  Now, that rhombus method should be the routine that the terminal driver falls back on if there is no whole image projection feature as in PostScript (i.e., the terminal driver can call a routine that happens to be in the src directory, no big deal).  I didn't know any language or library would have such a feature so didn't account for it originally, so a lack of foresight on my part.  That can be fixed easily, if developers decide to do so.

> draw_inside_color_smooth_box_postscript could be rewritten as well to
> produce smooth shading instead of 1000 single-color boxes (smooth
> liear shading with a stitching function). I know exactly what has to
> be done, but I would need some thinking to implement it properly. If
> someone knows PostScript language better than I do, I'm ready to
> describe the procedure more precisely. (A better and more efficient
> code can be produced using a new approach.)

Think of how best to do this before embarking on it.  PostScript is the most feature rich language I'm aware of.  (The Adobe language reference should be consulted first.)

Are you saying you have a method that does shading in general?  Or just for PostScript?

> Many plot on http://gnuplot.sourceforge.net/demo_4.1/pm3d.html could
> be drawn more efficiently if I knew in advance that I'm able to draw
> an NxM image as opposed to drawing NxM rectangles. Even the 4th and
> the 5th example could be simplified considerably, but the examples
> 6-12 are obvious examples of such inefficient graphic, which could be
> stored as a bitmap image. At which places in the source should
> (colud?) this be improved?

I agree.  Regarding the PostScript image projection, in fact, even the images with non-square parallelograms can be done efficiently with image data, so long as each element has four sides of the same size.  We just removed from the image routine a test to verify that every element is of the same size.  Such code could be used to check if the pm3d image would fit the bill.  (Yes, it will slow the code slightly, but as soon as it fails then things speed up again because the code would stop checking.)

That would mean that

* somewhere in the pm3d code would be this test to check if the pm3d drawing constitutes a flat 2D surface.

* if flat surface, call the "image" terminal routine having a new projection angle input

* For those terminals not supporting projected images, they can callback the routine that draws projected images with individual rhombus-es (or rhombi?)

I guess I've never completely understood the convention of "default routine" in the terminal driver concept.  Someone will have to explain this.  (I can think of two essentially the same, but slightly different approaches.)

Dan

smooth shading & terminal specialities

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

Hello,


In color.c I noticed the following code:

    if (gppsfile)
=09draw_inside_color_smooth_box_postscript(out);
    else
=09draw_inside_color_smooth_box_bitmap(out);

I need my own version of drawing "smooth_box" (the terminal supports
vector graphic format, so drawing a whole lot of rectangles of single
color is extremely inefficient). Should I say

    if (gppsfile)
=09draw_inside_color_smooth_box_postscript(out);
    else if(term->name =3D=3D "my terminal")
        MY_TERMINAL_draw_inside_color_smooth_box();
    else
        ...

or is there a better (more consistent) solution? I hate touching the
code outside my own (new) terminal, but in this case I probably can't
avoid it.

draw_inside_color_smooth_box_postscript could be rewritten as well to
produce smooth shading instead of 1000 single-color boxes (smooth
liear shading with a stitching function). I know exactly what has to
be done, but I would need some thinking to implement it properly. If
someone knows PostScript language better than I do, I'm ready to
describe the procedure more precisely. (A better and more efficient
code can be produced using a new approach.)


Many plot on http://gnuplot.sourceforge.net/demo_4.1/pm3d.html could
be drawn more efficiently if I knew in advance that I'm able to draw
an NxM image as opposed to drawing NxM rectangles. Even the 4th and
the 5th example could be simplified considerably, but the examples
6-12 are obvious examples of such inefficient graphic, which could be
stored as a bitmap image. At which places in the source should
(colud?) this be improved?

Thanks a lot,
    Mojca

Re: wxWidgets terminal (another bug report)

[<tim...@en...>]

>> Configuration fails if wxWidgets is disabled:
>>
>> lascaux [27] ./configure --disable-wxwidgets
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking whether build environment is sane... yes
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> [...snip...]
>> checking for pdflib.h... yes
>> checking for PDF_begin_pattern in -lpdf... yes
>> checking for PDF_setdashpattern in -lpdf... yes
>> checking for PDF_begin_document in -lpdf... yes
>> checking for multi-byte support in x11... checking for XmbDrawString i=
n
>> -lX11... yes
>> configure: error: conditional "am__fastdepCXX" was never defined.
>> Usually this means the macro was only invoked conditionally.
>> lascaux [28]
>
> The error is pretty explicit. The problem is that I put the following
> checks in 'if' block :
>
> AC_PROG_CXX
> AC_PROG_CXXCPP
>
> I did that because C++ is not needed if the wxWidgets terminal is not
> compiled. But I have not found any information about such a case on the
> web.
> Obviously this doesn't work, so I will have to put them
> unconditionnally... at the risk of breaking a platform where there's no
> C++ compiler. Is it acceptable ?

I have been in big trouble !

The autotools are definitely not designed to make a language optional.

As reported above, the checks must be done unconditionally or Autoconf
won't work.

If I put the two checks unconditionally, and execute the resulting
'configure' on a system without any C++ compiler, the script itself will
succeed, and I can even disable the wxWidgets terminal, but it will fail
at compile time, because the autotools still think that the project
contains some C++ files, and tries to link with g++ by default, even when
it can't find it !

So this would oblige to have a C++ compiler to build gnuplot, even withou=
t
the wxWidgets terminal. I respond to my question above : this is obviousl=
y
not acceptable.

I have finally found a workaround : if the C++ compiler is really absent
(that can be tested easily), set CXX to $CC, so that automake will finall=
y
use $CC to do the link. I have tested it, and it seems to work as
expected.

(but I am not really happy with that, and it made me wonder once again if
I should throw wxWidgets in favor of gtk+, which is written in C...)

Timoth=E9e