Hi Werner, wxwidgets works fine for me on Linux using e.g.
./x24c -dev wxwidgets but I don't think I am getting the freetype backend since the fonts all work fine. The message you are getting occurs when freetype is initialised. This is before any text plotting occurs and so shouldn't be as a result of my recent changes. If you force freetype but no anti-aliasing, i.e. ./x24c -dev wxwidgets -drvopt smooth=0,freetype=1,text=0 then things break. Problem is in the logic in the driver code. It's different to gd.c. If you set smooth=0 then it will always fail with the message you have got. I've fixed this in svn. Can you try again? Andrew On Tue, Jan 20, 2009 at 03:54:42PM +0100, Werner Smekal wrote: > Hi, > > I'm not 100% sure, if this problem is due to these changes, but suddenly > smoothing with the freetype routines in the wxWidgets driver on Windows > doesn't work anymore. I get the following output: > > *** PLPLOT WARNING *** > Insufficient colour slots available in CMAP0 to do text smoothing. > > I'm quite sure, that this wasn't a problem before. Does it work on Linux? > > Regards, > Werner > > On Mon, 19 Jan 2009 20:21:24 +0100, Alan W. Irwin > <ir...@beluga.phys.uvic.ca> wrote: > > >On 2009-01-19 10:08-0000 Andrew Ross wrote: > > > >>The [example 24 smooth=1] problem arises in src/plfreetype.c in > >>FT_PlotChar. There are two > >>different code paths depending on whether the pixel mode is mono (i.e. > >>no anti-aliasing) or not. However, the first path is also taken if icol0 > >>= 0, i.e. the background colour. I can't quite see the logic for this. > >>Normally is is not a problem since you wouldn't display text in the > >>background colour. Example 24 however plots 4 coloured bands so you > >>can't see the background, then switches to the background colour to > >>print the text. The crazy fonts arise because the code assumes a mono > >>font - i.e. each pixel is represented by one bit. This is not the case > >>for the anti-aliased text in the background colour. I've just commented > >>out this special case for icol0 = 0. > > > >>From this and subsequent posts by you and Andrew Roach it appears you > >>have > >figured out a solution that works reasonably well in most cases. > > > >Thanks! > > > >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 > DVR-Nr: 0005886 > > 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
