[cairo] Re[2]: Cairographics on win32

[Oleg Smolsky]

Hello Carl,

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
CAIRO_HAS_WIN32_FONT=1
CAIRO_HAS_WIN32_SURFACE=1

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.

Best regards,
Oleg.