Hi Alan, > > 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).
If you drop the -drvopt stuff, then the default is smooth=1,freetype=1,text=0. Text is the option to turn on/off the driver's own text processing, which doesn't work for the AGG backend anyway in the moment. > 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. As far as I remember that was made deliberately by me, since I never knew which is the slave and which is the master plot and was annoyed, that I always chose the wrong ;). So there is no mixing, but in the moment if you hit return in any window the main loop is "informed" to advance. I can have a look, how xwin does this logic and implement this as well for the wxwidgets driver. > > 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. I can confirm this and I'll have a look into this. Example 14 segfaulted for me now all the times, but removing the build tree and recompiling everything solved that. Seems that CMake got confused. Anyway gdb has also problems for the dynamic driver case, since it's segfaulting while the driver is loaded, that's also very annoying ;). Disabling the dynamic drivers allows me to debug it at least, at the first look this seems to be quite complicated, since it segfaults way after the close button is processed, in fact the program should never get there. I'll keep you informed. > > > 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 Hmm, I don't think so, since it actually shouldn't be a demo similar to the other examples, it's just showing how to use the bindings and the demo should behave like a real application. But on the other side, it's then maybe easier to test in the test_interactice script, so I'll implement it. > > > * 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. Yes, no message is better, you don't get such messages in "normal apps", I think this would confuse users. > > > * Could you change wxPLplotDemo to put the backend name in the title > (like > you do for -dev wxwidgets)? Will do. > > > * 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? Not in the moment, since the AGG backend doesn't work right now with the wxWidgets bindings. There is some fundamental problem making this work, but I'll definitely want to solve that. > > > * 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. Will look at that too. Thanks for the reports. Regards, Werner > > > 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 -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sme...@iap.tuwien.ac.at web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 ------------------------------------------------------------------------------ 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
