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

Arrow head filling patch, and "port.trm"

[Chris K <gnu...@li...>]

Hi,

  In the process of writing a new terminal type, I noticed that
curr_arrow_headfilled means
  0 no filling, just two lines for an open arrow head
  1 no filling, draw closed arrow head
  2 filled, draw closed arrow head

But the "test" command, which draws 6 arrows, draws the one that points down
using curr_arrow_headfilled set to 3.

This is (accidentally?) processed by do_arrow as a value of 1 would be, since
do_arrow only tests it against !=0 and ==2.

Since this is the only use of a value of of 3, I think the value of 3 in test.c
should be changed to 1.  I posted this one character patch on sourceforge:

--- src/term.c  2006-03-18 19:03:16.000000000 +0000
+++ src/term-new.c      2006-03-31 20:57:34.000000000 +0100
@@ -1963,7 +1963,7 @@
     (*t->arrow) (x, y, x - xl, y, END_HEAD);
     curr_arrow_headfilled = 2;
     (*t->arrow) (x, y, x, y + yl, END_HEAD);
-    curr_arrow_headfilled = 3;
+    curr_arrow_headfilled = 1;
     (*t->arrow) (x, y, x, y - yl, END_HEAD);
     curr_arrow_headfilled = i;
     xl = t->h_tic * 5;

Pre-Announcing "port.trm" :

The ability to write the commands as ascii text to a file descriptor port is why
it is called "port.trm".  The idea to for the parent process to read the
commands and render/process them.

I wanted to run gnuplot as a subprocess and render the output in my main
program.  The easiest way to collect the rendering commands was much like the
debug.trm device.  So the new "port.trm" device uses fprintf to send a legible
ascii description of the rendering commands to either the output file or to an
integer file descriptor passed as a terminal option.

> gnuplot> set term port fd 5 500 500
> Terminal type set to 'port'
> Options are 'fd 5 size 500 500'

Most of the semantics of the options are decoded by "port.trm" into ascii words:

> Arrow 142 170 232 80 (ArrowStyle 18 15 90 AHF_Open DrawLineAndHead AHS_NoHead)

It was in defining all the cases for AHF_Open that I noticed the warning about
the value 3 passed by test.  As a further example, the end of the output of the
test command is then:

> FillBox (FS_Pattern 9) 412 0 12 62
> Move 412 0
> Vector 412 62
> Vector 424 62
> Vector 424 0
> Vector 412 0
> Put_Text 418 68 (LenString 2 (2039))
> LineType 2
> Filled_Polygon (FS_Solid 100) 7 [(400,415),(387,436),(362,436),(350,415),(362,393),(387,393),(400,415)]
> LineType -2
> Justify JCenter
> Put_Text 375 446 (LenString 23 (28636f6c6f72292066696c6c656420706f6c79676f6e3a))
> LineType -2
> Text
> Reset

Where the strings are encoded as hex, preceded by an explicit length.  The
actual rendering of markers and arrows is done with do_point and do_arrow at the
moment.  Their usage will be made optional.  For now, port.trm does not support
enhanced text.

At the other end of the pipe, I have a simple Haskell program that parses the
ascii commands and uses gtk2hs and cairo to render to a window.  This now
handles everything produced by the test command.  The only tricky bit in
rendering it was to rotate the text around the vertical center instead of the
baseline.

But any other program could use the output of "port.trm" in this way.  They just
have to parse the output text.

When it is a bit more polished, I will post a copy of "port.trm" to sourceforge.

-- 
Chris Kuklewicz

Re: Snapshot on Sourceforge

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

Hans-Bernhard Bröker wrote:
> James K. Gruetzner wrote:
>> As the release of v.4.2 nears, it might now be appropriate to 
>> periodically make snapshot tarballs of the development version 
>> available on the sourceforge project website.  
> 
> We will do that if and when we actually decide to tackle the next 
> release.  I don't see that actually happening right now.

Given the recent discussions on the list about what needs to be done for 
a 4.2 release, it seems that some are already thinking about it.

In any case, why not make tarballs available for the same reason Windows 
and OS/2 testing binaries are made available: for users who are unable 
to either check out or compile the source themselves.

THeo

Re: Snapshot on Sourceforge

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

James K. Gruetzner wrote:
> As the release of v.4.2 nears, it might now be appropriate to periodically 
> make snapshot tarballs of the development version available on the 
> sourceforge project website.  

We will do that if and when we actually decide to tackle the next 
release.  I don't see that actually happening right now.

gnuplot question

[Courtney S. <cou...@gm...>]

To whom it may concern,

How do I set palette to read in a binary rgb palette file for a 3d
image (pm3d) ?


Thank You,
Csc...@uc...

Snapshot on Sourceforge

[James K. G. <jk...@sa...>]

I've been using version 4.1 since last summer for my regular work; it has a 
few bugs, but the added features since v.4.0 make it worthwhile.  Alas, due 
to our corporate firewall, I've depended upon some kind soul to download and 
tarball from the CVS and send it to me.

As the release of v.4.2 nears, it might now be appropriate to periodically 
make snapshot tarballs of the development version available on the 
sourceforge project website.  

I understand that time considerations may make this impossible, but if it 
could be done, it would be greatly appreciated.

  jkg

Re: Patch for config/makefile.mgw

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

Timothée Lecomte wrote:
> Each time I use a freshly downloaded version from the CVS, I have to make
> the following modifications to make it succeed. I hope they could be
> included in the CVS version, in the case this makefile is supposed to be
> used with MSYS as I use it :

The trick is: it isn't.  Or rather, it never was.  makefile.mgw was 
written before MSYS existed.  It assumes the native MinGW ports of tools 
are used.

> MSYS uses by default /[Drive letter] as the root directory for the
> translation of the windows paths.

Not just by default, but by only option.  Unlike in the real Cygwin (of 
which it is a reduced subset), MSYS doesn't allow any choice in this matter.

> -  TERMLIBS += -lgd
> +  TERMLIBS += -lbgd

I'm a little wary of changing this --- trying to keep abreast with all 
packaging decisions made by third-party libraries in our pre-built 
makefiles may not be worth trying.  Some editing of the makefiles is 
expected to be necessary.

> @@ -357,10 +357,10 @@
>  # convert gnuplot.doc to gnuplot.rtf
>  $(HELPFILE): doc2rtf.exe $(D)gnuplot.doc win/wgnuplot.hpj
>  	./doc2rtf $(D)gnuplot.doc win/gnuplot.rtf
> -	$(HCW) /c /e win/wgnuplot.hpj
> +	$(HCW) //c //e win/wgnuplot.hpj

It may be easier to use -c and -e instead.

>  doc2rtf.exe: $(D)doc2rtf.c $(D)termdoc.c $(D)xref.c
> -	$(LD) $(LDFLAGS) -o $@ -DWINDOWS_NO_GUI $(CFLAGS) -I. -I$(D) -I$(T) $^
> +	$(LD) $(LDFLAGS) -o $@ -DWINDOWS_NO_GUI $(CFLAGS) -I. -I$(D) -I$(T)
> -I../term $^

> Then, with the original line for doc2rtf.exe, the linker reports that it
> can't find *.trm files, although $(T) expands as ../term/ correctly. By
> manually adding -I../term, it finds them. 

Probably a parser hickup in msys caused by the trailing /, possibly in 
conjunction with the usual / vs. \ vs. Unixy backslash-escapes typically 
encountered in using Unix-born makefiles on MS platforms.

Patch for config/makefile.mgw

[<tim...@en...>]

Hi !

I have used makefile.mgw for some time now to build my snapshots includin=
g
the wxWidgets terminal. I use it with MSYS/MinGW. MSYS (part of the MinGW
project) provides the shell and the translations between unix paths and
windows paths.

Each time I use a freshly downloaded version from the CVS, I have to make
the following modifications to make it succeed. I hope they could be
included in the CVS version, in the case this makefile is supposed to be
used with MSYS as I use it :

--- makefile.mgw
+++ /mnt/fat/gnuplot-cvs2/config/makefile.mgw
@@ -104,7 +104,7 @@
 # To compile the .hlp file you need hcw either out of Microsoft SDK or M=
S
Help
 # Workshop. The latter can be obtained at
www.helpmaster.com/help/devaids.htm.
 # Put the path to hcw here unless it is already in PATH:
-#HCWPATH =3D /Program\ Files/Help\ Workshop/
+#HCWPATH =3D /c/Program\ Files/Help\ Workshop/
 #HCWPATH =3D h:/mssdk/bin/
 HCW =3D $(HCWPATH)hcw
 # Switches are for HCW 4.03:

MSYS uses by default /[Drive letter] as the root directory for the
translation of the windows paths.


@@ -170,7 +170,7 @@
 ifdef GD
   CFLAGS +=3D -DHAVE_LIBGD
-  TERMLIBS +=3D -lgd
+  TERMLIBS +=3D -lbgd
 endif

 ifdef GIF


The gd precompiled package for window uses bgd.dll instead of gd.dll
gd-config is not included in thus precompiled package, so t can't be used
to retrieve the linker flags.

@@ -357,10 +357,10 @@
 # convert gnuplot.doc to gnuplot.rtf
 $(HELPFILE): doc2rtf.exe $(D)gnuplot.doc win/wgnuplot.hpj
 	./doc2rtf $(D)gnuplot.doc win/gnuplot.rtf
-	$(HCW) /c /e win/wgnuplot.hpj
+	$(HCW) //c //e win/wgnuplot.hpj

 doc2rtf.exe: $(D)doc2rtf.c $(D)termdoc.c $(D)xref.c
-	$(LD) $(LDFLAGS) -o $@ -DWINDOWS_NO_GUI $(CFLAGS) -I. -I$(D) -I$(T) $^
+	$(LD) $(LDFLAGS) -o $@ -DWINDOWS_NO_GUI $(CFLAGS) -I. -I$(D) -I$(T)
-I../term $^

 #make binary demo files
 $(M)bf_test.exe : bf_test.c dbinary.$(O) alloc.$(O)


Two things here :
First, MSYS will expand /c and /e as C:\ and E:\, so to avoid this we nee=
d
to use //c and //e
Then, with the original line for doc2rtf.exe, the linker reports that it
can't find *.trm files, although $(T) expands as ../term/ correctly. By
manually adding -I../term, it finds them. There should be a cleaner
solution, but I simply don't understand why it doesn't work
out-of-the-box...

Best regards,

Timoth=E9e Lecomte

Re: Interactive terminals : behaviour on window resizing

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

Ethan A Merritt wrote:

> Huh?  In my experience image viewers (ImageMagick, qiv) and PDF
> viewers (acroread)  *do* scale the image with the window size.

Same here.

> At least they do if you set that as the default behaviour, which I
> generally do.  The setting is usually called something like
> "fit to window".  Although now that you have me thinking of specific
> applications, it is true that the text-reading apps like Acroread
> or kpdf do scale the font as well.  That makes sense for pure text
> documents, but I don't see why it would make sense for graphics.

PDF and PostScript are designed to be scalable graphics.

I think that non-scaling the font isn't necessarily a bad thing.  When one is doing plot layout, you'd like fine control and not have gnuplot be choosing things in some way one doesn't like (unless perhaps there is some special font size which means to choose the most reasonable size font).

Anyway, what would be nice is some way to get back from the x11 window the "scale".  The idea would be that I could choose the font size in X11 and resize the window until the font and plot agree and then query the scale.  If I then choose that scale with other terminals, we'd hope to get a good match and avoid doing some trial and error.  But I bet it wouldn't be as productive as one would hope... it's sort of a WYSIWYG, which never did really come to fruition in the computer world, at least not linux.

Dan

Re: [Gnuplot-info] plot and splot with vectors

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

On Monday 27 March 2006 05:06 am, Hans-Bernhard Br=F6ker wrote:
> Donald J Bindner wrote:
> >>> plot "vec.dat" w vec
> >>> It works in my older version, but in the CVS pull, there is no
> >>> arrow head.
>=20
> I did some investigating in the meantime.  Turns out this is an utter=20
> mess, created by about 4 separate attempts at getting option parsing for=
=20
> 'with vectors' to work piled on top of each other.
>=20
> The core problem is that the '{s}plot' parser now only initializes the=20
> relevant data structure for the arrows in a part of the 'while still=20
> some command-line text left to parse' that is never reached in the
> above case.

I won't try to defend the "utter mess", but I think this particular
failure was introduced when we removed the initialization code from
all the <foo>_parse() routines so that successive calls were=20
incremental.  The 2D and 3D plot structures should properly have
their corresponding fields initialized to something reasonable.
Such initialization certainly can't hurt, and I'll add it to the
respective allocation routines cp_alloc() and sp_alloc().

This may actually allow us to remove some of the "utter mess", but
I won't do that without further inspection or testing.

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

Re: feature idea: "NOW" as function or variable (current time in seconds...)

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

Andreas K. Huettel wrote:
> 
> I've been looking for a way to specify that only the last e.g. 24h of a 
> logfile are plotted, e.g. 
> 
> set xrange [NOW-secondsperday:NOW]

On system that support pipes and have Unix-ish tools installed, a 
variation on the theme of

	set xrange [`date yesterday`:`date`]

should do that.

> IMHO, it would make a useful addition for future gnuplot versions to be 
> able to access the current time in e.g. the form of a timestamp. 

Feature request --> post it to the Feature Request Tracker on 
SourceForge.Net.

Re: Interactive terminals : behaviour on window resizing

[<tim...@en...>]

> On Monday 27 March 2006 10:02 am, Timoth=E9e Lecomte wrote:
>> My proposal is to
>> scale everything in the plot (including font size and linewidths)
>> with the window size, and to keep the global 1:1 aspect ratio by
>> leaving blanks on the top+bottom or left+right of the plot.
>
> I suppose it is a matter of taste, but I do not like the idea
> of rescaling the linewidth or font size.

Ok, I can understand that.
If I implement this (later), I will add an option regarding this
behaviour, at least for testing purposes.

Timoth=E9e

Re: Interactive terminals : behaviour on window resizing

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

On Monday 27 March 2006 10:02 am, Timoth=E9e Lecomte wrote:
> My proposal is to
> scale everything in the plot (including font size and linewidths)
> with the window size, and to keep the global 1:1 aspect ratio by
> leaving blanks on the top+bottom or left+right of the plot.

I suppose it is a matter of taste, but I do not like the idea
of rescaling the linewidth or font size. =20

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

Re: Interactive terminals : behaviour on window resizing

[<tim...@en...>]

> Timoth=E9e Lecomte wrote:
> [Don't rescale anything.]
>
>> Yes, but as mentioned in my reply to Ethan's message, it's the way mos=
t
>> other applications work.
>
> We have to be careful what kind of applications we compare to, here.
> There are two major classes.   One class holds those apps where the GUI
> window is just a peep-hole through which you look at a small part of a
> much large document: a "viewport".  This is the case for all text
> processors, spreadsheets, and lots of others.  Here, zooming and GUI
> window resizing can be (and usually are) treated as separate user
> commands.
>
> The other class of applications have GUI windows that *by definition*
> show their content in its entirety.  Media players and all kinds of use=
r
> interface dialogs, e.g. In such programs, a resize of the window
> forcibly triggers a redraw from scratch, often with a re-layout.

I had forgotten the media players and similar applications. You're right,
gnuplot belongs to this category.


> Some apps are mixtures between these two basic cases.  E.g. in a web
> browser, vertical resize will just show you more of the page, but
> horizontal resize triggers redraw and changes the layout.  Acroread
> changes behaviour depending on which "zoom" mode you selected.
>
> The problem we're facing with gnuplot is that we're firmly in the secon=
d
> category: we have a 1:1 relationship between the GUI window and the plo=
t
> that's shown in it.   So we never actually zoom into the graphic, but w=
e
> re-do the plot.  Except in those cases where we can't.  Then we just
> have to decide among several equally bad alternatives.
>
> Particularly in case of a multiplot, I don't think there's *anything*
> useful that can be done.  So we could
>
> 1) bluntly refuse to resize the GUI window --- just inform the GUI that
> this window is non-resizable until further notice
>
> 2) allow resize, but don't try to redraw --- just blank the window.
>
> 3) do what we do now: i.e. replay the series of term API operations
> stored by the GUI window handler, with re-mapped coordinates.
>
> 4) (only for non-multiplots, may need mousing turned on): send a
> 'replot' command back to gnuplot through the mouse command channel
>
>> For my wxt terminal, it would just imply (for example) a new button 'f=
it
>> to window' that the user would have to click on to inform gnuplot of t=
he
>> new geometry.
>
> We don't need such a button.  That must the one-and-only behaviour.
> Zooming into a plot such that only part of it is visible is just
> useless.  A plot only makes sense if you can see all of it.
>

I like the idea to do 'replot' automatically whenever it's possible, and
to handle multiplot (and other possible problematic situations)
separately.

Then, for the multiplot case, the option 3 which corresponds to the
current situation is probably the best. However, remains here the questio=
n
of the way the coordinates are remapped. My proposal is to scale
everything in the plot (including font size and linewidths) with the
window size, and to keep the global 1:1 aspect ratio by leaving blanks on
the top+bottom or left+right of the plot.

In practise, it would probably imply a new mousing command like
'GE_sizechanged' which would either do 'replot' if it is possible or fall
back to a new terminal routine 'term->scale()'.

Timoth=E9e

feature idea: "NOW" as function or variable (current time in seconds...)

[Andreas K. H. <A.K...@me...>]

Dear developers, 

I've been looking for a way to specify that only the last e.g. 24h of a 
logfile are plotted, e.g. 

set xrange [NOW-secondsperday:NOW]

IMHO, it would make a useful addition for future gnuplot versions to be 
able to access the current time in e.g. the form of a timestamp. 

Or am I just missing something that is already implemented (in 4.0)?

Best, Andreas


--
This message is transmitted using 100% recycled electrons.

---------------------------------------------------------------------
Dr. Andreas K. Huettel                  tel. +31 15 27 88102  (univ.)
Molecular Electronics and Devices            +31 6 42527466  (mobile)
Kavli Institute of Nanoscience Delft    A.K...@me...
Delft University of Technology             A.K...@tn...
PO Box 5046, 2600 GA Delft                          ma...@ak...
The Netherlands                     http://www.akhuettel.de/research/
---------------------------------------------------------------------
home addr.:  Andreas K. Huettel, Hugo de Grootstraat 12, Delft 2613TV
---------------------------------------------------------------------
Please use GNUPG or PGP for signed and encrypted email. My public key
can be found at  http://www.akhuettel.de/pgp_key.html

[ 1232950 ] -persist option does not work in Version 4.0.0 (Windows)

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

The patch in the attachment makes pgnuplot respect the `-persist` command=

line option. Previously, an `exit` command was always sent to wgnuplot
when there was nothing more in the pipe. Thus, things like
echo plot sin(x) | pgnuplot -persist
did cause wgnuplot to exit directly after plotting.

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

Re: [Gnuplot-info] plot and splot with vectors

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

> I did some investigating in the meantime.  Turns out this is an utter 
> mess, created by about 4 separate attempts at getting option parsing for 
> 'with vectors' to work piled on top of each other.
> 
> The core problem is that the '{s}plot' parser now only initializes the 
> relevant data structure for the arrows in a part of the 'while still 
> some command-line text left to parse' that is never reached in the
> above case.  For gnuplot-beta readers: default_arrow_style() is never 
> called if "with vectors" is the last thing on the plot commands line, 
> and "arrow_parse()" doesn't initialize anything either.

 {s}plot needs to be moved to table-based parsing to be brought in line
 with the rest of the code, see the comments in tables.c.

Re: [Gnuplot-info] plot and splot with vectors

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

Donald J Bindner wrote:
> On Sat, Mar 25, 2006 at 06:44:32PM +0100, Hans-Bernhard Br?ker wrote:
>> Donald J Bindner wrote:
>>> vec.dat:
>>> 0 0 1 1
>>> I tried to plot it with:
>>> plot "vec.dat" w vec
>>> It works in my older version, but in the CVS pull, there is no
>>> arrow head.
>> Yep, that's a bug alright.  I'll investigate.

I did some investigating in the meantime.  Turns out this is an utter 
mess, created by about 4 separate attempts at getting option parsing for 
'with vectors' to work piled on top of each other.

The core problem is that the '{s}plot' parser now only initializes the 
relevant data structure for the arrows in a part of the 'while still 
some command-line text left to parse' that is never reached in the
above case.  For gnuplot-beta readers: default_arrow_style() is never 
called if "with vectors" is the last thing on the plot commands line, 
and "arrow_parse()" doesn't initialize anything either.

Re: Interactive terminals : behaviour on window resizing

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

Timothée Lecomte wrote:

> At least for me with a CVS version picked up one month ago, the new window
> size is taken into account when you do 'set term x11', but not for a
> simple new plot.

Hmm... that's not how I remember it (dimly) from Ethan's description 
when he added this.

[Don't rescale anything.]

> Yes, but as mentioned in my reply to Ethan's message, it's the way most
> other applications work. 

We have to be careful what kind of applications we compare to, here. 
There are two major classes.   One class holds those apps where the GUI 
window is just a peep-hole through which you look at a small part of a 
much large document: a "viewport".  This is the case for all text 
processors, spreadsheets, and lots of others.  Here, zooming and GUI 
window resizing can be (and usually are) treated as separate user commands.

The other class of applications have GUI windows that *by definition* 
show their content in its entirety.  Media players and all kinds of user 
interface dialogs, e.g. In such programs, a resize of the window 
forcibly triggers a redraw from scratch, often with a re-layout.

Some apps are mixtures between these two basic cases.  E.g. in a web 
browser, vertical resize will just show you more of the page, but 
horizontal resize triggers redraw and changes the layout.  Acroread 
changes behaviour depending on which "zoom" mode you selected.

The problem we're facing with gnuplot is that we're firmly in the second 
category: we have a 1:1 relationship between the GUI window and the plot 
that's shown in it.   So we never actually zoom into the graphic, but we 
re-do the plot.  Except in those cases where we can't.  Then we just 
have to decide among several equally bad alternatives.

Particularly in case of a multiplot, I don't think there's *anything* 
useful that can be done.  So we could

1) bluntly refuse to resize the GUI window --- just inform the GUI that 
this window is non-resizable until further notice

2) allow resize, but don't try to redraw --- just blank the window.

3) do what we do now: i.e. replay the series of term API operations 
stored by the GUI window handler, with re-mapped coordinates.

4) (only for non-multiplots, may need mousing turned on): send a 
'replot' command back to gnuplot through the mouse command channel

> For my wxt terminal, it would just imply (for example) a new button 'fit
> to window' that the user would have to click on to inform gnuplot of the
> new geometry.

We don't need such a button.  That must the one-and-only behaviour. 
Zooming into a plot such that only part of it is visible is just 
useless.  A plot only makes sense if you can see all of it.

Re: Interactive terminals : behaviour on window resizing

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

On Sunday 26 March 2006 01:22 pm, Timoth=E9e Lecomte wrote:
> So let's narrow the discussion to the wxt terminal which know how to
> rescale fonts thanks to pango (however I don't know how it copes with
> non-scalable fonts... are they absolutely non-scalable ? ).

Bitmapped fonts are absolutely non-scalable.
This is an issue for x11/png(gd)/pbm, but I don't know if it=20
arises for pango.

> >>   1) really scale everything - including the font size
> >
> > This would be very odd in x11.  I cannot think of a single x11 applicat=
ion
> > in which the font size changes as you resize the window.  Generally you
> > pick a readable font size, and that's the size you get no matter how big
> > or small the window is.
>=20
> That's a good point.
> But notice that, apart from the gnuplot, I can't even think of any X11
> application which scale anything when the user resizes the window. Image
> viewers (gv, gimp...), web browsers (firefox...), pdf viewers (kpdf,
> acrobat reader...), etc. usually don't rescale anything, but behave like
> the point 2 that I describe below.

Huh?  In my experience image viewers (ImageMagick, qiv) and PDF
viewers (acroread)  *do* scale the image with the window size.
At least they do if you set that as the default behaviour, which I
generally do.  The setting is usually called something like
"fit to window".  Although now that you have me thinking of specific
applications, it is true that the text-reading apps like Acroread
or kpdf do scale the font as well.  That makes sense for pure text
documents, but I don't see why it would make sense for graphics.

Perhaps my expectations are colored by the field I work in.
The molecular graphics viewers which are used routinely in=20
my field scale objects up or down with the current window size,
but they do not scale the fonts.

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

Re: Interactive terminals : behaviour on window resizing

[<tim...@en...>]

[cc-ing to the mailing list, to keep the thread consistent]

> Timoth=E9e Lecomte wrote:
>> I would like to discuss what is the expected behaviour of the
>> interactive
>> terminals when the user resizes the windows.
>
> I don't think there is any formalized expectation beyond "try to make a=
s
> much sense as possible".

Sure, I completely agree !

>
>> The X11 terminal is resizing the plot by scaling everything on it exce=
pt
>> the font size and the linewidths. Thus, if the user makes the window
>> smaller, ticks labels may overlap, the plot box gets closer to the
>> window's edges and may overlap the labels, etc.
>> If another plot command is issued, the ratio is kept, so that the
>> position
>> of the box doesn't change for example.
>
> I'm not quite sure which "ratio" you're referring to there.

I mean the global aspect of the plot (box position, overlapping if any
because of the rescaling), as opposed to the situation described just
below.

>
>> If 'set term x11; replot' is issued, the window size seems to be probe=
d,
>
> Yes.  There's a back channel from gnuplot_x11 to gnuplot (the same one
> usually used for mouse interaction) which is used to inform the core
> about the actual geometry of the plot.  IIRC, it's supposed to used not
> only if you 'set term x11', but actually on each new plot.

At least for me with a CVS version picked up one month ago, the new windo=
w
size is taken into account when you do 'set term x11', but not for a
simple new plot.

>
>> The Windows terminal behaves similarly, except that term->xmax and
>> term->ymax seem to be stored at once on startup only, so that 'set ter=
m
>> win; replot' won't change the layout of the plot at all.
>
> Win.trm's internal coordinates have no relation to the GUI window's
> size.  The transformation between these artificial coordinates and
> screen pixels is handled by the graphical output layer.

Ok, thanks for the details.


>> I can imagine two other possibilites for the plot behavior when the us=
er
>> changes the window's size :
>>
>>   1) really scale everything - including the font size
>
> That would be manifestly wrong.  Font size is specified by the user, an=
d
> it's absolute.  It's not supposed to change just because you changed th=
e
> size of the plot.

You're right.
At least, thinking of it as a value relative to the window size leads to
inconsistencies when gnuplot's core is informed of a new geometry for a
new plot.

>
>>   2) don't scale anything and just display the plot centered in the
>> window
>> if it is smaller than the window, and if it is bigger add scrollbars o=
n
>> the edges of the window.
>
> Seems like you're missing the most obvious possibility:
>
> 3) Leave it to the core engine to re-layout the entire plot for the new
> window size, i.e. automatically trigger a "replot".
>
> The reason we're not doing that is that it's not always (easily)
> possible, because of 'multiplot' and because data may no longer be
> available.

That is the underlying problem (I experienced it, and I aknowledged it at
the end of my first message).


>> The second solution (don't scale anything) has the advantage to be
>> faster,
>> as it has basically no complex operation at all to be done when the
>> window's size changes.
>
> And it has the major disadvantage that if the user makes the window
> smaller than it originally was, part of the plot will now be invisible.

Yes, but as mentioned in my reply to Ethan's message, it's the way most
other applications work. I am not saying it is the optimal solution, but
it may be better that the current one.

For my wxt terminal, it would just imply (for example) a new button 'fit
to window' that the user would have to click on to inform gnuplot of the
new geometry.


> Ultimately, if the plot is a multiplot, *nothing* can really be done
> that would get us a sensible plot that doesn't explicitly violate at
> least some of the explicit or implicit requests issued by the user.
> Either the font size will be wrong, or the layout will no longer be
> adjusted to the font size, or the layout will be fundamentally differen=
t
> from what size, origin and margin were set to.
>
> For short, it's generally an impossible mission.  "replot" is correct i=
f
> it can be done --- but sometimes it just isn't.

Agreed. So a long-run goal could be to rework this.

Re: Interactive terminals : behaviour on window resizing

[<tim...@en...>]

>> I would like to discuss what is the expected behaviour of the
>> interactive
>> terminals when the user resizes the windows.
>
>> I am now asking what is the best behaviour in these situations. The
>> purpose of gnuplot is to make the layout automatically, and to make it
>> good. So, to my mind, rescaling everything except the fontsize is kind
>> of
>> strange, as it gives overlapping.
>
> I am afraid that most terminal types do not have enough information
> about fonts to re-scale on their own.
> And what if the font isn't scalable?

So let's narrow the discussion to the wxt terminal which know how to
rescale fonts thanks to pango (however I don't know how it copes with
non-scalable fonts... are they absolutely non-scalable ? ).

>
>> I can imagine two other possibilites for the plot behavior when the us=
er
>> changes the window's size :
>>
>>   1) really scale everything - including the font size
>
> This would be very odd in x11.  I cannot think of a single x11 applicat=
ion
> in which the font size changes as you resize the window.  Generally you
> pick a readable font size, and that's the size you get no matter how bi=
g
> or small the window is.

That's a good point.
But notice that, apart from the gnuplot, I can't even think of any X11
application which scale anything when the user resizes the window. Image
viewers (gv, gimp...), web browsers (firefox...), pdf viewers (kpdf,
acrobat reader...), etc. usually don't rescale anything, but behave like
the point 2 that I describe below.

>
>>   2) don't scale anything and just display the plot centered in the
>> window
>> if it is smaller than the window, and if it is bigger add scrollbars o=
n
>> the edges of the window.
>
> Why would you ever want that?

Because it seems more consistent than rescaling and thus losing the
initial well-calculated layout, and because it is the usual behaviour of
other applications as explained above.

>
>> Thanks for your insight on this topic.
>
> One change that has been suggested for x11 is to honor the
> "set ratio" command; scaling up or down as the window size changes, but
> always keeping the requested aspect ratio.

This is a very interesting option. However remains the question of the
font scaling.

Thank you for your comments.

Timoth=E9e Lecomte

Re: CVS ignores share and share/LaTeX

[James R. V. Z. <jr...@co...>]

=?ISO-8859-1?Q?Hans-Bernhard_Br=F6ker?= <br...@ph...> wrote:
>cvs update doesn't get you files in newly started directories unless 
>explicitly asked to.  You have to "cvs update -d" to get them.

Thanks, I had forgotten about -d.

           - Jim Van Zandt

Re: CVS ignores share and share/LaTeX

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

James R. Van Zandt wrote:
> I don't have a directory share, let alone a file share/Makefile.in.
> And "cvs update" does not download it.

cvs update doesn't get you files in newly started directories unless 
explicitly asked to.  You have to "cvs update -d" to get them.

> several files.  However there is also a file .cvsignore, which
> explains why "cvs update" does not download it.

No.  That's not what .cvsignore is about.

CVS ignores share and share/LaTeX

[James R. V. Z. <jr...@co...>]

I see that Thimo Neubauer has orphaned the Debian package of gnuplot
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357753).  I am
thinking about taking over as maintainer, and am trying to get my copy
of the sources up to date.  However, my builds are failing during
configuration like this:

  ...
  config.status: creating lisp/Makefile
  config.status: creating m4/Makefile
  config.status: creating man/Makefile
  config.status: error: cannot find input file: share/Makefile.in
  
I don't have a directory share, let alone a file share/Makefile.in.
And "cvs update" does not download it.

I can browse the cvs repository and see share, share/LaTeX, and
several files.  However there is also a file .cvsignore, which
explains why "cvs update" does not download it.

Makefile.am still mentions the share directory, and configure.in
lists share/Makefile and share/LaTeX/Makefile as output files.  For
now, I am deleting those entries.  What is the right fix here?

                 - Jim Van Zandt

Re: To distribute of translated manual

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

shige 03/25 2006
----------------

Hans-Bernhard Brr wrote:

| The general idea is you become a gnuplot team member and check them into 
| CVS yourself, so you can also update them on your own schedule, without 
| our help.  Failing that, zip them up and post the package to the 
| 'Patches' tracker.

O.K. I will post gzip files to 'Patches' section. I will send A,
B,C,G and I in this time.

 A: gnuplot-ja.doc.gz
 B: term-ja.diff.gz
 C: README.ja.gz
 G: wgnuplot-ja.mnu.gz
 I: README.win-ja.gz

| I really would like to avoid it.  How is making the Japanese version of 
| wgnuplot.hlp more complicated than the normal one?

The Japanese RTF file is not make correctly by "make rtf", so we
have to do as the followings:

% cd docs
% patch -p1 < ../../doc2rtf-38j0.diff
% make clean
% make 'CFLAGS=-g -O2 -DJAPANESE -DALL_TERM_DOC' doc2rtf
% gcc -o testrtf1 ../../testrtf1.c
% ./doc2rtf gnuplot-ja.doc tmpf
% nkf -s -Lw tmpf | ./testrtf1 > gnuplot-ja.rtf

where doc2rtf-38j0.diff and testrtf1.c are for encoding of the 
Japanese (8bit) RTF file which are available as

 http://takeno.iee.niit.ac.jp/~foo/gp-jman/data/doc2rtf-38j0.diff
 http://takeno.iee.niit.ac.jp/~foo/gp-jman/data/testrtf1.c

and nkf is the standard Japanese encoding filter from EUC-JP 
(using Japanese Unix) to Shift_JIS (using Japanese MS-Windows).

For making other format files like LaTeX, PDF, we also need some 
additional instructions, or do another way for the Japanese 
document.

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