On 2009-01-20 16:52+0100 Werner Smekal wrote: > Ah, sorry. Actually I initialized smooth_text=-1 (although this should > be 1) in my last changes. My bad. But due this you found a bug in the > driver ;). Very well! > > So, sorry for the noise, it works now again also on Windows.
Hi Werner: I have a segfault to report for wxwidgets on Linux for narrowly defined circumstances, but first the good news. I confirm on my Debian testing platform that for revision 9358 ( TTFDIR=/usr/share/fonts/truetype ; PLPLOT_FREETYPE_SANS_FONT=$TTFDIR/arphic/bkai00mp.ttf PLPLOT_FREETYPE_SERIF_FONT=$TTFDIR/freefont/FreeSerif.ttf PLPLOT_FREETYPE_MONO_FONT=$TTFDIR/ttf-devanagari-fonts/lohit_hi.ttf PLPLOT_FREETYPE_SCRIPT_FONT=$TTFDIR/unfonts/UnBatang.ttf PLPLOT_FREETYPE_SYMBOL_FONT=$TTFDIR/ttf-bengali-fonts/JamrulNormal.ttf c/x24c -dev wxwidgets -drvopt smooth=0,freetype=1,text=0) gives pretty good (slightly ragged looking letters) results for the AGG backend. If I drop all the -drvopt stuff (which I believe is the same as smooth=1, freetype=1, and text=1), the results look outstanding. It's great that the default looks so good now (assuming the user has installed libAGG). No segfaults were encountered for example 24 or any other single-stream example. However, for example 14 I have evidence that the windows events from the two streams are getting confused, and I also get a segfault for that example for a particular narrow pattern of use. Here are the details for example 14. If I run the example the usual two windows are displayed (master and slave). If I hit return when the slave is in focus or the master in focus, both plot windows move on to the next page. If I hit return again in either master or slave, the process smoothly terminates. Note, this behaviour is different then -dev xwin where a hit of return is ignored if it is done with the slave window in focus. That's consistent with the idea that the slave should not affect the master. The wxwidgets issue of the slave being in control of the master could just be a minor side issue, but I think it is consistent with the idea that the wxwidgets device is confusing windows events from the two separate streams which is a much more serious issue. There are five other (besides hitting return) possible methods for terminating the window. There are two window manager controls for doing it and the corresponding alt-F4 and the wxwidgets file button for exit and the corresponding alt-x. If I use any of those 5 methods when the slave is in focus, I get the "Program aborted" message. If I use any of those 5 methods when the master is in focus, I get a segfault. Again, this is consistent with the idea that the wxwidgets device is confusing windows events from the two separate streams. I assume the fix is to change some variables in the wxwidgets device code to be stored in a stream-dependent way similar to changes we have made in other devices recently to deal with example 14. The "hit return" termination method and the 5 other termination methods all work fine for the single-stream examples. Some comments on wxPLplotDemo. * The "hit return" method does nothing. Perhaps that should be changed to be consistent with -dev wxwidgets * The 5 other termination methods terminate silently without the "Program aborted" message (but also without a segfault). I am not sure whether you want to be consistent with -dev wxwidgets here in generating the message. Your call. * Could you change wxPLplotDemo to put the backend name in the title (like you do for -dev wxwidgets)? * From the way the result looks, it appears it is using the default backend rather than AGG. Could you change it to the same great defaults that occur for -dev wxwidgets? * There are some funny discontinuities in the sinc curve displayed by wxPLplotDemo compared to the nice smooth results in example 1. That may simply be the result of using the default backend or it may be an additional issue. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
