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
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?
On Tue, Jan 20, 2009 at 03:54:42PM +0100, Werner Smekal wrote:
> 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?
> On Mon, 19 Jan 2009 20:21:24 +0100, Alan W. Irwin
> <irwin@...> 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
> >figured out a solution that works reasonably well in most cases.
> >Alan W. Irwin
> >Astronomical research affiliation with Department of Physics and
> >University of Victoria (astrowww.phys.uvic.ca).
> >Programming affiliations with the FreeEOS equation-of-state
> >for stellar interiors (freeeos.sf.net); PLplot scientific plotting
> >package (plplot.org); the libLASi project (unifont.org/lasi); the Loads
> >Linux Links project (loll.sf.net); and the Linux Brochure Project
> >Linux-powered Science
> >This SF.net email is sponsored by:
> >SourcForge Community
> >SourceForge wants to tell your story.
> >Plplot-devel mailing list
> Dr. Werner Smekal
> Institut fuer Allgemeine Physik
> Technische Universitaet Wien
> Wiedner Hauptstr 8-10
> A-1040 Wien
> DVR-Nr: 0005886
> email: smekal@...
> 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