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

color loop for gd.trm

[Shigeharu T. <sh...@ie...>]

shige 10/07 2005
----------------

The following patch do use small number of colors in gd.trm. This
enables to set simply the same colors as in x11 term by:

  set term png colorloop xffffff x000000 x404040 \
  xff0000 x00ff00 x0000ff xff00ff x00ffff xa0522d xffa500 xff7f50

or as in win term by:

  set term gif colorloop xffffff x000000 x404040 \
  xff0000 x00ff00 x0000ff xff00ff x000080 \
  x800000 x008080 x000000 x808080 x008040 \
  x808000 x800080 xc0c0c0 x00ffff xffff00

Although png term use 256 colors even if the number of colors was 
given explicitly, the colorloop option tells gnuplot to use only 
specified colors.

----- From here -----
--- gd.trm.ORG	Sat Sep 24 15:42:05 2005
+++ gd.trm	Fri Oct  7 20:48:34 2005
@@ -101,6 +101,8 @@
  *                          added support for line width and TrueType fonts
  */
 
+#define COLORLOOP
+
 #include "driver.h"
 
 #ifdef TERM_REGISTER
@@ -221,6 +223,9 @@
     PNG_TRUECOLOR, PNG_NOTRUECOLOR,
     PNG_LINEWIDTH,
     GIF_ANIMATE, GIF_DELAY, GIF_LOOP, GIF_NOOPT,
+#ifdef COLORLOOP
+    PNG_COLORLOOP,
+#endif
     PNG_OTHER
 };
 
@@ -233,6 +238,9 @@
 static int PNG_YMAX = GREG_YMAX;
 static const int PNG_POINT_SCALE = 3;
 static int PNG_ps = 3;
+#ifdef COLORLOOP
+static int PNG_color_loop = FALSE;
+#endif
 
 static struct gen_table PNG_opts[] =
 {
@@ -259,6 +267,9 @@
     { "loop", GIF_LOOP },
     { "noopt$imize", GIF_NOOPT }, /* end of gif animation options */
     { "lw", PNG_LINEWIDTH },
+#ifdef COLORLOOP
+    { "colorloop", PNG_COLORLOOP },
+#endif
     { NULL, PNG_OTHER }
 };
 
@@ -694,6 +705,12 @@
 	    png_state.frame_optimization = FALSE;
 	    gif_anim_option = 1;
 	    break;
+#ifdef COLORLOOP
+	case PNG_COLORLOOP:
+	    PNG_color_loop = TRUE;
+	    c_token++;
+	    break;
+#endif
 
 	case PNG_OTHER:
 	default:
@@ -839,6 +856,9 @@
 
     sprintf(term_options + strlen(term_options),
 	    "size %d,%d ", PNG_XMAX, PNG_YMAX);
+#ifdef COLORLOOP
+    if(PNG_color_loop) strcat(term_options,"color_loop ");
+#endif
 
     for (i = 0; strlen(term_options) + 9 < MAX_LINE_LEN &&
            i < png_state.n_colors; i++) {
@@ -1156,8 +1176,13 @@
 	    (web_color_rgbs[i].r << 16) |
 	    (web_color_rgbs[i].g << 8) |
 	    web_color_rgbs[i].b;
+#ifdef COLORLOOP
+    if (PNG_color_loop == FALSE && png_state.n_colors < WEB_N_COLORS)
+	png_state.n_colors = WEB_N_COLORS;
+#else
     if (png_state.n_colors < WEB_N_COLORS)
 	png_state.n_colors = WEB_N_COLORS;
+#endif
     for (i = 0; i < png_state.n_colors; i++) {
 	rgb = png_state.rgb_table[i];
 	png_state.color_table[i] =
----- To here ------

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: bug in terminals affected by 'set size'

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

> I should also point out that the existing PostScript and eps output
> offers a possible easy fix to at least part of this dilemma if you
> are willing to use an editor.  The following line appears near the
> very top of the output file:
> /gnulinewidth 5.000 def
>
> If you are planning to scale up your plot by a factor of 2 and
> don't want the line widths to became twice as thick, you can replace
> that with
> /gnulinewidth 2.500 def

I've just noticed there is also /userlinewidth, but it does not change 
anything? Isn't this a bug?

Another strange thing: I've put two plots (two pages) into postscript file. 
There is
 	/gnulinewidth 5.000 def
in the header.

Now, I wanted to increase the linewidth 5 times on the 2nd page by this 
change:

grestore
end
showpage
%%Page: 2 2
gnudict begin
gsave
/gnulinewidth 25.000 def
50 50 translate
0.100 0.100 scale

However, it changed also the line width on the first page! Why?! ... or is 
it a bug in ghostscript? When it draws it 1st time, then it is ok, but when 
you go back from the 2nd to the 1st page (gv, gsview), the linewidth gets 
wrong. That's probably the value of the variable was overwritten in the 
dictionary?

Question: how to organize different linewidths on different pages, or rather 
in different subplots?

> We could, I think, do exactly the same with font sizes by introducing
> a global multiplier in the header
> /gnufontsize 1.000 def

This would be useful.

---
PM

Re: bug in terminals affected by 'set size'

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

> One difficult thing is a0 posters: it is not possible to make big enough
> eps images with Gnuplot to be included into an a0 poster.  Of course,
> there is a workaround; one just plots everything in smaller scale in
> Gunplot (a4 vs a0), and scales the result back into a0.  However, the
> calculations with font sizes and linewidths are something that a user
> shouldn't need to do.

Using scalable fonts, it is feasible using "set termoptions font ..." <= 
it's only here you give the font scale. Now, we miss "set termoptions 
linewidth x" to scale in the same way.

> Origin (a windows GUI driven plotting program), because it seems not to
> have such limitation.

I would combine several eps plots together using Xfig, or LaTeX.

> set term post eps canvas 8cm, 5cm
> set term post canvas a0

Actually there are two possibilities what this "8cm" can mean:
   - scalable size
   - non-scalable size

I think there is some unity in the postscript definition which will keep the 
true dimension, whatever preceding "x y scale" command is. Something like
"8 25.4 mul truept" vs "8 25.4 mul pt". But I don't know the details.

---
PM

Re: CodeStyle

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

> In `CodeStyle`, section `Layout and Indentation` one tab
> per indent is recommended, with a 4 spaces equivalent to
> one tab (ts=4). (But most code seems to use ts=8 anyway.)

It does not write that "it is recommended", but "IMHO the only useful 
style", and then: "Much of the code seems to assume tab=8, and uses 4 
spaces, then one tab, then tab+4, then 2tab, ...".

I prefer the current n*8+4.

---
PM

Re: bug in terminals affected by 'set size'

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

On Thursday 06 October 2005 03:38 pm, Harald Harders wrote:
> 
> I still have the idea that there should be a terminal-independent option
> that changes the size of the canvas by a factor. I am aware that this
> would be difficult to explain because a thing like
>   set canvasscale 1.5,1.5
>   set terminal png size 640,480
> would lead to a picture of the size 960 x 720 which seams pretty
> unlogical.

That is, in fact, what "set size" + "set term png size XX,YY"
has done all along.

The fact that I didn't even know this myself until testing shows
that it is not obvious :-)


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

Re: bug in terminals affected by 'set size'

[Harald H. <h.h...@tu...>]

On Thu, 6 Oct 2005, Ethan Merritt wrote:

> On Thursday 06 October 2005 12:17 pm, Harald Harders wrote:
> >
> > [... a lot of discussion about sizes above 1 ...]
> >
> > In my opinion, there are two mutually exclusive solutions:
> >
> > 1.) 'set size' before 'set terminal' can affect the canvas size. Then,
> > sizes below and above 1 have to be valid because then 'size 1,1' means the
> > default size. Partly, this is the current state while sizes > 1 only work
> > partly.
>
> I am being educated about this use of "set size".  It's not the way I
> have been using it, but I fully understand the argument about not
> necessarily wanting to scale line widths and font sizes with the
> graph size.  So I retract my previous claim that sizes greater than 1
> are never correct.
>
> But, as you say, it only partly works now.
> For instance, setting the size to something other than 1,1 before
> setting the terminal seems to break multiplot layouts.

Do you mean the automatic ones? I always to multiplots by hand and they
also work for plots with sizes greater than 1.

> > 2.) 'set size' only affects the size of the plot within the current
> > canvas while the canvas (or bouding box or what ever) is influenced by
> > another mechanism, e.g., 'set terminal <term> size <x,y>'. Here, the
> > possible values can be different for different terminals, e.g.,
> >   set terminal postscript size 5cm,3cm
> >   set terminal postscript eps size 300pt,200pt
> >   set terminal postscript eps size 300,200 # could default to pt
> >   set terminal postscript eps size 300,200 offset 100,150
> >        # results in %%BoundingBox: 100 150 400 350
> >   set terminal gif size 300,200 # defaults to pixel
> >   set terminal gif size 1in,1in resolution 300 # = 300 x 300 pixel, 300dpi
>
> That is the way I would prefer to have it work.
> The range of reasonable canvas sizes is clearly terminal-dependent,
> so choosing a size should done in the terminal-specific initialization.
> It will mean modifying drivers, but it seems straightforward.

I agree. Sounds like a plan and a lot of work.

> Next problem:
>
> The harder task related to this is the larger issue of remedying
> the lack of line and text clipping in the core routines.
> Right now  "set size 0.1,0.1;  set term <foo>; test"
> will crash on many terminal types because the various
> lines and text on the test page are not clipped against the
> reduced canvas size.  Regular plotting is somewhat better, since
> the actual plot elements are properly clipped. But elements such
> as the key, title, and individually placed arrows or labels are
> not clipped and still prone to cause segfaults.  The pdf terminal
> is particularly sensitive to this, but all drivers that use
> the shared routines in bitmap.c suffer the same problem.
>
> The code in the current clipping routines would do the job,
> except currently it explicitly clips to the plot area, not the canvas.
> I think the way forward is to:
>
> 1) move  xright, xleft, ytop, ybot into a new structure, e.g.
>    struct {int xright; int xleft; int ytop; int ybot;} bounding_box.
>
> 2) create and maintain two global instances of such a structure;
>    one that describes the plot area, another that describes the
>    whole canvas.
>
> 3) modify the clip_line() and clip_point() to clip against whichever
>    bounding_box structure is currently active
>
> 4) Existing calls to the clipping routines will continue to
>    work as always, and clip against the plot area.
>    Any code that needs to place elements outside the plot (key, title,
>    arrows, axis lables, ...) would change the active bounding_box
>    to the entire canvas, clip, and then restore the bounding_box.
>
> At that point we would have protected all drivers against
> out-of-range vectors and moves.  Text clipping would not be
> perfect, but better than it is now.

May be we should start with this task of two different clipping boxes
(plot and canvas). Then, the rest could be done sequencially.


I still have the idea that there should be a terminal-independent option
that changes the size of the canvas by a factor. I am aware that this
would be difficult to explain because a thing like
  set canvasscale 1.5,1.5
  set terminal png size 640,480
would lead to a picture of the size 960 x 720 which seams pretty
unlogical. But in some cases such a function could be useful. For some
terminals this new function would then do the same as a 'set size' before
'set terminal' does now. But I think, this functionality could be added
after providing a clean solution for differentiation between plot size and
canvas size.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: bug in terminals affected by 'set size'

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

On Thursday 06 October 2005 02:41 pm, Petr Mikulik wrote:
> Shouldn't there be "set term post eps scale nx,ny" to scale the canvas to a 
> given size? (Gnuplot could be used for making highway billboards :-)

This is the sort of example I originally had in mind.  If you are trying to
scale up an eps figure uniformly, to highway billboard size for example,
you don't *need* a scale parameter because the eps format is inherently
scalable.  Yes, the lettering will be half a meter tall and the lines a
couple of cm thick, but that way they can be read by passing motorists.

What I have learned is that people want to change the size of the
figure *without* scaling the font size or line widths.  The current
"set size" command does this, but does not do a very consistent job of it.
 
> Further, what I miss is a "scale", mainly for an inset figure inside another 
> figure (i.e., in multiplot). It would scale the figure with all linewidth, 
> fonts etc. Or rather "fontscale"...

Are you saying that you do, or do not, want the fonts to change size if
the figure changes size?

I should also point out that the existing PostScript and eps output
offers a possible easy fix to at least part of this dilemma if you
are willing to use an editor.  The following line appears near the
very top of the output file:
 /gnulinewidth 5.000 def

If you are planning to scale up your plot by a factor of 2 and
don't want the line widths to became twice as thick, you can replace
that with
 /gnulinewidth 2.500 def


We could, I think, do exactly the same with font sizes by introducing
a global multiplier in the header
 /gnufontsize 1.000 def





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

Re: bug in terminals affected by 'set size'

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

Shouldn't there be "set term post eps scale nx,ny" to scale the canvas to a 
given size? (Gnuplot could be used for making highway billboards :-)

Further, what I miss is a "scale", mainly for an inset figure inside another 
figure (i.e., in multiplot). It would scale the figure with all linewidth, 
fonts etc. Or rather "fontscale"...

---
PM

Re: bug in terminals affected by 'set size'

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

On Thursday 06 October 2005 12:17 pm, Harald Harders wrote:
> 
> [... a lot of discussion about sizes above 1 ...]
> 
> In my opinion, there are two mutually exclusive solutions:
> 
> 1.) 'set size' before 'set terminal' can affect the canvas size. Then,
> sizes below and above 1 have to be valid because then 'size 1,1' means the
> default size. Partly, this is the current state while sizes > 1 only work
> partly.

I am being educated about this use of "set size".  It's not the way I
have been using it, but I fully understand the argument about not
necessarily wanting to scale line widths and font sizes with the 
graph size.  So I retract my previous claim that sizes greater than 1
are never correct.

But, as you say, it only partly works now.
For instance, setting the size to something other than 1,1 before
setting the terminal seems to break multiplot layouts.

 
> 2.) 'set size' only affects the size of the plot within the current
> canvas while the canvas (or bouding box or what ever) is influenced by
> another mechanism, e.g., 'set terminal <term> size <x,y>'. Here, the
> possible values can be different for different terminals, e.g.,
>   set terminal postscript size 5cm,3cm
>   set terminal postscript eps size 300pt,200pt
>   set terminal postscript eps size 300,200 # could default to pt
>   set terminal postscript eps size 300,200 offset 100,150
>        # results in %%BoundingBox: 100 150 400 350
>   set terminal gif size 300,200 # defaults to pixel
>   set terminal gif size 1in,1in resolution 300 # = 300 x 300 pixel, 300dpi

That is the way I would prefer to have it work.
The range of reasonable canvas sizes is clearly terminal-dependent, 
so choosing a size should done in the terminal-specific initialization.
It will mean modifying drivers, but it seems straightforward.


Next problem:

The harder task related to this is the larger issue of remedying
the lack of line and text clipping in the core routines.
Right now  "set size 0.1,0.1;  set term <foo>; test"
will crash on many terminal types because the various 
lines and text on the test page are not clipped against the
reduced canvas size.  Regular plotting is somewhat better, since
the actual plot elements are properly clipped. But elements such
as the key, title, and individually placed arrows or labels are
not clipped and still prone to cause segfaults.  The pdf terminal
is particularly sensitive to this, but all drivers that use
the shared routines in bitmap.c suffer the same problem.

The code in the current clipping routines would do the job,
except currently it explicitly clips to the plot area, not the canvas.
I think the way forward is to:

1) move  xright, xleft, ytop, ybot into a new structure, e.g.
   struct {int xright; int xleft; int ytop; int ybot;} bounding_box.

2) create and maintain two global instances of such a structure;
   one that describes the plot area, another that describes the
   whole canvas.

3) modify the clip_line() and clip_point() to clip against whichever
   bounding_box structure is currently active

4) Existing calls to the clipping routines will continue to
   work as always, and clip against the plot area.
   Any code that needs to place elements outside the plot (key, title,
   arrows, axis lables, ...) would change the active bounding_box
   to the entire canvas, clip, and then restore the bounding_box.

At that point we would have protected all drivers against 
out-of-range vectors and moves.  Text clipping would not be
perfect, but better than it is now.

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

Re: bug in terminals affected by 'set size'

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

On Thu, Oct 06, 2005 at 09:17:04PM +0200, Harald Harders wrote:
> 2.) 'set size' only affects the size of the plot within the current
> canvas while the canvas (or bouding box or what ever) is influenced by
> another mechanism, e.g., 'set terminal <term> size <x,y>'. Here, the
> possible values can be different for different terminals, e.g.,
>   set terminal postscript size 5cm,3cm
>   set terminal postscript eps size 300pt,200pt
>   set terminal postscript eps size 300,200 # could default to pt
>   set terminal postscript eps size 300,200 offset 100,150
>        # results in %%BoundingBox: 100 150 400 350
>   set terminal gif size 300,200 # defaults to pixel
>   set terminal gif size 1in,1in resolution 300 # =3D 300 x 300 pixel, 3=
00dpi

> For compatibility reasons, the first solution could be useful, while th=
e
> second solution is more clear and introduces a new important feature.

    I vote for 2nd solution.

--
    Ga=EBl

Re: bug in terminals affected by 'set size'

[Harald H. <h.h...@tu...>]

[... a lot of discussion about sizes above 1 ...]

In my opinion, there are two mutually exclusive solutions:

1.) 'set size' before 'set terminal' can affect the canvas size. Then,
sizes below and above 1 have to be valid because then 'size 1,1' means the
default size. Partly, this is the current state while sizes > 1 only work
partly.

2.) 'set size' only affects the size of the plot within the current
canvas while the canvas (or bouding box or what ever) is influenced by
another mechanism, e.g., 'set terminal <term> size <x,y>'. Here, the
possible values can be different for different terminals, e.g.,
  set terminal postscript size 5cm,3cm
  set terminal postscript eps size 300pt,200pt
  set terminal postscript eps size 300,200 # could default to pt
  set terminal postscript eps size 300,200 offset 100,150
       # results in %%BoundingBox: 100 150 400 350
  set terminal gif size 300,200 # defaults to pixel
  set terminal gif size 1in,1in resolution 300 # = 300 x 300 pixel, 300dpi

To me it was nonsense to use 'set size' to reduce the canvas size and to
forbid to enlarge the canvas size using it.

For compatibility reasons, the first solution could be useful, while the
second solution is more clear and introduces a new important feature.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: bug in terminals affected by 'set size'

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

Aapo Lankinen wrote:
> Anyway, because there are different paper sizes possible in postscript
> and because eps figures are of different size by their nature, there
> really should be such a size option as you suggested.  But I think its
> name should not be "size", because the "size" is already a reserved
> keyword for "set" and it would cause confusion.  How would e.g.
>
> set term post eps canvas 8cm, 5cm
> set term post canvas a0

Well, there is a "size" option for the bitmap drivers, as noted
upthread.  So I think "size" is the right way to go.  It might be a
good idea to rename these option to the more meaningful "canvas".
I'm not sure.

> sound?  Is this kind of behaviour possible to implement for just one
> terminal driver without touching others?  This way there would be no
> need to change the "set size" behaviour at all, and by choosing default
> a4 size canvas for postscript, there would be perfect backward
> compatibility.

I'm pretty sure this is possible.  The terminal drivers are almost
completely independent from each other, even in parsing their
terminal options.

But the "set size" behaviour would have to change, I think.
Something like

set size 1/sqrt(2), sqrt(2)
set term post eps

to change to portrait EPS wouldn't work no more.  Well, one could
use the "set size" setting at the time of the "set term" command as
default canvas size (relative to the hardwired default) if no other
size is given.  ... Did I mention that I don't like the command line
syntax of gnuplot very much?

Juergen

Re: bug in terminals affected by 'set size'

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

On Thu, Oct 06, 2005 at 11:43:34AM +0300, Aapo Lankinen wrote:
> > set term post eps size 8cm, 5cm
> > set term post eps size 5in, 3in

> The obvious workaround (which works for me anyway) is to fiddle around
> with the size parameter, which as discussed can quite freely be choosed
> in range [0,1].  But for a newcomer it surely is irritating that you
> can't set the explicit bounding box in the unit of your choice. =20

    I must say I fully agree. Such an option would be extremely useful.
And adding it to epslatex and metapost terminals could be useful too.

--
    Ga=EBl

Re: bug in terminals affected by 'set size'

[Aapo L. <aap...@gm...>]

On Thu, 2005-10-06 at 09:42 +0200, Juergen Wieferink wrote:
> I'd like the option to set it using arbitrary dimensions.  Something
> like
> 
> set term post eps size 8cm, 5cm
> set term post eps size 5in, 3in
> 
> really should be possible.  Personally, I don't see any need for an
> explicit bounding box specification.  But if someone does, I'm fine
> with it -- as long as there is also some "size" option.

Yes, that would be a good thing.  One thing that Gnuplot is very good at
is its ability to produce very clean and good-looking plots for
inclusion in documents.  Unfortunately, it's little difficult to have
plot canvas in an exact arbitrary size, as you described.  Of course,
scaling of the image is not feasible, as linewidths and font sizes in
the document wouldn't be consistent after the scaling.

The obvious workaround (which works for me anyway) is to fiddle around
with the size parameter, which as discussed can quite freely be choosed
in range [0,1].  But for a newcomer it surely is irritating that you
can't set the explicit bounding box in the unit of your choice.  That
makes integration with LaTeX documents a little more difficult, but not
impossible.

One difficult thing is a0 posters: it is not possible to make big enough
eps images with Gnuplot to be included into an a0 poster.  Of course,
there is a workaround; one just plots everything in smaller scale in
Gunplot (a4 vs a0), and scales the result back into a0.  However, the
calculations with font sizes and linewidths are something that a user
shouldn't need to do.  Many fellow students around here rather use
Origin (a windows GUI driven plotting program), because it seems not to
have such limitation.  However, Origin is not a solution for me, because
a) Origin eps files are crap b) usually Origin plots look hideous c) I
rather use Linux d) I'm (usually) able to workaround the Gnuplot
oddities.

Anyway, because there are different paper sizes possible in postscript
and because eps figures are of different size by their nature, there
really should be such a size option as you suggested.  But I think its
name should not be "size", because the "size" is already a reserved
keyword for "set" and it would cause confusion.  How would e.g. 

set term post eps canvas 8cm, 5cm
set term post canvas a0

sound?  Is this kind of behaviour possible to implement for just one
terminal driver without touching others?  This way there would be no
need to change the "set size" behaviour at all, and by choosing default
a4 size canvas for postscript, there would be perfect backward
compatibility. 

							Aapo

Re: bug in terminals affected by 'set size'

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

Ethan Merritt wrote:
> For PostScript-like terminals it is a bit more complicated, since the
> output file eventually needs the 4 corners of a bounding box rather
> than just a width and height.  What would you prefer:
>
>   set term post eps size XX,YY
>
> 	more consistent with pixel-based terminals,
> 	but no explicit control over placement on page
>
>   set term post eps boundingbox x1,y1,x2,y2
>
> 	corresponds exactly to what will appear in the *.eps file

I'd like the option to set it using arbitrary dimensions.  Something
like

set term post eps size 8cm, 5cm
set term post eps size 5in, 3in

really should be possible.  Personally, I don't see any need for an
explicit bounding box specification.  But if someone does, I'm fine
with it -- as long as there is also some "size" option.


Juergen

CodeStyle

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

In `CodeStyle`, section `Layout and Indentation` one tab
per indent is recommended, with a 4 spaces equivalent to
one tab (ts=4). (But most code seems to use ts=8 anyway.)

'Newer' versions (>=1.2) of GNU indent can handle this.
So the recommended invocation of indent in `CodeStyle`
should probably be changed to:
indent -kr -cp0 -l132 -lps -br -psl -ts4

Bastian

Re: pslatex terminal output--Problem identified.

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

> | Do you mean  gget.m  from octave-forge?
> | It works OK.
>
> No, it is a terrible kluge and has a built-in race condition because
> it sends a "save" command to gnuplot then waits a while (how long is

Yes, it is quite strange ... I think that's due to Windows (no stdout et 
al).

Please find enclosed gget2.m. It's a version with implementation according 
to the current ginput.m (available from gnuplot's site, Octave section).
I think the code is clean. However, I don't know what happens on Windows.


> the format of the output is not well defined and could change with any new 
> release of gnuplot.

I don't think this is happening. There may be some changes due to addition 
of new options.

---
PM

Re: Patch for RFE [ 992352 ] [Win32] console backlog length is hardwired

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

Petr Mikulik wrote:
> It would be useful to set these parameters from a menu / popup menu, 
> instead to search for it in a file.
> 
> Can the line width be "infinite"? Or even better: cannot it be the 
> number of chars of the terminal window which can be printed (and 
> automatically change it when window size changes)?

That would be nice indeed. But the way it is implemented right now
that would be a major change.
A dialog would be nice to have, but its not necessary and possibly
not worth the effort. We would want to save the value to wgnuplot.ini
anyway.

Bastian

> 
> ---
> PM
> 

Re: bug in terminals affected by 'set size'

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

On Wednesday 05 October 2005 03:17 am, Robert Hart wrote:
> Basically your argument only makes sense if each terminal allows an
> explicit size argument in the term options. Then the "set size" option
> simply allows you to scale the plot within those bounds.

I agree.  So let's add a "size XX,YY" option to those terminals where
it is currently missing.  For pixel-based terminals this is trivial.
I've just done so for PBM.  [*]


For PostScript-like terminals it is a bit more complicated, since the
output file eventually needs the 4 corners of a bounding box rather
than just a width and height.  What would you prefer:

  set term post eps size XX,YY   

	more consistent with pixel-based terminals,
	but no explicit control over placement on page

  set term post eps boundingbox x1,y1,x2,y2

	corresponds exactly to what will appear in the *.eps file

For PostScript proper (as opposed to eps), I would prefer a different
approach.  I propose instead to update the patch #908040 that almost
made it into version 4.0, which breaks out the PostScript prolog text
into an external file that can be locally customized.  Then you could
have an A4 prolog, a USLetter prolog, and so on.  This mechanism allows
great flexibility in locally configuring the PostScript output without
having to modify gnuplot itself.  

The main stumbling block at the time was figuring out where to store
such an external file on a  MSWin box.  I am the wrong person to
sort this out, but I can't believe it's an insurmountable hurdle.



[*] Side Note: the generic bit-map routines in bitmap.c are in serious
need of clipping tests.  Right now if you select a too-small bitmap
dimension, the use of unsigned ints to represent coordinates bites in
a big way.  Any coordinate that tries to go negative wraps to a
ridiculously large number instead, essentially sending the code into
an infinite loop.  Try "set size .1,.1; set term pbm; test".
One more example of why I think we should try to rid the core 
routines of using "unsigned int" for coordinates.
 

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

Re: Patch for RFE [ 992352 ] [Win32] console backlog length is hardwired

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

It would be useful to set these parameters from a menu / popup menu, instead 
to search for it in a file.

Can the line width be "infinite"? Or even better: cannot it be the number of 
chars of the terminal window which can be printed (and automatically change 
it when window size changes)?

---
PM

Re: Patch for RFE [ 992352 ] [Win32] console backlog length is hardwired

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

Robert Hart wrote:
> On Wed, 2005-10-05 at 14:42 +0200, Bastian Maerkisch wrote:
>=20
>>Hi,
>>
>>this patch adds two new settings to wgnuplot.ini:
>>`BacklogLength` and `BacklogWidth`. This way a user can
>>adjust the length and width of the internal backlog
>>buffers accordings to his personal preferences.
>>
>>Bastian
>>
>>plain text document attachment (win_backlog-20051005.patch)
>>diff -ur gnuplot/src/win/wtext.c gnuplot-current/src/win/wtext.c
>>--- gnuplot/src/win/wtext.c	2004-07-07 18:56:08.000000000 +0200
>>+++ gnuplot-current/src/win/wtext.c	2005-10-05 14:06:48.063228500 +0200=

>>@@ -323,6 +323,10 @@
>>     WritePrivateProfileString(section, "TextFont", profile, file);
>>     wsprintf(profile, "%d", lptw->bSysColors);
>>     WritePrivateProfileString(section, "SysColors", profile, file);
>>+    wsprintf(profile, "%d", lptw->ScreenSize.x);
>>+    WritePrivateProfileString(section, "BacklogWidth", profile, file);=

>>+    wsprintf(profile, "%d", lptw->ScreenSize.x);
>=20
> Shouldn't one of these by ScreenSize.y?

Ouch. The second one should have been ScreenSize.y.

>=20
>=20
>>+    WritePrivateProfileString(section, "BacklogLines", profile, file);=

>>     if (iconic)
>> 	ShowWindow(lptw->hWndParent, SW_SHOWMINIMIZED);
>>     return;
>>@@ -382,6 +386,11 @@
>>     GetPrivateProfileString(section, "SysColors", "", profile, 80, fil=
e);
>>     if ((p =3D GetInt(profile, &lptw->bSysColors)) =3D=3D NULL)
>> 	lptw->bSysColors =3D 0;
>>+
>>+    if (bOKINI) {
>>+	lptw->ScreenSize.x =3D GetPrivateProfileInt(section, "BacklogWidth", =
80, file);
>>+	lptw->ScreenSize.y =3D GetPrivateProfileInt(section, "BacklogLines", =
80, file);
>=20
>=20
> Did you mean 500 here?

No. Current default is 80 for both dimensions.

>=20
>=20
>>+    }
>> }
>>=20
>>
>>--- gnuplot/term/win.trm	2005-08-09 11:07:02.000000000 +0200
>>+++ gnuplot-current/term/win.trm	2005-10-05 14:28:23.571548500 +0200
>>@@ -609,7 +609,10 @@
>> "       [WGNUPLOT]",
>> "       TextOrigin=3D0 0",
>> "       TextSize=3D640 150",
>>-"       TextFont=3DTerminal,9",
>>+"       TextFont=3DTerminal,9",
>>+"	SysColors=3D1",
>>+"	BacklogWidth=3D80",
>>+"	BacklogLines=3D500",
>=20
>=20
> Or did you mean 80 here?
>=20
> I think there's a tabs vs. spaces thing going on here. Not sure what
> format is preferred, but I'd go with the existing file format.

Sorry for that. Seems like Visual Studio is ignoring my preferences :-(.

But no, both numbers were put in by purpose. It doesn't say in the help
file that the values shown are the default ones. Just an example.

>=20
>=20
>> "       GraphOrigin=3D0 150",
>> "       GraphSize=3D640 330",
>> "       GraphFont=3DArial,10",
>>@@ -632,7 +635,9 @@
>> " solid line in color mode, or a dashed line in monochrome mode.  The =
default",
>> " line width is 1 pixel.  If `Linestyle` is negative, it specifies the=
 width of",
>> " a SOLID line in pixels.  Line1 and any linestyle used with the `poin=
ts` style",
>>-" must be SOLID with unit width.",
>>+" must be SOLID with unit width.",
>>+" `BacklogWidth` and `BacklogLength` specify the size of the initernal=
 backlog"
>>+" of the windows terminal window."
>=20
>=20
> What is the current "hardwired" value, and what is the problem with it?=

> Would it be possible to come up with a better default? Also what happen=
s
> with very large values? Don't you have a 16k limit on the buffer size i=
n
> win16? That's only 200 80-character lines.

As said above the "hardwired" value is 80 for both dimensions which shoul=
d be
reasonable for most cases. People with large displays may want to avoid
unnecessary line breaks. And I personally like the buffer to be large eno=
ugh
to contain the output of "show all".
I haven't considered 'large' values and I haven't considered Win16.
Would something like this be ok?

#ifdef WIN32
/* wild guess for the limits here */
# define BACKLOG_MAX_LINES 0x1000
# define BACKLOG_MAX_WIDTH 0x400
#else
# define BACKLOG_MAX_LINES 200
# define BACKLOG_MAX_WIDTH  80
#endif
=2E..
lptw->ScreenSize.y =3D GPMIN( GetPrivateProfileInt(section, "BacklogLines=
", 80, file), BACKLOG_MAX_LINES );
lptw->ScreenSize.x =3D GPMIN( GetPrivateProfileInt(section, "BacklogWidth=
", 80, file), BACKLOG_MAX_WIDTH );


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

Re: Patch for RFE [ 992352 ] [Win32] console backlog length is hardwired

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

On Wed, 2005-10-05 at 17:40 +0200, Bastian Maerkisch wrote:
> 
> Petr Mikulik wrote:
> >> this patch adds two new settings to wgnuplot.ini:
> >> `BacklogLength` and `BacklogWidth`. This way a user can
> >> adjust the length and width of the internal backlog
> >> buffers accordings to his personal preferences.
> > 
> > 
> > It compiles well.
> > BTW, what is it "Backlog"? Maybe "CommandScreen"?
> > 
> 
> To me - being a german - 'backlog' did sound like a reasonable
> name for the display buffer ;). Maybe someone could help with a
> better name?
> 
Is this analogous to what would be called a "Scrollback buffer" on a
terminal?

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: Patch for RFE [ 992352 ] [Win32] console backlog length is hardwired

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

On Wed, 2005-10-05 at 14:42 +0200, Bastian Maerkisch wrote:
> Hi,
> 
> this patch adds two new settings to wgnuplot.ini:
> `BacklogLength` and `BacklogWidth`. This way a user can
> adjust the length and width of the internal backlog
> buffers accordings to his personal preferences.
> 
> Bastian
> 
> plain text document attachment (win_backlog-20051005.patch)
> diff -ur gnuplot/src/win/wtext.c gnuplot-current/src/win/wtext.c
> --- gnuplot/src/win/wtext.c	2004-07-07 18:56:08.000000000 +0200
> +++ gnuplot-current/src/win/wtext.c	2005-10-05 14:06:48.063228500 +0200
> @@ -323,6 +323,10 @@
>      WritePrivateProfileString(section, "TextFont", profile, file);
>      wsprintf(profile, "%d", lptw->bSysColors);
>      WritePrivateProfileString(section, "SysColors", profile, file);
> +    wsprintf(profile, "%d", lptw->ScreenSize.x);
> +    WritePrivateProfileString(section, "BacklogWidth", profile, file);
> +    wsprintf(profile, "%d", lptw->ScreenSize.x);

Shouldn't one of these by ScreenSize.y?

> +    WritePrivateProfileString(section, "BacklogLines", profile, file);
>      if (iconic)
>  	ShowWindow(lptw->hWndParent, SW_SHOWMINIMIZED);
>      return;
> @@ -382,6 +386,11 @@
>      GetPrivateProfileString(section, "SysColors", "", profile, 80, file);
>      if ((p = GetInt(profile, &lptw->bSysColors)) == NULL)
>  	lptw->bSysColors = 0;
> +
> +    if (bOKINI) {
> +	lptw->ScreenSize.x = GetPrivateProfileInt(section, "BacklogWidth", 80, file);
> +	lptw->ScreenSize.y = GetPrivateProfileInt(section, "BacklogLines", 80, file);

Did you mean 500 here?

> +    }
>  }
>  
> 
> --- gnuplot/term/win.trm	2005-08-09 11:07:02.000000000 +0200
> +++ gnuplot-current/term/win.trm	2005-10-05 14:28:23.571548500 +0200
> @@ -609,7 +609,10 @@
>  "       [WGNUPLOT]",
>  "       TextOrigin=0 0",
>  "       TextSize=640 150",
> -"       TextFont=Terminal,9",
> +"       TextFont=Terminal,9",
> +"	SysColors=1",
> +"	BacklogWidth=80",
> +"	BacklogLines=500",

Or did you mean 80 here?

I think there's a tabs vs. spaces thing going on here. Not sure what
format is preferred, but I'd go with the existing file format.

>  "       GraphOrigin=0 150",
>  "       GraphSize=640 330",
>  "       GraphFont=Arial,10",
> @@ -632,7 +635,9 @@
>  " solid line in color mode, or a dashed line in monochrome mode.  The default",
>  " line width is 1 pixel.  If `Linestyle` is negative, it specifies the width of",
>  " a SOLID line in pixels.  Line1 and any linestyle used with the `points` style",
> -" must be SOLID with unit width.",
> +" must be SOLID with unit width.",
> +" `BacklogWidth` and `BacklogLength` specify the size of the initernal backlog"
> +" of the windows terminal window."

What is the current "hardwired" value, and what is the problem with it?
Would it be possible to come up with a better default? Also what happens
with very large values? Don't you have a 16k limit on the buffer size in
win16? That's only 200 80-character lines.

-- 
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: Patch for RFE [ 992352 ] [Win32] console backlog length is hardwired

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

Petr Mikulik wrote:
>> this patch adds two new settings to wgnuplot.ini:
>> `BacklogLength` and `BacklogWidth`. This way a user can
>> adjust the length and width of the internal backlog
>> buffers accordings to his personal preferences.
>=20
>=20
> It compiles well.
> BTW, what is it "Backlog"? Maybe "CommandScreen"?
>=20

To me - being a german - 'backlog' did sound like a reasonable
name for the display buffer ;). Maybe someone could help with a
better name?

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

Re: Patch for RFE [ 992352 ] [Win32] console backlog length is hardwired

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

> this patch adds two new settings to wgnuplot.ini:
> `BacklogLength` and `BacklogWidth`. This way a user can
> adjust the length and width of the internal backlog
> buffers accordings to his personal preferences.

It compiles well.
BTW, what is it "Backlog"? Maybe "CommandScreen"?

---
PM