[cairo] using cairo in c++

[Bill Spitzak]

John Taber wrote:
> Aha, turns out 'pkg-config' was the culprit
> 
> fltk configure uses 'pkg-config' to get the cairo lib paths and I had 
> installed cairo from the tar source and I guess cairo "make install" 
> does not update pkg-config as to where the cairo files are.  [Which 
> would be handy to call out in the cairo installation page - btw when I'm 
> done here I will do a section on using cairo with fltk]
> 
> Fltk compiled fine with cairo but now in my cairo test program I get 
> undefined reference errors for my cairo commands - I guess I'm missing 
> some header file
> 
> #include <fltk/x.h>
> 
> void draw() {
>   snippet_normalize(fltk::cc, 200,200); //<=== snippet... undefined
>   cairo_arc(fltk::cc, .5, .5, .4, 45.0, 180.0); //<=== cairo_arc undef
> }
> 
> the fltk::cc context seems to be created and found.  I tried adding
> #include <cairo.h>  but that created context conflicts with <x.h>

Probably the problem is that x.h contains the following code:

# if USE_CAIRO
#  include <cairo.h>
#  include <cairo-xlib.h>
# else
  typedef struct cairo cairo_t;
# endif
extern FL_API cairo_t*	cc;
/* FL_API is the Windows declspec junk */

Likely if you "#define USE_CAIRO 1" at the start of your source code, it 
will work. However this should not be necessary. I believe the 
definition of cairo_t has changed in cairo 1.0.0 and the x.h file needs 
to be changed to match. A better solution is to make an fltk/cairo.h 
which simply includes cairo.h and also declares the context. I'm not 
thrilled with this, but fltk already contains wrappers for many header 
files including string.h, gl.h and math.h (mostly to provide portability 
to Windows).

The problem is that I need to declare the existence of the static cairo 
context and I tried to put it into an existing header file. This is the 
primary reason I asked a long time ago for cairo to use a thread-static 
context like OpenGL, as the need to declare this context object and get 
it to code that calls cairo is a serious impediment to adding cairo 
drawing to existing code. If cairo had not required this context 
argument then fltk/x.h would not even be necessary, instead you would 
just include cairo.h directly.

PS: other question. I would like to get fltk to use the "toy" font 
interface but am in desperate need of a font listing. Will the Xft code 
that lists fonts produce a reasonable subset of the names the "toy" 
interface takes? Also on Windows will using their font listing produce a 
reasonable subset? By "reasonable subset" I mean 90% or so of the fonts 
the user would actually care about, and NO names that don't work.