Hi @claell,

We use GTK3 installer because Pango is needed. If you find another (quite easy) way to install Pango on Windows, you’ll have a more recent version of glib.

Else, you can use the WeasyPrint Windows executable available on the latest release.

@grewn0uille, thanks for your reply!

I already suspected the reasons behind this. But the thing is that currently, that is causing the mentioned issue. But maybe, there is no other good way to put in the documentation, instead. I was hoping that there are newer versions of GTK3/a standalone Pango installer that can be referenced in the WeasyPrint documentation.

@claell Could you please try to uninstall GTK3 and unzip the zip from this build in C:\Program Files\GTK3-Runtime Win64 (even if it’s actually GTK4, that’s just a test). You should have a C:\Program Files\GTK3-Runtime Win64\bin folder, and WeasyPrint should work!

Just did that and tested. Unfortunately, that gives me this error:

OSError: ctypes.util.find_library() did not manage to locate a library called 'fontconfig-1'

Without anything in that folder, I get:

OSError: cannot load library 'gobject-2.0-0': error 0x7e.  Additionally, ctypes.util.find_library() did not manage to locate a library called 'gobject-2.0-0'

So, extracting that into the folder did something, but probably some libraries are not found (maybe due to name change).

Just did that and tested. Unfortunately, that gives me this error:

Oh yes, Fontconfig’s not included in this build.

Maybe we should ask Windows users to use Msys2, just as we do in CI. Their packages are regularly updated.

I am open to other solutions. As a user, I mostly want an easy and robust way to use WeasyPrint. 🙂

If MYSYS2 is the way, then I'll use that. What are the steps to make it work with WeasyPrint?

I am open to other solutions. As a user, I mostly want an easy and robust way to use WeasyPrint. 🙂

There are many other solutions that may be actually easier depending on your use case and your experience:

• you can use the GTK3 installer as you did, as the message is just a warning and doesn’t prevent WeasyPrint from working correctly,
• you can use the Windows executable that comes with all the dependencies bundled,
• you can use WSL2,
• you can use a Linux VM or a container, as WeasyPrint is already packaged for many Linux distributions.

If you do want to try Msys2, you can follow its installation guide. Then, you can more or less follow what’s done in CI:

• pacman -S mingw-w64-x86_64-pango
• python -m pip install weasyprint
• weasyprint --info

Maybe, I should have added that I want to use WeasyPrint from a Python program within Windows.

If I understand things correctly, many of the solutions mentioned would not work with the WeasyPrint Python script, as the WeasyPrint package could for example not interact with the GTK libraries in WSL2, right? And I think the same is true for MYSYS2? Because there, WeasyPrint is installed in the MYSYS2 shell, which is not connected to my Windows WeasyPrint installation?

The first option that you mentioned brings us back to this issue. Sure, it works, but is not ideal.

So to specify again, what I want as a user:

Use WeasyPrint with a (native) Python installation on Windows. So I use my Code editor on Windows, there select the correct Python version with installed packages and run the script. That script then uses the required libraries on my computer.

• The setup should be easy (ideally installing the WeasyPrint package and if needed on time executing an installer for needed dependencies)
• There should not be warnings like the one from this issue

Is there a solution that can do this?

And I think the same is true for MYSYS2? Because there, WeasyPrint is installed in the MYSYS2 shell, which is not connected to my Windows WeasyPrint installation?

Msys2 installs DLLs on the filesystem, and you can reach them without its shell. Look at what’s done in CI, we don’t launch WeasyPrint’s tests from the Msys2 shell. I suppose you can do the same, maybe by setting the WEASYPRINT_DLL_DIRECTORIES environment variable.

• The setup should be easy

I wish too there was an easy way to install packages on Windows, just as Homebrew on Mac or package managers on Linux.

Is there a solution that can do this?

It’s a question for you, and other Windows users, isn’t it? I’ve not used Windows for years, I don’t know anything about how it works, you probably know much more than me to answer this question! 😄

To be honest, by far, most OS-specific problems we have to deal with come from Windows, even if most of our users are on Linux. We tried many different ways to help Windows users, by spending countless days on the Windows documentation, by spending weeks trying to generate exe files (that just fail randomly on some Windows computers, print error messages on other computers, are randomly marked as trojans by Kapersky and Windows Defender), by answering countless issues, with countless comments added to closed issues.

And what’s the result of this endless work? People complain, and ask for even more solutions.

🙏🏽 Please, dear Windows users, do propose a solution. If you want an easy way to install WeasyPrint, please help us, just as Homebrew packagers on Mac, or Linux users opening pull requests and packaging WeasyPrint and its dependencies. 🙏🏽

Everyone is allowed to find solutions and contribute!

Ah, didn't know that MSYS2 works like that. Then, this is exactly the easy solution, I am looking for (plus it has a package manager, which makes updating packages very convenient).

I read some frustration with Windows from your post, and really, I can understand that. I just aim to have a working solution, and hopefully, MSYS2 will do that for me. :)

(BTW, I am using Linux since I was a child, just also have Windows machines for daily work, and as a user, I must say that desktop Windows is at least nowadays much better with fewer bugs than Linux desktop environments - especially with multiple screens, ...).

Okay, quick update:

I happened to already had MSYS2 installed on my system. Apparently, it even had the Pango package installed, already, at least it said so when I ran pacman -S mingw-w64-x86_64-pango.

So, with that information, probably some environment variable needs to be set for WeasyPrint to find the libraries. I'll try to play around with it; some hint might be needed, but let's see.

If that succeeds, then possibly, that might be a nice way of setup to add to the documentation (as apparently, there are not really up to date installers of GTK available for Windows - didn't check, but I guess you'd use them if they were existing).

Mh, I had a look in the MSYS2 directory on my computer. In theory, I could make the environment variable point to that (or one of the subfolders). But from what I saw, I expect it to not work. There doesn't seem to be a fontconfig inside.

Okay, just tried copying the content from C:\msys64\mingw64 to C:\Program Files\GTK3-Runtime Win64.

This is the error that I get:

OSError: cannot load library 'gobject-2.0-0': error 0x7e.  Additionally, ctypes.util.find_library() did not manage to locate a library called 'gobject-2.0-0'

I also found https://github.com/Automattic/node-canvas/wiki/Installation:-Windows-(using-MSYS2), which describes a rather complicated procedure; not sure whether this is also needed for WeasyPrint.

Here’s what I did in my VM to test:

• Install Msys2, keep the default options, the Msys2 terminal is automatically launched at the end.
• In the Msys2 shell, pacman -S mingw-w64-x86_64-pango, then close the Msys2 shell.
• Install Python3 from Microsoft Store.
• Launch cmd.exe:
  • python3 -m venv venv
  • venv\Scripts\activate
  • pip install weasyprint
  • set WEASYPRINT_DLL_DIRECTORIES=C:\msys64\mingw64\bin
  • weasyprint --info

I get:

System: Windows
…

In the future, we can even include C:\msys64\mingw64\bin in default paths where libraries are searched for, as we did for the GTK3 installer, so that users don’t have to set the environment variable.

Mh, setting the environment variable didn't work either. Maybe there is something from with my MSYS2 installation or the weasyprint setup. I'll test again, with a more clean set up.

Okay, so here are my steps (tested on another machine with rather clean set up):

• Have Python installed (mine was already installed, through the Python installer, for the user, not for admin, version is 3.11.9, in case it matters)
• Install MSYS2 (from https://www.msys2.org/)
• After installation, in the shell execute pacman -S mingw-w64-x86_64-pango
• Open a Windows terminal, run pip install weasyprint
• in the terminal, run set WEASYPRINT_DLL_DIRECTORIES=C:\msys64\mingw64\bin
• run weasyprint --info

Output (shortened to the relevant part):

OSError: cannot load library 'gobject-2.0-0': error 0x7e.  Additionally, ctypes.util.find_library() did not manage to locate a library called 'gobject-2.0-0'

Not sure, I think venv shouldn't be necessary, and it should also not matter from where Python was installed, right? So I am really puzzled, why it works for you, but I can't get it to run on two machines.

Also, I manually checked the contents of C:\msys64\mingw64\bin. There is no file called gobject-2.0-0 in there. Possibly, that points towards the issue?

Edit: Well, there is libgobject-2.0-0.dll in there, so probably that shouldn't be the issue.

Okay, so the first issue/mistake I made is apparently using Windows Terminal (which runs PowerShell), and while set works in cmd, it doesn't seem to work as expected in PowerShell.

Now, I seem to have successfully set the environment variable, but as of now still get the same error from weasyprint.

Edit: Well, there is libgobject-2.0-0.dll in there, so probably that shouldn't be the issue.

Yes, that’s the DLL you need.

Okay, so the first issue/mistake I made is apparently using Windows Terminal (which runs PowerShell), and while set works in cmd, it doesn't seem to work as expected in PowerShell.

I suppose that this syntax works with PowerShell. I didn’t test.

Not sure, I think venv shouldn't be necessary

Using a virtual environment is almost always a good idea. This way you exactly know which version of Python you use and which libraries you’re importing. Otherwise, who knows where import weasyprint finds the WeasyPrint library or which weasyprint executable you’re launching?

it should also not matter from where Python was installed, right?

I don’t know. I don’t know anything about Windows.

I am really puzzled, why it works for you, but I can't get it to run on two machines.

Maybe you could try to really follow the steps I proposed (with Python from the store, a virtual environment, and cmd) and see if it works? If it does, then you can spend all the time you want to try all the other ways you want.

Yup, I found most of the things already. Also tested in cmd. I am now testing with Python from MS Store and venv, as proposed.

BTW: I am using Windows 11, in case that is relevant.

So, following your steps worked. Now, the question is why (or why it didn't work before).

As I set up the GTK3 installer again on a machine, I noticed that it required a reboot for WeasyPrint to pick up the location (possibly because I fiddled around a bit with the files, etc.). So maybe, the virtual environment will make setting the environment variable work properly.

Interestingly, after testing different combinations, I found that it is Python from the Windows Store, which was the important factor here (just adding for documentation, in the future this will likely be irrelevant).

I'll now try setting the environment variable permanently and restarting Windows afterward. Hopefully, then also the weasyprint installation from the "regular" Python interpreter will pick it up.

This is really puzzling to me. Setting the environment variable permanently (using setx), tried both for user and system and also rebooted afterward, doesn't make weasyprint --info work for me, either.

Possibly, that environment variable is only picked up under certain circumstances by WeasyPrint.

I hope these findings give some hints on how to do a permanent inclusion of the MSYS2 path, that will then hopefully lead to a more flawless and straightforward experience on Windows.

So, following your steps worked.

Then, that was a good idea to follow my steps.

Interestingly, after testing different combinations, I found that it is Python from the Windows Store, which was the important factor here (just adding for documentation, in the future this will likely be irrelevant).

Any idea why?

Possibly, that environment variable is only picked up under certain circumstances by WeasyPrint.

That’s just os.getenv(), nothing strange:

You can try to launch a Python interpreter and type:

import os
print(os.getenv('WEASYPRINT_DLL_DIRECTORIES'))

I’ll change the documentation, asking users to use Msys2, because it’s maintained and because that’s what we use for CI. I’ll add the steps I proposed, because they’re straightforward and I know that they work. If users want to try other solutions, no problem, but there’s nothing I can do for them.

Any idea why?

No, that is puzzling me. I know that Python from the Windows Store is set up slightly differently. Maybe it's also something else, didn't really test different Python versions, yet.

You can try to launch a Python interpreter and type:

import os
print(os.getenv('WEASYPRINT_DLL_DIRECTORIES'))

Just tried (for both, the normally installed Python and the one from the Windows store). Both seemed to give the same output, so nothing strange there, that I could spot.

I also figured out some code to test within a python interpreter (possibly making things less dependent on other functions and allowing testing right from within a python version):

Test code:

import os
os.environ['WEASYPRINT_DLL_DIRECTORIES']='C:\\msys64\\mingw64\\bin'
print(os.getenv('WEASYPRINT_DLL_DIRECTORIES'))
import weasyprint

Still the same issue; I tested Python 3.11 and 3.12, both, from Store and normal installation. The pattern stays the same. Store works, normal installation doesn't.

Possibly, it will work when the MSYS2 path is hardcoded as in

Let's see, I guess I'll need to wait for now and see. Thanks for your help (and in general supporting Windows in the first place), so far!

Which Python installer do you use exactly?

The ones from https://www.python.org/downloads/

(visiting from a Windows computer):

Edit: Specifically: https://www.python.org/ftp/python/3.12.3/python-3.12.3-amd64.exe

Then I don’t know what’s wrong.

Yes, that's also what is puzzling me. Maybe some special thing about my setup, a rare bug, ...

I’ve open #2151, please check that everything is OK before we can close this issue!