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

Re: black rectangle below rotated color text on x11

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

>> There is yet another code which looks "suspictious" to me, because it
>> was formerly surrounded by #if defined(PM3D) && defined(USE_MOUSE):
>
> That bit is OK, I think.  The xor GC is used for drawing the "rubber-band"
> ruler and zoom-box lines.  It would not be needed if there is no
> mouse support.  Or were you suspicious about something different?

For #ifdef USE_MOUSE it is OK, the additional && defined(PM3D) was probably 
a mistake.

---
PM

Re: black rectangle below rotated color text on x11

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

On Sunday 07 August 2005 02:48 am, Petr Mikulik wrote:
> > Amazingly enough, I think this problem may go away when you remove the
> > conditional coding of PM3D.
>
> Let's see. I've just committed the removal.

OK. I've collapsed gc_pm3d back into the main gc.  That fixed the
rotated-text color bug for white or near-white backgrounds.
I've also finally understood how to apply Dave Denholm's suggestion
for avoiding color-mangling by making 2 passes. That fixes the problem
for all backgrounds, at least if the display visual is TrueColor or
DirectColor. I'm not so sure about PseudoColor visuals, but at any
rate the fall-back to  "gnuplot*fastrotate: off" is still available.

I have not yet merged the pm3d and non-pm3d command protocols sent
from x11.trm to gplot_x11.c.  That would remove a bit of redundant
code at each end, but I don't expect any effects on performance.

> There is yet another code which looks "suspictious" to me, because it
> was formerly surrounded by #if defined(PM3D) && defined(USE_MOUSE):

That bit is OK, I think.  The xor GC is used for drawing the "rubber-band"
ruler and zoom-box lines.  It would not be needed if there is no
mouse support.  Or were you suspicious about something different?

> gplt_x11.c, line 5039:
>
> #ifdef USE_MOUSE
>      {
>          /* create the xor GC just for allocating the xor value
>           * before a palette is created. This way the xor foreground
>           * will be available. */
>          AllocateXorPixel(cmap_ptr);
>      }
> #endif
> }
>
> ---
> PM

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

Re: black rectangle below rotated color text on x11

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

> Amazingly enough, I think this problem may go away when you remove the
> conditional coding of PM3D.

Let's see. I've just committed the removal.

> The underlying problem seems to be that gnuplot_x11 is keeping separate 
> graphics contexts for pm3d and non-pm3d drawing.  The color mismatch comes 
> at least sometimes, and maybe always, because of an inconsistent mapping 
> of colors in the two contexts.
>
> If we unconditionally support PM3D, then I don't see any need to keep two
> separate contexts; we can merge all the uses of gc_pm3d back into the main gc.
> In preliminary testing, this cures the observed bug.
>
> By the way -- gplt_x11.c is an example of code where simply removing
> #ifdef PM3D / #endif  brackets is not the way to go.  The code
> inside these brackets is often parallel to, rather than in addition to,
> the non-PM3D case.

Could you please make this "unification"?


There is yet another code which looks "suspictious" to me, because it was 
formerly surrounded by #if defined(PM3D) && defined(USE_MOUSE):

gplt_x11.c, line 5039:

#ifdef USE_MOUSE
     {
         /* create the xor GC just for allocating the xor value
          * before a palette is created. This way the xor foreground
          * will be available. */
         AllocateXorPixel(cmap_ptr);
     }
#endif
}

---
PM

Re: Minor fix to code from cvs

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

On Saturday 06 August 2005 04:26 am, Bastian M=C3=A4rkisch wrote:
> I was just trying to compile a current gnuplot version from cvs
> and got an error in src/set.c. The patch below will fix it.

I've applied that fix.  Thanks.
I've also removed a C++ style comment that was introduced into color.c

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Minor fix to code from cvs

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

I was just trying to compile a current gnuplot version from cvs 
and got an error in src/set.c. The patch below will fix it.

Bastian

---------------------------------------------------------------------------------
--- gnuplot/src/set.c	2005-08-06 10:26:18.000000000 +0200
+++ test/src/set.c	2005-08-06 11:24:13.703125000 +0200
@@ -3570,8 +3570,8 @@
 		axis_array[i].tic_rotate = 0;
 	    ++c_token;
 	} else if (almost_equals(c_token, "off$set")) {
+	    struct position lpos;
 	    ++c_token;
-	    struct position lpos;
 	    get_position_default(&lpos, character);
 	    for (i = 0; i < AXIS_ARRAY_SIZE; ++i)
 		axis_array[i].ticdef.offset = lpos;
---------------------------------------------------------------------------------

Re: black rectangle below rotated color text on x11

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

On Wednesday 03 August 2005 08:57 am, Petr Mikulik wrote:
> 
> => the the bounding box of the string gets black background on x11. Is it 
> possible to fix it?

Amazingly enough, I think this problem may go away when you remove the
conditional coding of PM3D.   The underlying problem seems to be that
gnuplot_x11 is keeping separate graphics contexts for pm3d and non-pm3d
drawing.  The color mismatch comes at least sometimes, and maybe always,
because of an inconsistent mapping of colors in the two contexts.

If we unconditionally support PM3D, then I don't see any need to keep two
separate contexts; we can merge all the uses of gc_pm3d back into the main gc.
In preliminary testing, this cures the observed bug.

By the way -- gplt_x11.c is an example of code where simply removing
#ifdef PM3D / #endif  brackets is not the way to go.  The code
inside these brackets is often parallel to, rather than in addition to,
the non-PM3D case.  Some of this code can be deleted altogether
when PM3D does not need to be handled as a special case of something else.
For example, the x11.trm/gplt_x11.c communication protocol has two sets of
set-linetype commands  'L' and 'l'.  They both do basically the same thing
except that one is applied to the gc_pm3d and the other to gc.  Merge the
two gc's and you don't need separate handling routines.



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

Re: Unexpected warning message from new "set key" code

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

Ethan Merritt wrote:
> With the new 'set key' code in place, I get the following warning
> when running 
>     gnuplot simple.dem
> 
> set key outside below
>                 ^
> "simple.dem", line 31: warning: Multiple location region settings
> 
> 
> It does not seem to hurt anything, but it is disconcerting.
> Do we need this warning message?

Eh, I don't know.  It's up to the list.  Take it out if you like.  (Or if you want me to write a quick patch, let me know.)

In some sense, for the new way of thinking, "outside" and "below" do not conflict.  Right?  "outside" is kind of redundant if one has already said "below", but fine.

I think the warning comes about because in the old way of thinking of things (and still compatible) "outside" meant outside and to the upper right of the plot.  So, before the changes it really is a conflict and a warning should be issued.  The question maybe should be Why didn't there used to be a warning?

I guess I've argued strongly for a more flexible and general way of thinking but confused matters by placating the old restrictive syntax by adding this warning message.

Take out the warning?  Take out the warning completely?  Take out the warning just for this old special condition?

Dan

Unexpected warning message from new "set key" code

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

With the new 'set key' code in place, I get the following warning
when running 
    gnuplot simple.dem

set key outside below
                ^
"simple.dem", line 31: warning: Multiple location region settings


It does not seem to hurt anything, but it is disconcerting.
Do we need this warning message?


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

Re: black rectangle below rotated color text on x11

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

On Wednesday 03 August 2005 08:57 am, Petr Mikulik wrote:
> Please try this:
> 
> set label 1 "hello" at 0,2 rotate by 90
> plot x
> pause -1
> 
> set label 1 textcolor rgb "red"
> plot x
> 
> => the the bounding box of the string gets black background on x11. Is it 
> possible to fix it?

Yes. Turn off the x11 resource "fastrotate".

echo "gnuplot*fastrotate:  off" | xrdb -merge



This is a known, and long-since discussed, problem.
To rotate text correctly in the presence of extra colors is *very* slow,
to the point that x performance is seriously degraded.
Since most plots do not need this feature, the default is to use the
older, faster, rendering algorithm.




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

Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

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

As indicated earlier, I tend to remove PM3D compile options (i.e. to have 
all PM3D code in) in order to clean up the source code. The only vote 
against was that 16bit DOS will not compile any longer due to "640 KB 
limit", but this argument was refused.

I guess I do the change during the weekend, unless there are yet more 
agreed votes against.

---
PM

black rectangle below rotated color text on x11

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

Please try this:

set label 1 "hello" at 0,2 rotate by 90
plot x
pause -1

set label 1 textcolor rgb "red"
plot x

=> the the bounding box of the string gets black background on x11. Is it 
possible to fix it?

---
PM

Re: [Gnuplot-cvs] CVS Update: gnuplot

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

Ethan Merritt wrote:

> In what way do you see this as different from the notion of
> `reset, then apply explicit changes` ?

Not a lot.  But that's partly missing the point: the concept of 
"explicit changes" currently simply doesn't exist anywhere in save.c, 
except your recent modification.  It might be a good idea to keep in 
mind should we ever want to re-write save_set() almost from scratch, but 
for now, the strategy is:  save all settings in a way that overwrites 
whatever previous settings there were.

> While we're on the topic, I have a related problem that I really don't
> know how best to deal with.   The "datastrings" and "histograms" modules
> make heavy use of the ability to read tic-labels and key-titles from a
> data file.  Internally, these label structures are fed into the same
> data structures that are loaded by explicit user commands like
>   set xtics ("foo" 1, "bar" 2, "etc" 3)
> 
> But this means that when you `save` the current state, you get a dump
> of the most recent tic labels read from a data file.  This is really
> annoying if you don't remember to wipe the xtic entries clear, either
> before saving or after restoring.   What are your thoughts on this
> issue?

I see two major possibilities:

1) handle it the same way it's done for other things that change 
dynamically during a plot, most notably the ranges: duplicate the key 
data structures, prefix one with "set_", and copy the set_ versions into 
the un-prefixed instance in axis.h:AXIS_INIT{2,3}D

2) move the labels found in the data file to some other place, and 
change gen_tics and/or xtick{2,3}d_callback to use that instead of 
normal ones.

Re: [Gnuplot-cvs] CVS Update: gnuplot

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

On Monday 01 August 2005 08:48 am, Hans-Bernhard Broeker wrote:
> Ethan A Merritt wrote:
> > So you expect restoring from a saved file to do an implicit `reset`?
> > There has been no guarantee of this in the past that I know of.
> 
> But it's implicit consequence of what "save" does: it save all the 
> settings.  All of them.  So yes, loading that file again should restore 
> them all, otherwise, we can't really say we "saved" them.

In what way do you see this as different from the notion of
`reset, then apply explicit changes` ?

The latter approach is the one assumed by Petr's gpsavediff script,
for instance.

While we're on the topic, I have a related problem that I really don't
know how best to deal with.   The "datastrings" and "histograms" modules
make heavy use of the ability to read tic-labels and key-titles from a
data file.  Internally, these label structures are fed into the same
data structures that are loaded by explicit user commands like
  set xtics ("foo" 1, "bar" 2, "etc" 3)

But this means that when you `save` the current state, you get a dump
of the most recent tic labels read from a data file.  This is really
annoying if you don't remember to wipe the xtic entries clear, either
before saving or after restoring.   What are your thoughts on this
issue?



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

Re: [Gnuplot-cvs] CVS Update: gnuplot

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

Ethan A Merritt wrote:
> So you expect restoring from a saved file to do an implicit `reset`?
> There has been no guarantee of this in the past that I know of.

But it's implicit consequence of what "save" does: it save all the 
settings.  All of them.  So yes, loading that file again should restore 
them all, otherwise, we can't really say we "saved" them.

> I think there are other bits of context as well that are not necessarily
> restored to default state by executing a `save`d file.

I think the code in 'save.c' actually goes to quite some length to make 
sure this doesn't happen.  It took several iterations to get that right, 
too, as a quick look over the cvs log of save.c will reveal.

Re: Should we provide a keyword than means (1/0) ?

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

Ethan A Merritt wrote:

> Sure. But in this case the behavior of sscanf() or strtod() does not
> matter. parse_primary_expression() has:

>     } else if (isanumber(c_token)) {
>     } else if (isletter(c_token)) {
>     } else

> So even if the code in scanner.c has previously identified this token as
> NaN or Inf, parse_primary_expression() will ignore that and instead
> try to find a variable with that name.

Not really.  Note how isanumber() is implemented: it returns

	!token[t_num].is_token

i.e. if NaN was found in the command line, this leaves it completely up 
to the scanner whether to interpret that as a token (i.e. keyword or 
variable) or as a number.

Re: Should we provide a keyword than means (1/0) ?

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

> I can see how it would be hard for new users to work this out
> on their own.  "Illegal divide by zero" is not usually the
> same as "Omit this point" in the larger world.
> 	plot <foo> using 1 : ($2 > 0 ? $2 : 1/0)
> 	plot <foo> using 1 : ($2 > 0 ? $2 : omit)

I think it does not matter whether it is 1/0 or omit. I prefer to keep 1/0, 
or type NaN. Rather the current syntax should be better advertised. FAQ, 
documentation?

---
PM

Re: Should we provide a keyword than means (1/0) ?

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

On Sunday 31 July 2005 12:03 pm, you wrote:
> Ethan Merritt wrote:
> > I am surprised to find that NaN is not accepted already.
> > It's acceptable in a data file.
>
> But not reliably.  It's a feature of the systems sscanf() / strtod()
> implementation whether NaN will be accepted, and if so, which input
> string will get you this result.

Sure. But in this case the behavior of sscanf() or strtod() does not
matter. parse_primary_expression() has:

    } else if (isanumber(c_token)) {
        /* work around HP 9000S/300 HP-UX 9.10 cc limitation ... */
        /* HBB 20010724: use this code for all platforms, then */
        union argument *foo = add_action(PUSHC);
        convert(&(foo->v_arg), c_token);
        c_token++;
    } else if (isletter(c_token)) {
	... check for functions or variables ...
    } else
	... check for operators ...

So even if the code in scanner.c has previously identified this token as
NaN or Inf, parse_primary_expression() will ignore that and instead
try to find a variable with that name.

This seems wrong to me, although no one has complained up til now.
Having gone to the trouble of parsing and categorizing of each token in
scanner.c, we then ignore that work and have parse_primary_expression()
do a less complete check on its own.  Wouldn't it be better to simply
test the flag previously set in token[t_num].l_val.type ?

So instead of the tests above for (isanumber(c_token)) etc, we would
have a switch statement 
	switch(token[t_num].l_val.type)

Yes, I see that the code in scanner.c probably won't catch NaN of Inf
either. But the point is that even if we were to make the code in
scanner() match the code in df_tokenise(), which would make sense for
consistency, it would still be ignored during expression parsing.


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

Re: Should we provide a keyword than means (1/0) ?

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

Ethan Merritt wrote:
> I am surprised to find that NaN is not accepted already.
> It's acceptable in a data file.

But not reliably.  It's a feature of the systems sscanf() / strtod() 
implementation whether NaN will be accepted, and if so, which input 
string will get you this result.  Remember: there could still be 
machines out there that don't have NaNs at all.

Re: Should we provide a keyword than means (1/0) ?

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

On Friday 29 July 2005 04:04 pm, Daniel J Sebald wrote:

> > you could write
> > 	plot <foo> using 1 : ($2 > 0 ? $2 : omit)
> 
> All of those would be fine.  Perhaps NAN as well.

I am surprised to find that NaN is not accepted already.
It's acceptable in a data file.

But extending the expression parser to handle NaN
(and presumably Inf) is a somewhat separate question.


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

Re: Should we provide a keyword than means (1/0) ?

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

Ethan Merritt wrote:

> So I wonder if it would be a good idea to add some keyword like
> "skip" or "omit" or "invalid" or "undefined".  Instead of
> writing
> 	plot <foo> using 1 : ($2 > 0 ? $2 : 1/0)
> you could write
> 	plot <foo> using 1 : ($2 > 0 ? $2 : omit)

All of those would be fine.  Perhaps NAN as well.

Daniel

Should we provide a keyword than means (1/0) ?

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

I have noticed that many questions posted to the newsgroup
fall into the general category 
"How do I *not* plot part of my data or function?".
The answer usually involves a conditional expression with the
constant value  "1/0"   used to generate invalid data points.

I can see how it would be hard for new users to work this out
on their own.  "Illegal divide by zero" is not usually the 
same as "Omit this point" in the larger world.

So I wonder if it would be a good idea to add some keyword like
"skip" or "omit" or "invalid" or "undefined".  Instead of
writing
	plot <foo> using 1 : ($2 > 0 ? $2 : 1/0)
you could write
	plot <foo> using 1 : ($2 > 0 ? $2 : omit)


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

Re: Mouse in x11 interactive terminal

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

On Friday 29 July 2005 04:54 am, 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" 

That looks correct to me.




[it doesn't matter now, but...]

The original logic of having a global variable "isatty_state" escapes me.
There was already a global "interactive", and the only initialization of
isatty_state is the one shown above.  I fail to see how having two
globals is an improvement over just using the one that was there already.

If we get rid of isatty_state in x11.trm, then the only two remaining
drivers that refer to the global "interactive" flag are

post.trm:
                    if ((lf && lf->interactive) || interactive)
                        PS_load_fontfile(new_ps_fontfile,FALSE);

amiga.trm:
		    doesn't do anything in term->text or term->suspend
		    if (!interactive)


The postscript use looks dubious to me.  Why would we not want to 
load a font file in non-interactive mode?
(Harald, do you remember this?)

The amiga code we can do away with by dropping amiga support :-)





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

Ethan Merritt wrote:

> Not quite.  The ghostscript bug should not affect conversion to pdf, 
> because that is a conversion from one vector description to another.
> Acrobat, or xpdf, would have to introduce their own separate aliasing
> bug to get the display wrong.

Well, I know what you are thinking, but I'm not so sure that is the case with ghostscript.  It may be.  However, my experience is that if something is wrong in one variation of ghostscript software (e.g., ghostview) it is a problem in all variations of ghostscript (e.g., translator).

Dan

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

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

On Friday 29 July 2005 10:54 am, Daniel J Sebald wrote:
> 
> Those lines we are seeing aren't a problem with PostScript.

  right

> They are a problem with the interpretter's antialiasing routine.

  not so much a problem with the routine itself, as a bad choice of
  which elements to apply it to.

> When the mesh lines are turned on, they cover up the artifact (the bug) 
> in GhostView and all its related software (gs, ps2pdf, etc.).
> That's the way I'm understanding it.     

Not quite.  The ghostscript bug should not affect conversion to pdf, 
because that is a conversion from one vector description to another.
Acrobat, or xpdf, would have to introduce their own separate aliasing
bug to get the display wrong.


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

[...]

I agree with everything you said...
 
> 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.

but I think this is what the issue is.  Those lines we are seeing aren't a problem with PostScript.  They are a problem with the interpretter's antialiasing routine.  When the mesh lines are turned on, they cover up the artifact (the bug) in GhostView and all its related software (gs, ps2pdf, etc.).  That's the way I'm understanding it.

Dan