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

Re: [Bug 688243] Spurious lines between joined filled rectangles and antialiasing (fwd)

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

Daniel J Sebald wrote:
> Hans-Bernhard Broeker wrote:
>> Daniel J Sebald wrote:
>>> course, this demo example doesn't have high enough spatial frequency 
>>> to cause aliasing.)

>> That's quite exactly wrong.  All pm3d plots, indeed almost exactly
>> *every* plot gnuplot is capable of generating, contains ample amounts of
>> infinitely high spatial frequency details --- every thing we output has
>> perfectly sharp borders, including the coloured areas generated by pm3d.

> No, the example I was referring to is a low frequency sinc function that 
> is adequately sampled.  

I think we're talking about two different sampling processes here.

A PM3D function plot that ends up on any raster device (no matter 
through which driver) always involves at least two sampling processes: 
one from a (hopefully) continuous 3D surface to a polygon mesh, the from 
from that polygon mesh to pixels.  The sampling frequency for the first 
one (controlled by "set isosamples" and "set samples" in gnuplot) may be 
as smoothly and adequately sampled as it wants: the polygon mesh that 
comes out of this process still has sharply defined corners and edges 
(e.g. a sharp boundary between two uniformly gray rectangles of 
different gray values), and those will quite certainly alias as they get 
scan-converted to pixels.  It's this latter sampling process and the 
aliasing it generates that we're having problems with.

The only way to keep that from happening would be to match the "set 
{iso}samples" settings in gnuplot exactly to the actual output 
resolution.  For drives like GD, X11 and some others, that's possible; 
for PostScript it's not.

> which is correct.  From ghostview's perspective, whenever the display is 
> of lower resolution than the image contained inside the PostScript file, 
> there is the possibility of aliasing and antialiasing should be 
> applied.  

For gnuplot output, the image is pretty much always of infinite spatial 
resolution: we have razor-sharp edges all over the place.  Ghostscript 
trying to antialias its display of what we give it is therfore perfectly 
justified.  The problem is not that gs tries to antialias, it's that it 
fails to get it done.

> For all I know, "antialiasing" in GhostView could mean both antialiasing 
> (more image pixels than screen pixels) and reconstruction (more screen 
> pixels than image pixels).  In fact, that is probably the case.  I say 
> that because I have used GhostViews zoom function to greatly expand a 
> few pixels in a subwindow.  

You're missing an important details: PostScript doesn't *have* pixels. 
It's a vector-based graphics description format.  Pixels and aliasing 
only get involved as this continuous description gets mapped to discrete 
output formats.

Re: [Bug 688243] Spurious lines between joined filled rectangles and antialiasing (fwd)

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

This discussion seems to be veering off on a tangent,
since the bug has been confirmed to lurk on the ghostscript side
rather than in gnuplot's driver.

As I understand it, we're waiting to hear back from
the ghostscript people if there is a PostScript command that can
be embedded in the file which would set GraphicsAlphaBits to 1.
I imagine this would be some variant of

    /GraphicsAlphaBits where
    {(%something identifying ghostscript%) 
     <</GraphicsAlphaBits 1>> setdevparams} if

(obviously not tested by me)

But I fear this will encounter a number of problems,
such as not being allowing inside an EPSF file.



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

Re: [Bug 688243] Spurious lines between joined filled rectangles and antialiasing (fwd)

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

Hans-Bernhard Broeker wrote:
> Daniel J Sebald wrote:
> 
>> course, this demo example doesn't have high enough spatial frequency 
>> to cause aliasing.)
> 
> 
> That's quite exactly wrong.  All pm3d plots, indeed almost exactly
> *every* plot gnuplot is capable of generating, contains ample amounts of
> infinitely high spatial frequency details --- every thing we output has
> perfectly sharp borders, including the coloured areas generated by pm3d.

No, the example I was referring to is a low frequency sinc function that is adequately sampled.  When displayed on the screen, "perfectly sharp borders" is something different.  That is what a reconstruction filter is for (different than an antialiasing filter), to smooth out the sharp edges after reconstructing a signal.  A reconstruction filter is the case where an image "pixel" occupies multiple screen pixels.  They really should be smoothed between image pixels before being displayed.  If the image/screen is one-to-one pixels, then the smoothing is inherently done by the monitor screen (unless you place your eye real close to the screen to see individual dots).

You described aliasing below:

> Aliasing has nothing to do with monochrome vs. colour.  Aliasing
> is the artefact invariably created whenever you point-sample (i.e.
> render to pixels) a signal at a frequency that's lower than the signal's
> actual bandwidth.

which is correct.  From ghostview's perspective, whenever the display is of lower resolution than the image contained inside the PostScript file, there is the possibility of aliasing and antialiasing should be applied.  (But applied correctly of course, not with strange lines.)  For all I know, "antialiasing" in GhostView could mean both antialiasing (more image pixels than screen pixels) and reconstruction (more screen pixels than image pixels).  In fact, that is probably the case.  I say that because I have used GhostViews zoom function to greatly expand a few pixels in a subwindow.  There is no need for GhostView to apply antialiasing to such an image, yet the lines still appear.

If I bumped up the frequency of that sinc function, I'm sure aliasing would begin to happen.  Try this:

1) Run Petr's pm3d.dem demo until the grayscale example that says "gray map".

2) Break out of the demo and change the range as

set xrange [-1500:1500]
set yrange [-1500:1500]

3) replot

And you will see strange patterns on the image that shouldn't be there because by choosing such a large range the frequency of the sinc within the plotted area is much too great to be displayed.


> More to the point: our x11.trm *knows* the (assumed) resolution of the
> X11 driver, and it does the reduction to integer coordinates itself.
> I.e. the entire rendering process is controlled by gnuplot alone.
> post.trm, OTOH, cannot even make an educated guess what the actual
> output device resolution --- so it just assumes it's 720 DPI.

Right, but the X11 windows can be scaled to have lower resolution.  Hence there is a routine in gnuplot_x11 that does that conversion.

Dan

Re: [Bug 688243] Spurious lines between joined filled rectangles and antialiasing (fwd)

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

Daniel J Sebald wrote:

> course, this demo example doesn't have high enough spatial frequency 
> to cause aliasing.)

That's quite exactly wrong.  All pm3d plots, indeed almost exactly
*every* plot gnuplot is capable of generating, contains ample amounts of
infinitely high spatial frequency details --- every thing we output has
perfectly sharp borders, including the coloured areas generated by pm3d.

> The color bar also looks much better.  (No aliasing possible there in
>  monochrome, unless intentional.)

Aliasing has nothing to do with monochrome vs. colour.  Aliasing
is the artefact invariably created whenever you point-sample (i.e.
render to pixels) a signal at a frequency that's lower than the signal's
actual bandwidth.

For all plot features that have at least one dimension not larger than
one pixel (i.e. dots, lines, and any borders between solid-filled areas,
and vertices of solid-filled polygons), you invariably get aliasing.  It 
manifests itself in the fact that the feature will be displayed up to 
half a pixel away from its "true" position.

>> I think the situation is slightly better for the X11 driver, 
>> because the resolution of the output device is known in advance, 
>> you can therefore round coordinates to get better results.

More to the point: our x11.trm *knows* the (assumed) resolution of the
X11 driver, and it does the reduction to integer coordinates itself.
I.e. the entire rendering process is controlled by gnuplot alone.
post.trm, OTOH, cannot even make an educated guess what the actual
output device resolution --- so it just assumes it's 720 DPI.

Re: Mouse in x11 interactive terminal

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

>> It looks that with this this removal from plot.c
>> 
>> #ifdef PIPE_IPC
>>     /* isatty_state is set here and nowhere else! (used in term/x11.trm) */
>>     isatty_state = interactive;
>>     if (!isatty_state) {
>>        /* stdin is not from a tty --> Turn mouse off.
>>         * can be turned on again, e.g. if the user
>>         * wants to write on a pipe to gnuplot */
>>        mouse_setting.on = 0;
>>     }
>> #endif
>> 
>> I can also remove all other occurencies of the variable "isatty_state" 
>
> Then you didn't look very close, or you're silently assuming the context of 
> an already modified source tree.  The primary user of this variable is 
> x11.trm, in the shape of macro X11_ALLOW_EVENTS.  At least, it still was in 
> the CVS source as of yesterday.

I did, but I didn't want to enclose the full patch. That variable is used 
only if set in the above code in plot.c to be removed.

I enclose the complete patch.

---
PM

Re: Mouse in x11 interactive terminal

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

Petr Mikulik wrote:
> It looks that with this this removal from plot.c
> 
> #ifdef PIPE_IPC
>     /* isatty_state is set here and nowhere else! (used in term/x11.trm) */
>     isatty_state = interactive;
>     if (!isatty_state) {
>        /* stdin is not from a tty --> Turn mouse off.
>         * can be turned on again, e.g. if the user
>         * wants to write on a pipe to gnuplot */
>        mouse_setting.on = 0;
>     }
> #endif
> 
> I can also remove all other occurencies of the variable "isatty_state" 

Then you didn't look very close, or you're silently assuming the context 
of an already modified source tree.  The primary user of this variable 
is x11.trm, in the shape of macro X11_ALLOW_EVENTS.  At least, it still 
was in the CVS source as of yesterday.

Re: xtics according to a nonlinear scale

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

Giuseppe Angilella wrote:
> is it possible to have an user-defined scale on an axis according to a 
> given nonlinear function? 

Not really.  The problem is that it is really quite hard to find any 
generally applicable, sensible way of distributing tics on such 
arbitrarily deformed axes, so odds are you'ld have to place the tics 
manually anyway --- in which case there wouldn't not much to be gained 
by having such a feature in gnuplot in the first place.

So: transform the data to be plotted, and place tics manually, as in

	set parametric
	set xtics ('1' f(1), '2' f(2), '3' f(3))
	plot f(t), f(g(t)) t 'g(x)'

xtics according to a nonlinear scale

[Giuseppe A. <Giu...@ct...>]

Hi,

is it possible to have an user-defined scale on an axis according to a 
given nonlinear function? I mean something like "set logscale x", but with 
tics distributed according to x**2 or any other given f(x).

I know I could use "set xtics", and then define every single tic I need, 
but that's of course much more cumbersome.

Thanks for every hint.

Giuseppe.

Re: Mouse in x11 interactive terminal

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

>>> I propose to switch on mouse also for this combination.
>>> That would make many people happy and gnuplot behaviour compatible.

It looks that with this this removal from plot.c

#ifdef PIPE_IPC
     /* isatty_state is set here and nowhere else! (used in term/x11.trm) */
     isatty_state = interactive;
     if (!isatty_state) {
        /* stdin is not from a tty --> Turn mouse off.
         * can be turned on again, e.g. if the user
         * wants to write on a pipe to gnuplot */
        mouse_setting.on = 0;
     }
#endif

I can also remove all other occurencies of the variable "isatty_state" which 
is not used for any other purpose.

---
PM

Re: [Bug 688243] Spurious lines between joined filled rectangles and antialiasing (fwd)

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

Robert Hart wrote:
> On Thu, 2005-07-28 at 11:02 -0500, Daniel J Sebald wrote:
> 

<snip>

> Presumeably what we are seeing is some kind of rounding error, where our
> two adjoining polygons don't lead to a final alpha value of one. By
> having a positive thickness to the lines around the objects, they
> effectively overlap (albeit slightly) and hence are more likely to get
> it right.

Oh, I see.  That might also explain the odd polygon colors I used to see.

Actually, I just found that the problem hasn't gone away with the software in Fedora 3.  It is obviously much better so perhaps there were multiple issues.

Anyway, I'm using GhostView right now to view one of Petr's b/w sinc-like, 2D-projected, grayscale images.  There are lines; but turning off antialiasing from the "State" menu causes the lines to go away.  (Of course, this demo example doesn't have high enough spatial frequency to cause aliasing.)  The color bar also looks much better.  (No aliasing possible there in monochrome, unless intentional.)

> An alternative approach, which may produce better results, is to rended
> the image at a higher resolution, and then reduce the resolution. This
> may not necessarily need more memory, as the image could be split into
> smaller tiles, but that is getting off topic.

That's on topic.  

> I think the situation is slightly better for the X11 driver, because the
> resolution of the output device is known in advance, you can therefore
> round coordinates to get better results. (I think ghostscript
> antialiased images can look quite blurry especially for vertical and
> horizontal lines)

Perhaps.

Dan

Re: [Bug 688243] Spurious lines between joined filled rectangles and antialiasing (fwd)

[Robert H. <en...@no...>]

On Thu, 2005-07-28 at 11:02 -0500, Daniel J Sebald wrote:
> I'm getting into ghostview more than I care to know, but a rhetorical question would be, Is the 1, 2, 4 something having to do with the number of surrounding pixels or elements that are averaged (i.e., the kernel)?  And if 1 is chosen it means no smoothing?  (I.e., no antialiasing.)  A good routine would figure out how big the kernel should be.

I thought the 1, 2, 4 bit is adding an alpha channel to the image. When
any object is drawn, this is set to a value that represents the
proportion of a pixel that has been "used". When subsequent objects are
drawn, then a new colour can be assigned to the pixel based on the
current colour and alpha value and the new colour and alpha.

Thus with 1bit, each pixel is either used or not used. With 2bits, there
are 4 levels - not used, 1/3 used, 2/3 used, fully used, and with 4bits
there are 16 levels.

Presumeably what we are seeing is some kind of rounding error, where our
two adjoining polygons don't lead to a final alpha value of one. By
having a positive thickness to the lines around the objects, they
effectively overlap (albeit slightly) and hence are more likely to get
it right.

An alternative approach, which may produce better results, is to rended
the image at a higher resolution, and then reduce the resolution. This
may not necessarily need more memory, as the image could be split into
smaller tiles, but that is getting off topic.

> > It 
> > would probably need much more memory to antialias the final image (and 
> > to remember all graphics elements there).
> 
> I'll admit that when I did the imaging for the X11 driver I
> disregarding aliasing (i.e., no averaging is done when the image is
> decimated).  But I felt that was a case of speed/usefulness versus
> complete correctness.  If ever the issue comes up, I can address it.
> But given the nature of typical image data, it often isn't a problem
> and it doesn't have a consistent, glaring characteristic like white
> lines.

I think the situation is slightly better for the X11 driver, because the
resolution of the output device is known in advance, you can therefore
round coordinates to get better results. (I think ghostscript
antialiased images can look quite blurry especially for vertical and
horizontal lines)

The openGL terminal driver I wrote had an optional antialias mode. I
don't recall getting any major problems, but I may not have tried the
specific cases that we are seeing here. I think OpenGL uses an 8-bit
alpha channel, so maybe that is why.

Rob

-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: [Bug 688243] Spurious lines between joined filled rectangles and antialiasing (fwd)

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

Petr Mikulik wrote:
>> This doesn't seem like a problem that should exist as it is described 
>> below in the manual.  It sounds to me like it has something to do with 
>> the lowpass filter kernel used to rid aliasing.  Perhaps it was 
>> originally written to render in a way that stuck them in a corner 
>> without a lot of rewrite.
> 
> 
> I wonder what's the algorithm for antialiasing is & should be. 
> Currently, it seems that they antialias the current drawn rectangle with 
> its current surrounding (e.g. white background), instead of waiting for 
> some potential future object (rectangle) that will be drawn closely.

Well, of course in the case of nonuniform sampling it is a huge issue.  That's a theoretical issue in the realm of research, if ever it has a solution.  But in the case of a grid of points one would average the colors of surrounding pixels; how many depends on the resolution of the original image versus the resolution of the display.

I'm getting into ghostview more than I care to know, but a rhetorical question would be, Is the 1, 2, 4 something having to do with the number of surrounding pixels or elements that are averaged (i.e., the kernel)?  And if 1 is chosen it means no smoothing?  (I.e., no antialiasing.)  A good routine would figure out how big the kernel should be.

> It 
> would probably need much more memory to antialias the final image (and 
> to remember all graphics elements there).

That is true, but the correct way.  But it shouldn't be too much extra memory in the case of a rectangular grid.  (Perhaps that is why ghostview's image doesn't have this problem.)  Also, I would think there are multirate approaches, e.g., rather than attempting to get the final antialiased image in one pass, use gradual smoothing and several passes to get to the final resolution.

I'll admit that when I did the imaging for the X11 driver I disregarding aliasing (i.e., no averaging is done when the image is decimated).  But I felt that was a case of speed/usefulness versus complete correctness.  If ever the issue comes up, I can address it.  But given the nature of typical image data, it often isn't a problem and it doesn't have a consistent, glaring characteristic like white lines.

Like I said, I'm not seeing this problem anymore.  Don't know why.

Dan

Re: Volunteer to add AC_CHECK_LIB() for iconv routines?

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

Hans-Bernhard Br=F6ker wrote:

[GD detection failures caused by undefined references into -liconv...]

> other libraries) but still insists on trying its own tests even if=20
> gdlib-config was found. =20

The original reporter of this problem has since provided more=20
information.  Turns out the key mistake was that not only shouldn't our=20
configure be trying to test libgd features by running test links; it's=20
getting those testlinks critically wrong, too.  They don't use the=20
necessary libraries as reported by "gdlib-config --libs".  Moving this=20
fragment in configure.in:

   if test -n "$GDLIB_CONFIG"; then
     libgd_LIBS=3D`gdlib-config --libs`
   fi

to a point *before* we try AC_CHECK_LIB() calls on libgd features, might =

already help.  But the correct approach would be not to test links at=20
all, if gdlib-config is available: it already reports everything we want =

to know about libgd, including the feature selection.

So, to summarize: there is an error our configure.in that's causing=20
those problems, and there's no point in explicitly checking for -liconv=20
as a workaround.

Re: [Bug 688243] Spurious lines between joined filled rectangles and antialiasing (fwd)

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

> This doesn't seem like a problem that should exist as it is described below 
> in the manual.  It sounds to me like it has something to do with the lowpass 
> filter kernel used to rid aliasing.  Perhaps it was originally written to 
> render in a way that stuck them in a corner without a lot of rewrite.

I wonder what's the algorithm for antialiasing is & should be. Currently, it 
seems that they antialias the current drawn rectangle with its current 
surrounding (e.g. white background), instead of waiting for some potential 
future object (rectangle) that will be drawn closely. It would probably need 
much more memory to antialias the final image (and to remember all graphics 
elements there).

It seems that my proposed "stroke" to /f and /h and redrawing the interior 
of the color box twice improve the rendering fine.

>> I'm asking about how to switch GraphicsAlphaBits from within the ps code...
> I'd be careful to not add such a thing *unless* it is standard PostScript.

Not without discussion.

---
PM

Re: [Bug 688243] Spurious lines between joined filled rectangles and antialiasing (fwd)

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

Petr,

My somewhat limited experience with ghostscript was disappointing.  I appreciate what it does, but it seems less than elegant.  I looked at some of the PostScript code it generates when translating and it appeared bloated in a major way.

I've seen this before with some of your demo examples.  It bewildered me.  Not only were the white lines present, but the color scheme was incorrect for a large percentage of the parallelograms.  But I thought it was fixed since I no longer saw the effect in ghostview after I upgraded to Fedora 3.

This doesn't seem like a problem that should exist as it is described below in the manual.  It sounds to me like it has something to do with the lowpass filter kernel used to rid aliasing.  Perhaps it was originally written to render in a way that stuck them in a corner without a lot of rewrite.

> I'm asking about how to switch GraphicsAlphaBits from within the ps code...

I'd be careful to not add such a thing *unless* it is standard PostScript.

Dan


Petr Mikulik wrote:
> Below is a answer to the bug report by ghostscript people. The 
> referenced bug 687742 refers to ghostscript documentation, where, 
> amazingly, you can read the following:
> 
> -dTextAlphaBits=n
> -dGraphicsAlphaBits=n
>     These options control the use of subsample antialiasing. Their use 
> is highly recommended for producing high quality rasterizations. The 
> subsampling box size n should be 4 for optimum output, but smaller 
> values can be used for faster rendering. Antialiasing is enabled 
> separately for text and graphics content. Allowed values are 1, 2 or 4.
> 
>     Note that because of the way antialiasing blends the edges of shapes 
> into the background when they are drawn some files that rely on joining 
> separate filled polygons together to cover an area may not render as 
> expected with GraphicsAlphaBits at 2 or 4. If you encounter strange 
> lines within solid areas, try rendering that file again with 
> -dGraphicsAlphaBits=1.
> 
> I'm asking about how to switch GraphicsAlphaBits from within the ps code...
> 
> 
> ---------- Forwarded message ----------
> Date: Wed, 27 Jul 2005 13:10:25 -0700 (PDT)
> From: bug...@gh...
> Subject: [Bug 688243] Spurious lines between joined filled rectangles and
>     antialiasing
> 
> http://bugs.ghostscript.com/show_bug.cgi?id=688243
> 
> ------- Additional Comments From ale...@co...  2005-07-27 13:10 
> -------
> Created an attachment (id=1578)
>  --> (http://bugs.ghostscript.com/attachment.cgi?id=1578&action=view)
> foo.ps -- modified sample
> 
> This is an old and rather difficult to fix issue. See the bug 687742 for 
> the
> discussion. gnuplot can try to write adjacent boxes in the single fill
> operation but this is not possible when the bxes have different colors.
> See the modified sample file.
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO 
> September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

[Bug 688243] Spurious lines between joined filled rectangles and antialiasing (fwd)

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

Below is a answer to the bug report by ghostscript people. The referenced 
bug 687742 refers to ghostscript documentation, where, amazingly, you can 
read the following:

-dTextAlphaBits=n
-dGraphicsAlphaBits=n
     These options control the use of subsample antialiasing. Their use is 
highly recommended for producing high quality rasterizations. The 
subsampling box size n should be 4 for optimum output, but smaller values 
can be used for faster rendering. Antialiasing is enabled separately for 
text and graphics content. Allowed values are 1, 2 or 4.

     Note that because of the way antialiasing blends the edges of shapes 
into the background when they are drawn some files that rely on joining 
separate filled polygons together to cover an area may not render as 
expected with GraphicsAlphaBits at 2 or 4. If you encounter strange lines 
within solid areas, try rendering that file again with 
-dGraphicsAlphaBits=1.

I'm asking about how to switch GraphicsAlphaBits from within the ps code...


---------- Forwarded message ----------
Date: Wed, 27 Jul 2005 13:10:25 -0700 (PDT)
From: bug...@gh...
Subject: [Bug 688243] Spurious lines between joined filled rectangles and
     antialiasing

http://bugs.ghostscript.com/show_bug.cgi?id=688243

------- Additional Comments From ale...@co...  2005-07-27 13:10 -------
Created an attachment (id=1578)
  --> (http://bugs.ghostscript.com/attachment.cgi?id=1578&action=view)
foo.ps -- modified sample

This is an old and rather difficult to fix issue. See the bug 687742 for the
discussion. gnuplot can try to write adjacent boxes in the single fill
operation but this is not possible when the bxes have different colors.
See the modified sample file.

Re: test palette

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

On Wednesday 27 July 2005 02:48 pm, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> > On Wednesday 27 July 2005 02:05 am, Petr Mikulik wrote:
> > 
> >>>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"?
> >>
> >>set label {<tag>} {"<label text>"}
> > 
> > That is unambiguous, since <tag> cannot be a string, and "<label text>"
> > cannot be a number.  
> 
> It's still at least somewhat ambiguous, because <tag> can be a variable, 
> which could be either the string or a number.

How is that ambiguous?  
If it evaluates to a number, then it is in fact the label tag (id #).
If it evaluates to a string, then it is the label text.
The parsing code handles both cases correctly.
This was a pain to get right, but it does work.
 
> >>set title {"<title-text>"}
> >>set xlabel {"<label>"}
> 
> > What is ambiguous in these commands?
> 
> Well, does
> 
> 	set title f
> 
> change the title text, the x offset, or the font?

We are never looking for a variable or an expression after "set",
so "title" is unambiguously a keyword.  The version 4.1 syntax
wants an explicit keyword "font" before a font string, and an
explicit keyword "offset" before an offset. That is what I meant
when I said that addition of these keywords has disambiguated the
syntax.

Old scripts did not use these keywords, but then again old scripts
did not use string variables.  So backwards compatibility is
maintained by accepting commands without these new keywords.
But if you want to use string variables, then for correctness you
must also use the keywords.  

You might quibble that  `set title "arial"`  is somehow recognizable
as intending to change the font rather than the title string.
But neither the old nor the new code treats this as anything other
than the title string. Similarly,  `set title "foo" "arial"`  is
interpreted by both the old (pre 4.1) and the new code as setting
both the title string and the font, though 4.1 issues a warning that
you should have used a "font" keyword.

I think we are in pretty good shape.  The guiding rule is to
check for all legal keywords first, and only then consider the
possibility that it may be a case of deprecated syntax where the
keyword is omitted.  If the input script predates the introduction
of string variables, this works correctly because there will never
be a string variable that might be confused with a keyword.  If it
is a newer script that does use string variables, well then it's
a case of operator error if they fail to use the new syntax.

But there may be a few commands like the one that started this
discussion, where I forgot to add parsing code for the new keywords.
Those are the cases I'm asking about.


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

Re: test palette

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

Ethan Merritt wrote:
> On Wednesday 27 July 2005 02:05 am, Petr Mikulik wrote:
> 
>>>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"?
>>
>>set label {<tag>} {"<label text>"}
> 
> 
> That is unambiguous, since <tag> cannot be a string, and "<label text>"
> cannot be a number.  

It's still at least somewhat ambiguous, because <tag> can be a variable, 
which could be either the string or a number.

>>set title {"<title-text>"}
>>set xlabel {"<label>"}

> What is ambiguous in these commands?

Well, does

	set title f

change the title text, the x offset, or the font?

Re: test palette

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

On Wednesday 27 July 2005 18:18, Ethan Merritt wrote:
> On Wednesday 27 July 2005 02:05 am, Petr Mikulik wrote:
> > > 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"?
> >
> > set label {<tag>} {"<label text>"}
>
> That is unambiguous, since <tag> cannot be a string, and "<label text>"
> cannot be a number.  The existing code correctly handles this.

But then also "plot 'file.dat' notitle with lines" is unambiguus.
The token "with" is a valid key word at its place, so it has to be
read as one.  It should be general policy that key words have higher
precedence than optional expressions (numbers and strings).

That said, the implementation of "notitle" is buggy.  And I don't
really know how it should be fixed.

Juergen

Re: test palette

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

On Wednesday 27 July 2005 02:05 am, Petr Mikulik wrote:
> > 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"?
> 
> set label {<tag>} {"<label text>"}

That is unambiguous, since <tag> cannot be a string, and "<label text>"
cannot be a number.  The existing code correctly handles this.

> set timestamp {"<format>"} ... {"<font>"}

OK. There's a case I missed when adding the disambiguating keyword "font".
I'll fix that.  The "set timestamp" command is also an example of the
documentation lagging the code by not mentioning the keyword "offset".

> set title {"<title-text>"}
> set xlabel {"<label>"}

What is ambiguous in these commands?

-- 
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

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

I have filled in this bug report:

http://bugs.ghostscript.com/show_bug.cgi?id=688243

Summary: Spurious lines between joined filled rectangles and antialiasing


---
PM

Re: Volunteer to add AC_CHECK_LIB() for iconv routines?

[<br...@ph...>]

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

I don't think so.  The actual problem here is that a gnuplot build was 
failing on functions in -liconv, which gnuplot doesn't use at all.  I 
can see no sane reason we should have to check for a library which we 
never use.

The dependence on this library was introduced by -lgd, in that case, and 
as far as I can tell, the actual reason the build failed was that our 
configure script checks for the existence of gdlib-config (which exists 
for the exact purpose of informing us about such dependencies of -lgd on 
other libraries) but still insists on trying its own tests even if 
gdlib-config was found.  That feels quite wrong to me.  I think that if 
we did find gdlib-config, all direct tests for libgd features have to be 
done against output of that tool.

The second half of the original problem may well have been that the OP's 
gdlib-config was buggy.

Re: test palette

[<br...@ph...>]

Petr Mikulik wrote:
> The problem is only when user defines a variable with name same as a 
> keyword. This is not allowed in normal programming languages.

That narrows down 'normal' quite a bit more than acceptable.

Whether or not the keywords of the command syntax are just keywords or 
actually "reserved words" is one of many things that programming 
languages are classified by.  It's not justified to declare all 
languages that don't reserve their keywords strictly to themselves as 
"not normal".

And let's not forget that gnuplot allows quite heavy abbreviation.  You 
can't seriously be planning to forbid users from creating functions or 
variables named 't' or 'w' just because they might collide with

	p 'file' t "foo" w l

Re: test palette

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

>> 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".

The problem is only when user defines a variable with name same as a 
keyword. This is not allowed in normal programming languages.

> 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"?

set label {<tag>} {"<label text>"}
set timestamp {"<format>"} ... {"<font>"}
set title {"<title-text>"}
set xlabel {"<label>"}

---
PM

Re: Volunteer to add AC_CHECK_LIB() for iconv routines?

[Lars H. <lhe...@us...>]

Ethan Merritt writes:
> Copyied from the newsgroup, in the hope that someone will
> volunteer to add the appropriate checks to ./configure.in
 
 Try this fragment. I added it to GD's configure for 2.0.9.

AM_ICONV
if test -n "$LIBICONV" ; then
  LIBS="$LIBS $LIBICONV"
fi
 
AC_CHECK_HEADERS(iconv.h,
  [AC_MSG_CHECKING(whether iconv.h defines iconv_t)
   AC_EGREP_HEADER([typedef.*iconv_t],iconv.h,
     [AC_MSG_RESULT(yes)
      AC_DEFINE(HAVE_ICONV_T_DEF, 1,
                [Define if <iconv.h> defines iconv_t.])],
      AC_MSG_RESULT(no))])