[cairo] Cairo on win32

[Hans Breuer]

At 23:07 26.05.04, Maarten Breddels wrote:
>I read on the Dia thread that Hans Breuer also got cairo working on
>win32. Nonetheless I hereby send a small diff and 2 files. I don't care
>which patch gets into the cvs, i'd just like to see cairo on win32.
>
>The diff includes a change to the freetype backend, instead of the
>FcPattern argument, the font create function takes a filename as
>argument, or a part of the filename(<windows font dir>\<pattern>.ttf),
>where the <windows font dir> is taken from the registry. In cairoint.h I
>changed the default font to 'times', (so it will load
>'c:\windows\fonts\times.ttf').

Why didn't you use fontconfig - which is available for win32 too ?
[Should be availbale where Gimp 2.0 is, ie. Tor's site]
To avoid the extra dependency ? [IIRC it already does the necessary
Registry lookup and it will definitely be needed when Cairo and Pango
do work together more closely.

>The file cairo_win32.c includes the function FcUtf8ToUcs4 taken from
>fontconfig (is this ok?) since it's needed in cairo_ft_font.c but
>fontconfig isn't linked to . It also includes a load of #pragma
>directives to export the symbols for building a DLL. This avoids adding
>(ugly) dsa __declspec(dllexport)'s to cairo.h. This approach gives an
>advantage over an '.DEF' file, because symbols are exported
>conditionally, depending on CAIRO_HAS_PS_SURFACE etc.

Nice to see that there is another (ugly:) way to export symbols. I see the 
benefit but am not sure if it will stay one the long run. Also isn't it 
pure maginal to exclude the PS Surface, i.e. make something optional which 
doesn hurt anyone.

If there is really some backend missing sometime in a Cairo build would 
just exporting the function anyway - with simple implementation reporting 
an error - be better ?
NOTE: if a symbol is missing in a DLL which is statically linked into a 
program the program won't start anymore.
Thus you - as a user - don't only loose one backend but maybe the whole thing.


>cairo_win32_surface.c implements a simple surface for displaying on a
>window, usefull for playing around with cairo on windows.
In my mind the Cairo Win32 Surface was always based on a Device Context - a 
HDC in win32 api parlance. Having a Window Creation within Cairo is sure 
useful to have something visible, but finally the window creation and event 
handling needs to be outside of Cairo to make it fit with the next level - 
being either a toolkit or an application.

Using a Device Context would also allow Cairo to not only draw on windows 
and memory backends but also to be bound to a printer (driver). On could 
even use
a metafile DC got from CreateEnhMetaFile(() and let the update be done by 
PlayEnhMetaFile(). See dia/plug-ins/wmf/wmf.cpp for all those nice things 
being doable with metafiles ;-)

[...]
>static cairo_int_status_t
>_cairo_win32_surface_show_page (void *abstract_surface)
>{
>     cairo_int_status_t status;
>     cairo_win32_surface_t *surface = abstract_surface;
>         int exit = 0;
>         MSG msg;
>         HDC hdc;
>
>         ShowWindow(surface->hwnd, SW_SHOWDEFAULT);
>     status = _cairo_win32_surface_copy_page (surface);
>     if (status)
>         return status;
>         GdiFlush(); // Let gdi know we updated the dib surface
>         hdc = GetDC(surface->hwnd);
>         BitBlt(hdc, 0, 0, surface->width, surface->height, surface->cdc, 
> 0, 0, SRCCOPY);
>         ReleaseDC(surface->hwnd, hdc);
>
>         while(GetMessage(&msg, NULL, 0, 0) == 1)
>         {
>                 TranslateMessage(&msg);
>                 DispatchMessage(&msg);
>         }
>
>     _cairo_win32_surface_erase (surface);
>
>     return CAIRO_STATUS_SUCCESS;
>}

If I understand correctly this function does only return until the user 
closes the window (or is it the application, WM_QUIT ?)

Regarding your other mail : I'm definitely interested in a native 
cairo_win32_font implementation - and also interested in some "more native" 
win32 backend as outlined above (but even more in a PDF backend ;). But I 
don't know when I'll find the time to implement something along those lines 
myself.

Thanks,
         Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert