Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2006-09-03 20:53:22
|
Hans-Bernhard Br=F6ker wrote: > Daniel J Sebald wrote: [snip] >> There is no attempt to make the polygon appear symmetric. Of course,=20 >> the formula could be appropriately scaled to attempt a symmetric=20 >> hexagon, but even that won't work so well. =20 >=20 >=20 > It will, if the attempt is made properly. Using the appearance of this= =20 > hexagon as a guide to "correct" x11.trm and gplt_x11.c can only make=20 > things worse, not better. I hear you. My alteration was just a proof of concept, hence I didn't pu= t together any formal patch. A proper attempt can be made, and should be= in my opinion. >=20 >> The ramifications of that are not that important right now, but I do=20 >> wonder why if x11.trm assumes 4096 by 4096 the default window size in=20 >> gnuplot_x11 is >> >> static unsigned int gW =3D 640, gH =3D 450; >=20 >=20 > Because those two are completely separate things. Terminal coordinates= =20 > don't have to be identical to screen pixels --- and for a terminal like= =20 > x11, which can be rescaled on the fly, without the core's knowledge,=20 > they can't be. Well, yes. Once the plot is done, resizing the window will distort the p= lot. However, if by resizing the window the t->xmax and t->ymax are upda= ted accordingly, a "replot" could redraw the plot in the proportions appr= opriate for the new xmax/ymax. The utility of that approach is that it gives the user a rough, but reaso= nable estimate of what the eventual plot might look like in a different o= utput format, e.g., proportions of histogram thickness to height. One co= uld experiment with different aspect ratios for the borders. I think it has a use. It would at least be worth trying, to see if devel= opers like its behavior. Maybe a good time to look at that is when the p= age/graph/plot (or whatever it was) coordinate systems idea is revisited. Dan --=20 Dan Sebald phone: 608 256 7718 email: daniel DOT sebald AT ieee DOT org URL: http://webpages DOT charter DOT net/dsebald/ |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-09-03 22:05:30
|
On Sunday 03 September 2006 02:03 pm, Daniel J Sebald wrote:
>
> My alteration was just a proof of concept,
> hence I didn't put together any formal patch.
> A proper attempt can be made, and should be in my opinion.
> >
> >> The ramifications of that are not that important right now, but I do
> >> wonder why if x11.trm assumes 4096 by 4096 the default window size in
> >> gnuplot_x11 is
> >>
> >> static unsigned int gW = 640, gH = 450;
Can we just drop this discussion?
I don't think it is going in any useful direction.
(1) You are talking about the output of "test", which doesn't go
through any of the normal scaling routines nor any of the plot
layout code.
(2) I *like* the behavior of the x11 terminl window.
It dynamically resizes the plot to fit the current
window size, which is exactly what I want and expect.
By way of contrast, the wxt terminal is very annoying in
that after resizing the window, the plot it contains fills
only some non-obvious fraction of the new size
As to 4096x4096, that is the resolution to which the terminal
coordinates are kept. The anti-aliasing would be improved if
it were increased to some larger value, but that turns out to be
messy. I tried it at one point, but gave it up because I broke
too many things in the process. I'm sure it's possible, but it's
non-trivial.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Daniel J S. <dan...@ie...> - 2006-09-04 00:15:38
|
Ethan A Merritt wrote: > On Sunday 03 September 2006 02:03 pm, Daniel J Sebald wrote: > >>My alteration was just a proof of concept, >>hence I didn't put together any formal patch. >>A proper attempt can be made, and should be in my opinion. >> >>>>The ramifications of that are not that important right now, but I do >>>>wonder why if x11.trm assumes 4096 by 4096 the default window size in >>>>gnuplot_x11 is >>>> >>>>static unsigned int gW = 640, gH = 450; > > > Can we just drop this discussion? > I don't think it is going in any useful direction. > > (1) You are talking about the output of "test", which doesn't go > through any of the normal scaling routines nor any of the plot > layout code. > > (2) I *like* the behavior of the x11 terminl window. > It dynamically resizes the plot to fit the current > window size, which is exactly what I want and expect. That's is fine. > By way of contrast, the wxt terminal is very annoying in > that after resizing the window, the plot it contains fills > only some non-obvious fraction of the new size That's not so nice > > As to 4096x4096, that is the resolution to which the terminal > coordinates are kept. The anti-aliasing would be improved if > it were increased to some larger value, but that turns out to be > messy. I tried it at one point, but gave it up because I broke > too many things in the process. I'm sure it's possible, but it's > non-trivial. You must agree that by fixing the dimensions that the x11 display doesn't actually display in proper proportions for some plot elements. (Unless the user resizes to a square window.) That seems like an unfortunate thing somehow. If there is some aliasing issue, the value of the dimensions isn't important, the proportion is. And if some ridiculous proportion comes about because the user resizes to say 800 x 4, well then maintaining proportionality isn't that important. Anyway, there is no easy way to modify t->xmax or t->ymax, is there? The simplest solution would have to be a new term option "set term x11 size X,Y" and then have gplt_x11.c use gp_exec_event(). Dan |
|
From: <tim...@en...> - 2006-09-04 12:22:16
|
> Ethan A Merritt wrote: >> On Sunday 03 September 2006 02:03 pm, Daniel J Sebald wrote: >> >>>My alteration was just a proof of concept, >>>hence I didn't put together any formal patch. >>>A proper attempt can be made, and should be in my opinion. >>> >>>>>The ramifications of that are not that important right now, but I do >>>>>wonder why if x11.trm assumes 4096 by 4096 the default window size i= n >>>>>gnuplot_x11 is >>>>> >>>>>static unsigned int gW =3D 640, gH =3D 450; >> >> >> Can we just drop this discussion? >> I don't think it is going in any useful direction. >> >> (1) You are talking about the output of "test", which doesn't go >> through any of the normal scaling routines nor any of the plot >> layout code. >> >> (2) I *like* the behavior of the x11 terminl window. >> It dynamically resizes the plot to fit the current >> window size, which is exactly what I want and expect. > > That's is fine. > >> By way of contrast, the wxt terminal is very annoying in >> that after resizing the window, the plot it contains fills >> only some non-obvious fraction of the new size > > That's not so nice I have heard you, guys. It looks like the old and well-known behaviour of the x11 terminal has more weight than my little ideas about aspect ratios. Give me a couple of days and I'll revert the behaviour of the wxt termina= l to make it work as the x11 one does. Timoth=E9e |
|
From: Daniel J S. <dan...@ie...> - 2006-09-04 21:42:47
|
Hans-Bernhard Br=F6ker wrote: > Daniel J Sebald wrote: >=20 >> You must agree that by fixing the dimensions that the x11 display >> doesn't actually display in proper proportions for some plot >> elements. (Unless the user resizes to a square window.) =20 >=20 >=20 > It looks like you're stilling missing the point. The ratio of x and y=20 > coordinate ranges in the terminal definition has *no* direct relation t= o=20 > the actual size of the window. There's a coordinate transformation=20 > between the two. The core code knows that. Its way of taking care of=20 > such things are the v_tic and h_tic elements. *These* are the ones tha= t=20 > have to end up equally long on the output medium. That's why the arrow= s=20 > in the demo, and the implementation of "set size ratio -1", refer to=20 > v_tic and h_tic. >=20 >> Anyway, there is no easy way to modify t->xmax or t->ymax, is there? >=20 >=20 > Depends on what you call easy. X11 already modifies the font size=20 > on-the-fly, by using feed-back from x11.trm to the X11 window and back=20 > to x11.trm (see X11_graphics()). There's no particularly strong reason= =20 > that would keep it form doing the same for the size. OK, I wasn't clear on the v_tic/h_tic usage. So, does this mean that "te= rm_test" should not by using t->xmax, but rather some function of t->h_ti= c? Same for v_tic/ymax? Let me look quick at "test" results again... Well, it is difficult to ju= dge the relationship of the little tics on "test" given how small they ar= e. (Displaying 10x the tic values would be nicer.) But from what I see = all terminals have v_tic equal to h_tic (on my monitor) including x11. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-09-04 21:48:22
|
Daniel J Sebald wrote: > OK, I wasn't clear on the v_tic/h_tic usage. So, does this mean that "term_test" should not by using t->xmax, but rather some function of t->h_tic? Same for v_tic/ymax? The problem with that is that here are the definitions for v_tic and h_tic in x11.trm. /* approximations for typical font/screen sizes */ # define X11_VCHAR (X11_YMAX/25) # define X11_HCHAR (X11_XMAX/100) And since v_tic and h_tic are unsigned int, there is potentially a loss of resolution in using v_tic/h_tic as measures of aspect ratio for the output device. Dan |
|
From: <br...@ph...> - 2006-09-04 22:03:51
|
Daniel J Sebald wrote: > OK, I wasn't clear on the v_tic/h_tic usage. Yes. And that's what I've been telling you for days, now. > So, does this mean that "term_test" should not by using t->xmax, but > rather some function of t->h_tic? If the aim is to get a visually regular hexagon: absolutely. And not just "should" it do so: it does, to get the arrows to point into 45 degree directions. > are. (Displaying 10x the tic values would be nicer.) Coincidentally, that's precisely what the filled hexagon does... Which provides a rather strong argument to keep it exactly as it is. > But from what I see all terminals have v_tic equal to h_tic (on my > monitor) including x11. Yes. Because your monitor, and all the other terminals you tested (in the size you did test them) have a 1:1 pixel aspect ratio in terminal coordinates, i.e. the ratio term->x_max/term->y_max matches the physical edge ratio of your on-screen display. |
