On 2017-10-17 15:48+0100 p.d.rosenb...@gmail.com wrote:
Sorry, thought I sent the message below, but I just found it in my drafts. wxWidgets accepts a font name, then uses the style for fallback if that named font doesn't exist. In the plplot wxWidgets backend we don't use the name because plplot doesn't include the ability to pass the name in as you have found. I personally would like to see PLplot follow a similar pattern – in fact I think this was one of my first feature requests a long time ago. As well as being generally useful, I think some journals have specific fonts that should be used. Unfortunately I’m not sure if other drivers are able to function in this way and an API change is often difficult as it requires updating all the supported languages. However, I relatively easily add this to the wxWidgets API only, as a method of the wxPLplotstream class.
Alan would you support such a change? The call itself could accept a
pointer to a wxFont object as a wxWidgets native way to set the font. Hi Phil: Our long PLplot tradition is those who code get the last say. So none of us including me have any veto power here. However, that said, I would advise you not to develop an additional specific font feature for the wxwidgets device mainly because my experiences with specific font approaches has been mostly bad. For one example of this, look at the "More on the reason for the missing PDF glyphs" heading in doc/docbook/README.developers. That was a case where I was very careful to optimize the choice of specific fonts as best I could. But more typical is the user case where bad specific fonts are chosen with many missing glyphs as a result whenever the user attempts to use anything outside the ascii subset of UTF-8. This is one of the reasons I have deprecated the plfreetype approach (which uses specific fonts and which is currently used by the wingcc device and our old version of the wxwidgets-related code). In sum, I just feel pretty strongly that generic fonts (which are already working well for the wxwidgets device driver) are a much easier approach for us to support and users to use. If despite this advice you do decide to go ahead and provide an additional feature to our wxwidgets-related code that supports user choice of specific fonts, I would not object further, but please document that added feature (including the missing glyph problems that might result). Of course, regardless of your decision on this, I feel the most important current issues for our wxwidgets related code are the interactive problems and inefficiency issues I have documented recently for the non-IPC3 case for -dev wxwidgets on the Linux platform. So your verifications and fixes for those issues (using your access to debugging facilities on Linux platforms) would be much appreciated. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Plplot-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
