[mcclim-devel] Freetype bindings

Christophe Rhodes csr21 at cam.ac.uk
Wed Mar 23 09:22:00 UTC 2005


Hi,

I've been playing with the bindings to freetype in
Experimental/freetype, with a view to using them in one of my apps --
there is a font which I need to use which is available to me in
truetype format (and, in addition, it makes the Climacs window look
pretty).

I've run into multiple problems, most of which I've worked around in
some way or other.  One which is definitely not this list's problem is
the fact that sbcl miscompiles freetype-ffi.lisp; it gets confused
over some forward declarations, and subsequently refuses to do
anything with certain foreign structures.  I believe the sbcl experts
are working on this problem; however, there is a simple workaround,
which is to load the freetype-ffi.lisp file as source.

A more serious problem lies in the fact that the ffi bindings are very
definitely 32-bit centric; certain things are defined as (signed 32)
or (unsigned 32) when they should be long or unsigned-long.  (This
causes segmentation faults on 64-bit platforms).  I have manually
corrected the bindings, but I think the right answer is to generate
the bindings themselves as part of the compilation process: in other
words, do something similar to sbcl's sb-grovel, and ask the C
compiler on the host system to emit suitable Lisp code, using sizeof,
offsetof, and the C preprocessor itself.

One word of warning at this point: it is easy to crash your lisp if
you're not careful, because the bindings are not fully type-declared,
so sbcl spews compiler diagnostics to *standard-output* when calling
the freetype functions.  This is bad if the freetype functions are
being called in order to emit characters to a clim pane bound to
*standard-output*... I've been using 
  (handler-bind ((compiler-note #'muffle-warning)) (climacs-gui::climacs)) 
or similar to work around this.

The remaining glitch -- one that I have not managed to solve, is that
there are visual artifacts with the bindings.  A full redraw usually
solves any such artifacts, but during the course of interaction,
characters are often misplaced.  A chance mention on IRC suggests that
this might be caused by insufficient display-finish-outputs; does
anyone have any suggestions as to where to look for these?

A screenshot, for the interested: 
  <http://www-jcsu.jesus.cam.ac.uk/~csr21/tabcode-font.png>.

Cheers,

Christophe



More information about the mcclim-devel mailing list