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

Re: test palette

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

On Tuesday 26 July 2005 12:53 pm, Juergen Wieferink wrote:
> 
> gnuplot> plot 'file' notitle with lines
> 
> 1) Two gnuplot syntax rules collide at this point: On the one hand
>    gnuplot is greedy: If "with" is a string variable it is to be
>    ignored because it is the title for "title with".  On the other
>    hand it is a key word and as such not to be interpreted as
>    variable name.

Hmm. I wish you had brought that up a few months ago, when the
syntax    ... notitle "title"
was added.  This is indeed a problem.  I am rather inclined to say
we should back out the option altogether since it creates ambiguous
syntax.

> I'd prefer the second case, but how to cope here for "title"?  I
> *really* think we need a stricter syntax policy how to handle these
> cases.

I wonder how far away we are from being able to have that policy
be simply "no ambigous syntax is permitted".   Several disambiguating
keywords have been added already  (e.g.  "font", "offset", "at")
for exactly this reason.   Do you know of any other cases that are
violators, like  ... notitle "title"?


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Volunteer to add AC_CHECK_LIB() for iconv routines?

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

Copyied from the newsgroup, in the hope that someone will
volunteer to add the appropriate checks to ./configure.in

I note with sympathy that the same article cited below says

 "Although they have many problems, and are hated by most of
  their users, Autotools are currently the best way to handle
  a multi-platform, adaptable building system."

Ethan Merritt <merritt@u.washington.edu> wrote:
>lutz <lu...@nu...> wrote:
>>
>>/usr/local/lib/libgd.so: undefined reference to `libiconv_open'
>>/usr/local/lib/libgd.so: undefined reference to `libiconv_close'
>>/usr/local/lib/libgd.so: undefined reference to `libiconv'
>
>On my machine these functions do not come
>from a separate libiconv* library; they are part of the locale
>support provided directly by glibc.

It turns out that this is a "well-known" difference between linux and
BSD-derived systems, something I learned only now via a NewsForge
article on portable configurations:
    http://programming.newsforge.com/article.pl?sid=05/07/19/1713230

It suggests adding an AC_CHECK_LIB() macro to the configuration script 
that checks for the iconv routines.  Maybe we should do that.



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: test palette

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

On Tuesday 26 July 2005 09:49 am, Ethan Merritt wrote:
> 
> gnuplot>  set title offset 1,1
>           undefined variable: offset
>  
> What has happened is that whenever the keyword "title"
> is seen, the parser calls try_to_get_string(), which
> then chokes if the next token on the line is a keyword
> rather than a string or an expression.

I have just fixed the class of error exemplified above by
adding an explicit check for valid keywords in set_xyzlabel().
This is similar to existing code in set_label().  

However, I think it would be cleaner if the expression evaluation
code triggered by try_to_get_string() simply returned an undefined
variable rather than bailing to the command line with an error message.
That would be a more general solution to the problem, and would
remove the need for long lists of explicit tests for various keywords
in these and other places.

The first place to change is f_push(), if anyone wants to look
into this.  


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: test palette

[Juergen W. <wie...@fr...>]

Ethan Merrit wrote:
> Simpler example of breakage:
>
> gnuplot>  set title offset 1,1
>           undefined variable: offset
>
>
> What has happened is that whenever the keyword "title"
> is seen, the parser calls try_to_get_string(), which
> then chokes if the next token on the line is a keyword
> rather than a string or an expression.
>
> I don't know when or how this broke - possibly at the
> time of Harald Harders' addition of the generalized
> "offset" keyword for all string positions.
>
> I'm not sure yet where to fix it.

I think try_to_get_string() should check the expression before
evaluating it (using isstring() and friends :-)

I'm quite surprised it doesn't do so far.  This bug must have been
there for quite a long time...

I'm short of time at the moment, so I haven't really checked this
suggestion.


Juergen

Re: test palette

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

On Tuesday 26 July 2005 08:41 am, Juergen Wieferink wrote:
> Hi,
> 
> I get a strange error message in recent CVS:
> 
> ...
> 
> Terminal type set to 'x11'
> gnuplot> test palette
> gnuplot> test palette
>          line 835: undefined variable: character


Simpler example of breakage:

gnuplot>  set title offset 1,1
          undefined variable: offset


What has happened is that whenever the keyword "title"
is seen, the parser calls try_to_get_string(), which
then chokes if the next token on the line is a keyword
rather than a string or an expression.

I don't know when or how this broke - possibly at the
time of Harald Harders' addition of the generalized
"offset" keyword for all string positions.

I'm not sure yet where to fix it.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: test palette

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

> I get a strange error message in recent CVS:
>
> ...
>
> Terminal type set to 'x11'
> gnuplot> test palette
> gnuplot> test palette
>         line 835: undefined variable: character

It fails in command.c:test_palette_subcommand(). Firstly it does 
save_set(f), then load_file(f, NULL, FALSE);

The error message is after/during the 2nd load.

I had a look what is inside of these temporary files. "diff" says that the 
1st file contains
 	set style histogram clustered gap 2 title 0, 0, 0

while the 2nd
 	set style histogram clustered gap 2 title character 0, 0, 0

This looks like a bug in the "set" or "save" of histogram.

---
PM

test palette

[Juergen W. <wie...@fr...>]

Hi,

I get a strange error message in recent CVS:

...

Terminal type set to 'x11'
gnuplot> test palette
gnuplot> test palette
         line 835: undefined variable: character

gnuplot>


Juergen

Re: Automatic placement of the key

[Hans-Bernhard B. <br...@ph...>]

Ga=EBl Varoquaux wrote:
>     I just saw a figure in an article that had been made with gnuplot
> and the author did not bother move the key, that fell right in the curv=
e
> (try "plot [0:1] x" to see what I mean).=20

The pilot error happened even earlier.  It's almost never a good idea to =

have a key as part of the plot itself if the plot is to be used as a=20
figure in a larger document.  The description of what's in the plot=20
should go into the figure caption.

>     It might be interesting to have by default an automatic choice of
> where the key goes : top right by default, then an choice of top left,
> top middle, bottom right, bottom left, with a small algorithm that woul=
d
> choose the least encumbered part of the graph.

The problem is that this algorithm would have to be anything but small=20
to be usable.  In a nutshell, every object handed over from the core to=20
the terminal API for display would have to be analyzed and its effect=20
recorded.  To do it meaningfully, we'ld need to know the size of the key =

  area before we output anything to the terminal, which would entail a=20
re-design of the core drawing routines.

Re: Automatic placement of the key

[V. <gae...@no...>]

On Sat, Jul 23, 2005 at 11:25:40PM -0500, Daniel J Sebald wrote:
> Certainly possible Gael (but little time).=20

    Sure. I am aware of this as I am myself struggling to get my project
moving forward.

> set key auto

> ?  Or simply from now one have "default" mean ostensibly auto placement=
?

    Both, I think : "set key auto", as a default value.

> But... I suggest not emarking on such a feature until key layout for 2D=
 and=20
> 3D is made more uniform.

    I am making some progress on the povray terminal. You can have a
look at http://www.eleves.ens.fr/home/varoquau/gnuplot where you will
find the current povray.trm, and the demo file render through the
povray terminal. I use this to debug the terminal. I am finishing it :
debugging it, adjusting its overall structure, improving the quality of
the povray file generated. Most of the common features of a gnuplot
terminal are already implemented.

    As for the key, the title, the colorbox, and other 2D elements that
have not to be placed on the plot I think it might be interesting to
deal with them in the camera's space, rather than in the plot's space.
This is how I position the lights and this is how I want to orient the
text (though this is still to do). I have defined a "x,y,z" space, which
is the plot's space, and an "a,b,c" space, which is the camera's space.
Maybe when we build the 3D terminal API it might be interesting to have
different calls to position elements in one frame or the other.

 Indeed "set key auto" in 3D implies that gnuplot will have to project
the points of the plots to position the key, which, with a 3D compatible
driver means redoing twice the same work. Yes I agree that we have to
wait for the 2D/3D code restructuring before implementing a "set key
auto", however I think it is something that we must keep in mind.

--
    Ga=EBl

Re: Automatic placement of the key

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

Ga=EBl Varoquaux wrote:
>     I just saw a figure in an article that had been made with gnuplot
> and the author did not bother move the key, that fell right in the curv=
e
> (try "plot [0:1] x" to see what I mean).=20
>=20
>     It might be interesting to have by default an automatic choice of
> where the key goes : top right by default, then an choice of top left,
> top middle, bottom right, bottom left, with a small algorithm that woul=
d
> choose the least encumbered part of the graph.

Certainly possible Gael (but little time).  An "optimization" algorithm s=
eems rather difficult, i.e., one that identifies the least encumbered par=
t of the graph.  It is difficult to define that in the first place.

However, one could take the approach that

1) Compute the size of the key before rendering the plot.

2) Compute the position where that key would land for all nine possible i=
nterior.

3) Keep a C array of counts of how many times a point lands in each of th=
e nine possible key areas.

4) Choose the smallest count to be the key location.  If there is a tie, =
impose the priority top right, top left, etc.

It would mean some extra overhead (quite a bit actually) required at the =
low level of laying out points.  And I assume you would propose something=
 like:

set key auto

?  Or simply from now one have "default" mean ostensibly auto placement?

But... I suggest not emarking on such a feature until key layout for 2D a=
nd 3D is made more uniform.

Dan

Automatic placement of the key

[V. <gae...@no...>]

    I just saw a figure in an article that had been made with gnuplot
and the author did not bother move the key, that fell right in the curve
(try "plot [0:1] x" to see what I mean).=20

    It might be interesting to have by default an automatic choice of
where the key goes : top right by default, then an choice of top left,
top middle, bottom right, bottom left, with a small algorithm that would
choose the least encumbered part of the graph.

--
    Ga=EBl

Re: pm3d antialiasing (was: /f + /h, color box)

[Juergen W. <wie...@fr...>]

Petr Mikulik wrote:
> >> => the output is clearly full of lines (png16m) or dots (png256). The
> >> pdf file does not raster at all under gs 8.5, and with empty area under
> >> gs 7.07.
> >
> > I really struggled with this anti-aliasing problem until "with
> > image" was introduced.
>
> Wow, that's a pity you haven't struggled to figure out & submit this bug
> over that long time since "with image".

Well, I didn't quite exactly submit a bug report but I actually have
reported the problem:

    news:cd5ia0$rch$1...@sa...


Juergen

Re: spurious lines in gs with antialiasing

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

On Friday 22 July 2005 12:09 am, you wrote:
> > I have
> > gs -v
> >  ESP Ghostscript 7.07.2 (2003-11-19)
>
> I have 7.07.1 and 8.50
>
> > After running your suggested test script through the
> > current cvs version of gnuplot, I do not see the
> > artifacts you describe
> >
> > - viewing in gv works fine
>
> Try to change scaling.

I have done so. No problems.
Same for scaling in Acrobat after conversion to pdf.

> > - converting to png via ImageMagick's "convert" command
> >  works fine. (This calls gs, but I don't know the specific
> >  options it uses).
>
> Try "convert -density 23" (play with the number) and it will appear.

density less than 72 never works well. This has nothing to
do with gnuplot.  If you need to convert to a smaller image,
you should do something like "convert -density 150  -geometry 20%"
so that anti-aliasing is used.

> It depends on the output image resolution.

I believe you.  But that suggests that the undesired white lines
are 1 pixel wide, and as you reduce the resolution that "1 pixel"
becomes proportionally larger.
That does indeed sound like it could the result of fill-with-no-stroke.

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

Re: /f + /h, color box

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

Petr Mikulik wrote:
>>> => the output is clearly full of lines (png16m) or dots (png256). The 
>>> pdf
>>> file does not raster at all under gs 8.5, and with empty area under gs
>>> 7.07.
>>
>>
>> I really struggled with this anti-aliasing problem until "with
>> image" was introduced.
> 
> 
> Wow, that's a pity you haven't struggled to figure out & submit this bug 
> over that long time since "with image".
> 
>> Would it be possible to draw the colorbox using the "image" code?  I 
>> know that this doesn't generally solve the problem, but its effects 
>> would be reduced significantly.
> 
> 
> Then it would require WITH_IMAGE to be compiled in (is it the way 
> "term->filled_gradient" should be implemented?)

Actually, one could still use an image concept for plotting terminals yet not have WITH_IMAGE.  But I agree, it seems odd to have the plot constructed of overlapping, potentially aliasing polygons, but not the colorbox.

Dan

Re: /f + /h, color box

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

>> => the output is clearly full of lines (png16m) or dots (png256). The pdf
>> file does not raster at all under gs 8.5, and with empty area under gs
>> 7.07.
>
> I really struggled with this anti-aliasing problem until "with
> image" was introduced.

Wow, that's a pity you haven't struggled to figure out & submit this bug 
over that long time since "with image".

> Would it be possible to draw the colorbox using the "image" code?  I know 
> that this doesn't generally solve the problem, but its effects would be 
> reduced significantly.

Then it would require WITH_IMAGE to be compiled in (is it the way 
"term->filled_gradient" should be implemented?)

I would like to see first comments from local postscript gurus, then fill in 
ghostscript bug report, and wait to their answer.

---
PM

Re: spurious lines in gs with antialiasing

[Hans-Bernhard B. <br...@ph...>]

Petr Mikulik wrote:
> Please try it with other resolutions.

*Which ones*?  I tried with both resolution at 50 dpi (the one you used 
in your PNG tests), and it didn't make a difference.

> Try also rastering to png.

That almost certainly doesn't make a difference.  The gaps are produced 
in ghostscript's rastering engine, not in the output to some file format.

Re: spurious lines in gs with antialiasing

[Hans-Bernhard B. <br...@ph...>]

Petr Mikulik wrote:
> It does not help. Try to play with /F in the attached example. Also 
> added blue background. And tested with different direction of stacked 
> boxes.

On of this windows box (GSview 4.6, AFPL Ghostscript 8.14, resolution 
300 dpi, "Zoom Resolution" 300 dpi), I get no gaps with the script as 
sent (third version of /F active) --- but they appear if I select the 
first version (no stroke), and they also re-appear if I reduce the 
'setlinewidth' to zero.  So yes, the fix does appear to work.

Re: spurious lines in gs with antialiasing

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

>> Please try it with other resolutions.
>
> *Which ones*?  I tried with both resolution at 50 dpi (the one you used in 
> your PNG tests), and it didn't make a difference.

17, 23, 32, 75, ... whatever random sequence. For some of them, you will see 
it. At least I do.

>> Try also rastering to png.
>
> That almost certainly doesn't make a difference.  The gaps are produced in 
> ghostscript's rastering engine, not in the output to some file format.

Not gnuplot's "set term png", but ghostscript's "-sDEVICE=pngXXXX -rNN".
See the script (command) in a previous mail.

---
PM

Re: spurious lines in gs with antialiasing

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

> Petr Mikulik wrote:
>> It does not help. Try to play with /F in the attached example. Also added 
>> blue background. And tested with different direction of stacked boxes.
>
> On of this windows box (GSview 4.6, AFPL Ghostscript 8.14, resolution 300 
> dpi, "Zoom Resolution" 300 dpi), I get no gaps with the script as sent (third 
> version of /F active) --- but they appear if I select the first version (no 
> stroke), and they also re-appear if I reduce the 'setlinewidth' to zero.  So 
> yes, the fix does appear to work.

Please try it with other resolutions.
Try also rastering to png.

---
PM

Re: /f + /h, color box -- Re: Fix multiplot problem with epslatex terminal

[Juergen W. <wie...@fr...>]

On Thursday, 2005-07-21 14:04, Petr Mikulik wrote:
> => the output is clearly full of lines (png16m) or dots (png256). The pdf
> file does not raster at all under gs 8.5, and with empty area under gs
> 7.07.

I really struggled with this anti-aliasing problem until "with
image" was introduced.  Would it be possible to draw the colorbox
using the "image" code?  I know that this doesn't generally solve
the problem, but its effects would be reduced significantly.


Juergen

Re: spurious lines in gs with antialiasing

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

> I have
> gs -v
>  ESP Ghostscript 7.07.2 (2003-11-19)

I have 7.07.1 and 8.50

> After running your suggested test script through the
> current cvs version of gnuplot, I do not see the
> artifacts you describe
>
> - viewing in gv works fine

Try to change scaling.

> - converting to png via ImageMagick's "convert" command
>  works fine. (This calls gs, but I don't know the specific
>  options it uses).

Try "convert -density 23" (play with the number) and it will appear.

> evidence that the bug is restricted to some very specific
> gs versions.

I don't think so, it depends on the output image resolution.

---
PM

Re: spurious lines in gs with antialiasing

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

Petr:

You mentioned problems with both gs 7.07 and 8.something.

I have
gs -v
  ESP Ghostscript 7.07.2 (2003-11-19)

After running your suggested test script through the
current cvs version of gnuplot, I do not see the
artifacts you describe

- viewing in gv works fine
- converting to pdf via ps2pdf and viewing in acrobet works fine
- converting to png via ImageMagick's "convert" command
  works fine. (This calls gs, but I don't know the specific
  options it uses).

I don't what this means, exactly, but I offer it as possible
evidence that the bug is restricted to some very specific
gs versions.




-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: spurious lines in gs with antialiasing

[Theo H. <th...@ph...>]

Hans-Bernhard Broeker wrote:
> Petr Mikulik wrote:
> 
>> Well, it looks to me that it must be a bug in ghostscript -- some 
>> rounding of positions or whatever. Below is a simplest postscript code 
>> that demonstrates spurious lines in a pm3d-like image:
> 
> 
> I don't fully agree that those lines are "spurious".  Since you only
> fill-ed the paths, but didn't stroke them, there are technically
> gaps of zero pixel width between adjacent tiles.  And just like lines of 
> width zero are not exactly the same thing as no lines at all, gaps of 
> width zero are not the same as no gap at all.  For this to be a 
> meaningful test, the paths could have to be both filled and stroked.

I just tried this. Fill-ing and stroke-ing gives much better results: 
the lines occur less frequently, and with less intensity. It seems to me 
that if filled polygons were stroke-d with a line width just slightly 
over the nominal value, the anti-aliasing problem with Ghostscript could 
be worked around. Unfortunately, I don't know enough Postscript to be 
able to test this.

THeo

Re: spurious lines in gs with antialiasing

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

>> Well, it looks to me that it must be a bug in ghostscript -- some rounding 
>> of positions or whatever. Below is a simplest postscript code that 
>> demonstrates spurious lines in a pm3d-like image:
>
> I don't fully agree that those lines are "spurious".  Since you only
> fill-ed the paths, but didn't stroke them, there are technically
> gaps of zero pixel width between adjacent tiles.  And just like lines of 
> width zero are not exactly the same thing as no lines at all, gaps of width 
> zero are not the same as no gap at all.  For this to be a meaningful test, 
> the paths could have to be both filled and stroked.

It does not help. Try to play with /F in the attached example. Also added 
blue background. And tested with different direction of stacked boxes.

> Fill-ing and stroke-ing gives much better results: the lines occur less 
> frequently, and with less intensity.

I don't think so. Try to render the result into a png file (command in my 
previous mail), not onto x11 display.

---
PM

Re: spurious lines in gs with antialiasing

[Hans-Bernhard B. <br...@ph...>]

Petr Mikulik wrote:
> Well, it looks to me that it must be a bug in ghostscript -- some 
> rounding of positions or whatever. Below is a simplest postscript code 
> that demonstrates spurious lines in a pm3d-like image:

I don't fully agree that those lines are "spurious".  Since you only
fill-ed the paths, but didn't stroke them, there are technically
gaps of zero pixel width between adjacent tiles.  And just like lines of 
width zero are not exactly the same thing as no lines at all, gaps of 
width zero are not the same as no gap at all.  For this to be a 
meaningful test, the paths could have to be both filled and stroked.