Menu
▾
▴
gnuplot-beta
|
From: Mojca M. <moj...@gm...> - 2011-01-17 13:04:28
|
Dear list,
I'm using Mac. I remember that I managed to compile gnuplot with wxt
terminal on Mac once, but it was hanging and one couldn't do anything
with it (function was drawn, but one could not click on the window).
I have now tested gnuplot 4.2.2 for Windows (precompiled) on Windows 7
and it hangs almost in the same way as it does on mac (only that it
doesn't even draw anything). Using
set term windows
and then continue with that old terminal works fine, but wxt seems to
be just as broken under windows as it is on mac. Does it work for
others and on what version of Windows?
Thanks,
Mojca
|
|
From: Mojca M. <moj...@gm...> - 2011-01-17 17:27:09
|
Dear list,
I'm sorry. I take my word back.
Gnulpot used to hang for a very very very long time each time when I
tried it (until I lost all the hope and forced closing it). After the
fifth try it now works without a problem. I cannot figure out what
exactly could go wrong, but it does work now.
I don't like the fact that I have to use
set encoding cp852
(this could be either automatic or it could support UTF-8 in Windows
Vista and 7) and help files are missing (that could easily be fixed, I
assume), but my original complaint wasn't entirely true.
Gnuplot also signals a "crash" to OS when closed with "that cross on
the upper right corner" which should probably not happen, but well ...
Mojca
2011/1/17 Mojca Miklavec wrote:
> Dear list,
>
> I'm using Mac. I remember that I managed to compile gnuplot with wxt
> terminal on Mac once, but it was hanging and one couldn't do anything
> with it (function was drawn, but one could not click on the window).
>
> I have now tested gnuplot 4.2.2 for Windows (precompiled) on Windows 7
> and it hangs almost in the same way as it does on mac (only that it
> doesn't even draw anything). Using
> set term windows
> and then continue with that old terminal works fine, but wxt seems to
> be just as broken under windows as it is on mac. Does it work for
> others and on what version of Windows?
>
> Thanks,
> Mojca
>
|
|
From: Peter J. <pet...@gm...> - 2011-01-17 17:55:39
|
I experience the same on a virtualboxed Vista setup, with gnuplot 4.4.2 and 4.5 both. The wxt terminal window appears, but without any content, and the application doesn't respond anymore. I have to kill it every time, no "it magically fixed itself after the fifth time" for me. Interestingly, it works as expected on a (real) Windows XP. The problem with the help files is a longstanding one, and AFAIK it's not that easy to fix. There is a system component that was in XP but is missing from Vista et al., that's why the help doesn't work. You can install that component from Microsoft's site, after that it'll work. (I can't recall its name now) Péter Juhász 2011/1/17 Mojca Miklavec <moj...@gm...>: > Dear list, > > I'm sorry. I take my word back. > > Gnulpot used to hang for a very very very long time each time when I > tried it (until I lost all the hope and forced closing it). After the > fifth try it now works without a problem. I cannot figure out what > exactly could go wrong, but it does work now. > > I don't like the fact that I have to use > set encoding cp852 > (this could be either automatic or it could support UTF-8 in Windows > Vista and 7) and help files are missing (that could easily be fixed, I > assume), but my original complaint wasn't entirely true. > > Gnuplot also signals a "crash" to OS when closed with "that cross on > the upper right corner" which should probably not happen, but well ... > > Mojca > > > 2011/1/17 Mojca Miklavec wrote: >> Dear list, >> >> I'm using Mac. I remember that I managed to compile gnuplot with wxt >> terminal on Mac once, but it was hanging and one couldn't do anything >> with it (function was drawn, but one could not click on the window). >> >> I have now tested gnuplot 4.2.2 for Windows (precompiled) on Windows 7 >> and it hangs almost in the same way as it does on mac (only that it >> doesn't even draw anything). Using >> set term windows >> and then continue with that old terminal works fine, but wxt seems to >> be just as broken under windows as it is on mac. Does it work for >> others and on what version of Windows? >> >> Thanks, >> Mojca >> > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Ethan M. <merritt@u.washington.edu> - 2011-01-17 18:12:08
|
On Monday, January 17, 2011, Mojca Miklavec wrote: > > I don't like the fact that I have to use > set encoding cp852 > (this could be either automatic or it could support UTF-8 in Windows > Vista and 7) and help files are missing (that could easily be fixed, I > assume), but my original complaint wasn't entirely true. If you know how to persuade Windows to accept UTF-8, please let us know. I was under the impression that Windows could not handle it. Microsoft (and Sun) chose to go with 16-bit encodings instead. As to "set encoding cp852", how would you suggest this be made automatic? And why? Can't you just put it in your initialization file? > Gnuplot also signals a "crash" to OS when closed with "that cross on > the upper right corner" which should probably not happen, but well ... I have not seen that. Could you provide a specific recipe for replicating this problem? Ethan |
|
From: Tatsuro M. <tma...@ya...> - 2011-01-17 23:07:53
|
Hello The wxt terminal uses the fontconfig + Freetype for font handling. You can use utf-8 character encoding to use unicode. In the gnuplot/binary in gnuplot 4.4.2 binary distribution, fc-list-gp.exe is included. Please read README.Windows in gnuplot directory. * fc-list-gp.exe : This program is the renamed fontconfig utlity which outputs a list of fonts managed by the fontconfig library used in this gnuplot distribution. ! fc-list-gp > fc-list.txt lists which font is available in your system. Regards Tatsuro -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Mojca M. <moj...@gm...> - 2011-01-17 23:38:09
|
Hello,
2011/1/18 Tatsuro MATSUOKA wrote:
>
> The wxt terminal uses the fontconfig + Freetype for font handling.
That was indeed one of the best improvements over the old windows
terminal (where support for any encoding but ASCII was just a dream
and nobody knew how to select a font ...).
> You can use utf-8 character encoding to use unicode.
If I create a file 'a.plt' in UTF-8 encoding and use
load 'a.plt'
then UTF-8 works without a problem.
However if I type
set xlabel 'ačšž'
plot sin(x)
then it won't recognize the input unless I explicitely specify
set encoding cp852
so it's just a problem of correctly interpreting the input, not a
problem of drawing it (which was also problematic on the old windows
terminal).
I also need to tell that when I use "cmd" and change the font in
Properties to Lucida Console for example, then I'm able to paste a
Greek alpha into cmd window. However when I run gnuplot, this is
impossible - I can apparently only use characters from cp1250/cp852.
There is no way to enter any Greek letter at all.
I'm using Slovenian locale. Maybe the program behaves different in
Japanese locale.
Thanks a lot,
Mojca
|
|
From: Tatsuro M. <tma...@ya...> - 2011-01-18 01:21:03
|
Hello --- Mojca Miklavec wrote: > If I create a file 'a.plt' in UTF-8 encoding and use > load 'a.plt' > then UTF-8 works without a problem. > > However if I type > set xlabel 'a将ュ将゛将�#39; > plot sin(x) > then it won't recognize the input unless I explicitely specify > set encoding cp852 > so it's just a problem of correctly interpreting the input, not a > problem of drawing it (which was also problematic on the old windows > terminal). > > I also need to tell that when I use "cmd" and change the font in > Properties to Lucida Console for example, then I'm able to paste a > Greek alpha into cmd window. However when I run gnuplot, this is > impossible - I can apparently only use characters from cp1250/cp852. > There is no way to enter any Greek letter at all. In Japanese windows, the situation is the same. We have to use a suitable text editor and execute in the script for the utf-8. In Unix (including Cygwin) terminal emulator works at various locale so that we can use the utf-8 on the terminal. There is the Msys mintty on windows. It seem to treat the UTF-8. However it cannot be used for gnuplot.exe (cursor behaviors are too strange to use it. Probably it is optimized for Msys system.) I hope the Msys mitty like a program that can be used for windows native environments. Regards Tatsuro -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Tatsuro M. <tma...@ya...> - 2011-01-17 22:59:19
|
Hello --- Mojca Miklavec wrote: > Gnuplot also signals a "crash" to OS when closed with "that cross on > the upper right corner" which should probably not happen, but well ... For wxt terminal, "press cross on the upper right corner" causes crash. I can fix this if windows api function SetConsoleCtrlHandler. (I have tried and tested once.) The reason I have not submit this patch is that I cannot make a decision in which it is implemented in plot.c or win/winmain.c. If the patch is hopeful I will post it to the bug tracker. Regards Tatsuro -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2011-01-17 21:32:57
|
On 17.01.2011 18:55, Peter Juhasz wrote: > The wxt terminal window appears, but without any content, and the > application doesn't respond anymore. I have to kill it every time, no > "it magically fixed itself after the fifth time" for me. My experience on a real Windows box was somewhat similar, but ultimately different. The first plot from the first wxt version of gnuplot I ever ran took _ages_. Yes, it did feel like eternity, but ulimately it got there. Ever since, it just works. So apparently there's something the wxt framework needs to do once to work properly. Maybe you guys just need to be a bit more patient before killing it. > The problem with the help files is a longstanding one, and AFAIK it's > not that easy to fix. There is a system component that was in XP but > is missing from Vista et al., that's why the help doesn't work. You > can install that component from Microsoft's site, after that it'll > work. (I can't recall its name now) If only it were that simple. The real problem is that even after you have winhelp32 installed, it'll _still_ refuse to display our help pages, because they have arrived on the system without having been "blessed" by an official MSI installer. So you have to explicitly remove a "this is a nasty file from somewhere in the big, nasty Internet, so it can't be allowed to work" flag from the file in Explorer. |
|
From: Tatsuro M. <tma...@ya...> - 2011-01-17 22:49:50
|
Hello I have gotten the netbook recently. The OS is windows 7 starter. I have installed gnuplot into C:\Progaram Files as an administrator. I have also install winhelp32 for window 7. The wxt terminal and help works without problem. For help file, the below might helps you. http://sourceforge.net/tracker/?func=detail&aid=2984116&group_id=2055&atid=102055 Regards Tatsuro --- Hans-Bernhard Br将モker wrote: > On 17.01.2011 18:55, Peter Juhasz wrote: > > > The wxt terminal window appears, but without any content, and the > > application doesn't respond anymore. I have to kill it every time, no > > "it magically fixed itself after the fifth time" for me. > > My experience on a real Windows box was somewhat similar, but ultimately > different. The first plot from the first wxt version of gnuplot I ever > ran took _ages_. Yes, it did feel like eternity, but ulimately it got > there. Ever since, it just works. > > So apparently there's something the wxt framework needs to do once to > work properly. > > Maybe you guys just need to be a bit more patient before killing it. > > > The problem with the help files is a longstanding one, and AFAIK it's > > not that easy to fix. There is a system component that was in XP but > > is missing from Vista et al., that's why the help doesn't work. You > > can install that component from Microsoft's site, after that it'll > > work. (I can't recall its name now) > > If only it were that simple. The real problem is that even after you > have winhelp32 installed, it'll _still_ refuse to display our help > pages, because they have arrived on the system without having been > "blessed" by an official MSI installer. So you have to explicitly > remove a "this is a nasty file from somewhere in the big, nasty > Internet, so it can't be allowed to work" flag from the file in Explorer. > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Allin C. <cot...@wf...> - 2011-01-18 02:00:08
|
On Mon, 17 Jan 2011, [ISO-8859-1] Hans-Bernhard Br wrote: > On 17.01.2011 18:55, Peter Juhasz wrote: > > > The wxt terminal window appears, but without any content, and the > > application doesn't respond anymore. I have to kill it every time, no > > "it magically fixed itself after the fifth time" for me. > > My experience on a real Windows box was somewhat similar, but ultimately > different. The first plot from the first wxt version of gnuplot I ever > ran took _ages_. Yes, it did feel like eternity, but ulimately it got > there. Ever since, it just works. > > So apparently there's something the wxt framework needs to do once to > work properly. Interesting. "My" app gretl ( gretl.sf.net ) calls gnuplot to generate graphs. These are not displayed using the wxt terminal, rather we get gnuplot to generate a PNG file using the pngcairo terminal (which of course shares a lot of code with wxt) and then we display the PNG in a GTK window that's under gretl's control. But we're seeing the same, quite mysterious, issue on Windows: the "first" gnuplot plot takes a long time to appear, where "long" can be anything from 5-10 seconds to well over a minute. It looks like the app is off in the ozone, but eventually the plot appears. I'm not sure exactly what "first" means here -- first plot after booting Windows, first plot after initially installing or updating gretl + gnuplot? -- since that seems to vary. But subsequent plots take a sane amount of time (i.e. barely noticeable delay). My first thought on this was that maybe Windows is conducting some elaborate security audit on the toolchain that's involved (GLib, pango and so on), but that's only a wild guess. I wish I understood what's going on, because it creates a very bad impression for new users. (No such problem on Linux or Mac.) Allin Cottrell |
|
From: Mojca M. <moj...@gm...> - 2011-01-18 02:56:32
|
2011/1/18 Allin Cottrell wrote: > > But we're seeing the same, quite mysterious, issue on Windows: the > "first" gnuplot plot takes a long time to appear, where "long" > can be anything from 5-10 seconds to well over a minute. It looks > like the app is off in the ozone, but eventually the plot appears. > I'm not sure exactly what "first" means here -- first plot after > booting Windows, first plot after initially installing or updating > gretl + gnuplot? -- since that seems to vary. But subsequent plots > take a sane amount of time (i.e. barely noticeable delay). > > My first thought on this was that maybe Windows is conducting some > elaborate security audit on the toolchain that's involved (GLib, > pango and so on), but that's only a wild guess. I wish I > understood what's going on, because it creates a very bad > impression for new users. (No such problem on Linux or Mac.) Wait, that sounds familiar! My bet is that fc-cache runs in the background to regenerate font index "every now and then", so that one can use any given font on the system. This doesn't happen on Mac on Linux since fontconfig database update runs independently in the background. But if gnuplot is compiled with fontconfig under windows it first checks when the database has last been generated and if enough time elapsed, it regenerates the database which may take pretty long (depending on the number of fonts available on the system). Mojca |
|
From: Allin C. <cot...@wf...> - 2011-01-18 03:10:40
|
On Tue, 18 Jan 2011, Mojca Miklavec wrote: > 2011/1/18 Allin Cottrell wrote: > > > > But we're seeing the same, quite mysterious, issue on Windows: the > > "first" gnuplot plot takes a long time to appear, where "long" > > can be anything from 5-10 seconds to well over a minute. It looks > > like the app is off in the ozone, but eventually the plot appears. > > I'm not sure exactly what "first" means here -- first plot after > > booting Windows, first plot after initially installing or updating > > gretl + gnuplot? -- since that seems to vary. But subsequent plots > > take a sane amount of time (i.e. barely noticeable delay). > > > > My first thought on this was that maybe Windows is conducting some > > elaborate security audit on the toolchain that's involved (GLib, > > pango and so on), but that's only a wild guess. I wish I > > understood what's going on, because it creates a very bad > > impression for new users. (No such problem on Linux or Mac.) > > Wait, that sounds familiar! > > My bet is that fc-cache runs in the background to regenerate font > index "every now and then", so that one can use any given font on the > system. > > This doesn't happen on Mac on Linux since fontconfig database update > runs independently in the background. But if gnuplot is compiled with > fontconfig under windows it first checks when the database has last > been generated and if enough time elapsed, it regenerates the database > which may take pretty long (depending on the number of fonts available > on the system). Aha! That sounds quite plausible. Next time I boot windows I'll try to investigate. I suppose that if I can find the relevant cache file and delete it, then I ought to be able to provoke the long wait for a plot? Allin Cottrell |
|
From: Allin C. <cot...@wf...> - 2011-01-18 04:07:31
|
On Mon, 17 Jan 2011, Allin Cottrell wrote: > On Tue, 18 Jan 2011, Mojca Miklavec wrote: > > > > My bet is that fc-cache runs in the background to regenerate font > > index "every now and then", so that one can use any given font on the > > system. (and this can take a looong time). I notice that in gnuplot's cp_cairo.c there's a comment (around line 690) about "working around a bug in the cairo/win32 backend for font rendering": the work-around involves gp_cairo on Windows using the freetype + fontconfig backend by preference to the win32 backend. Following Mojca's lead, this could explain the initial long wait for gnuplot output. I'm wondering, is the cairo bug in question still there? Unfortunately the comment is not specific (no bugzille ID). But if the issue is fixed in current cairo it could be worth making a change. Cairo's win32 backend doesn't have the problem of a long wait on first use. Allin Cottrell |
|
From: Tatsuro M. <tma...@ya...> - 2011-01-18 04:26:43
|
Hello I also experienced long time wait on the wxt terminal on windows 7 starter. >From second time, I have never waited so long. Regards Tatsuro --- Allin Cottrell wrote: > On Mon, 17 Jan 2011, Allin Cottrell wrote: > > > On Tue, 18 Jan 2011, Mojca Miklavec wrote: > > > > > > My bet is that fc-cache runs in the background to regenerate font > > > index "every now and then", so that one can use any given font on the > > > system. > > (and this can take a looong time). > > I notice that in gnuplot's cp_cairo.c there's a comment (around > line 690) about "working around a bug in the cairo/win32 backend > for font rendering": the work-around involves gp_cairo on Windows > using the freetype + fontconfig backend by preference to the win32 > backend. Following Mojca's lead, this could explain the initial > long wait for gnuplot output. > > I'm wondering, is the cairo bug in question still there? > Unfortunately the comment is not specific (no bugzille ID). But if > the issue is fixed in current cairo it could be worth making a > change. Cairo's win32 backend doesn't have the problem of a long > wait on first use. > > Allin Cottrell > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2011-01-18 06:38:43
|
On Monday, January 17, 2011, Allin Cottrell wrote: > On Mon, 17 Jan 2011, Allin Cottrell wrote: > > > On Tue, 18 Jan 2011, Mojca Miklavec wrote: > > > > > > My bet is that fc-cache runs in the background to regenerate font > > > index "every now and then", so that one can use any given font on the > > > system. > > (and this can take a looong time). > > I notice that in gnuplot's cp_cairo.c there's a comment (around > line 690) about "working around a bug in the cairo/win32 backend > for font rendering": the work-around involves gp_cairo on Windows > using the freetype + fontconfig backend by preference to the win32 > backend. Following Mojca's lead, this could explain the initial > long wait for gnuplot output. > > I'm wondering, is the cairo bug in question still there? > Unfortunately the comment is not specific (no bugzille ID). But if > the issue is fixed in current cairo it could be worth making a > change. Cairo's win32 backend doesn't have the problem of a long > wait on first use. Here's a link to the original thread reporting the problem in cairo's win32 backend: http://groups.google.com/group/comp.graphics.apps.gnuplot/browse_thread/thread/5742a3d915085f7b/d075063d7da423e9?hl=en&ie=UTF-8&oe=utf-8&q=missing+pixels+for+Windows+PNG+driver&pli=1 I think there's enough information there to test whether the bug is still present or not. If the bug has been fixed in some more recent cairo version, the test on WIN32 and cairo versioning in .../src/wxterminal/gp_cairo.c can be modified appropriately. Or you could write to Behdad Esfahbod and ask him, since he was the cairo developer who recognized the problem and suggested the work-around. Ethan |
|
From: Allin C. <cot...@wf...> - 2011-01-18 14:29:49
|
On Mon, 17 Jan 2011, sfeam (Ethan Merritt) wrote: > On Monday, January 17, 2011, Allin Cottrell wrote: > > On Mon, 17 Jan 2011, Allin Cottrell wrote: > > > > > On Tue, 18 Jan 2011, Mojca Miklavec wrote: > > > > > > > > My bet is that fc-cache runs in the background to regenerate font > > > > index "every now and then", so that one can use any given font on the > > > > system. > > > > (and this can take a looong time). > > > > I notice that in gnuplot's cp_cairo.c there's a comment (around > > line 690) about "working around a bug in the cairo/win32 backend > > for font rendering": the work-around involves gp_cairo on Windows > > using the freetype + fontconfig backend by preference to the win32 > > backend. Following Mojca's lead, this could explain the initial > > long wait for gnuplot output. > > > > I'm wondering, is the cairo bug in question still there? > > Unfortunately the comment is not specific (no bugzille ID). But if > > the issue is fixed in current cairo it could be worth making a > > change. Cairo's win32 backend doesn't have the problem of a long > > wait on first use. > > Here's a link to the original thread reporting the problem > in cairo's win32 backend: > > http://groups.google.com/group/comp.graphics.apps.gnuplot/browse_thread/thread/5742a3d915085f7b/d075063d7da423e9?hl=en&ie=UTF-8&oe=utf-8&q=missing+pixels+for+Windows+PNG+driver&pli=1 Thanks! I had a vague memory of that discussion but had forgotten the details. There have been a fair number of commits in the cairo-font-win32 area since then (14 months ago) so this is probably worth revisiting. I'll try some testing with cairo 1.10.2 on Windows. Allin Cottrell |
|
From: Bastian M. <bma...@we...> - 2011-03-30 19:08:46
|
Am 18.01.2011 15:29, schrieb Allin Cottrell: > On Mon, 17 Jan 2011, sfeam (Ethan Merritt) wrote: > >> On Monday, January 17, 2011, Allin Cottrell wrote: >>> On Mon, 17 Jan 2011, Allin Cottrell wrote: >>> >>>> On Tue, 18 Jan 2011, Mojca Miklavec wrote: >>>>> >>>>> My bet is that fc-cache runs in the background to regenerate font >>>>> index "every now and then", so that one can use any given font on the >>>>> system. >>> >>> (and this can take a looong time). >>> >>> I notice that in gnuplot's cp_cairo.c there's a comment (around >>> line 690) about "working around a bug in the cairo/win32 backend >>> for font rendering": the work-around involves gp_cairo on Windows >>> using the freetype + fontconfig backend by preference to the win32 >>> backend. Following Mojca's lead, this could explain the initial >>> long wait for gnuplot output. >>> >>> I'm wondering, is the cairo bug in question still there? >>> Unfortunately the comment is not specific (no bugzille ID). But if >>> the issue is fixed in current cairo it could be worth making a >>> change. Cairo's win32 backend doesn't have the problem of a long >>> wait on first use. >> >> Here's a link to the original thread reporting the problem >> in cairo's win32 backend: >> >> http://groups.google.com/group/comp.graphics.apps.gnuplot/browse_thread/thread/5742a3d915085f7b/d075063d7da423e9?hl=en&ie=UTF-8&oe=utf-8&q=missing+pixels+for+Windows+PNG+driver&pli=1 > > Thanks! I had a vague memory of that discussion but had forgotten > the details. There have been a fair number of commits in the > cairo-font-win32 area since then (14 months ago) so this is > probably worth revisiting. I'll try some testing with cairo 1.10.2 > on Windows. > > Allin Cottrell I have tried to reproduce the original bug report of the font problem in cairopng with pango 1.28.3 and cairo 1.10.2 on Windows. The result using current CVS (freetype + fontconfig) looks like this: http://www.physi.uni-heidelberg.de/~bmaerk/tmp/gretl_bug.png And here's the result using the win32 backend: http://www.physi.uni-heidelberg.de/~bmaerk/tmp/gretl_bug-win32.png Both versions look fine to me. Should we apply the revised test you proposed? > #if CAIRO_VERSION_MAJOR < 2 && CAIRO_VERSION_MINOR < 10 Or should we test for the pango version here? There's another reason why I would prefer that the cairo/pango terminals use the win32 backend: In my experience, these terminals (read: cairo/pango/fontconfig) fail to find a sensible default font ("Sans") on 4 out of 5 Windows machines. For me, it fails on three different XP machines and on a Win 7 (x64) machine. It only works on a Vista machine. This is the result of 'enhancedtext.dem' using the pngcairo terminal with no font specified: http://www.physi.uni-heidelberg.de/~bmaerk/tmp/fontconfig-bug.png Bastian |
|
From: Petr M. <mi...@ph...> - 2011-01-18 08:28:18
|
> Maybe you guys just need to be a bit more patient before killing it. > > > The problem with the help files is a longstanding one, and AFAIK it's > > not that easy to fix. There is a system component that was in XP but > > is missing from Vista et al., that's why the help doesn't work. You > > can install that component from Microsoft's site, after that it'll > > work. (I can't recall its name now) > > If only it were that simple. The real problem is that even after you > have winhelp32 installed, it'll _still_ refuse to display our help > pages, because they have arrived on the system without having been > "blessed" by an official MSI installer. So you have to explicitly > remove a "this is a nasty file from somewhere in the big, nasty > Internet, so it can't be allowed to work" flag from the file in Explorer. Would an installer help here? It's nice gnuplot installation is just "unzip this file", but maybe an installer or a setup-script doing - download and install winhelp32 - remove security bits - run gnuplot for the 1st time would help here. --- PM |
|
From: Allin C. <cot...@wf...> - 2011-01-18 19:39:30
|
On Mon, 17 Jan 2011, sfeam (Ethan Merritt) wrote: > If the bug [in font-handling in the win32 backend to cairo] has > been fixed in some more recent cairo version, the test on WIN32 > and cairo versioning in .../src/wxterminal/gp_cairo.c can be > modified appropriately. I've now tried building gnuplot (CVS) with the special switch on WIN32 disabled, and running it with cairo 1.10.2. I'm not seeing the problem of missing font-pixels that we observed back in November 2009. I haven't tried a rigorous comparison against freetype/fontconfig at this point, but first impression is that maybe we don't need the work-around with current cairo. Maybe bracket the special code with #if CAIRO_VERSION_MAJOR < 2 && CAIRO_VERSION_MINOR < 10 or similar? (At least as an experiment for CVS users.) Allin Cottrell |
|
From: Tatsuro M. <tma...@ya...> - 2011-01-18 22:42:30
|
Hello Please report your trail here if you will finished it. At the moment I am occupied because of the current octave activity, I cannot commit it by myself. Regards Tatsurp --- Allin Cottrell wrote: > On Mon, 17 Jan 2011, sfeam (Ethan Merritt) wrote: > > > If the bug [in font-handling in the win32 backend to cairo] has > > been fixed in some more recent cairo version, the test on WIN32 > > and cairo versioning in .../src/wxterminal/gp_cairo.c can be > > modified appropriately. > > I've now tried building gnuplot (CVS) with the special switch on > WIN32 disabled, and running it with cairo 1.10.2. I'm not seeing > the problem of missing font-pixels that we observed back in > November 2009. I haven't tried a rigorous comparison against > freetype/fontconfig at this point, but first impression is that > maybe we don't need the work-around with current cairo. > > Maybe bracket the special code with > > #if CAIRO_VERSION_MAJOR < 2 && CAIRO_VERSION_MINOR < 10 > > or similar? (At least as an experiment for CVS users.) > > Allin Cottrell > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Tatsuro M. <tma...@ya...> - 2011-01-18 22:42:34
|
Hello Please report your trail here if you will finished it. At the moment I am occupied because of the current octave activity, I cannot commit it by myself. Regards Tatsurp --- Allin Cottrell wrote: > On Mon, 17 Jan 2011, sfeam (Ethan Merritt) wrote: > > > If the bug [in font-handling in the win32 backend to cairo] has > > been fixed in some more recent cairo version, the test on WIN32 > > and cairo versioning in .../src/wxterminal/gp_cairo.c can be > > modified appropriately. > > I've now tried building gnuplot (CVS) with the special switch on > WIN32 disabled, and running it with cairo 1.10.2. I'm not seeing > the problem of missing font-pixels that we observed back in > November 2009. I haven't tried a rigorous comparison against > freetype/fontconfig at this point, but first impression is that > maybe we don't need the work-around with current cairo. > > Maybe bracket the special code with > > #if CAIRO_VERSION_MAJOR < 2 && CAIRO_VERSION_MINOR < 10 > > or similar? (At least as an experiment for CVS users.) > > Allin Cottrell > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Ethan M. <merritt@u.washington.edu> - 2011-01-18 20:15:05
|
On Tuesday, January 18, 2011 11:39:23 am Allin Cottrell wrote: > On Mon, 17 Jan 2011, sfeam (Ethan Merritt) wrote: > > > If the bug [in font-handling in the win32 backend to cairo] has > > been fixed in some more recent cairo version, the test on WIN32 > > and cairo versioning in .../src/wxterminal/gp_cairo.c can be > > modified appropriately. > > I've now tried building gnuplot (CVS) with the special switch on > WIN32 disabled, and running it with cairo 1.10.2. I'm not seeing > the problem of missing font-pixels that we observed back in > November 2009. I haven't tried a rigorous comparison against > freetype/fontconfig at this point, but first impression is that > maybe we don't need the work-around with current cairo. > > Maybe bracket the special code with > > #if CAIRO_VERSION_MAJOR < 2 && CAIRO_VERSION_MINOR < 10 OK. But is it the cairo version or the pango version that matters? The code in question seems to be calling into the pango library. Ethan > > or similar? (At least as an experiment for CVS users.) > > Allin Cottrell |
|
From: Allin C. <cot...@wf...> - 2011-01-19 02:30:05
|
On Tue, 18 Jan 2011, Ethan Merritt wrote: > On Tuesday, January 18, 2011 11:39:23 am Allin Cottrell wrote: > > On Mon, 17 Jan 2011, sfeam (Ethan Merritt) wrote: > > > > > If the bug [in font-handling in the win32 backend to cairo] has > > > been fixed in some more recent cairo version, the test on WIN32 > > > and cairo versioning in .../src/wxterminal/gp_cairo.c can be > > > modified appropriately. > > > > I've now tried building gnuplot (CVS) with the special switch on > > WIN32 disabled, and running it with cairo 1.10.2. I'm not seeing > > the problem of missing font-pixels that we observed back in > > November 2009. I haven't tried a rigorous comparison against > > freetype/fontconfig at this point, but first impression is that > > maybe we don't need the work-around with current cairo. > > > > Maybe bracket the special code with > > > > #if CAIRO_VERSION_MAJOR < 2 && CAIRO_VERSION_MINOR < 10 > > OK. But is it the cairo version or the pango version that matters? > The code in question seems to be calling into the pango library. I think it's cairo that matters. I'm using the same pango version as I was when we saw problems in November 2009 (1.24.5) but have updated from cairo 1.8.8 to 1.10.2. Allin Cottrell |
|
From: Tatsuro M. <tma...@ya...> - 2011-01-19 03:42:32
|
Hello --- Allin Cottrell wrote: The code in question seems to be calling into the pango library. > > I think it's cairo that matters. I'm using the same pango version > as I was when we saw problems in November 2009 (1.24.5) but have > updated from cairo 1.8.8 to 1.10.2. > Thank you for your information. For windows build of 4.4.2 on the Official release, I used cairo-1.8.10. Currently I have been using cairo-1.10.0 since 2010-10-25 for cvs binary release. http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ Regards Tatsuro -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
