Hi Werner: As part of my tests, I recently ran "make test_interactive" in the installed examples tree, and I would like to comment here on the wxwidgets results of those tests. These comments are only relevant to post-release because it is obviously far too late for this release to make the major changes I recommend for wxwidgets below.
I finally figured out how to access wxwidgets-2.8 from Debian Lenny (install the libwxbase2.8-dev package and use update-alternatives to make sure you have the correct version of wx-config rather than the 2.6 version of that app. Then run cmake as normal). Using update-alternatives I could easily switch between the 2.6 and 2.8 versions of wxwidgets. The first gives me the (AGG) device version and the second gives me the (wxGC) device version just like you designed it. The principal wxwidgets issues I noticed for my interactive tests were the following: * For wxwidgets (AGG) there are constant problems with vertical positioning of text. That is because that version depends on plfreetype which has known vertical positioning issues along with other problems. I doubt the plfreetype issues are ever going to get fixed so my (post-release) advice is to only support wxwidgets-2.8 (most modern distros should have that version since Debian Lenny does). This should allow you to dump your fallback method for old wxwidgets versions and dump the AGG method as well. AGG is great, but when dragged down by the limitations of the plfreetype approach I don't think it is worth it. Dumping these first two methods and concentrating solely on wxGC should greatly simplify your wxwidgets life. Once I saw those all-too-familiar plfreetype bad vertical offsets, I quit testing wxwidgets (AGG) and did the rest of my tests for wxwidgets (wxGC). * For wxwidgets (wxGC) there are intermittent problems with horizontal positioning of text, but vertical is fine. It appears to me that freetype=0 with this backend (i.e., it does not use the plfreetype approach). That explains why there are no vertical offset problems, and there must be some issue with horizontal offsets with whatever method is used by wxGC to render the specified glyphs. Sometimes the horizontal offset is perfect, and sometimes the horizontal offset has an extremely large error (e.g., example 1 titles for sub-pages 1 and 2 are fine, but the titles for subpages 3 and 4 are badly displaced). This may simply be due to a bug in how the wxwidgets device interfaces with the wxGC method. However, it could also be an issue with how the wxGC method is implemented for wxwidgets-2.8 on Linux (or all platforms). Do you see this example 1 wxGC issue on windows? * I think I follow the code well enough to see that the wxGC font selection mechanism is via the fontFamilyLookup table in wxwidgets.h. That table associates the 5 generic PLplot font hint types (san, sans-serif, monotype, etc.) with wxwidgets font types wxFONTFAMILY_SWISS, wxFONTFAMILY_ROMAN, wxFONTFAMILY_TELETYPE, etc. That method appears promising since is is completely independent of the lame plfreetype font selection mechanism. But from example 24 the method is not working very well since all of the exotic glyphs are rendered as empty boxes. Is there some way you can tell wxwidgets to use a high-quality system font-selection mechanism for whatever platform it is running (e.g., fontconfig on Linux)? Ideally, what you want is the font selection to automatically find the best system font to render the glyph consistent with the font hint given by PLPlot. That is what is implemented with the qt and cairo device drivers, but that mechanism is currently not working very well with the wxwidgets device driver with wxGC. I suppose you could be up against some wxGC limitation. Alternatively, there may be a bug in the interface between wxwidgets and wxGC or something else you need to specify to get the font selection working properly for wxGC. 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 __________________________ ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
