[cairo] Re: Cairographics on win32
oleg.smolsky at pacific-simulators.co.nz
Thu Apr 7 15:04:05 PDT 2005
Carl Worth wrote on Friday, 8 April 2005:
> As for the rest of it, there are some problems. In the proposed
> packaging/msvc/cairo-features.h, you have:
> //#define @PS_SURFACE_FEATURE@
> //#define @PDF_SURFACE_FEATURE@
> //#define @PNG_SURFACE_FEATURE@
> //#define @XLIB_SURFACE_FEATURE@
> //#define @QUARTZ_SURFACE_FEATURE@
> //#define @XCB_SURFACE_FEATURE@
> #define WIN32_SURFACE_FEATURE
> //#define @GLITZ_SURFACE_FEATURE@
> //#define @FT_FONT_FEATURE@
> First, there's a style problem as I don't like //-style in C code,
> (regardless of what C99 might say about it).
Sure, I can make everything ANSI C compliant. In any case, I've just
checked, and the only macros I really need are
and they are defined inside my .vcproj.
Actually, IMHO, they should be in packaging/msvc/cairo-features.h
which should be included really really early by every .c file......
> Second, the feature name macros are being defined improperly. They
> should be:
> #define CAIRO_HAS_NO_PS_SURFACE
> #define CAIRO_HAS_NO_PDF_SURFACE
> #define CAIRO_HAS_NO_XLIB_SURFACE
> #define CAIRO_HAS_WIN32_SURFACE
But that's only true as far your autoconf makefiles go. The source
code (namely cairo.c) references things like CAIRO_HAS_PS_SURFACE.
> But, third, and most important, I really don't like the idea of
> putting a build structure into the main cairo source tree that
> hard-codes away backends with no reason. The PS, PDF, and XLIB
> backends are all quite portable and should work just fine on the
> win32 platform.
I don't think so. Although, say, xlib backend is just a pile of
recompilable C code, a win32/msvc build would never have enough
headers to acually compile it. And even if these headers were
available, IMHO, xlib is a useless thing to have on win32. (unless you
are talking about the whole cygwin port, and that's not the case here)
>> P.P.S. where did PNG surface go?
> We eliminated PNG support as a separate surface type. This was really
> just providing a different way to create an image surface, and it had
> the downside of only providing PNG output from an image surface.
> Now, instead, we have a new cairo_surface_write_png.
Oh, I see. This makes sense.
More information about the cairo