Re: x11 terminal size (was Re: tiny fonts with wxt term)

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

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