Inkscape

Can't export PNG image on Windows

Bug #1685091 reported by shark0r
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
High
Patrick Storz
Inkscape 1.0
0.92.x
Fix Released
Medium
Patrick Storz
Inkscape 0.92.2 "0.92.2"

Bug Description

version: Rev 15625 built by myself, and Rev 15615 downloaded from http://download.tuxfamily.org/inkscape/. 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 );
  how.append("b");
  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.

See original description
Revision history for this message
shark0r (shark0r) wrote :
shark0r (shark0r)
description: updated
Revision history for this message
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?

Revision history for this message
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 2.47.4.0, and that of 15625 is 2.52.0.0.

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.

Revision history for this message
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.

[1] https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-glib2/0001-Use-CreateFile-on-Win32-to-make-sure-g_unlink-always.patch
[2] https://bugzilla.gnome.org/show_bug.cgi?id=674214
[3] http://pubs.opengroup.org/onlinepubs/009695399/functions/fopen.html
[4] https://msdn.microsoft.com/library/yeby3zcb.aspx

Revision history for this message
Patrick Storz (ede123) wrote :

Minimal fix (only solving the issue with duplicate 'b' specifier) pushed to 0.92.x in
http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15416

A more complete fix that also addresses the unnecessary conditional compilation pushed to trunk in
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/15630

Please check for regressions (especially on POSIX systems)!

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

For reference:
MSYS2 downstream bug https://github.com/Alexpux/MINGW-packages/issues/2393

jazzynico (jazzynico)
Changed in inkscape:
importance: Undecided → High
milestone: none → 0.93
Qantas94Heavy (qantas94heavy)
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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