[cairo] Cairo on Win32 platform

[Maarten Breddels]

Hi,

It might be a good time to add the win32 support to cvs. I've just
updated from cvs, most of the pattern stuff works. I've completed the
win32 font support, added a win32 surface backend, updated the freetype
backend and changed the font backend as described by the email I send a
few minutes ago. 

I also noticed that the postscript backend didn't work on win32, it
spits out binary data which ghostscript doesn't like. I tried to output
base85 encoding, but didn't get it to work without an hour :) So now it
generates hex output, which doubles the amount of data :(. 

I've noticed something didn't work with the pattern interface. When
fonts are drawn in the -x direction, the, it gets clipped. The problem
is that (0,0) and (text_extents.width, text_extents.height) are expected
to form a bounding box and the source pattern which is passed to the
font api is incorrent. This is not the case when text is rotated. I
guess we also want a cairo_font_getbbox(..)
Besides that, the patterns are looking kewl.

Some stuff I forgot in the previous email:
I've also added 
    double x_width;
    double y_width;
    double x_height;
    double y_height;
    double x_origin;
    double y_origin;
To the cairo_text_extents_t structure.
And
    double x_height;
    double y_height;
To the cairo_font_extents_t structure.

I don't really like the x_ y_ prefixes btw, maybe cairo_point_t is
needed?
(w_width, y_width) forms a vector that goes from the bottom left to the
top left corner of the text. I've written a fontdemo1.c file which
demonstrates these members.

I couldn't make a patch, when executing:
$ cvs rdiff -r SNAPSHOT_0_1_20 cairo
I get:
cvs-1.12.1-4 [server aborted]: Xr.pc.in,v is ambiguous; could mean
xr.pc.in,v or
 Xr.pc.in,v
Maybe, because win32 filesystem is case insensitive.

Well, I hope this version can be commited to cvs, I've create a diff,
and placed it together with the 3 new files and the fontdemo at:
http://freedesktop.org/~dmon/

-Maarten Breddels