gnuplot-beta — Developers and beta testers of new gnuplot code

Re: default: x11 or wxt?

[<tim...@en...>]

> On SUSE 10.0, I can see the following problem with wxt: the mouse curso=
r
> is
> white. Thus you don't see the pointer on white graph background. We tri=
ed
> to
> debug it with Timothee some time ago, and it turned out to be due to a
> combination of the wx (2.6.1) et al libraries, which is obviously fixed=
 in
> newer wx. Does somebody else see this problem?

Strange problem, indeed. It would help to have other reports.


> Would it be helpful if wxterminal supports -background command line
> option?
> Or the config dialog could have an option to change the background colo=
r.

I thought the new rectangle feature by Ethan could provide that without
anything special in the terminal, as it is done in the demos:

set style rectangle back fc lt -3 fillstyle  solid 1.00 border -1

Am I right ?

>
> BTW, in the wxt "config" dialog, I propose to write "(-persist)" instea=
d
> of
> "(persist)", etc.

I guess you are thinking of the command line option. Please note that you
can also use 'set term wxt persist', so the '-' would be misleading in
that case.

Best regards,

Timoth=E9e

>
> ---
> PM

Re: default: x11 or wxt?

[Petr M. <mi...@ph...>]

On SUSE 10.0, I can see the following problem with wxt: the mouse cursor is 
white. Thus you don't see the pointer on white graph background. We tried to 
debug it with Timothee some time ago, and it turned out to be due to a 
combination of the wx (2.6.1) et al libraries, which is obviously fixed in 
newer wx. Does somebody else see this problem?

Would it be helpful if wxterminal supports -background command line option?
Or the config dialog could have an option to change the background color.

BTW, in the wxt "config" dialog, I propose to write "(-persist)" instead of 
"(persist)", etc.

---
PM

Re: tiny fonts with wxt term

[Richard H. <r.h...@rl...>]

Timothée Lecomte wrote:

<snip previous conversation> 

> 
> Ok.
> 
> Next serie of questions :
> 
> Are you using a recent CVS checkout (recent is quite large here, I did not
> change the code for months now) ?

I checked out the code during late august 2006.

> What's your version of pango ?
> 

pango version: 1.10.2.21

> I will dig into the code and see what I can find.
> 
> Thank you for your testing.
> 

your welcome! It's a great piece of software which I am please to be able to
help with!

cheers,
Richard

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

[Ethan A M. <merritt@u.washington.edu>]

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

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

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

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

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/

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

[Ethan A M. <merritt@u.washington.edu>]

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

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

[<br...@ph...>]

Daniel J Sebald wrote:
> Hans-Bernhard Br=F6ker wrote:

> But that turns out to be the case, from the evidence I see. =20

You're misinterpreting the evidence.  A sequence of examples doesn't=
=20
prove a design.

In other words, the success you saw is a random accident.

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.

But the problem is *not* that this default doesn't match the 4096x409=
6=20
terminal size. It's that it doesn't match the default h_tic and v_tic=
=20
settings.

The core issue is a missing feature: X11 doesn't update its h_tic and=
=20
v_tics if the graph window changes size.

> 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

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.

You're mistaking random coincidence for design.

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

[<br...@ph...>]

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.

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

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

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

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
>> 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

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

Re: tiny fonts with wxt term

[<tim...@en...>]

> Hi Timothee,
>
> Appologies for not following this thread up,

No problem.

>
>>
>> Please, Richard, answer to my previous mail (or this one ;) otherwise =
we
>> will never know where your problem comes from with wxt and we won't be
>> able to debug it. Please confirm that you are using "oversampling" by
>> looking at the configuration dialog in the wxt terminal (the tool icon
>> on
>> the right).
>
> my Rendering Method: Antialiasing and oversampling.

ok.

>
>> Please also run 'fc-list' in a console, it will give you a
>> list of fonts known to fontconfig.
>
> it returns 602 different fonts,

You definetely do not have any problem on this side.
>
>> Please also try :
>>
>> set term wxt font ",200"
>>
>> or another very large font size just in case.
>>
>
> I tried this with 20 in the beginning, but 200 makes the difference
> obvious:
> http://www2.warwick.ac.uk/cll/skills/eportfolio/students/eportfoliodire=
ctory/current/phrfaj/gnuplot200font.png
>
> With the font size set to 200, changing the font to one listed in the 6=
02
> list has the desired effect,
>
> r,

Ok.

Next serie of questions :

Are you using a recent CVS checkout (recent is quite large here, I did no=
t
change the code for months now) ?
What's your version of pango ?

I will dig into the code and see what I can find.

Thank you for your testing.

Best regards,

Timoth=E9e

Re: tiny fonts with wxt term

[Richard H. <r.h...@rl...>]

Timothée Lecomte wrote:

<snip previous conversation>

Hi Timothee, 

Appologies for not following this thread up,

> 
> Please, Richard, answer to my previous mail (or this one ;) otherwise we
> will never know where your problem comes from with wxt and we won't be
> able to debug it. Please confirm that you are using "oversampling" by
> looking at the configuration dialog in the wxt terminal (the tool icon on
> the right).

my Rendering Method: Antialiasing and oversampling.

> Please also run 'fc-list' in a console, it will give you a 
> list of fonts known to fontconfig. 

it returns 602 different fonts,

> Please also try : 
> 
> set term wxt font ",200"
> 
> or another very large font size just in case.
> 

I tried this with 20 in the beginning, but 200 makes the difference obvious:
http://www2.warwick.ac.uk/cll/skills/eportfolio/students/eportfoliodirectory/current/phrfaj/gnuplot200font.png

With the font size set to 200, changing the font to one listed in the 602
list has the desired effect,

r,

Re: default: x11 or wxt?

[<tim...@en...>]

> On Friday 01 September 2006 03:43 am, Richard Henwood wrote:
>> I installed wxt out of curiosity.
>> These are my general, initial impressions and thoughts:
>
>> I didn't work 'out of the box' for me - fonts are tiny.
>
> I too had font problems. Upgrading the support libraries and installing
> fontconfig made it work.  But a user guide to fonts would be a nice
> addition to the documentation.  Unfortunately, I myself only definitive=
ly
> understand fonts for PostScript and libgd.  The other terminal types I
> struggle with just as much as the next guy.

Fonts handling in general is very complicated because it eventually has t=
o
handle many aspects of the problem, and it's not always about "finding th=
e
font file" unfortunately.

Fontconfig is a tool to manage the fonts that are installed on your unix
system. If fontconfig does not know about any font, most graphic apps
including those based on gtk and qt won't work correctly or will choose
some ugly default font.

Pango is a higher level library that takes care of languages, fonts
aspects, characters coverage, and redering. It looks in the fonts
registered in fontconfig to find the one that is best suited to the chain
of utf8 characters that it has to render. This font is the one that
contains most of the characters of the given string (that's the "characte=
r
coverage" of the font) and that respects the style that the user asked fo=
r
(bold, oblique, sans, serif, or more strict requirements such as the font
name directly).

To the end user, there is very little to do on a recent distribution,
since pango and fontconfig have been used for years now.

Of course, in Richard's case, there must be a bug in the way I coded it
for the wxt terminal.

I agree that a general fonts user guide would be nice.

>> It is slower than x11, am I going to run into 'out of memory' problems=
 as
>> as well?
>
> Petr has been saying this also, but to me the response seems snappy
> enough.  It may be slower than x11, but on my machines the difference
> is not enough to matter.  It could again be a question partly of
> newer support libraries, and of course how fast is the CPU it runs
> on.

Richard, you're not going to run out-of-memory, nor will your computer
explode !

The wxt terminal provides anti-aliasing, and that's its unique feature.
Only The aqua terminal for mac is the only other terminal to provide it
too.

For those of you who have not tried its refreshed gnuplot taste yet, here
is a recycled screenshot (wxt on top, x11 on bottom):

http://tipote.free.fr/wxt19.png

Currently (and I should stress on "currently"), this better visual
rendering comes with a little slow-down compared to the x11 terminal. But
cairo (the underlying graphic library) is a fast-improving pease of
software, and you would be amazed to read the mailing list and see how
good is the work done on it, and how cooperative its development is. For
example, these days were proposed improvements from the leading developpe=
r
of the FreeType project (font antialiasing). X and mozilla developpers ar=
e
involved too. The algorithms currently used by cairo are known to be
suboptimal, and the wxt terminal uses the all-software rendering path. In
the future, we will profit from optimization in cairo as well as hardware
accelerated rendering, providing the state-of-the-art performance for
gnuplot at a low price since cairo and its friend libraries will do the
hard work for us.

In the mean time, if you want to keep x11 the default on top of wxt, it's
not a problem for me. However, in my opinion, the first use of gnuplot fo=
r
new users is mostly drawing 2D curves, and the wxt terminal does that muc=
h
nicer than the X11 terminal, and for no noticeable slowness. When it come=
s
to dense 3D plots or images, I agree that wxt is noticeably slower. If yo=
u
will, I can add a message in the wxt help, explaining that "native"
terminals (win and x11) can be used instead if performance is an issue.



>> Does gnuplot support alpha channel?
>
> Up until now it only supports an alpha channel in the sense that
> several terminal drivers (png jpeg gif) allow you to specify a
> transparent background.
>
> Adding additional support for transparency is high on my list
> of post-4.2 projects.  You can see a demo of preliminary support
> for transparent fill areas on
>     http://skuld.bmsc.washington.edu/people/merritt/gnuplot/
>
> So far I have it working fully for wxt, and partially for svg,
> png, jpeg, and pdf.  I will need to tap other people's expertise
> in order to extend support to additional terminal types.

Ethan, that's a very nice and valuable work !

Best regards,

Timoth=E9e

Re: default: x11 or wxt?

[<tim...@en...>]

> On Friday 01 September 2006 03:43 am, Richard Henwood wrote:
>> I installed wxt out of curiosity.
>> These are my general, initial impressions and thoughts:
>
>> I didn't work 'out of the box' for me - fonts are tiny.
>
> I too had font problems. Upgrading the support libraries and installing
> fontconfig made it work.  But a user guide to fonts would be a nice
> addition to the documentation.  Unfortunately, I myself only definitive=
ly
> understand fonts for PostScript and libgd.  The other terminal types I
> struggle with just as much as the next guy.

Fonts handling in general is very complicated because it eventually has t=
o
handle many aspects of the problem, and it's not always about "finding th=
e
font file" unfortunately.

Fontconfig is a tool to manage the fonts that are installed on your unix
system. If fontconfig does not know about any font, most graphic apps
including those based on gtk and qt won't work correctly or will choose
some ugly default font.

Pango is a higher level library that takes care of languages, fonts
aspects, characters coverage, and redering. It looks in the fonts
registered in fontconfig to find the one that is best suited to the chain
of utf8 characters that it has to render. This font is the one that
contains most of the characters of the given string (that's the "characte=
r
coverage" of the font) and that respects the style that the user asked fo=
r
(bold, oblique, sans, serif, or more strict requirements such as the font
name directly).

To the end user, there is very little to do on a recent distribution,
since pango and fontconfig have been used for years now.

Of course, in Richard's case, there must be a bug in the way I coded it
for the wxt terminal.

I agree that a general fonts user guide would be nice.

>> It is slower than x11, am I going to run into 'out of memory' problems=
 as
>> as well?
>
> Petr has been saying this also, but to me the response seems snappy
> enough.  It may be slower than x11, but on my machines the difference
> is not enough to matter.  It could again be a question partly of
> newer support libraries, and of course how fast is the CPU it runs
> on.

Richard, you're not going to run out-of-memory, nor will your computer
explode !

The wxt terminal provides anti-aliasing, and that's its unique feature.
Only The aqua terminal for mac is the only other terminal to provide it
too.

For those of you who have not tried its refreshed gnuplot taste yet, here
is a recycled screenshot (wxt on top, x11 on bottom):

http://tipote.free.fr/wxt19.png

Currently (and I should stress on "currently"), this better visual
rendering comes with a little slow-down compared to the x11 terminal. But
cairo (the underlying graphic library) is a fast-improving pease of
software, and you would be amazed to read the mailing list and see how
good is the work done on it, and how cooperative its development is. For
example, these days were proposed improvements from the leading developpe=
r
of the FreeType project (font antialiasing). X and mozilla developpers ar=
e
involved too, . The algorithms currently used by cairo are known to be
suboptimal, and the wxt terminal uses the all-software rendering path. In
the future, we will profit from optimization in cairo as well as hardware
accelerated rendering, providing the state-of-the-art performance for
gnuplot at a low price since cairo and its friend libraries will do the
hard work for us.

In the mean time, if you want to keep x11 the default on top of wxt, it's
not a problem for me. However, in my opinion, the first use of gnuplot fo=
r
new users is mostly drawing 2D curves, and the wxt terminal does that muc=
h
nicer than the X11 terminal, and for no noticeable slowness. When it come=
s
to dense 3D plots or images, I agree that wxt is noticeably slower. I can
add a message in the wxt help, explaining that "native" terminals (win an=
d
x11) can be used instead if performance is an issue.



>> Does gnuplot support alpha channel?
>
> Up until now it only supports an alpha channel in the sense that
> several terminal drivers (png jpeg gif) allow you to specify a
> transparent background.
>
> Adding additional support for transparency is high on my list
> of post-4.2 projects.  You can see a demo of preliminary support
> for transparent fill areas on
>     http://skuld.bmsc.washington.edu/people/merritt/gnuplot/
>
> So far I have it working fully for wxt, and partially for svg,
> png, jpeg, and pdf.  I will need to tap other people's expertise
> in order to extend support to additional terminal types.

Ethan, that's a very nice and valuable work !

Best regards,

Timoth=E9e

Re: tiny fonts with wxt term

[<tim...@en...>]

> Ethan Merritt wrote:
>
>> On Thursday 31 August 2006 01:47 am, Richard Henwood wrote:
>>>
>>> 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 was bitten by this problem also.
>> The wxt terminal obtains fonts via a shared desktop utility called
>> "fontconfig".  I was not using this utility prior to this, so on my
>> machines no configuration had been set up and wxt could not find any
>> useful fonts.
>>
>> Installing/running fontconfig will create an XML file
>> /etc/fonts/fonts.conf that tells the support libraries where to
>> find fonts on your system.
>>
>> It may also be that you do have a working fontconfig, but it
>> doesn't know about any TrueType fonts (e.g. arial) you may have
>> installed by other mechanisms.
>>
>
> hmmmm... I suspected that gnuplot was having problems finding fonts.
>
> However, fontconfig is set up, the xml is correctly configured, I think=
 it
> is working.

Please, Richard, answer to my previous mail (or this one ;) otherwise we
will never know where your problem comes from with wxt and we won't be
able to debug it. Please confirm that you are using "oversampling" by
looking at the configuration dialog in the wxt terminal (the tool icon on
the right). Please also run 'fc-list' in a console, it will give you a
list of fonts known to fontconfig. Please also try :

set term wxt font ",200"

or another very large font size just in case.

Thank you in advance.

Best regards,

Timoth=E9e

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

[<tim...@en...>]

> 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

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

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

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

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

[Ethan A M. <merritt@u.washington.edu>]

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

Re: tiny fonts with wxt term

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

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/

Re: tiny fonts with wxt term

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

Theo Hopman wrote:
> Daniel J Sebald wrote:
> 
>> Below is the before and after screen shot for a non-resized x11 window.
> 
> 
> In the "after" screen shot, the arrows are no longer at integer 
> multiples of 45 degrees. I don't know whether they were intended to be, 
> but in the "before" shot, they look like they are.
> 
> THeo

I was wondering if anyone would catch that.  I think the symmetry wasn't intended in this case.  Here's the code:

    xl = t->h_tic * 7;
    yl = t->v_tic * 7;
    i = curr_arrow_headfilled;
    curr_arrow_headfilled = 0;
    (*t->arrow) (x, y, x + xl, y, END_HEAD);
    curr_arrow_headfilled = 1;
    (*t->arrow) (x, y, x - xl, y, END_HEAD);
    curr_arrow_headfilled = 2;

etc.  It uses the horizontal and vertical tic, both of which are constants in x11.trm and defined as:

/* approximations for typical font/screen sizes */
# define X11_VCHAR (X11_YMAX/25)
# define X11_HCHAR (X11_XMAX/100)
# define X11_VTIC (X11_YMAX/100)
# define X11_HTIC (X11_XMAX/150)

How these definitions should have any relation to the screen or font "guesstimates", I'm not sure.

Suffice it to say that with the above definitions the xl and yl are not the same.  However, I patched gnuplot so that the plot size gnuplot is told matches the default in gplt_x11.c.  (Until someone manually resizes the window.)  The ratio for this test plot is 1:1.  Hence, to get symmetry xl and yl should be equal.

Dan

Re: tiny fonts with wxt term

[Theo H. <th...@ph...>]

Daniel J Sebald wrote:
> Below is the before and after screen shot for a non-resized x11 window.

In the "after" screen shot, the arrows are no longer at integer 
multiples of 45 degrees. I don't know whether they were intended to be, 
but in the "before" shot, they look like they are.

THeo

Re: tiny fonts with wxt term

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

Daniel J Sebald wrote:
> Richard Henwood wrote:
> 
> 
>>Anyway... here you go:
>>
>>http://www2.warwick.ac.uk/cll/skills/eportfolio/students/eportfoliodirectory/current/phrfaj/gnuplotproblems/gnuplotfontproblem2.png
> 
> 
> Furthermore, there is something interesting about the polygon
> compared to what I see in the x11 "test".  In your screenshot
> the polygon looks nice and symmetric.  In the x11 test on my
> screen (see below) I'm seeing an asymmetric polygon.  The
> aspect ration for the two screen shots is about the same.
> I can understand that the lines might be a different thickness
> and that sort of thing.  But why should the aspect ration of
> the polygon be so different?

This seems to be an issue with x11 dimensions.  (Guess I recall this now.)  test_term() assumes the ratio is 1:1 by virtue of

            for (i = 0; i < n; i++) {
                corners[i].x = cen_x + radius * cos(2*M_PI*i/n);
                corners[i].y = cen_y + radius * sin(2*M_PI*i/n);
            }

There is no attempt to make the polygon appear symmetric.  Of course, the formula could be appropriately scaled to attempt a symmetric hexagon, but even that won't work so well.  For the x11 terminal, t->xmax and t->ymax are fixed at 4096 in x11.trm.

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;

You'd think a logical choice would be to make the ratio t->xmax : t->ymax the same as the ratio gW : gH.  (I know, just change .geometry in the X resources.)

As a simple test, I've changed 

# define X11_YMAX 4096

to

# define X11_YMAX 2880

inside x11.trm.  Then in gplt_x11.c I've gone through and modified all the spots where a 4096 should be 2880 and 4095 should be a 2879 to get the plot aligned correctly.  (These numbers should be derived from a #define value.)

Below is the before and after screen shot for a non-resized x11 window.

Dan

Re: tiny fonts with wxt term

[Ethan A M. <merritt@u.washington.edu>]

On Friday 01 September 2006 01:54 am, Richard Henwood wrote:
> I just tried 'set term png font budmo' (i have budmo.ttf) and this exposed
> the fact that my GDFONTPATH wasn't set... I've fixed that: PNG works but
> problem remains in wxt.

It is an unfortunate fact that the font handling mechanisms for the
different terminal types are all different. They are not really under
our control, as it is done by external libraries.

The png/jpeg/gif terminals use libgd (with libfreetype underneath).

PostScript depends on the printer to find its own fonts, although
we do provide a mechanism for embedding fonts if necessary.

wxt - I don't understand very well, except that it uses pango

svg - I *really* don't understand very well, except to know that it
      seems to depend on the svg viewing program.  The Adobe svg
      plugin only recognizes fonts in some proprietary format.
      The firefox and konqueror svg plugins find at least some
      of my system fonts.  But I have not been able to get any of
      the plugins to find a font by its URL.

x11 - Simple fonts are easy.  Fancy stuff like multi-byte fonts or
      alternate character encodings are problematic.  Gnuplot
      provides   set term x11 font "mbfont:aa,bb,cc"
      for these cases, but setting it up correctly is difficult.

pdf - depends on the viewing program

windows, pm, etc - I don't use, and don't know anything about fonts.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742