Can't export PNG image on Windows

Bug #1685091 reported by shark0r on 2017-04-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Patrick Storz
Patrick Storz

Bug Description

version: Rev 15625 built by myself, and Rev 15615 downloaded from Both are x64 and both have this problem.
OS: Windows 7 64bit

To export the document to PNG image, when I pressed the "Export" button, Inkscape showed a message box "Could not export to filename XXX.png" and couldn't save the file.
"Export PNG Image" failed, but "Cairo PNG" in "Save a Copy" worked.

I have seen the codes. In sp_png_write_rgba_striped(), helper/png-write.cpp I saw this line.

  fp = Inkscape::IO::fopen_utf8name(filename, "wb");

And in fopen_utf8name(), io/sys.cpp, I found these lines, in an #ifndef block and only be executed on Windows.

  Glib::ustring how( mode );
  DEBUG_MESSAGE( .... );
  fp = g_fopen(utf8name, how.c_str());

So 'how' became "wbb" and g_fopen() returned NULL. If I changed 2nd parameter of fopen_utf8name() to "w", PNG file was saved properly.
But these lines exist in the stable release 0.92.1 too. Not sure why 0.92.1 doesn't have this problem.

And I checked further and found 2 other lines called fopen_utf8name() with mode "rb" or "wb", in sp_file_save_backup(), src/file.cpp.

shark0r (shark0r) wrote :
shark0r (shark0r) on 2017-04-21
description: updated
Alvin Penner (apenner) wrote :

not reproduced on Windows 10, Inkscape 0.92+devel 15626

could you try exporting to a different drive and directory to see if that changes anything?

shark0r (shark0r) wrote :

I did further tests. If I replaced libglib-2.0-0.dll in 0.92.1 with the same dll in Rev 15625, the problem occurred in 0.92.1 too.
Due to DLL dependency I couldn't test 0.92.1 DLL with 15625 exe.

And I wrote a small program which loaded Glib DLL and called g_fopen("a.txt", "wbb"). g_fopen() succeeded with 0.92.1 DLL but failed with 15625 DLL.

Maybe there was something changed in Glib. The version number of 0.92.1's DLL is, and that of 15625 is

Is "wbb" or "rbb" a reasonable value for g_fopen()? I used g_printerr() to show the value of 'how' and it was surely "wbb".
If this is an undocumented behavior, I think it would be better to fix it.
But I am not sure which way is better. Change fopen_utf8name() itself and remove "how.append("b");", or change fopen_utf8name() callings and remove the "b" mode.

Patrick Storz (ede123) wrote :

The issue arises because MSYS2 uses a patched version of glib's stdio.c (see [1]) that obviously chokes on the duplicated 'b' modifier. (For the background of this patch see [2]).

As the duplication of 'b' certainly does not seem to be standard conforming (see [3,4]) that code should be fixed and we're certainly lucky Microsoft's implementation of fopen() was lenient enough not to fail before.

A general thing I noticed: Why do we use separate code paths in fopen_utf8name() to start with? Calling g_filename_from_utf8() followed by g_open() should work across all OSs.


Patrick Storz (ede123) wrote :

Minimal fix (only solving the issue with duplicate 'b' specifier) pushed to 0.92.x in

A more complete fix that also addresses the unnecessary conditional compilation pushed to trunk in

Please check for regressions (especially on POSIX systems)!

Changed in inkscape:
assignee: nobody → Eduard Braun (eduard-braun2)
status: New → Fix Committed
Patrick Storz (ede123) wrote :

For reference:
MSYS2 downstream bug

jazzynico (jazzynico) on 2017-04-22
Changed in inkscape:
importance: Undecided → High
milestone: none → 0.93
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.