Menu
▾
▴
gnuplot-beta
|
From: Richard H. <r.h...@rl...> - 2006-08-31 10:55:07
|
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.
Any suggestions?
richard
|
|
From: Daniel J S. <dan...@ie...> - 2006-08-31 20:49:52
|
Richard Henwood wrote: > 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). 1 pixel? Not much info that can be conveyed with that, is there? Have you confirmed that wxt is working with some other application on your system and that this is isolated to gnuplot? What does "test" look like on your system? Could you create a screen capture? Richard, we've just had a discussion about wxt/x11. You chose wxt because why? It was the default? Just curious. Ethan, is there some other terminal in which the font heights would behave similar to wxt and might be illustrated on Richard's system? Dan |
|
From: Richard H. <r.h...@rl...> - 2006-09-01 08:04:19
|
Daniel J Sebald wrote: > Richard Henwood wrote: >> 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). > > 1 pixel? Not much info that can be conveyed with that, is there? > > Have you confirmed that wxt is working with some other application on your > system and that this is isolated to gnuplot? > > What does "test" look like on your system? Could you create a screen > capture? > Hi Dan, Indeed: a screen shot is worth a thousand words. I regularly skim posts to gnuplot usenet, looking for screenshots to see what people are up to... so I should be been more forthcoming myself! Anyway... here you go: http://www2.warwick.ac.uk/cll/skills/eportfolio/students/eportfoliodirectory/current/phrfaj/gnuplotproblems/gnuplotfontproblem2.png > Richard, we've just had a discussion about wxt/x11. You chose wxt because > why? It was the default? Just curious. > Once I got it compiled in, it was the default so it sorta' chose me! I'll follow up to 'default: x11 or wxt' thread. r, |
|
From: Daniel J S. <dan...@ie...> - 2006-09-02 19:25:02
|
Richard Henwood wrote: > Anyway... here you go: > > http://www2.warwick.ac.uk/cll/skills/eportfolio/students/eportfoliodirectory/current/phrfaj/gnuplotproblems/gnuplotfontproblem2.png Thanks. Well, clearly the font is tiny. 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? >>Richard, we've just had a discussion about wxt/x11. You chose wxt because >>why? It was the default? Just curious. >> > > > Once I got it compiled in, it was the default so it sorta' chose me! > I'll follow up to 'default: x11 or wxt' thread. OK, well that is something for the developers to think about. If we are going to have wxt as one of the defaults on some systems, we should be reasonably certain it works. We don't want the community's first impression of wxt to be negative. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-09-03 00:38:28
Attachments:
test-x11.png
test-x11-patched.png
|
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 |
|
From: Theo H. <th...@ph...> - 2006-09-03 02:46:42
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2006-09-03 03:15:39
|
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
|
|
From: <br...@ph...> - 2006-09-04 22:15:23
|
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. |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-08-31 21:11:55
|
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. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Richard H. <r.h...@rl...> - 2006-09-01 08:55:39
|
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. 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. r, |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-09-02 22:24:43
|
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
|
|
From: <tim...@en...> - 2006-09-04 12:38:57
|
> 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 |
|
From: Richard H. <r.h...@rl...> - 2006-09-04 13:27:32
|
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, |
|
From: <tim...@en...> - 2006-09-04 20:42:31
|
> 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 |
|
From: Richard H. <r.h...@rl...> - 2006-09-05 07:26:14
|
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 |
|
From: <tim...@en...> - 2006-09-06 12:32:36
|
Richard Henwood wrote:
> Timoth=C3=A9e Lecomte wrote:
>
> <snip previous conversation>
<snip again>
Richard, can you also try without oversampling ? ("Rendering method =3D=20
antialiasing" or "no antialiasing")
Thank you.
Best regards,
Timoth=C3=A9e
|
|
From: Richard H. <r.h...@rl...> - 2006-09-06 12:50:28
|
Timothée Lecomte wrote:
> Richard Henwood wrote:
>> Timothée Lecomte wrote:
>>
>> <snip previous conversation>
> <snip again>
>
> Richard, can you also try without oversampling ? ("Rendering method =
> antialiasing" or "no antialiasing")
>
After switching to "without oversampling on both 'antialiasing' or 'no
antialiasing'" the fonts look fine. However I need to close wxt term and
reopen in order to get this working predictably.
If I make the changes to the rendering method and then resize, without
closing/reopening the result is unpredictable, including: huge fonts, only
some text displayed, graphics become pixelated, even a lockup.
HTH
r,
|
|
From: <tim...@en...> - 2006-09-10 17:11:22
|
Richard Henwood wrote:
> Timoth=C3=A9e Lecomte wrote:
>
> =20
>> Richard Henwood wrote:
>> =20
>>> Timoth=C3=A9e Lecomte wrote:
>>>
>>> <snip previous conversation>
>>> =20
>> <snip again>
>>
>> Richard, can you also try without oversampling ? ("Rendering method =3D
>> antialiasing" or "no antialiasing")
>>
>> =20
>
> After switching to "without oversampling on both 'antialiasing' or 'no
> antialiasing'" the fonts look fine. However I need to close wxt term an=
d
> reopen in order to get this working predictably.
> =20
Typically you change the rendering method, click 'Ok' or 'Apply', and=20
type 'replot' in the command line. Closing the terminal should not be=20
needed (all the more since it only hides the window but does not do=20
anything else actually), exiting gnuplot should not be needed too.
So, the bug only appears when the rendering method is set to=20
'Antialiasing and oversampling', right ?
Can you tell me if a font of size 200 with 'Antialiasing and=20
oversampling' looks exactly the same as a size of 10 without=20
'oversampling' ?
(the oversampling precisely involves a scaling of 20)
> If I make the changes to the rendering method and then resize, without
> closing/reopening the result is unpredictable, including: huge fonts, o=
nly
> some text displayed, graphics become pixelated, even a lockup.
> =20
Indeed. For this to work as expected, I would have not to change the=20
internal variables immediately, but schedule the change for the time of=20
the next plot. Maybe I should do that before the release...
> HTH
> r,
> =20
Best regards,
TImoth=C3=A9e
|
|
From: <tim...@en...> - 2006-09-10 17:54:02
|
Timoth=C3=A9e Lecomte wrote: > ... > So, the bug only appears when the rendering method is set to=20 > 'Antialiasing and oversampling', right ? > Can you tell me if a font of size 200 with 'Antialiasing and=20 > oversampling' looks exactly the same as a size of 10 without=20 > 'oversampling' ? > (the oversampling precisely involves a scaling of 20) > > =20 And please note that the two fixes that I have just committed are=20 unfortunately unrelated to your problem... Timoth=C3=A9e |
|
From: <tim...@en...> - 2006-09-10 22:18:08
|
Timoth=C3=A9e Lecomte wrote: > Richard Henwood wrote: > > =20 >> If I make the changes to the rendering method and then resize, without >> closing/reopening the result is unpredictable, including: huge fonts, = only >> some text displayed, graphics become pixelated, even a lockup. >> =20 >> =20 > Indeed. For this to work as expected, I would have not to change the=20 > internal variables immediately, but schedule the change for the time of= =20 > the next plot. Maybe I should do that before the release... I just commited a change to do that, so that particular misbehaviour on=20 window resize right after a change of the rendering settings is fixed.=20 Unfortunately, I still have not found the source of your first problem. Best regards, Timoth=C3=A9e |
|
From: Richard H. <r.h...@rl...> - 2006-09-11 10:25:18
|
Timothée Lecomte wrote: > Richard Henwood wrote: >> Timothée Lecomte wrote: <snips'> >> > Typically you change the rendering method, click 'Ok' or 'Apply', and > type 'replot' in the command line. Closing the terminal should not be > needed (all the more since it only hides the window but does not do > anything else actually), exiting gnuplot should not be needed too. > > So, the bug only appears when the rendering method is set to > 'Antialiasing and oversampling', right ? correct. > Can you tell me if a font of size 200 with 'Antialiasing and > oversampling' looks exactly the same as a size of 10 without > 'oversampling' ? It does not look _exactly_ the same. The font appears to be the same size but on switching there is some slight movement in exact positions of text. It is very slight an I can only notice it because I watch it switch. > (the oversampling precisely involves a scaling of 20) > >> If I make the changes to the rendering method and then resize, without >> closing/reopening the result is unpredictable, including: huge fonts, >> only some text displayed, graphics become pixelated, even a lockup. >> > Indeed. For this to work as expected, I would have not to change the > internal variables immediately, but schedule the change for the time of > the next plot. Maybe I should do that before the release... it would be desirable from my point of view. r, |
|
From: <tim...@en...> - 2006-09-11 16:35:50
|
Richard Henwood a =C3=A9crit : > Timoth=C3=A9e Lecomte wrote: > =20 >> So, the bug only appears when the rendering method is set to >> 'Antialiasing and oversampling', right ? >> =20 > > correct. > > =20 >> Can you tell me if a font of size 200 with 'Antialiasing and >> oversampling' looks exactly the same as a size of 10 without >> 'oversampling' ? >> =20 > > It does not look _exactly_ the same. The font appears to be the same si= ze > but on switching there is some slight movement in exact positions of te= xt. > It is very slight an I can only notice it because I watch it switch. > =20 Ok, I was interested in the size in particular. So it seems the=20 oversampling scale is somehow not applied to the text on your setup.=20 That's strange... Could you please try the demo 'enhancedtext.dem' and tell me if it shows=20 the same issue ? (the text goes through a slightly different code path=20 for the enhanced text mode). Another question, most likely unrelated : what's your screen dpi ?=20 (dots-per-inch, this info is given by 'xdpyinfo' for example) >> >> =20 >>> If I make the changes to the rendering method and then resize, withou= t >>> closing/reopening the result is unpredictable, including: huge fonts, >>> only some text displayed, graphics become pixelated, even a lockup. >>> =20 >>> =20 >> Indeed. For this to work as expected, I would have not to change the >> internal variables immediately, but schedule the change for the time o= f >> the next plot. Maybe I should do that before the release... >> =20 > > it would be desirable from my point of view. > =20 This is committed. Best regards, Timoth=C3=A9e |
|
From: <tim...@en...> - 2006-09-11 22:06:51
|
Timoth=C3=A9e Lecomte wrote:
> Richard Henwood a =C3=A9crit :
> =20
>> Timoth=C3=A9e Lecomte wrote:
>> =20
>> =20
>>> So, the bug only appears when the rendering method is set to
>>> 'Antialiasing and oversampling', right ?
>>> =20
>>> =20
>> correct.
>>
>> =20
>> =20
>>> Can you tell me if a font of size 200 with 'Antialiasing and
>>> oversampling' looks exactly the same as a size of 10 without
>>> 'oversampling' ?
>>> =20
>>> =20
>> It does not look _exactly_ the same. The font appears to be the same s=
ize
>> but on switching there is some slight movement in exact positions of t=
ext.
>> It is very slight an I can only notice it because I watch it switch.
>> =20
>> =20
> Ok, I was interested in the size in particular. So it seems the=20
> oversampling scale is somehow not applied to the text on your setup.=20
> That's strange...
> Could you please try the demo 'enhancedtext.dem' and tell me if it show=
s=20
> the same issue ? (the text goes through a slightly different code path=20
> for the enhanced text mode).
>
> Another question, most likely unrelated : what's your screen dpi ?=20
> (dots-per-inch, this info is given by 'xdpyinfo' for example)
I hope I am not asking too much... Richard, could you please apply the=20
attached patch to your gnuplot checkout ? It will add a couple of=20
debugging messages that would help me greatly.
To apply the patch, go to the cvs checkout directory, and then:
cd src/wxterminal
patch -p1 < debug_richard.diff
cd ../..
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 without=20
oversampling.
(we could also meet on irc, #gnuplot on freenode)
Thank you very much.
Best regards,
Timoth=C3=A9e
|
|
From: <tim...@en...> - 2006-09-11 22:13:06
Attachments:
debug_richard.diff
|
Timoth=C3=A9e Lecomte wrote: > > Richard, could you please apply the=20 > attached patch to your gnuplot checkout ? Oops, forgot to attach the patch, as usual. Sorry about that. Timoth=C3=A9e |
|
From: <tim...@en...> - 2006-09-13 22:23:47
|
Richard Henwood wrote: > On Wed, Sep 13, 2006 at 12:34:27PM +0200, Timoth=E9e Lecomte wrote: > =20 >> Richard Henwood wrote: >> =20 >>> On Wed, Sep 13, 2006 at 11:07:30AM +0200, Timoth=E9e Lecomte wrote: >>> =20 >>> =20 > <snip> > =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 >> 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 ? >> >> =20 > > cairo: 1.0.2-25 > pango: 1.10.2-21 > > wxGTK: 2.6.2.1-20 > > r, > =20 Well, I finally figured out the problem (the scaling matrix not applied=20 to the fonts), told about it on #freedesktop, and the friendly=20 pango/cairo guys told me that it got fixed in pango 1.10.3 (and newer,=20 we are at 1.14.3 right now). I can indeed reproduce the problem with=20 pango 1.10.2. Please update your pango copy if you can. Meanwhile, I'll bump the=20 needed version of pango to 1.10.3 in the gnuplot's configure script. Thanks for your help in tracking down this bug (I'm glad it's not in my=20 code ;). Best regards, Timoth=E9e |
