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

Re: spurious lines in gs with antialiasing

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

On Thu, 2005-07-21 at 14:15 +0200, Petr Mikulik wrote:

> Questions to postscript gurus:
> 1. Is it a gs bug?

Yes I think so. Acrobat Distiller seems to be able to do the right
thing. I've also seen similar bugs in output from various other
programs.

> 2. Can gnuplot overcome it? (Ignore antialiasing, ...)

In your example, I modified the coordinates to give a slight overlap
(making each rectangle 100.1 points wide) Whether it would be practical
to do this in the postscript terminal is another matter. (I guess you'd
have to find the centroid of each polygon, and then scale all the
coordinates.

Maybe there are other approaches, but I suggest leaving it - people can
either a) live with it b) turn of antialiasing or c) wait until
ghostscript fix the bug.

You might want to post a bug on bugs.gnuplot.com

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: [ gnuplot-Patches-1191202 ] Fix multiplot problem with epslatex terminal

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

>> Example: I want to add one more to  avoid codes like 'if (term->name=="pm")
>
> That's a bad example, because it only occurs in code segments that are
> already conditional on OS2.  Making it a terminal entry test instead would
> not actually simplify the call sites.  I.e. it would still have to be
> #ifdef OS2
>   ... other OS2-specific code ...
>   if (term->whatever)
>      (term->whatever)(foo);
> #endif

Better example is (see set.c: "set mouse" switches on relevant menu items 
in PM terminal):

#if defined(USE_MOUSE) && defined(OS2)
     update_menu_items_PM_terminal();
#endif

=>

#if defined(USE_MOUSE)
     if (term->interactive) {
 	term->interactive("mouse", "is", "enabled");
 	term->interactive("cursor", "is", "whatever");
 	term->interactive("allow", "q", "hotkey closes window");
     }
#endif


>>> /* Used by post.trm to optimize the color box (called from color.c)
>>>  * Could be generalized to draw arbitrary rectangles with gradient
>>>  * fill.
>>>  */
>>> term->gradient_fill(int xl, int xh, int yl, int yh, struct gradient *g)
>>
>> I don't think that's necessary. Only those few pieces needing this can use
>> "if (terminal is postscript) ..." as it is now.
>
> Wait. Isn't that exactly the opposite of what you were arguing above
> with respect to "if (terminal is pm)" ?
>
> Anyhow, if you think it is useful to optimize a gradient-filled
> rectangle, why limit it to postscript?  libgd and (I think) svg also
> could support this.

Now I see the point. It is OK with me.

---
PM

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:

%!
/M {moveto} bind def
/L {lineto} bind def
/R {rmoveto} bind def
/V {rlineto} bind def
/C {closepath} def

% Change the position, and spurious lines may move!!!
-50 20 translate
1 1 translate

1 setlinewidth
0.5 setgray
/y {100} def
newpath 100 y M 100 0 V 0 100 V -100 0 V closepath fill
newpath 200 y M 100 0 V 0 100 V -100 0 V closepath fill
newpath 300 y M 100 0 V 0 100 V -100 0 V closepath fill
newpath 400 y M 100 0 V 0 100 V -100 0 V closepath fill
newpath 500 y M 100 0 V 0 100 V -100 0 V closepath fill

/y {300} def
newpath 100 y M 100 0 V 0 100 V -100 0 V 0 -100 V closepath fill
newpath 200 y M 100 0 V 0 100 V -100 0 V 0 -100 V closepath fill
newpath 300 y M 100 0 V 0 100 V -100 0 V 0 -100 V closepath fill
newpath 400 y M 100 0 V 0 100 V -100 0 V 0 -100 V closepath fill
newpath 500 y M 100 0 V 0 100 V -100 0 V 0 -100 V closepath fill

showpage


You can change the resolution "-r50" and see how the spurious lines are 
moving.

a=demo2.ps

A="-dGraphicsAlphaBits=4"

D=png16m
#D=png256

gs -q -r50 $A -sDEVICE=$D \
         -dSAFER -dNOPAUSE -dBATCH -sOutputFile=$a.png $a -quit
gqview $a.png


Questions to postscript gurus:
1. Is it a gs bug?
2. Can gnuplot overcome it? (Ignore antialiasing, ...)

---
PM

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

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

> So, the combination of `set palette defined` _and_ special-case treatment of 
> postscript causes anti-aliasing problems.

I did some tests and this proposed patch:

-"/f {rlineto fill} bind def\n",
+"/f {rlineto gsave stroke grestore fill} bind def\n",

-"/h {rlineto rlineto rlineto gsave fill grestore} bind def\n",
+"/h {rlineto rlineto rlineto gsave stroke grestore gsave fill grestore} bind def\n",

does not fix it. Try:

set pm3d map
set samples 200,200
set isosamples 100,100
splot x

set term post color; set out 'a.ps'
replot
set term pop; set out

and then you see spurious lines also with "set palette gray" or whichever 
palette you want.

Actually, it does not depend on the palette at all!!!
Put this below the current definition of /g:

/g { pop 0.5 setgray } bind def

=> you see a sputious network of lines again.


Further try this shell script to convert the postscript file to png or pdf:

a=a.ps

#A="-dTextAlphaBits=4 -dGraphicsAlphaBits=4"
#A="-dTextAlphaBits=4"
A="-dGraphicsAlphaBits=4"

# Choose either of two:
D=png16m
#D=png256

gs -q -r50 $A -sDEVICE=$D \
 	-dSAFER -dNOPAUSE -dBATCH -sOutputFile=$a.png $a -quit

ps2pdf $A $a $a.pdf

gqview $a.png


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

So, the question is what's the simplest postscript file showing this 
behaviour? See next mail...

---
PM

Re: [ gnuplot-Patches-1191202 ] Fix multiplot problem with epslatex terminal

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

On Wednesday 20 July 2005 01:13 am, Petr Mikulik wrote:
> > new options.  In recent posts you have expressed great
> > concern about code bloat and the resulting size of the gnuplot
> > binary.  Since every new terminal API call introduces a function
> > pointer slot into ~50 driver entry tables, I would have thought you
> > to oppose proliferation of new terminal API functions. And to
> 
> I would also prefer to reduce the terminal API bloat by having more generic 
> APIs.

Oh dear.  I do not see a consensus emerging ;-(

 
> Example: I want to add one more to  avoid codes like 'if (term->name=="pm")

That's a bad example, because it only occurs in code segments that are
already conditional on OS2.  Making it a terminal entry test instead would
not actually simplify the call sites.  I.e. it would still have to be
#ifdef OS2
   ... other OS2-specific code ...
   if (term->whatever)
      (term->whatever)(foo);
#endif


> >
> > /* Used by post.trm to optimize the color box (called from color.c)
> >  * Could be generalized to draw arbitrary rectangles with gradient
> >  * fill.
> >  */
> > term->gradient_fill(int xl, int xh, int yl, int yh, struct gradient *g)
> 
> I don't think that's necessary. Only those few pieces needing this can use 
> "if (terminal is postscript) ..." as it is now.

Wait. Isn't that exactly the opposite of what you were arguing above
with respect to "if (terminal is pm)" ?

Anyhow, if you think it is useful to optimize a gradient-filled
rectangle, why limit it to postscript?  libgd and (I think) svg also
could support this.



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

Re: Mouse in x11 interactive terminal

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

>> and do it also when driven via pipe (OS/2, Windows, ...). The only exception
>> is the X11 terminal when gnuplot runs in pipe.
>
> Are there any mousable terminals other than those three?

ggi (I never tried)

I wonder that Aqua does not have mousing capability.

>> I propose to switch on mouse also for this combination.
>> That would make many people happy and gnuplot behaviour compatible.
>
> I do not know the history of this choice, but changing to a default of
> "on" would be OK by me.

Let's do it. Would it be sufficient to remove "mouse_setting.on || " from 
below or something more is necessary?

#define X11_ALLOW_EVENTS (mouse_setting.on || isatty_state)

---
PM

Re: (s)plot 1/0 does not work

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

>> I've just noticed that
>>  	plot 1/0
>>  	splot 1/0
>> does not work:
>>
>> gnuplot> plot 1/0
>>                ^
>>           invalid expression
>>
>> gnuplot>
>>
>> (Thus e.g. "test palette" does not work.)
>>
>> Someone knows what's the problem?
>
> Yes.  I fear that's my fault.  An expression not containing dummy
> variables is evaluated to test for a string.  The attached patch
> fixes the behaviour.

Thanks, I'put it to cvs.

---
PM

Re: (s)plot 1/0 does not work

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

> I've just noticed that
>  	plot 1/0
>  	splot 1/0
> does not work:
>
> gnuplot> plot 1/0
>                ^
>           invalid expression
>
> gnuplot>
>
> (Thus e.g. "test palette" does not work.)
>
> Someone knows what's the problem?

Yes.  I fear that's my fault.  An expression not containing dummy
variables is evaluated to test for a string.  The attached patch
fixes the behaviour.


Juergen

Re: [ gnuplot-Patches-1191202 ] Fix multiplot problem with epslatex terminal

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

> >/* Used by post.trm to optimize the color box (called from color.c)
> > * Could be generalized to draw arbitrary rectangles with gradient
> > * fill.
> > */
> >term->gradient_fill(int xl, int xh, int yl, int yh, struct gradient *g=
)

> I don't think that's necessary. Only those few pieces needing this can =
use=20
> "if (terminal is postscript) ..." as it is now.

    I think that such entry would be very usefull for quite a lot of
terminals.

--
    Ga=EBl

Re: [ gnuplot-Patches-1191202 ] Fix multiplot problem with epslatex terminal

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

> new options.  In recent posts you have expressed great
> concern about code bloat and the resulting size of the gnuplot
> binary.  Since every new terminal API call introduces a function
> pointer slot into ~50 driver entry tables, I would have thought you
> to oppose proliferation of new terminal API functions. And to

I would also prefer to reduce the terminal API bloat by having more generic 
APIs.

Example: there are currently 4 APIs for USE_MOUSE. I want to add one more to 
avoid codes like 'if (term->name=="pm") ...' -- but I would have to edit all 
PM3D supporting *.trm because #ifdef PM3D follows #ifdef USE_MOUSE there. I 
think I will rather let set_ruler, set_cursor and set_something_new 
coalesce.

> But if that's the way you prefer to go, then I see an argument for
> at least three new API calls to cover existing use:
>
> /* This is the one that triggered the discussion.
>  * Used by epslatex for front/back text.
>  * Might be used by other terminal types if it were available
>  */
> term->layer(int layer);

OK

> /* Used by postscript to flag code sections for postprocessing by awk.
>  * Also requested multiple times as an enhancement for storing plot
>  * info (scaling, axis origin) in bitmap output formats
>  */
> term->comment(TBOOLEAN global_or_inline, const char *comment_text)
>
> /* Used by post.trm to optimize the color box (called from color.c)
>  * Could be generalized to draw arbitrary rectangles with gradient
>  * fill.
>  */
> term->gradient_fill(int xl, int xh, int yl, int yh, struct gradient *g)

I don't think that's necessary. Only those few pieces needing this can use 
"if (terminal is postscript) ..." as it is now.

> Yes, exactly.  That is functionally how the current code in color.c
> works, but the routines are not wrapped as terminal entry calls.
> It has a generic default routine for any terminal that supports
> pm3d filled rectangles:
>    draw_inside_color_smooth_box_bitmap()
> and a special case for the postscript driver:
>    draw_inside_color_smooth_box_postscript()

yes, that's it

---
PM

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

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

>> It has a generic default routine for any terminal that supports
>> pm3d filled rectangles:
>>    draw_inside_color_smooth_box_bitmap()
>> and a special case for the postscript driver:
>>    draw_inside_color_smooth_box_postscript()
>> 
>> How much optimization is it worth just to draw the colorbox?

It is worth it, and thus I did so in the very beginning. The postscript code 
has just few lines, while "set palette maxcolor 512" would produce 512+few 
more lines.

---
PM

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

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

> Yes, exactly.  That is functionally how the current code in color.c
> works, but the routines are not wrapped as terminal entry calls.
> It has a generic default routine for any terminal that supports
> pm3d filled rectangles:
>    draw_inside_color_smooth_box_bitmap()
> and a special case for the postscript driver:
>    draw_inside_color_smooth_box_postscript()
>
> As it happens, we have a bug report outstanding that the colorbox
> produced by this postscript special case code does not display
> properly in recent ghostscript/ghostview versions. So another
> option is to get rid of it altogether, assuming the generic routine
> doesn't suffer the same problem.  How much optimization is it worth
> just to draw the colorbox?

That's not bug of recent versions, but the old bug in pm3d postscript 
code visible when switching on aliasing in postscript. I though it was 
fixed, but it does not seem so. The point was that "fill" draws only inside 
of the area, not the path itself.

Solution: add stroke into /f and /h:


--- post-orig.trm       2005-07-20 09:23:00.000000000 +0200
+++ post.trm    2005-07-20 09:40:59.083990556 +0200
@@ -258,7 +258,7 @@
  "/V {rlineto} bind def\n",
  "/N {newpath moveto} bind def\n",
  "/C {setrgbcolor} bind def\n",
-"/f {rlineto fill} bind def\n",
+"/f {rlineto gsave stroke grestore fill} bind def\n",
  "/vpt2 vpt 2 mul def\n",
  "/hpt2 hpt 2 mul def\n",
  /* flush left show */
@@ -619,7 +619,7 @@
  "/PolyFill {gsave Density  fill grestore grestore} def\n",

  /* Special short form for the common case of a solid quadrangle */
-"/h {rlineto rlineto rlineto gsave fill grestore} bind def\n",
+"/h {rlineto rlineto rlineto gsave stroke grestore gsave fill grestore} 
bind def\n",

  "%\n",
  "% PostScript Level 1 Pattern Fill routine for rectangles\n",


I've just tested it and it works. I think I can put it into cvs?

---
PM

(s)plot 1/0 does not work

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

I've just noticed that
 	plot 1/0
 	splot 1/0
does not work:

gnuplot> plot 1/0
               ^
          invalid expression

gnuplot>

(Thus e.g. "test palette" does not work.)

Someone knows what's the problem?

---
PM

Re: [ gnuplot-Patches-1191202 ] Fix multiplot problem with epslatex terminal

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

Ethan Merritt wrote:
>Comment By: Hans-Bernhard Broeker (broeker)

>>The idea of a multi-function term->private is flawed, IMHO.
>>Even the name is, to some extent.  I had reasons to suggest
>>calling the one being invented here term->startlayer() instead.

> That is essentially what I proposed originally, and I understood
> you to be opposed to it at that time.

The problem I wanted to comment on here was that term->private() would 
be a good deal worse than term->layer().

>>A new API entry like the above would, effectively, specialize the
>>interface to gnuplot as the client, and kill all remaining hopes of one
>>day splitting up the program into well-separated layers of functionality.

Well, API design is tricky.  You have to make sure that the API is 
expressive enough to support all that needs to be done without such ugly 
hucks as are currently used, but still simple and well-defined enough 
that it can actually be used with some confidence.  A multi-function 
term->private() would violate all these ideas almost maximally.

> binary.  Since every new terminal API call introduces a function
> pointer slot into ~50 driver entry tables, I would have thought you
> to oppose proliferation of new terminal API functions. 

I do indeed oppose proliferation (it works against the "simple" 
criterion).  But that doesn't mean I want to oppose any and all extensions.

The strategy should be: _think_ before adding a new terminal entry: is 
this really something for the terminal driver to handle? And: what 
should the core do if this function is not implemented?  OTOH, a new 
terminal entry is always better than terminal-dependent code having to 
smuggled into the core.

> But if that's the way you prefer to go, then I see an argument for
> at least three new API calls to cover existing use:
>  term->layer(int layer);
>  term->comment(TBOOLEAN global_or_inline, const char *comment_text)
>  term->gradient_fill(int xl, int xh, int yl, int yh, struct gradient *g)

I'm not sure about comment(), but the other two would make sense, I think.

But I'm unconvinced that "begin next plot in a multiplot" is a signal 
that should be sent through a function called term->layer().  Layering 
is supposed to be about drawing order (front vs. back), whereas 
multiplot is about grouping.

Re: [ gnuplot-Patches-1191202 ] Fix multiplot problem with epslatex terminal

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

> >Comment By: Hans-Bernhard Broeker (broeker)
> Date: 2005-07-19 14:04
> 
> The idea of a multi-function term->private is flawed, IMHO.
>  Even the name is, to some extent.  I had reasons to suggest
> calling the one being invented here term->startlayer() instead.

That is essentially what I proposed originally, and I understood
you to be opposed to it at that time.
Here is your earlier response:
 
On Thu, 10 Mar 2005 
Hans-Bernhard Broeker <br...@ph...> wrote
> Ethan Merritt wrote:
>
> > How about a terminal entry point (*term->layer)((int) layernumber) 
> > that the core code would call at each stage of the plot process, once
> > per layer?

> What I'm a little bit worried about is, as always, the conceptual
> clarity of our terminal layer API.  So far, the terminal API is,
> essentially, just a rather generic vector drawing API --- all the way to
> the old "gnuplot library" which exported this API for generic usage.
> A new API entry like the above would, effectively, specialize the
> interface to gnuplot as the client, and kill all remaining hopes of one
> day splitting up the program into well-separated layers of functionality.

So now I am rather confused as to your actual preference.

> Trying to cram all "terminal-specific somethings" into a
> single function is not API design --- that's outright
> refusal to actually _do_ some interface design.  If some
> terminals may conceivably have their own special way of
> handling a particular job, then the gnuplot way to tell the
> core about that is by exporting a non-NULL terminal API
> entry.  

Here again I would appreciate it if you could clarify your
thoughts on the tradeoffs that inevitably arise when introducing
new options.  In recent posts you have expressed great
concern about code bloat and the resulting size of the gnuplot
binary.  Since every new terminal API call introduces a function
pointer slot into ~50 driver entry tables, I would have thought you
to oppose proliferation of new terminal API functions. And to
mitigate this by conditionally coding each one would require a massive
pass over all terminal drivers to include the appropriate conditional
code blocks in the terminal entry table.

But if that's the way you prefer to go, then I see an argument for
at least three new API calls to cover existing use:

 /* This is the one that triggered the discussion.
  * Used by epslatex for front/back text.
  * Might be used by other terminal types if it were available
  */
 term->layer(int layer);

 /* Used by postscript to flag code sections for postprocessing by awk.
  * Also requested multiple times as an enhancement for storing plot
  * info (scaling, axis origin) in bitmap output formats
  */ 
 term->comment(TBOOLEAN global_or_inline, const char *comment_text)

 /* Used by post.trm to optimize the color box (called from color.c)
  * Could be generalized to draw arbitrary rectangles with gradient
  * fill.
  */
 term->gradient_fill(int xl, int xh, int yl, int yh, struct gradient *g)

> The only remaining question then is whether the 
> default, non-special version of that function then becomes a
> default terminal API handler (like do_arrow() or do_point()
> in term.c), or the core code gets to look like
> 
>    if (term->do_special_job_x)
>      term->do_special_job_x(parameters);
>   else
>      default_handler_for_job_x(parameters);


Yes, exactly.  That is functionally how the current code in color.c
works, but the routines are not wrapped as terminal entry calls.
It has a generic default routine for any terminal that supports
pm3d filled rectangles: 
    draw_inside_color_smooth_box_bitmap()
and a special case for the postscript driver:
    draw_inside_color_smooth_box_postscript()

As it happens, we have a bug report outstanding that the colorbox
produced by this postscript special case code does not display 
properly in recent ghostscript/ghostview versions. So another
option is to get rid of it altogether, assuming the generic routine
doesn't suffer the same problem.  How much optimization is it worth
just to draw the colorbox?


		Ethan


> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2005-07-19 02:15
> 
> Message:
> Logged In: YES 
> user_id=235620
> 
> I think you are kind of missing the point of this new
> mechanism.  Your change to color.c still leaves
> PostScript-specific code there; it just changes the output
> command from "sprintf(..." to "term->private(...".   That is
> not an improvement IMHO.  The way to do this correctly would
> be something like:
> 
>     if (term->private)
>         (term->private)(TERM_PRIVATE_DRAW_COLORBOX);
>     else
>         draw_inside_color_smooth_box_bitmap()
> 
> And then move the original special case PostScript routine
> draw_inside_color_smooth_box_postscript entirely into the
> postscript driver.
> 
> However,  this doesn't work yet for a couple of reasons.
> 
> (1) In this particular case we really need to know more than
> the fact that the current terminal supports *some*
> term->private operation; we need to know that it
> specifically supports this one.  So I think we need to
> modify term->private to return success or failure.
> 
> (2) In this particular case we actually need to pass 4
> parameters (cb_x_from cb_x_to cb_y_from cb_y_to).  This
> points up the possibility that term->private should take a
> generic pointer-to-structure as a 2nd parameter rather than
> the (const char *) in my version.  I have a feeling that
> would be a headache to get past all the compilers we have to
> deal with, but it is almost certainly more portable than
> your suggestion to use va_dcl and varargs.
> 
> So I welcome your help in polishing this further, but I
> think we have some more work before the code in color.c can
> be handled cleanly.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Harald Harders (harders)
> Date: 2005-07-19 01:41
> 
> Message:
> Logged In: YES 
> user_id=207272
> 
> Your patch is a good improvement. But it still has
> postscript-specific code in color.c which also could be
> avoided. Have a look at the new version. 
> - It makes term->private even more universal by adding
> variable parameter lists.
> - gppsfile is removed from term_api.h since it is only used
> in term.c, now.
> 
> Please have a look at the source code where I have written
> "HH: Comment by Harald Harders" (term.c and post.trm). The
> return value of the function PS_RememberFont is lost since
> the pointer points to a local variable. If the contents is
> still there it is by accident.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2005-07-18 21:07
> 
> Message:
> Logged In: YES 
> user_id=235620
> 
> I think I will let the dust settle a bit more before
> applying this, but have a look at this revised version that
> deals with the postscript-specific code in pm3d as well.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Harald Harders (harders)
> Date: 2005-07-15 20:44
> 
> Message:
> Logged In: YES 
> user_id=207272
> 
> Ethan's patch works fine. I have applied some modifications:
> - The 'test' command did not use the LaTeX \gplbacktext
> command. This has been added.
> - term/README missed a description of the (*private)
> function. Fixed.
> - The constants TERM_PRIVATE_0 etc. weren't too descriptive.
> They may likely leed to confusion within short time. I have
> renamed them so that they are called what they do. If
> another terminal will need similar things it just can use
> the same constants. If new functionality will be needed,
> another constant may be added.
> - The function EPSLATEX_private used an int as parameter. I
> have changed it to t_termprivate which it was before, too.
> 
> In my opinion, this patch can go to CVS.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Harald Harders (harders)
> Date: 2005-07-14 09:39
> 
> Message:
> Logged In: YES 
> user_id=207272
> 
> At a first glance, the new patch looks good. I have not yet
> been able to test it. The 'private' function should be
> mentioned in term/README.
> 
> By the way: 'if (term->name == "epslatex")' was caused by
> programming C++ the whole day. ;-) Of course it's nonsense in C.
> 
> I also think that providing <terminal>_put_text() the
> information if text is front or back could be a good
> approach to avoid any terminal-specific code in graphics.c.
> But it appears to be a large change in the code.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2005-07-14 07:27
> 
> Message:
> Logged In: YES 
> user_id=235620
> 
> I have reverted the non-working code in cvs and regenerated
> a cleaned-up version of the previous patch. This should make
> it much more obvious what is being added, and where.  I've
> renamed the terminal API function from "sync" to "private".
>  Is that better?  I really don't care much what it's called.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Hans-Bernhard Broeker (broeker)
> Date: 2005-07-13 18:41
> 
> Message:
> Logged In: YES 
> user_id=27517
> 
> While I'm not particularly fond of calling it "sync", I find
> Ethan's patch much more easily agreeable than the previous
> ones.   I think it should go in like that, possibly renamed
> to "start_layer" or similar (layer stopping shouldn't be
> needed --- it's implicit in closing the plot via
> term->text() or a change to some other layer).
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2005-07-13 07:47
> 
> Message:
> Logged In: YES 
> user_id=235620
> 
> Neither the code currently in cvs nor the code in this patch
> actually *does* anything, because the test condition
>    if (term->name == "epslatex")
> is totally bogus.  Given that no-one has even noticed this
> non-functionality, I'm still not convinced that the whole
> idea is worth trampling on the core/terminal code layering.
> 
> Nevertheless, if you really want to pursue it, please have a
> look at the patch I have just uploaded.  It implements a new
> terminal API call as discussed previously on the mailing
> list.  I'm not thrilled about this API, since it's used only
> by epslatex, but at least it keeps the code in the core
> routines perfectly generic.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Harald Harders (harders)
> Date: 2005-05-29 20:01
> 
> Message:
> Logged In: YES 
> user_id=207272
> 
> I agree that terminal-specific code should be avoided in
> graph*.c. But in my opinion, this patch already is an
> improvement because it avoids the usage of terminal specific
> variables in these files. With this patch, gnuplot can be
> compiled without using post.trm.
> 
> If the routines <terminal>_put_text() knew if the printed
> text is 'back' of 'front' it would be easy to remove all
> terminal-specific code from graphics.c and graph3d.c. But at
> the moment, this is not the case.
> 
> Does anybody have an idea how to remove all
> terminal-specific code from non-terminal-specific files? By
> the way: pm3d.c also contains terminal-specific code (all
> lines containing the variable gppsfile).
> 
> ----------------------------------------------------------------------
> 
> Comment By: Ethan Merritt (sfeam)
> Date: 2005-05-17 18:04
> 
> Message:
> Logged In: YES 
> user_id=235620
> 
> I would still much rather see a fix that removed all
> epslatex-specific code from graphics.c and graph3d.c.  This
> patch would introduce yet more terminal-specific code, IMHO
> making things worse rather than better.
> 
> ----------------------------------------------------------------------
> 
> Comment By: Petr Mikulik (mikulik)
> Date: 2005-05-17 17:28
> 
> Message:
> Logged In: YES 
> user_id=31505
> 
> This patch applies OK, can it go to cvs now? 
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=302055&aid=1191202&group_id=2055
> 

-- 
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 Monday 18 July 2005 05:31 am, Petr Mikulik wrote:
> By default, all mouseable interactive terminals switch on mouse by default, 
> and do it also when driven via pipe (OS/2, Windows, ...). The only exception 
> is the X11 terminal when gnuplot runs in pipe.

Are there any mousable terminals other than those three?

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

I do not know the history of this choice, but changing to a default of
"on" would be OK by me.
	

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

Re: mouse in gnuplot

[Dmitri A. S. <das...@gm...>]

Theo Hopman wrote:
>
> 
> My confusion arises from the fact that in the examples you give, mousing 
> is not expected to work. Note that when I say "mousing", I refer to the 

May be in the first example (with -persist -- I misunderstood what this does).
In the second example:

gnuplot < fifo1
cat > fifo1

mousing works to full extend on linux (grid, logscale, help, zooming)...

None of those works on Mac OS X.

> THeo
> 

Regards,

Dmitri.
-- 

Re: CVS doesn't build epslatex terminal

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

On Saturday 16 July 2005 11:29 pm, Birger Brunswiek wrote:
> Hello List,
> I just downloaded the latest CVS and noticed that it does not compile
> with the epslatex terminal.

It should be fixed now.
The choice of post.trm pslatex.trm (and estimate.trm) is now controlled
at the top of term.h

tested with	-post
		+post -pslatex
		+post +pslatex


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

Re: mouse in gnuplot

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

Dmitri A. Sergatskov wrote:
> I guess I confused everyone with my first post. The issue I am trying to 
> solve is
> that I cannot get mouse to work in octave (which uses gnuplot as a plotting
> back end) on MacOSX (Tiger, kernel 8.2.0 <-- this might be important, since
> people with 8.1.0 does not seem to have this problem).
> So, I reduced the problem to a simple case of gnuplot being controlled 
> via pipe.
> On linux/x86 and on linux/ppc (FC4 in both cases) this works the same way
> as if gnuplot run "normally" (except that I have to set mouse explicitly).
> In MacOS X I cannot get mouse to work at all when gnuplot is controlled 
> through
> a pipe.

My confusion arises from the fact that in the examples you give, mousing 
is not expected to work. Note that when I say "mousing", I refer to the 
the full functionality described by the help given when 'h' is pressed 
in the gnuplot_x11 window. This includes zooming, labelling, and 
toggling of logarithmic axes and of grids. The display of the 
coordinates of the mouse cursor is generated by gnuplot_x11 itself, and 
does not require that gnuplot be running.

THeo

Re: mouse in gnuplot

[Dmitri A. S. <das...@gm...>]

Theo Hopman wrote:

>> This works as expected on linux/x86, linux/ppc and is not working on 
>> MacOSX/X11... (Tiger 10.4, kernel 8.2.0)

> 
> I'm not sure what behaviour you're expecting, but for me this gives 
> exactly the same results as with an unnamed pipe: there is a coordinate 
> display, but zooming and the like are not available. I did
> 
....

> 
> THeo
> 
> (BTW: System is Fedora Core 3)
> 

I guess I confused everyone with my first post. The issue I am trying to solve is
that I cannot get mouse to work in octave (which uses gnuplot as a plotting
back end) on MacOSX (Tiger, kernel 8.2.0 <-- this might be important, since
people with 8.1.0 does not seem to have this problem).
So, I reduced the problem to a simple case of gnuplot being controlled via pipe.
On linux/x86 and on linux/ppc (FC4 in both cases) this works the same way
as if gnuplot run "normally" (except that I have to set mouse explicitly).
In MacOS X I cannot get mouse to work at all when gnuplot is controlled through
a pipe.

I am not  really a Mac OS X expert, so any advice would be appreciated.
In particular, I would like to hear from anyone who has a similar setup
and who can or cannot reproduce the problem.

I also open to suggestion on what kind of testing and debugging I can do.

Sincerely,

Dmitri.
-- 

Re: mouse in gnuplot

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

Dmitri A. Sergatskov wrote:
> Theo Hopman wrote:
>> This is exactly the expected behaviour. gnuplot sees end of input from 
>> the pipe and quits. The x11 helper program gnuplot_x11 keeps running, 
>> as requested by -persist, but has nowhere to send the mouse events 
>> since gnuplot has finished. Hence, no mousing.
> 
> OK, here is a better test (courtesy of John Eaton):
> 
> mkfifo fifo1
> then in one xterm:
> 
> gnuplot < fifo1
> 
> in another xterm:
> 
> cat > fifo1
> set mouse
> plot sin(x)
> ...
> 
> This works as expected on linux/x86, linux/ppc and is not working on 
> MacOSX/X11... (Tiger 10.4, kernel 8.2.0)

I'm not sure what behaviour you're expecting, but for me this gives 
exactly the same results as with an unnamed pipe: there is a coordinate 
display, but zooming and the like are not available. I did

mkfifo fifo1
gnuplot -persist < fifo1 &
ps -u $USER
cat << EOC > fifo1
set mouse
plot sin(x)
EOC
ps -u $USER # note gnuplot is done but gnuplot_x11 is still running.

Once again, gnuplot sees an end-of-input on the named pipe, and quits. 
To prevent this, you need shell trickery like the following:

gnuplot <fifo1 3>fifo1 &

File descriptor 3 of gnuplot is redirected to the named pipe. As long as 
gnuplot is running (and doesn't close file descriptor 3), it won't 
encounter an end-of-input on the named pipe, and won't quit. Since 
gnuplot is still running, mousing works. Do `echo "quit" > fifo1` or the 
like to make gnuplot quit.

THeo

(BTW: System is Fedora Core 3)

Re: Advice in C code

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

Ga=EBl Varoquaux wrote:
>     Is the syntax :
>=20
>     current_color =3D (rgb_color){0, 0, 0};
>=20
>     Standard and portable.=20

Yes and no.  It's a GCC extension (--> see

	info gcc "C Extensions" compound

) that was adopted into C99. C99 is formally "the standard" since its
ratification, but it's an almost purely hypothetical thing in praxis.

 > It compiles with gcc 3.3.5 but I do not know
> if it is standard C.

It's not.  You'll notice if you tell GCC to disable extensions (-ansi=20
-pedantic, plus some -D flags to re-enable usual functionality of the C=20
library).

Re: mouse in gnuplot

[Dmitri A. S. <das...@gm...>]

Theo Hopman wrote:
> Dmitri A. Sergatskov wrote:
> 
>> Any idea why zooming with mouse does not work if I do:
>>
>> echo "set mouse; plot sin(x)"  | gnuplot -persist
>>
>> ?
>> (on linux/x86 - FC4 and FC3)
>>
>> The problem came about when I was trying to figure out why zooming
>> with mouse does not work on octave on MacOSX (with X11 term).
>> There is no problem with that on linux/x86 though...
>>
>> I tried both gnuplot-4 and a recent cvs snapshot.
> 
> 
> This is exactly the expected behaviour. gnuplot sees end of input from 
> the pipe and quits. The x11 helper program gnuplot_x11 keeps running, as 
> requested by -persist, but has nowhere to send the mouse events since 
> gnuplot has finished. Hence, no mousing.

OK, here is a better test (courtesy of John Eaton):

mkfifo fifo1
then in one xterm:

gnuplot < fifo1

in another xterm:

cat > fifo1
set mouse
plot sin(x)
...

This works as expected on linux/x86, linux/ppc and is not working on MacOSX/X11...
(Tiger 10.4, kernel 8.2.0)

(BTW, the line in FAQ that one needs to set mouse in .octaverc is probably not
the best advice. I think it is better to set it in .gnuplot, this way if
gnuplot restarted in the middle of the octave session it still gets
mouse support.)

> THeo

Dmitri.
-- 

Re: epslatex, pslatex, and pstex terminals do not exist anymore

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

On Sat, 16 Jul 2005, Harald Harders wrote:

> On Sat, 16 Jul 2005, Harald Harders wrote:
> 
> > Since yesterday's change concerning reorganisation of the
> > POSTSCRIPT_DRIVER conditionals, the terminals pslatex, pstex, and epslatex
> > do not exist anymore. The postscript terminal still works.
> >
> > Could please somebody fix this problem?
> > This patch should help:
> 
> Unfortunately, this patch does not work either. Hans-Bernhard, have you
> tested the change at all? 

Yes, but with a different objective in mind.  The trigger for the change 
was that it was impossible to build gnuplot without the postscript driver,
and tricky to avoid including the pslatex driver along with that.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: mouse in gnuplot

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

Dmitri A. Sergatskov wrote:
> Any idea why zooming with mouse does not work if I do:
> 
> echo "set mouse; plot sin(x)"  | gnuplot -persist
> 
> ?
> (on linux/x86 - FC4 and FC3)
> 
> The problem came about when I was trying to figure out why zooming
> with mouse does not work on octave on MacOSX (with X11 term).
> There is no problem with that on linux/x86 though...
> 
> I tried both gnuplot-4 and a recent cvs snapshot.

This is exactly the expected behaviour. gnuplot sees end of input from 
the pipe and quits. The x11 helper program gnuplot_x11 keeps running, as 
requested by -persist, but has nowhere to send the mouse events since 
gnuplot has finished. Hence, no mousing.

Note that you get the shell command line immediately after running the 
above command, despite not putting gnuplot in the background, indicating 
that gnuplot has finished. To verify, use ps or top.

THeo