[cairo-bugs] [Bug 103536] New: Windows filenames should be in UTF-8 encoding

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=103536

            Bug ID: 103536
           Summary: Windows filenames should be in UTF-8 encoding
           Product: cairo
           Version: unspecified
          Hardware: Other
                OS: Windows (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: win32 backend
          Assignee: cairo-bugs at cairographics.org
          Reporter: Tom.Schoonjans at me.com
        QA Contact: cairo-bugs at cairographics.org

Currently all cairo functions involving writing or reading from files, use the
fopen call to access those files. This works fine on Linux and macOS, but is
troublesome on Windows since it assumes that the filename string is encoded in
the ANSI codepage (see
https://msdn.microsoft.com/en-us/library/yeby3zcb.aspx#Anchor_2 for more on
this).

This means that UTF-8 encoded filenames cannot be passed to these cairo
methods, since any non-ASCII characters will be misinterpreted leading to
run-time fopen errors (file not found etc). This is particularly unfortunate
when writing cross platform software using Gtk+/Glib, which use UTF-8 filenames
throughout the API. 

Keeping in mind that Microsoft is actively discouraging the reliance on
codepages
(https://msdn.microsoft.com/en-us/library/windows/desktop/dd317756(v=vs.85).aspx),
I was wondering if the cairo maintainers would be willing to accept a patch
that fixes this issue by switching to the internal usage of _wfopen
(https://msdn.microsoft.com/en-us/library/yeby3zcb.aspx) for the Windows
platform, which would convert the UTF-8 filenames to their UTF-16 wide
character string counterparts that will then be passed to _wfopen, very similar
to what glib does with its g_fopen function.

I actually already found a 10 year old patch on the mailing list
(https://lists.cairographics.org/archives/cairo/2007-February/009591.html),
which was unfortunately never merged in, and may serve as a starting point for
a new patch, compatible with the master branch.

I would be more than willing to perform the necessary work for this.

Thanks in advance for your reply,

Tom

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cairographics.org/archives/cairo-bugs/attachments/20171101/0612a572/attachment.html>