[cairo] Cairo on win32

[Maarten Breddels]

Hans Breuer wrote:

>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.
>
>  
>
Well, the dll from the DIA site crashed, and i haven't figured out how
to build it myself. Can you give me some hints how to build it? What i
remembered is that there were some POSIX functions missing in the win32
libs, so i guess someone implemented them?

>>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.
>
>
>  
>
I now thing the def file is probably better, it's portable, and easy to
edit.

>>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 ;-)
>
>  
>
Well, the win32 backend was really not meant to be generic, I just like
it when you can get graphical output with just a few lines of code.
Maybe it's a good idea to make at least 2 backends for win32.
cairo_win32window_surface_backend and cairo_win32gdi_surface_backend.
One for a quick result non-generic as it can be, the other more generic
with bells and whistles. Do you think it's a good idea?

>[...]
>  
>
>>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 ?)
>
>  
>
Yes, it 'blocks' at every cairo_show_page(..), when the window closes it
goes on, until another cairo_show_page(..) gets called. So it's usefull
for displaying multiple pages.

>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
>
>  
>
If I have the time, i'll try to get it working with the current cairo
code again. Shall I email it to you when done?
Btw, a small tip, if you update the cairo code from cvs, add these lines
to your 'fake' stdint.h:
    typedef unsigned __int64    uint64_t;
    typedef __int64        int64_t;
It's needed for the new 64/128 bit integer math, and it took me a while
to get what was generating these strange compiler errors :)
Yeah, I feel an itch to implement a PDF too :) But I think I read that
some people are working on it, and I should spend more time on my study :)

Greetings, Maarten