Menu
▾
▴
gnuplot-beta
|
From: <tim...@en...> - 2006-09-13 10:35:38
|
Richard Henwood wrote: > On Wed, Sep 13, 2006 at 11:07:30AM +0200, Timoth=C3=A9e Lecomte wrote: > =20 >> Richard Henwood wrote: >> =20 >> >>> As you noted in other correspondence, the resizing 'bug' has been >>> fixed >>> =20 >> Ok. >> =20 >>> - although the text does not scale exactly with the drawings. >>> =20 >>> =20 >> I would need a screenshot or something to understand what you mean her= e. >> =20 > > ok, with 'Antialiasing'. - see attached > For example, the characters fill the box in default size, only half > fill in resize to ~half default and are 2x to big in 2x resize. > =20 Hmm, I never saw that. Thanks for reporting it. > Resizing, closing and then replotting the fonts appear to be the > same size as they are in default size. > =20 Yeas, that's how it is implemented. > I prefer the x11 behaviour on resize - where the fonts stay the same > size and I get more graph detail. > =20 Ok. > Does zooming by defining a region with right-click work? It doesn't > work on my version. I get 'function to plot' returned to the gnuplot > terminal. > =20 It does not work with 'test'. > >> With 'antialiasing and oversampling', you should read '_set_termvar=20 >> oversampling_scale =3D 20'. Can you verify if it's the case ? >> >> =20 > > With 'antialiasing and oversampling': > _set_termvar oversampling_scale =3D 20 > > and for the record, both 'No antialiasing' and 'Antialiasing' > _set_termvar oversampling_scale =3D 1 > =20 Ok, so there's no problem here. I'm starting to wonder if there could be=20 a problem with your version of pango and/or cairo. Could you tell me=20 what they are ? Thank you, best regards, Timoth=C3=A9e |
|
From: <tim...@en...> - 2006-09-13 10:41:29
|
Timoth=C3=A9e Lecomte wrote: > Richard Henwood wrote: > =20 > >> With 'antialiasing and oversampling': >> _set_termvar oversampling_scale =3D 20 >> >> and for the record, both 'No antialiasing' and 'Antialiasing' >> _set_termvar oversampling_scale =3D 1 >> =20 >> =20 Please also tell me the other lines (logical_rect.*). > Timoth=C3=A9e > > =20 |
|
From: <tim...@en...> - 2006-09-13 09:08:40
|
Richard Henwood wrote: > > The latest cvs and clear instructions and I'm getting the printf's. > Don't know what I got wrong but at least this is working. > =20 Good. > As you noted in other correspondence, the resizing 'bug' has been > fixed Ok. > - although the text does not scale exactly with the drawings. > =20 I would need a screenshot or something to understand what you mean here. > The results, from 'test': > > ... > System: Linux 2.6.16.21-0.13-smp > =20 Are you using a multiprocessor system ? That's interesting, because the=20 wxt terminal uses two threads and on such a system they would really run=20 in parallel unlike what happens on other machines like mine. > Copyright (C) 1986 - 1993, 1998, 2004 > Thomas Williams, Colin Kelley and many others > > Type `help` to access the on-line reference manual. > The gnuplot FAQ is available from > http://www.gnuplot.info/faq/ > > Send comments and help requests to > <gnu...@li...> > Send bug reports and suggestions to > <gnu...@li...> > > > Terminal type set to 'wxt' > gnuplot> test > _set_termvar fontsize =3D 10.000000 > _set_termvar PANGO_SCALE =3D 1024 > _set_termvar oversampling_scale =3D 1 > _set_termvar logical_rect.height =3D 16384 > _set_termvar logical_rect.width =3D 77824 > gnuplot> > > The font still look tiny with 'antialiasing and oversampling' > =20 With 'antialiasing and oversampling', you should read '_set_termvar=20 oversampling_scale =3D 20'. Can you verify if it's the case ? Best regards, Timoth=E9e |
|
From: <tim...@en...> - 2006-09-12 17:01:38
|
Richard Henwood wrote: > On Tue, Sep 12, 2006 at 09:59:23AM +0200, Timoth=C3=A9e Lecomte wrote: > =20 >> Richard Henwood wrote: >> =20 >>> see attached screenshot. >>> =20 >> Looks like I'm not the only one to forget to attach things... ;) >> >> =20 > > Indeed! > > second time lucky: > =20 Ok, so the enhanced text mode suffer from the same problem. Thanks. Timoth=C3=A9e > r, > =20 > > -----------------------------------------------------------------------= - > |
|
From: <tim...@en...> - 2006-09-12 17:17:44
Attachments:
debug_richard.diff
|
Richard Henwood wrote:
> On Tue, Sep 12, 2006 at 12:05:44AM +0200, Timoth=E9e Lecomte wrote:
>
> <snip>
>
> =20
>> To apply the patch, go to the cvs checkout directory, and then:
>>
>> cd src/wxterminal
>> patch -p1 < debug_richard.diff
>> cd ../..
>>
>> =20
>
> hmmmmmm, I think i've made a bit of a pigs ear of this:
>
> src/wxterminal> patch -p1 < /tmp/debug_richard.diff
> patching file gp_cairo.c
> Reversed (or previously applied) patch detected! Assume -R? [n] y
> Hunk #2 FAILED at 1602.
> Hunk #3 FAILED at 1611.
> 2 out of 3 hunks FAILED -- saving rejects to file gp_cairo.c.rej
> src/wxterminal>
>
> I answered y, maybe that should have been a 'N'?
> =20
That's my fault, I forgot to remove the CVS id at the beginning of the=20
diff file, and the 'patch' command probably got confused. Answering 'n'=20
should have been ok.
> =20
>> Finally recompile with make; make install
>>
>> Once you've done that, try with your favorite plot command ('test' is=20
>> fine) and please send me the output messages you obtain with and witho=
ut=20
>> oversampling.
>>
>> =20
>
> Ok, in the end I cut an pasted the diffd lines into gp_cairo.c and
> make' worked. Can I just run ./src/gnuplot - avoiding to need to
> make install?
> =20
Sure.
> I don't get any printf output with test.
> =20
Really ?? That's _very_ strange : if you placed this this serie of =20
printf at the right place, the output _must_ appear at least once per pl=
ot.
> So, apologies for my clumsiness, but:
> can you advise if I should start with a new
> checkout from CVS and if I should press y/n to the 'Assume -R?'
> query from patch.
> =20
If you cut and paste manually, that should be enough. Use the attached=20
patch with a fresh cvs checkout if you prefer.
Could you put your gnuplot source directory and send it to me ? I wonder=20
if you don't have some problem with the source itself, and with a little=20
case I could even try to run your executable on my machine. (however,=20
don't send it to the whole list to avoid loading others' mailboxes)
Best regards, and thanks again for your help to debug this,
Timoth=E9e
|
|
From: <tim...@en...> - 2006-08-31 21:18:12
|
Richard Henwood a =E9crit : > Hi folks, > > I have a CVS gnuplot compiled on my 64bit Suse 10.1 with Gnome Desktop > > G N U P L O T > Version 4.1 patchlevel 0 > last modified August 2006 > System: Linux 2.6.16.21-0.13-smp > > The font size with wxt terminal is tiny by default, ie ~ 1 pixel of the > default window size on my disply (1600x1200). > > I've tried: > set term wxt font "Arial,12" > > and other values but this has no effect. > > Trawling through pango messages sends me off to gtk etc, all without > anything that I can make sense of. > > All the other apps (like Inkscape, which I think use pango) look fine. > =20 Hi Richard, Thank you for trying gnuplot with the wxt terminal. By default, the wxt=20 terminal chooses the font "Sans" (which may be considered as a generic=20 font name, pango may choose whatever "sans" font it has) for the size 10. I will need a couple more information to debug that: can you tell me if=20 the "oversampling" is enabled (look at the configuration dialog in the=20 plot window), and what version of pango you have ? A screenshot may be useful too. Best regards, Timoth=E9e |
|
From: Daniel J S. <dan...@ie...> - 2006-09-04 21:35:29
|
Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> Daniel J Sebald wrote:
>>
>>> Richard Henwood wrote:
>=20
>=20
>> This seems to be an issue with x11 dimensions. (Guess I recall this=20
>> now.) test_term() assumes the ratio is 1:1 by virtue of
>=20
>=20
> The issue is not with x11 dimensions. It's with the assumption that=20
> this code
>=20
>> for (i =3D 0; i < n; i++) {
>> corners[i].x =3D cen_x + radius * cos(2*M_PI*i/n);
>> corners[i].y =3D cen_y + radius * sin(2*M_PI*i/n);
>> }
>=20
>=20
> was ever supposed to yield a regular polygon.
But that turns out to be the case, from the evidence I see. Here's a bri=
ef summary of running "test" on the various output devices. I highlight =
the issue of discussion, but include some other notes. In all cases, I'm=
using the *defaults*.
PNG: Text at an angle doesn't work (fine). The boxed text at the center=
of the plot is super; box fits tightly around the 1234 etc. The hexagon=
is nicely SYMMETRIC. The arrows (star pattern) are symmetric.
FIG: I'm getting what doesn't look like a good warning message about the=
palette:
gnuplot> set term fig
Terminal type set to 'fig'
Options are 'monochrome small pointsmax 1000 landscape inches dashed text=
normal fontsize 10 linewidth 1 depth 10 version 3.2'
gnuplot> set output 'test.fig'
gnuplot> test
fig: Palette used before set
gnuplot> set output
in either case of specifying "color" or not. The hexagon is SYMMETRIC. =
The star pattern is symmetric. When in monochrome mode, the boxed text i=
n the center of the screen has a *dashed* box instead of a solid box beca=
use of the color chosen; however, the box doesn't tightly fit around the =
text. It does fit tightly around the text when in "color" mode. Fill pa=
tterns appear unique to fig (fine). The zeroeth pattern fill has a huge =
solid line outlining it.
WXT: Looking at Richard Henwood's example test after having gotten it to=
work, everything looks nice. The hexagon is SYMMETRIC. Star pattern sy=
mmetric.
PostScript, as viewed through gv: The only issue is that the box around =
1234... does not fit tightly (color or monochrome). The hexagon is SYMME=
TRIC.
PDF, as viewed by acroread: The hexagon is SYMMETRIC. The unusual thing=
is that the box around the text is in fact less than it should be as opp=
osed to the loose fit of other media.
GIF: Same as PNG.
JPEG: Similar to GIF/PNG but with a slightly more bold appearnce. Looks=
good.
tkcanvas: For what it is worth, "filled polygons not supported". The bo=
x around the text 1234... is much too small, by about 65%. The line widt=
h test works, but the lines have rounded ends rather than flat ends. "ca=
n't rotate text" appears (no angled text, no vertical text). The arrows =
do not form a symmetric pattern. No pattern fill.
latex: None of the rotated text works (creates a blob of overwritten lin=
es). Line widths don't work. No pattern fill. No hexagon ("filled poly=
gons not supported"). Box too small around the text 1234... Only monoch=
rome. Arrows symmetric but only one type of arrow head.
PBM: Monochrome says "filled po" but it is positioned far off the right =
end of the image. Text 1234... is nicely boxed. No angled text, just ho=
rizontal/vertical. No line widths. Color does work, looks exactly the s=
ame as monochrome.
x11: The text 1234... is boxed well horizontally, but vertically the box =
is too long to the bottom of the text. The hexagon is ASYMMETRIC.
OK, so there are little things here and there in the, perhaps, lesser use=
d terminals. It would be nice to have all the things addressed. But bac=
k to my orignal point about one of the more used terminals, x11.
In all the terminals types that produce filled polygons that I have exami=
ned, x11 is the only one for which the default produces an asymmetric, fo=
otball shaped object rather than a symmetric hexagon. The bottom line is=
that x11 is not consistent with the rest of the output devices.
So, although others think this isn't important, I do think it is importan=
t and maintaining proportionality is for the benefit of the user. I'm no=
t asking for NeXT-like Display Postscript WYSIWIG-ness, but something wit=
hin reason.
I may re-examine this some time this winter.
Dan
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-09-04 23:46:26
|
On Monday 04 September 2006 03:17 pm, Hans-Bernhard Br=F6ker wrote:
>=20
> The core issue is a missing feature: X11 doesn't update its h_tic and=20
> v_tics if the graph window changes size.
No, but it does update them every time a new font takes effect.
Whenever a new font is set, gnuplot_x11 returns the font size information
and the current window size information to the core via this call:
1713: gp_exec_event(GE_fontprops, plot->width, plot->height,
1714: scaled_hchar, scaled_vchar, 0);
=20
This is caught by lines 1890ff in mouse.c:
case GE_fontprops:
term->h_char =3D ge->par1;
term->v_char =3D ge->par2;
/* Update aspect ratio based on current window size */
term->v_tic =3D term->h_tic * (double)ge->mx / (double)ge->my;
/* EAM FIXME - We could also update term->xmax and term->ymax here,=
*/
/* but the existing code doesn't expect it to change. =
*/
break;
Since this code is triggered by a font change, however, it is not
invoked by the "test" command. Arguably the same update should be
triggered by a resize event, but currently it isn't. Nevertheless,
since most real plots set the font at least once, things have
worked well enough in practice.
I still think worrying about the aspect ratio of the test polygon
printed on the terminal "test" page is a waste of time. It would
be much more useful to spend the effort dealing with real bugs in
real plots, except that I don't know of any serious enough to hold
up the 4.2 release.
=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Daniel J S. <dan...@ie...> - 2006-09-05 00:33:09
|
Ethan A Merritt wrote: > I still think worrying about the aspect ratio of the test polygon > printed on the terminal "test" page is a waste of time. It would > be much more useful to spend the effort dealing with real bugs in > real plots, except that I don't know of any serious enough to hold > up the 4.2 release. Well, get the release out the door, because things will just get worse... What's that saying about an idle mind? :-) Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-09-05 00:26:41
Attachments:
testterm-djs-4sep2006.patch
|
Alright, got it. So let's be clear... 1) The method for which the arrows example on test_term() uses "h_tic" an= d "v_tic" IS the proper way to layout elements. In which case, the polyg= on example should ALSO derive its coordinates in a similar fashion. I ca= n live with that; everything in one coordinate system. Right? I've attached a patch that scales the y component of the radius. Could s= omeone please apply this? Things look correct for the patch. The default X11 window shows a polygo= n proportion similar to all the rest. 2) I now see the formula controlling aspect ratio: /* Update aspect ratio based on current window size */ term->v_tic =3D term->h_tic * (double)ge->mx / (double)ge->my; /* EAM FIXME - We could also update term->xmax and term->ymax here, */ /* but the existing code doesn't expect it to change. */ All you had to do was point me to that and I would have understood. The aspect ratio with the mouse for the default window is then: v_tic =3D 38 h_tic =3D 27 or 1.41. (640/450 is 1.42 so the loss of resolution isn't bad.) Without= the mouse update the default window aspect ratio from # define X11_VTIC (X11_YMAX/100) # define X11_HTIC (X11_XMAX/150) would be 40/27 or 1.48. Slight discrepency, but not too bad. Inherent in the way this code is set up is that the aspsect ratio of view= ing device in terms of dimensions is 1:1. There is nothing wrong with th= at assumption; its the most logical given no further information. It is = just that I see now why h_tic and v_tic are as they are for x11, because = the assumption in x11.trm is that the plot is square, i.e. 4096 x 4096. Now, I think I understand the approach here, it's to allow scaling the wi= ndow in the case that corrections can't be fed back (via the mouse or wha= tever). Something to think about is that perhaps the 4096, i.e., the XMA= X and YMAX that gnuplot thinks it is using can be fed over to gplt_x11.c.= Then rather than divide by 4096, in gplt_x11.c would be division by xma= x and ymax. Would the numbers work themselves out that way? Another thing. Rather than fixing 4096 in the case where there is no inf= ormation about the x11 window, i.e., no mouse present, could x11.trm look= to some X resource to find the maximum screen size for the X11 display? = (If can't find that, then fall back on 4096.) Anyway, not of critical importance. Dan Hans-Bernhard Br=F6ker wrote: > Daniel J Sebald wrote: >=20 >> Hans-Bernhard Br=F6ker wrote: >=20 >=20 >> But that turns out to be the case, from the evidence I see. =20 >=20 >=20 > You're misinterpreting the evidence. A sequence of examples doesn't=20 > prove a design. >=20 > In other words, the success you saw is a random accident. >=20 > You stress the point that you used the *defaults* (your emphasis) for > all the terminals. And exactly there lies the problem: there is no > such thing as a universal "default" for the X11 terminal's actual > output window size. It can be overriden by a whole collection of > mechanism, half of which outside the control of gnuplot, by design=20 > (thing app defaults, X11 window managers, auto-placement, ...). In=20 > other words, the problem is at least partly a bad choice of default=20 > window size for x11. >=20 > But the problem is *not* that this default doesn't match the 4096x4096=20 > terminal size. It's that it doesn't match the default h_tic and v_tic=20 > settings. >=20 > The core issue is a missing feature: X11 doesn't update its h_tic and=20 > v_tics if the graph window changes size. >=20 >> In all the terminals types that produce filled polygons that I have=20 >> examined, x11 is the only one for which the default produces an=20 >> asymmetric, football shaped object rather than a symmetric hexagon. =20 >=20 >=20 > And now I suggest you repeat that same exercise on but switch your=20 > screen resolution to 1024x768, and 1280x1024 (both stretched to=20 > full-screen, no black bars around the picture). Look closely, and=20 > you'll find that all of a sudden, half of those formerly regular=20 > hexagons are now distorted, too, in at least one of those modes. >=20 > You're mistaking random coincidence for design. >=20 --=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-05 00:42:55
|
On Monday 04 September 2006 05:36 pm, Daniel J Sebald wrote: > Rather than fixing 4096 in the case where there is no information > about the x11 window, i.e., no mouse present, could x11.trm look to > some X resource to find the maximum screen size for the X11 display? (If can't find that, then fall back on 4096.) Dan, *please* just drop this. You fundamentally misunderstand what this number is used for. It has nothing, repeat nothing, to do with either the window size or the screen size. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
