[cairo] Using UTF-8 filenames on windows
otaylor at redhat.com
Fri Feb 9 17:41:04 PST 2007
The attached patch switches cairo over so that, like GLib, that
filenames in its API are in UTF-8, not in the current system codepage.
Motivation: Not all windows filenames are representable in the current
system codepage ... internally they are Unicode strings; If we look at
possible ways you might be using Cairo from C.
- Using cairo in combination with GLib and GTK+. In this case, you
want the filename encoding to match that of GLib, so that you can
open a filename returned from the filechooser, etc.
- Using cairo as part of a "normal" Win32 native program. In this case,
you probably have wide filenames and want a way to reliably and
fairly conveniently pass them to the cairo API.
- Using cairo from a language binding or as part of a cross-platform
abstraction. In this case you likely have a Unicode filename encoded
in some well known encoding and want to be able to reliably pass it
to the cairo API. (Or you might use the stream functions and not
worry about filenames at all.)
- Using some toy command-line program. In this case you probably only
have ASCII filenames so it doesn't matter.
In all but the last case UTF-8 is better than the system codepage. In
the last case, I'd argue that we just don't care that much. I care most
about the first case, where we have lots of code that we claim that is
portable between Windows and Linux without modification; it's nasty
to add "as long as you don't use cairo_surface_write_to_png()" to that.
The patch also adds three convenience functions:
The first is useful for the second use case, where someone is
integrating cairo with native Win32 APIs; I'd like to be able to tell
people how to manage that use case without having to write their own
10-15 line helper function.
The second is less useful, so is included mostly for completeness and to
provide a reminder that you can't just pass an ANSI codepage filename
directly to cairo.
The third is just a necessary part of the first two, since you can't
allocate memory from one DLL/EXE on Windows and free it from another.
* These convenience functions are guarded by CAIRO_HAVE_WIN32_SURFACE,
which is a little bit of a stretch, but should work out in
* The patch is against the 1.2 branch, since that's what I'm actively
using at the moment.
* I haven't tested the configure.in bits, since I'm not using autoconf
for my windows build; it's only a few lines, but I still probably
got something wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 10981 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070209/22655d45/cairo-utf8-filenames-0001.bin
More information about the cairo