Re: ***[Possible UCE]*** Re: x11 terminal size (was Re: tiny fonts with wxt term)

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

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/