Menu
▾
▴
gnuplot-beta
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-01-30 04:54:18
|
Almost 3 years ago, we had a thread titled
"What's left for a Version 4.0 release?"
It was useful in guiding the long process of readying the 4.0 official
release. I am hoping that a similar thread will kick off the 4.2
release process. I'm also hoping that this time it will take less
than a year to complete the process. We'll see.
Here is my evaluation of the state of the code base, and the
collection of bugs/patches/feature-requests on SourceForge.
I've split it into several parts:
core code
drivers
patches
feature requests
Core code
===========
Summary:
Either the cvs code is very stable, or no one is giving it a workout.
I think it's the former. Most of the recent bug reports against the
cvs version have turned out to be old problems that date back to
3.7 or earlier. The only major sore point that I see is the
clipping code. More on that later.
Issues:
- How many of the new options should be enabled by default?
Should any of them continue to be marked EXPERIMENTAL?
- Can we confirm that the code builds and runs on amiga? VMS?
If it doesn't even build, do we try to fix it or do we just stop
claiming to support those platforms?
- The binary file code is ugly, ugly, ugly. But it works.
If we hold up a release until all the code is beautiful, it will
never happen.
- Feature requests, patches
I've started a separate thread for these.
Known bugs:
- Clipping, particularly of arrows and filled polygons, is still
not done cleanly and therefore some terminals crash on reasonable
input.
This is the only known bug that I consider release-critical.
- Treatment of "missing" data as opposed to "invalid" data.
I think this is more a matter of poor documentation than an actual
bug, but I could be wrong. In any event, it's not fixable until
someone can point to an unambiguous statement of what *should*
happen in both cases, and a reproducible example that doesn't act
that way. SF bugs #775810 #918793 #969322 #1403945
- Miscellaneous open bug reports on SourceForge are related to
the core code rather than to individual terminals.
The list is actually quite short:
#1408955 ytics have wrong date with ydata time and "using 2"
#1363641 dgrid3d / xrange interaction
#1346814 cannot unset mxtics for time data
#1184989 set key below noautotitles; plot x -- crash
#1182499 set terminal doesn't automatically close output
#1158281 plotting a ternary function with undefined values
#1107709 plot [-1:1] x is plotted with asymmetric y-axis
#1058117 Legend Disappears on Some Plots
#1042785 reversed axis range breaks filled curves
#1039309 Strange xtics on 'time' plot
#1024394 bug on time/data format
#1004754 Tics and grid slightly outside border.
#992528 `set offset` can break `with filledcurves`
#634506 plotting a subrange of a contour plot
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-01-30 04:55:40
|
Almost 3 years ago, we had a thread titled=20
"What's left for a Version 4.0 release?"
It was useful in guiding the long process of readying the 4.0 official
release. I am hoping that a similar thread will kick off the 4.2
release process. I'm also hoping that this time it will take less
than a year to complete the process. We'll see.
Here is my evaluation of the state of the code base, and the
collection of bugs/patches/feature-requests on SourceForge.
I've split it into several parts:
core code
drivers
patches
feature requests
Drivers
=3D=3D=3D=3D=3D=3D=3D
Summary:
The major changes since 4.0 involved re-working the PostScript
driver and its derivatives. I think we made a mistake in leaving
old drivers in the 4.0 release, and should aim for simply removing
obsolete drivers in 4.2. Consider how many queries on the newsgroup
turn out to be from people whose gnuplot 4.0 was built with the
1995-era png driver rather than with libgd.
Issues:
- New drivers
+ aquaterm is already in cvs. I have some reservations about
making it a default, however, because it does not support all
the features of the x11 terminal. IMHO either the remaining
features should be added, or x11 should remain the default
terminal even on systems that support aqua.
+ Timoth=C3=A9e's wxWidgets driver is looking very solid, and should
go into cvs
+ I'm glad to see there is ongoing work on an OpenGL terminal,
but I don't see much chance anything will be ready for 4.2
- Old but not obsolete drivers
+ Windows is the 800 pound gorilla here. It has fallen behind=20
the other interactive drivers in capability, and it does not
seem to have a champion on the development team to bring it up
to par. Can we move to the wxWidgets driver instead, and=20
retain the existing windows driver only for older systems that
don't support wxWidgets?
- Obsolete drivers (any machine that can run these has a better
alternative driver). Should we remove them from the tree altogether?
+ openstep/next
I'm not an expert on the history of Apple O/S releases, but
it is my understanding that any machine these were relevant
to could now run the normal postscript driver for printer
output and x11 for interactive output. I used to have
a Next machine, and it did work for both postscript and
x11. But it's long gone.
+ ggi
Does not link properly against the ggi+xmi libraries currently
available on the web.
The basic ggi.trm works for me, but does not do anything useful
that cannot be better done with another terminal type.
As best as I can make out, gnuplot's xmi code was written to match
the SCO implementation, which is for all practical purposes
dead. And given SCO's claims of proprietary code, it is probably
not usable anyhow. =20
+ iris4d
I work in a lab that has used SGI workstations for at least the
last 12 years. *No one* uses the iris4d driver, and they never
have. You would think that the attraction of a separate driver
for 3D workstations would be that it supports 3D... but it doesn't.
+ ai
So far as I know, "set term post level1" is sufficient to=20
generate output compatible with Adobe Illustrator (ai).
If not, I'd rather fix post.trm than try to support the ancient
ai.trm.
Other dubious drivers:
+ svgalib
I have never managed to get this one to work right, and it's
a blatant security hole. But I know that some people use it,
because we get occasional bug reports [which don't get fixed].
Anyone know of a way to provide a linux console terminal=20
driver that doesn't have these problems?
Bugs:
Most of the bug reports on SourceForge are driver-specific.
Some are ancient, and some can probably be ignored.
windows:
#1413021 [Wgnuplot] pause 1;reread; blocks interaction
#1232950 -persist option does not work in Version 4.0.0 (Windows)
#982293 can't print color in win32 gnuplot 4.0
#561418 (MS Windows) 100% CPU Usage during pause
#233405 WGNUPL32.EXE crashes when printing directly (Win 95)
x11:
#1376604 misleading "noraise" resource; resource list in doc
#1305877 x11: cursor position in clipboard N/A in Qt/KDE applications
#997481 [autoconf] name transformation of gnuplot_x11
TeX:
#1377786 kpsexpand/kpsewhich from tetex are called unconditionally
#1367060 epslatex generates ambiguous TeX code
#1356987 erroneous eepic output for ylabel
#1355374 term tkcanvas perltk broken
other:
#1224391 Linux console corrupt screen after switch
#1039296 PDFlib Lite 6 output is broken for pipes, stdout
#596701 tkcanvas perltk problem
=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-01-30 05:00:32
|
Almost 3 years ago, we had a thread titled "What's left for a Version 4.0 release?" It was useful in guiding the long process of readying the 4.0 official release. I am hoping that a similar thread will kick off the 4.2 release process. I'm also hoping that this time it will take less than a year to complete the process. We'll see. Here is my evaluation of the state of the code base, and the collection of bugs/patches/feature-requests on SourceForge. I've split it into several parts: core code drivers patches feature requests Feature Requests ================ Summary: A suggestion with no actual code does not count for as much as a real patchset. That said, there are a few good ideas on the SourceForge site that might be worth looking at. If the implementation is easy enough, we might consider working on them for 4.2. The following look like plausible candidates to me: #1376595 Class and name strings of X Window #1117724 [fit] access to resulting chisquare #1078852 Flexible usage of geographic coordinates (ex. DD:MM:SS) #674055 mouse coordinate read-out in multiplot mode -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Bastian M. <bma...@we...> - 2006-03-17 07:43:39
|
Lately I have been working a bit on the windows terminal. It now has image, font selection and enhanced text support. Is there anything else you miss for a 4.2 release? Multiple window support is a candidate that most likely could be added rather easily. Btw. I am not claiming to be that champion ;) > - Old but not obsolete drivers > + Windows is the 800 pound gorilla here. It has fallen behind > the other interactive drivers in capability, and it does not > seem to have a champion on the development team to bring it up > to par. Can we move to the wxWidgets driver instead, and > retain the existing windows driver only for older systems that > don't support wxWidgets? On my list of changes for win.trm are a changes to WIN_options() to make it accept similar options as other terminals. The menu file wgnuplot.mnu definitely could do with some update before 4.2 as well. The current code as it is does not run on NT4 and possibly Win95 and Win32s. This is due to the new directory selection dialog introduced by me. I can think of these options to handle that: 1) provide a separate version for these systems (probably not Win32s ;-) 2) add more code to make it run on all systems 3) make Win98/WIN2000 a requirement (NT4 plus IE update does work, too), Is there an agreement what to do? Below some short comments on bugs specific to windows: > windows: > #1232950 -persist option does not work in Version 4.0.0 (Windows) A bug that needs to be fixed for 4.2. I will look into it. > #1413021 [Wgnuplot] pause 1;reread; blocks interaction Cannot comment. > #561418 (MS Windows) 100% CPU Usage during pause I cannot reproduce this. > #982293 can't print color in win32 gnuplot 4.0 > #233405 WGNUPL32.EXE crashes when printing directly (Win 95) Printing via win.trm in general seems to be buggy. This feature should probably be disabled for now. Bernhard recommends not to use it anyway. Bastian |
|
From: Petr M. <mi...@ph...> - 2006-03-22 15:27:28
|
> else you miss for a 4.2 release? Multiple window support is a candidate that > most likely could be added rather easily. Or use wxgnuplot > On my list of changes for win.trm are a changes to WIN_options() > to make it accept similar options as other terminals. The menu file > wgnuplot.mnu definitely could do with some update before 4.2 as well. Good point, can you patch them? > The current code as it is does not run on NT4 and possibly Win95 and Win32s. > This is due to the new directory selection dialog introduced > by me. I can think of these options to handle that: > 1) provide a separate version for these systems (probably not Win32s ;-) > 2) add more code to make it run on all systems > 3) make Win98/WIN2000 a requirement (NT4 plus IE update does work, too), Is > there an agreement what to do? Could you check on runtime "if (this_dll_available) then ..." ? >> windows: >> #1232950 -persist option does not work in Version 4.0.0 (Windows) > A bug that needs to be fixed for 4.2. I will look into it. > >> #1413021 [Wgnuplot] pause 1;reread; blocks interaction > Cannot comment. > >> #561418 (MS Windows) 100% CPU Usage during pause > I cannot reproduce this. Please write your comments into SF. Those unreproducible should be closed. >> #982293 can't print color in win32 gnuplot 4.0 >> #233405 WGNUPL32.EXE crashes when printing directly (Win 95) > Printing via win.trm in general seems to be buggy. This feature > should probably be disabled for now. Bernhard recommends not to use > it anyway. Thus, to be disabled? Hans-Bernhard? --- PM |
|
From: <tim...@en...> - 2006-03-22 19:59:53
|
Hi !
Here is a typo in gplt_x11.c, line 5963 :
} else if (reply.xselection.target =3D=3D XA_TIMESTAMP) {
- FPRINTF((stderr, "timestamp request from %d : %ld\n", i
+ FPRINTF((stderr, "timestamp request from %d : %ld\n",
reply.xselection.requestor, export_time));
XChangeProperty(dpy, reply.xselection.requestor,
reply.xselection.property, reply.xselection.target,
32, PropModeReplace, (unsigned char *) &(export_time), 1);
It only appears when DEBUG is defined, and comes probably from me as I
have proposed the above lines to cope with clipboard's problem...
Best regards,
Timoth=E9e Lecomte
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-03-23 07:03:26
|
On Wednesday 22 March 2006 11:59 am, Timoth=E9e Lecomte wrote:
>=20
> Here is a typo in gplt_x11.c, line 5963 :
Added to cvs.
Thanks
> } else if (reply.xselection.target =3D=3D XA_TIMESTAMP) {
>=20
> - FPRINTF((stderr, "timestamp request from %d : %ld\n", i
> + FPRINTF((stderr, "timestamp request from %d : %ld\n",
> reply.xselection.requestor, export_time));
> XChangeProperty(dpy, reply.xselection.requestor,
> reply.xselection.property, reply.xselection.target,
> 32, PropModeReplace, (unsigned char *) &(export_time), 1);
=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From:
<br...@ph...> - 2006-03-24 17:43:09
|
Petr Mikulik wrote: >> The current code as it is does not run on NT4 and possibly Win95 and >> Win32s. This is due to the new directory selection dialog introduced >> by me. I can think of these options to handle that: >> 1) provide a separate version for these systems (probably not Win32s ;-) >> 2) add more code to make it run on all systems >> 3) make Win98/WIN2000 a requirement (NT4 plus IE update does work, >> too), Is there an agreement what to do? > > Could you check on runtime "if (this_dll_available) then ..." ? I take that's what Bastian meant by option 1) add more code... >>> #982293 can't print color in win32 gnuplot 4.0 >>> #233405 WGNUPL32.EXE crashes when printing directly (Win 95) >> Printing via win.trm in general seems to be buggy. This feature >> should probably be disabled for now. Bernhard recommends not to use >> it anyway. > > Thus, to be disabled? Hans-Bernhard? Disabling it might be overkill: sometimes it _does_ work, to some extent. The real problem is that nobody seems to have any consistent explanation about when it'll work, and when it won't. On Win9x, it apparently never worked, on NT-based windows, it sometimes does. E.g. the "Print..." entry in the context menu of the graph window (available via the system menu if mousing is on) just got me a nicely working printout of the test page. The PrtSc button (--> command "screendump") also worked. |
|
From: <tim...@en...> - 2006-03-24 19:08:36
|
Hi ! I would like to discuss what is the expected behaviour of the interactive terminals when the user resizes the windows. The X11 terminal is resizing the plot by scaling everything on it except 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 positio= n of the box doesn't change for example. If 'set term x11; replot' is issued, the window size seems to be probed, updating term->xmax and term->ymax, and gnuplot updates the position of the box, the labels, etc. according to the new size. The Windows terminal behaves similarly, except that term->xmax and term->ymax seem to be stored at once on startup only, so that 'set term win; replot' won't change the layout of the plot at all. 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 can imagine two other possibilites for the plot behavior when the user changes the window's size : 1) really scale everything - including the font size 2) don't scale anything and just display the plot centered in the windo= w if it is smaller than the window, and if it is bigger add scrollbars on the edges of the window. The first solution leads to another problem : what to do with the text aspect ratio (height to width). Two possibilities again : a) scale the font size with the width of the window only and maintain the proportion of the text. This will give overlapping labels again if the user makes the height of the window smaller b) scale the whole text with the window, so the ratio width/height of the text won't be constant 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. But what would the user have to do to make the plot fit again in the window ? Just hit 'replot' ? Or 'set term wxt; replot' ? Click a toolbar button called 'Fit plot to window' and then hit 'replot' ? --Note that all these 'replot'-based solutions don't work with multiplot-= - Thanks for your insight on this topic. Best regards, Timoth=E9e Lecomte |
|
From: <tim...@en...> - 2006-03-26 21:46:13
|
[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. |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-03-25 06:42:42
|
On Friday 24 March 2006 11:08 am, Timoth=E9e Lecomte wrote: >=20 > 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? > I can imagine two other possibilites for the plot behavior when the user > changes the window's size : >=20 > 1) really scale everything - including the font size This would be very odd in x11. I cannot think of a single x11 application 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. > 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 on > the edges of the window. Why would you ever want that? =20 > 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. =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <tim...@en...> - 2006-03-26 21:22:58
|
>> 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 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-03-26 22:47:11
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2006-03-28 08:23:39
|
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 |
|
From:
<br...@ph...> - 2006-03-27 12:57:40
|
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. |
|
From: <tim...@en...> - 2006-03-27 18:03:01
|
> 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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-03-27 18:25:52
|
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 |
|
From: <tim...@en...> - 2006-03-27 18:29:58
|
> 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 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-04-15 04:55:53
|
On Sunday 29 January 2006 08:55 pm, Ethan A Merritt wrote:
>=20
> Here is my evaluation of the state of the code base, and the
> collection of bugs/patches/feature-requests on SourceForge.
Updated 14 Apr 2006
> Drivers
> =3D=3D=3D=3D=3D=3D=3D
>=20
> Summary:
> I think we made a mistake in leaving old drivers in the 4.0 release,
> and should aim for simply removing obsolete drivers in 4.2.=20
> Consider how many queries on the newsgroup=20
> turn out to be from people whose gnuplot 4.0 was built with the
> 1995-era png driver rather than with libgd.
=20
> Issues:
> + aquaterm is already in cvs. I have some reservations about
> making it a default, however, because it does not support all
> the features of the x11 terminal. IMHO either the remaining
> features should be added, or x11 should remain the default
> terminal even on systems that support aqua.
No change. Per?
> + Timoth=C3=A9e's wxWidgets driver
Will go into cvs when SourceForge gets their servers working,
which is now projected at next month sometime. Yuck.
> + I'm glad to see there is ongoing work on an OpenGL terminal,
> but I don't see much chance anything will be ready for 4.2
No response. Let's drop this one from consideration for 4.2
> - Old but not obsolete drivers
> + Windows is the 800 pound gorilla here.
Major upgrades from Bastian Maerkisch recently added to cvs.
No bug reports yet.
> - Obsolete drivers (any machine that can run these has a better
> alternative driver). Should we remove them from the tree altogether?
> + openstep/next
> + ggi
> + iris4d
I propose to remove these from the cvs source tree
+ eepic
Another candidate for obsolescence. The most recent comment
on SourceForge (#528909) is a 2002 suggestion from Lars that it
be dropped or disabled.
> Other dubious drivers:
> + svgalib
> I have never managed to get this one to work right, and it's
> a blatant security hole. But I know that some people use it
> + ai
> So far as I know, "set term post level1" is sufficient to=20
> generate output compatible with Adobe Illustrator (ai).
No change.
> Bugs:
>=20
> windows:
> #1232950 -persist option does not work in Version 4.0.0 (Windows)
Fixed
> #1413021 [Wgnuplot] pause 1;reread; blocks interaction
> #982293 can't print color in win32 gnuplot 4.0
> #561418 (MS Windows) 100% CPU Usage during pause
> #233405 WGNUPL32.EXE crashes when printing directly (Win 95)
I don't have any idea about the state of these.=20
Still bugs? Fixed?
> x11:
> #1376604 misleading "noraise" resource; resource list in doc
on my TODO list
> #1305877 x11: cursor position in clipboard N/A in Qt/KDE applicati=
ons
Fixed
> #997481 [autoconf] name transformation of gnuplot_x11
No idea. Lars? Hans?
> TeX:
> #1377786 kpsexpand/kpsewhich from tetex are called unconditionally
> #1367060 epslatex generates ambiguous TeX code
> #1356987 erroneous eepic output for ylabel
I think these can be marked "won't fix". =20
> #1355374 term tkcanvas perltk broken
This one even comes with a patch to fix it.
Can anyone confirm that the patch works?
> other:
> #1224391 Linux console corrupt screen after switch
> #1039296 PDFlib Lite 6 output is broken for pipes, stdout
> #596701 tkcanvas perltk problem
No change
=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: V. <gae...@no...> - 2006-04-15 08:49:48
|
On Fri, Apr 14, 2006 at 09:55:46PM -0700, Ethan A Merritt wrote:
> On Sunday 29 January 2006 08:55 pm, Ethan A Merritt wrote:
> > + I'm glad to see there is ongoing work on an OpenGL terminal,
> > but I don't see much chance anything will be ready for 4.2
> No response. Let's drop this one from consideration for 4.2
I had a look at implementing full 3D drivers back when I was
thinking of adding a povray terminal driver. Before any of these 3D
drivers can be implemented we need a full rework of the plotting code to
work in 3D until the last moment and then project.
I have a few ideas on what needs to be done (although it has been so
long since I looked at that that I forgot most of what I had learnt) but
I am far from having enough time to do it myself. Anyhow, this a big
change that should not be considered before next release.
Good luck with the 4.2 release, it will be much appreciated in
the labs (some features like plotting with images, or rgb colours are
really usefull).
--=20
Ga=EBl
|
|
From: Petr M. <mi...@ph...> - 2006-04-16 19:49:03
|
Thanks for these reports ... >> - Obsolete drivers (any machine that can run these has a better >> alternative driver). Should we remove them from the tree altogether? >> + openstep/next >> + ggi >> + iris4d > > I propose to remove these from the cvs source tree I agree ... I think that ggi was not used by anyone else than Johannes? >> Bugs: >> >> windows: >> #1232950 -persist option does not work in Version 4.0.0 (Windows) > Fixed >> #1413021 [Wgnuplot] pause 1;reread; blocks interaction >> #982293 can't print color in win32 gnuplot 4.0 >> #561418 (MS Windows) 100% CPU Usage during pause >> #233405 WGNUPL32.EXE crashes when printing directly (Win 95) > I don't have any idea about the state of these. > Still bugs? Fixed? Bastian, you are working actively on the Windows, can you please try and comment on these bugs, so that these reports can be closed? >> #1305877 x11: cursor position in clipboard N/A in Qt/KDE applications > Fixed I've just tried it .. yes, it seems to be fixed. --- PM |
|
From: Bastian M. <bma...@we...> - 2006-04-24 22:34:48
|
Some comments on the Windows bugs: Since I only have access to Win XP and Win 2000 I can only test on these machines. Especially the printing problems seem to be related to Win 9x. I cannot reproduce them on Win XP. Petr Mikulik wrote: > Thanks for these reports ... >>> Bugs: >>> >>> windows: >>> #1413021 [Wgnuplot] pause 1;reread; blocks interaction This is reproducible. Question is if it qualifies as a bug. wgnuplot cannot handle any user interaction while it is running a script. That's a design issue which would need some effort to change. At least does current behaviour seem to be non-obvious to users. I'll have a look at it when time permits. >>> #561418 (MS Windows) 100% CPU Usage during pause I have never seen a behavior like this. >>> #982293 can't print color in win32 gnuplot 4.0 >>> #233405 WGNUPL32.EXE crashes when printing directly (Win 95) All of this works just fine on my system. But that's XP... There's one more issue: current CVS builds crash on a Win NT4 system on startup. I suspect this has to do with my 'appdata-code' which I just cannot get right :-( I do not have access to NT4 or Win9x. Could somebody help me out here? Bastian |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-01-30 04:59:30
|
Almost 3 years ago, we had a thread titled "What's left for a Version 4.0 release?" It was useful in guiding the long process of readying the 4.0 official release. I am hoping that a similar thread will kick off the 4.2 release process. I'm also hoping that this time it will take less than a year to complete the process. We'll see. Here is my evaluation of the state of the code base, and the collection of bugs/patches/feature-requests on SourceForge. I've split it into several parts: core code drivers patches feature requests Patchsets ========= Summary: Although the current collection of patchsets on SourceForge represents a lot of work by a lot of people, I don't think there is much there that cries out for inclusion in a 4.2 release. Here's my attempt at sorting them: I'm willing to spend time to get it into 4.2 ================================================== 1267434 wxWidgets terminal 1218873 Change text rotating angle from int to float 908040 Break PostScript prologue file out of post.trm Maybe, if someone else does the work :-) ================================================== 1244775 Isolines optional on datafile splots 1199186 strftime and strptime 1077726 true depth ordering for pm3d plots Good idea, but not for 4.2 ================================================== 1252232 Allow UTF-8 input for normal postscript Type1 fonts 1252215 Font kerning in postscript terminal 1143563 Place arbitrary objects in plots 1196485 OpenGL terminal driver 1105717 Add '=' special file to reread '-' inline data I cannot judge these ================================================= 1398474 a driver for GD.pm 1384525 Small fixes to gd terminals 1294507 Fitting using CERN Minuit routines 1248308 Rexx scripting support 1233137 Font control in tkcanvas 1289725 handling double quotes in gnuplot-mode Reject for now; revisit later ============================= My evaluation is that the rest of these should be rejected, and the core ideas revisited later if there is still a need after the code destined for 4.2 has settled down. Note that several of these involve the clipping code, which I have separately listed as a release-critical issue. I just don't think that these particular patches are the way to get there, even though some of them were my own suggestions. 1364114 Extension of Ethans patch: Clipping in Postscript terminal 1356114 set term ... size <foo>,<baz> 1353539 Fix clipping for plots with canvas size != 1,1 1329098 New clipping code 1328103 Fix BoundingBox for large postscript plots 1321476 Draw zeroaxis at specified positions 1318546 Add 'offset' and 'backhead' to 'set arrow' 1262281 Povray terminal driver 1251204 Real 3d perspectivic look to splot 1206823 Boxed text labels 1193448 Use allterm.h for texinfo documentation 1185346 Autoscaling with constraint on final range. 1123355 Support a header file in epslatex terminal 1104264 Fix buggy clipping of arrows in large splots 1052938 Fix incorrect alignment of rotated multiline text 1044573 change density of generated tics 1030055 add user-specified colors to emf.trm 1027032 Connect gnuplot_x11 to exterior application window 1024305 pie graphs (work in progress) 982765 Patch for AI (Adobe Illustrator) term 936695 Some new logos 760421 plot smooth, with set log y 633724 new terminals:Python/Tk and Ruby/Tk 632289 new dgrid3d options: scaling and range 588805 external functions via plugins 551439 plot ... index by name instead of number -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-04-15 04:57:51
|
On Sunday 29 January 2006 08:59 pm, Ethan A Merritt wrote:
>
> Here is my evaluation of the state of the code base, and the
> collection of bugs/patches/feature-requests on SourceForge.
Updated 14 Apr 2006
> Patchsets
> =========
>
> I'm willing to spend time to get it into 4.2
> ==================================================
> 1267434 wxWidgets terminal
Will add to cvs when SourceForge recovers
> 1218873 Change text rotating angle from int to float
Will add to cvs when SourceForge recovers
(or maybe sooner, given that recovery is now projected for May)
> 908040 Break PostScript prologue file out of post.trm
Added to cvs
> Maybe, if someone else does the work :-)
> ==================================================
> 1244775 Isolines optional on datafile splots
> 1199186 strftime and strptime
> 1077726 true depth ordering for pm3d plots
No change
> Good idea, but not for 4.2
> ==================================================
> 1143563 Place arbitrary objects in plots
Added to cvs as EXPERIMENTAL (Petr talked me into it)
> 1252232 Allow UTF-8 input for normal postscript Type1 fonts
> 1252215 Font kerning in postscript terminal
> 1196485 OpenGL terminal driver
> 1105717 Add '=' special file to reread '-' inline data
No change
> I cannot judge these
> =================================================
> 1384525 Small fixes to gd terminals
Added to cvs
> 1398474 a driver for GD.pm
> 1294507 Fitting using CERN Minuit routines
> 1248308 Rexx scripting support
> 1233137 Font control in tkcanvas
> 1289725 handling double quotes in gnuplot-mode
No change
> Reject for now; revisit later
> =============================
> 1318546 Add 'offset' and 'backhead' to 'set arrow'
Added "backhead" (only) to cvs
> 1364114 Extension of Ethans patch: Clipping in Postscript terminal
> 1353539 Fix clipping for plots with canvas size != 1,1
> 1329098 New clipping code
> 1328103 Fix BoundingBox for large postscript plots
> 1104264 Fix buggy clipping of arrows in large splots
Closed - made obsolete by clipping and 'set term post size'
> 1206823 Boxed text labels
Closed - nobody liked it but me :-(
> 1030055 add user-specified colors to emf.trm
> 1024305 pie graphs (work in progress)
> 982765 Patch for AI (Adobe Illustrator) term
Closed - made obsolete by various features in current cvs
> 1027032 Connect gnuplot_x11 to exterior application window
Being re-worked by Daniel
> 1356114 set term ... size <foo>,<baz>
> 1321476 Draw zeroaxis at specified positions
> 1262281 Povray terminal driver
> 1251204 Real 3d perspectivic look to splot
> 1193448 Use allterm.h for texinfo documentation
> 1185346 Autoscaling with constraint on final range.
> 1123355 Support a header file in epslatex terminal
> 1052938 Fix incorrect alignment of rotated multiline text
> 1044573 change density of generated tics
> 936695 Some new logos
> 760421 plot smooth, with set log y
> 633724 new terminals:Python/Tk and Ruby/Tk
> 632289 new dgrid3d options: scaling and range
> 588805 external functions via plugins
> 551439 plot ... index by name instead of number
No change
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-04-15 04:51:24
|
On Sunday 29 January 2006 08:54 pm, Ethan A Merritt wrote:
>
> Here is my evaluation of the state of the code base, and the
> collection of bugs/patches/feature-requests on SourceForge.
Updated 14 Apr 2006
> Core code
> ===========
>
> Issues:
>
> - How many of the new options should be enabled by default?
> Should any of them continue to be marked EXPERIMENTAL?
Here's my scorecard from recent discussion on the list
rectangles and other objects keep as EXPERIMENTAL
plot style image remove warning
verify every pixel coordinate back out of cvs altogether
general binary data file reading mixed opinions
X11 polygon info in binary remove warning
string variables remove warning
command line macros remoce warning
> - Can we confirm that the code builds and runs on amiga? VMS?
I successfully built recent cvs on VMS. No word from any amiga fans.
I propose we drop any claims of amiga support for gnuplot
versions > 3.7
The code can stay, but no one knows if it works.
> Known bugs:
>
> - Clipping, particularly of arrows and filled polygons
> This is the only known bug that I consider release-critical.
Arrow clipping is now done in the core code.
Filled rectangles are also clipped in the core (mostly).
There are known problems with external libraries supporting
specific drivers (gd, pdf) but we may not be able to fix those.
> - Treatment of "missing" data as opposed to "invalid" data.
> I think this is more a matter of poor documentation than an actual
> bug, but I could be wrong. In any event, it's not fixable until
> someone can point to an unambiguous statement of what *should*
> happen in both cases, and a reproducible example that doesn't act
> that way. SF bugs #775810 #918793 #969322 #1403945
No change
> - Miscellaneous open bug reports on SourceForge
> #1184989 set key below noautotitles; plot x -- crash
> #1182499 set terminal doesn't automatically close output
> #1058117 Legend Disappears on Some Plots
> #1024394 bug on time/data format
These are marked as assigned to broeker
I believe they can be closed. Can you confirm this?
> #1346814 cannot unset mxtics for time data
I think this one is user error rather than a bug.
> #1408955 ytics have wrong date with ydata time and "using 2"
> #1363641 dgrid3d / xrange interaction
> #1158281 plotting a ternary function with undefined values
> #1107709 plot [-1:1] x is plotted with asymmetric y-axis
> #1042785 reversed axis range breaks filled curves
> #1039309 Strange xtics on 'time' plot
> #1004754 Tics and grid slightly outside border.
> #992528 `set offset` can break `with filledcurves`
> #634506 plotting a subrange of a contour plot
No change
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
