[cairo] Cairo on win32
dmon at xs4all.nl
Fri May 28 16:53:40 PDT 2004
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
>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
>>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
>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?
>>_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)
>> _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
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 :)
More information about the cairo