[windows prebuild] pixbuf fails when starting pympress

[pank]

Describe the bug

With the two latest releases, I am unable to start pympress on windows.
I get the following error.

$ pympress test.pdf
Traceback (most recent call last):
  File "D:/a/pympress/pympress/pympress/app.py", line 226, in do_open
  File "D:/a/pympress/pympress/pympress/app.py", line 156, in do_activate
  File "D:/a/pympress/pympress/pympress/ui.py", line 262, in __init__
  File "D:/a/pympress/pympress/pympress/pointer.py", line 103, in __init__
  File "D:/a/pympress/pympress/pympress/pointer.py", line 118, in load_pointer
gi.repository.GLib.GError: gdk-pixbuf-error-quark: Couldn’t recognize the image file format for file “c:\path\to\pympress\share\pixmaps\pointer_red.png”

I have tried

• To add and remove pympress from the PATH.
• To remove inkscape from the PATH. Neither helped.
• To remove other entries from path that might use gtk
• To start pympress from its path.
• Change the Python version via the conda environment.

To Reproduce

1. I download pympress-v1.7.2-x86_64.zip or pympress-v1.7.2-i686.zip.
2. I try to run it from cmd

Environment (please complete the following information):

• OS: Windows
• Python version: 3.7 or 3.10
• Pympress version: 1.7.2
• Installation method: Github release

Debug information (see below for file locations)

• What is reported in pympress.log? Not produced.
• Does the problem still happen if you remove your config file? Yes

Additional context

• No log seems to be produced. Glib seems to kill pympress before it starts.
• pympress/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache seems to be fine...
• I am trying to run pympress from a corporate windows 10. I cannot install pympress via chocolatey

[Cimbali]

Is the file mentioned in the error message at the expected location? Can you open it?

[pank]

The file is fine. It's a standard PNG that is recognized by the os and by other programmes. I get the same error with the version installed by the msi.

[pank]

I added the full backtrace in the first message. D:/a/pympress/pympress/pympress/app.py looks like a build path. My path is c:\path\to\pympress.

Is there any prefix I might need to change?

[Cimbali]

I don’t think the path should be an issue if the path in the error message is where the file is located. Sometimes Windows has a hard time with spaces in paths but that should be fine from python.

• The first thing to do would be to add some error handling in load_pointer − failing to load an asset should not crash the whole program.
• The second thing is figuring out why loading a normal png file fails, which could be due to Gdk.Pixbuf not finding image loaders in which case we should try to see if there’s an incorrect loaders.cache (though you see to have already checked that?). This means playing around with the gdk-pixbuf-query-loaders utility, and its GDK_PIXBUF_MODULEDIR environment variable if there is a need to look in non-standard places. Though I must say I don’t know if we ship the query-loaders utility.

[pank]

Hmm, I only seem to have the compiled/frozen pyc files and I don't think I could set up the dependencies for compiling pympress on this system.

loaders.cache seems solid to me. This is the png part:

...
"lib\\gdk-pixbuf-2.0\\2.10.0\\loaders\\libpixbufloader-png.dll"
"png" 5 "gdk-pixbuf" "PNG" "LGPL"
"image/png" ""
"png" ""
"\211PNG\r\n\032\n" "" 100
...

and the loaders folder have the libraries libpixbufloader-png.dll and libpixbufloader-png.dll.a.

I tried to load the shipped library in a clean py39 environment (it seems to frozen against py39):

>>> import sys 
>>> sys.path.append("c:/path/to/pympress/lib/")
>>> import gi
ImportError: cannot import name '_gi' from partially initialized module 'gi' (most likely due to a circular import) (c:/path/to/pympress/lib\gi\__init__.pyc)

Not sure if you are supposed to be able to do this with pyc files though.

I tried to install gdk-pixbuf with conda and set GDK_PIXBUF_MODULEDIR=c:\path\to\pympress\lib\gdk-pixbuf-2.0\2.10.0\loaders\. But it cannot load the loaders, maybe because of version mismatches...

Is there somewhere where I can see the environment used for building the package?

[Cimbali]

Yes the build system is through github actions, specifically the windows-build step in this workflow. It’s also listed in the README, it’s basically a full-on MSYS2 system with the following packages (skipping those only needed for the build process − where ${{ matrix.arch }} is either x86_64 or i686):

mingw-w64-${{ matrix.arch }}-gtk3
mingw-w64-${{ matrix.arch }}-cairo
mingw-w64-${{ matrix.arch }}-poppler
mingw-w64-${{ matrix.arch }}-python3
mingw-w64-${{ matrix.arch }}-python3-pip
mingw-w64-${{ matrix.arch }}-python3-gobject
mingw-w64-${{ matrix.arch }}-python3-cairo
mingw-w64-${{ matrix.arch }}-python3-appdirs
mingw-w64-${{ matrix.arch }}-python3-setuptools
mingw-w64-${{ matrix.arch }}-python3-packaging
mingw-w64-${{ matrix.arch }}-python3-cx_Freeze
mingw-w64-${{ matrix.arch }}-python3-babel
mingw-w64-${{ matrix.arch }}-python3-watchdog

I’ve built binaries with the latest commit and that messed up the naming a little bit as they are not releases, but those versions should run without crashing at least (though probably failing to load the pointers PNGs properly.)

• c76262d i686 msi
• c76262d i686 zip
• c76262d x86_64 msi
• c76262d x86_64 zip

A good other debugging element would be to figure out whether other PNGs fail to load (icons, etc.) or just the pointers.

[pank]

The links do not appear to be working.

Meanwhile, I have tried to setup a conda environment to run "pip" pympress.
But conda pygobject doesn't seem to provide Poppler binding.

$ python -m pympress
Traceback (most recent call last):
  File "C:\Anaconda3\envs\pympress\lib\runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\Anaconda3\envs\pympress\lib\runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "C:\Anaconda3\envs\pympress\lib\site-packages\pympress\__main__.py", line 102, in <module>
    from pympress import app
  File "C:\Anaconda3\envs\pympress\lib\site-packages\pympress\app.py", line 38, in <module>
    from pympress import util, config, document, ui, builder
  File "C:\Anaconda3\envs\pympress\lib\site-packages\pympress\document.py", line 50, in <module>
    gi.require_version('Poppler', '0.18')
  File "C:\Anaconda3\envs\pympress\lib\site-packages\gi\__init__.py", line 126, in require_version
    raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Poppler not available

I guess this would normally be provided by the gir-poppler package in e.g. Ubuntu or Debian. Do you think this would be a "bug" in the Conda Poppler package or a question of convincing pygobject that Poppler really is available?

Conda dependencies:

• gdk-pixbuf
• poppler
• gtk3
• pygobject
• python=3.10
• gobject-introspection

Edit: I guess gi support ins't enabled in the conda poppler package... conda-forge/poppler-feedstock#49 (comment)

[Cimbali]

I think the issue is having the full gtk/gobject-introspection system using a windows-built python whereas msys against uses a mingw (i.e. gcc) built python, where getting the full setup is much easier. Last I tried I couldn’t get Poppler and bindings to compile on windows (gtk worked but not fully featured I think, and a little brittle). Interesting though it is, it’s a bit too much of a rabbit hole for me. My last efforts are here though you may need an appveyor account to see them − all that was years ago though.

It is great that poppler is compiled and shipped on conda. It would be even greater if it shipped the .typelib and .gir files, or if they were in separate packages (through gir or typelib packages). The gtk3 package ships the basic ones:

Library/lib/girepository-1.0/GdkWin32-3.0.typelib
Library/lib/girepository-1.0/Gdk-3.0.typelib
Library/lib/girepository-1.0/Gtk-3.0.typelib
Library/share/gir-1.0/GdkWin32-3.0.gir
Library/share/gir-1.0/Gdk-3.0.gir
Library/share/gir-1.0/Gtk-3.0.gir

and gobject-introspection ships a lot of gir files but not the one for poppler of course.

Arguably it would only be a small increment to the conda recipes so could be extrapolated from their work and maybe even merged there.

I’ve also fixed the links to the installers and zips above to outside github for now − until they get a proper release which will make them downloadable.

[Cimbali]

You can get the binaries from the artifact zip here, that’s a little less shady: https://github.com/Cimbali/pympress/actions/runs/2610972958#artifacts

[pank]

I can start pympress with the latest build. But is still complaining about pngs.

Moving the mouse inside the window constantly creates errors relating to Adwaita icons_

(pympress.exe:19056): Gdk-CRITICAL **: 17:09:22.830: gdk_cairo_surface_create_from_pixbuf: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(pympress.exe:19056): Gtk-WARNING **: 17:09:22.885: Error loading theme icon 'window-close' for stock: Failed to load /org/gtk/libgtk/icons/16x16/actions/window-close.png: Unrecognized image file format

(pympress.exe:19056): Gtk-WARNING **: 17:09:22.919: Error loading theme icon 'image-missing' for stock: Failed to load c:\path\to\pympress\share\icons\Adwaita\16x16/status\image-missing.png: Unrecognized image file format

And I can crash the the program with the clicking help > shortcuts:

Gtk:ERROR:../gtk/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load c:\path\to\pympress\share\icons\Adwaita\16x16/status\image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Bail out! Gtk:ERROR:../gtk/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load c:\path\to\pympress\share\icons\Adwaita\16x16/status\image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)

Strangely, it does show the Annotations Highlight icons. But they blink when I hover the mouse over them.

[pank]

Aside: I just noticed that conda gdk doesn't support png:

(pympress) $ gdk-pixbuf-query-loaders  | grep -i png

but it is actually missing the pixbufloader files.

[Cimbali]

Interesting. Can you use that query loaders binary with GDK_PIXBUF_MODULEDIR set to the pympress-shipped module dir?

[Cimbali]

In any case I’ll try and get my hands on a windows machine soon and reproduce this.

[Cimbali]

By the way, does the log file contain a Media support using GdkPixbuf is disabled. error message?

[pank]

Interesting. Can you use that query loaders binary with GDK_PIXBUF_MODULEDIR set to the pympress-shipped module dir?

No it crashes. I think the versions are (too) different. It can't load any of the loaders.

But the loaders.cache is the same format as gdk-pixbuf-query-loaders, e.g.

"lib\\gdk-pixbuf-2.0\\2.10.0\\loaders\\libpixbufloader-png.dll"
"png" 5 "gdk-pixbuf" "PNG" "LGPL"
"image/png" ""
"png" ""
"\211PNG\r\n\032\n" "" 100

I can check if this matches the output on my GNU/Linux machine.

[Cimbali]

Thanks for checking. The Highlight buttons are rendered with cairo not GdkPixbufs as we need to color them − hence why they don’t suffer from a loader issue.

[pank]

By the way, does the log file contain a Media support using GdkPixbuf is disabled. error message?

I don't see those messages. Most seem to be missing png icons. One that I noticed is missing is the downward-pointing arrow for dropdown lists (e.g. in the window where you can configure the presenter's screen).

[Cimbali]

I just had an antivirus interfere with gdbus.exe… Could something like that happen to you?

Also are you using Windows 11? I only have 10 to test it on and can’t reproduce. Not that it should be the cause here.

Finally can you report the first 2 lines of your log file?