Weasyprint not working on Windows 7 x64 / Python 3.6.2 x64 / GTK3 runtime x64

[micsanbr]

Hello,

I tried to follow the installation instructions as carefully as possible (and repeated the process twice with python 3.6.4 and 3.6.2 without getting installation errors). I am running windows 64 bit, using python 64 bit and GTK 3 64 bit (gtk3-runtime-3.22.26-2017-11-15-ts-win64.exe).
Visual C++ Build Tools were already installed on the system previously as well as Visual Studio 2017.
I did run the line "pip install --upgrade setuptools" as instructed in Python's wiki.

WeasyPrint just prints multiple error messages when testing using the command:

python -m weasyprint http://weasyprint.org weasyprint.pdf

Traceback (most recent call last):
File "C:\Users\sad1lo\AppData\Local\Programs\Python\Python36\lib\runpy.py", line 183, in _run_module_as_main
mod_name, mod_spec, code = _get_module_details(mod_name, Error)
File "C:\Users\sad1lo\AppData\Local\Programs\Python\Python36\lib\runpy.py", line 142, in get_module_details
return get_module_details(pkg_main_name, error)
File "C:\Users\sad1lo\AppData\Local\Programs\Python\Python36\lib\runpy.py", line 109, in get_module_details
import(pkg_name)
File "C:\Users\sad1lo\AppData\Local\Programs\Python\Python36\lib\site-packages\weasyprint_init.py", line 375, in
from .css import preprocess_stylesheet # noqa
File "C:\Users\sad1lo\AppData\Local\Programs\Python\Python36\lib\site-packages\weasyprint\css_init.py", line 29, in
from . import computed_values
File "C:\Users\sad1lo\AppData\Local\Programs\Python\Python36\lib\site-packages\weasyprint\css\computed_values.py", line 16, in
from .. import text
File "C:\Users\sad1lo\AppData\Local\Programs\Python\Python36\lib\site-packages\weasyprint\text.py", line 18, in
import cairocffi as cairo
File "C:\Users\sad1lo\AppData\Local\Programs\Python\Python36\lib\site-packages\cairocffi_init.py", line 41, in
cairo = dlopen(ffi, 'cairo', 'cairo-2')
File "C:\Users\sad1lo\AppData\Local\Programs\Python\Python36\lib\site-packages\cairocffi_init.py", line 38, in dlopen
raise OSError("dlopen() failed to load a library: %s" % ' / '.join(names)) OSError: dlopen() failed to load a library: cairo / cairo-2

[micsanbr]

I found something called "GTK#" in my installed application list and decided to uninstall it.
I have no idea which other application installed it and if it will break something later on.

After this, I've repeated all the steps and now weasyprint works.

Perhaps the info could be added as a note to the installation instructions here:
http://weasyprint.readthedocs.io/en/latest/install.html#windows

Btw it's hard to miss the strange tone directed exclusively to Windows users ("Dear Windows user", "Don’t cheat", "kittens will die because of you", etc.).
The author sounds a bit childish.

[liZe]

The author sounds a bit childish.

I am.

Btw it's hard to miss the strange tone directed exclusively to Windows users

Btw it's hard to miss the strange tone from Windows users too!

A lot of users reported problems like this one (see #590 just after you, or #573 for example), that's why I'm angry. Not against users, against the OS.

I found something called "GTK#" in my installed application list and decided to uninstall it.

WeasyPrint relies on CairoCFFI, that uses ctypes.util.find_library from the standard library to find the DLL. If WeasyPrint can't find your DLL, it's because Python can't find it. And if Python can't find it, there's nothing I can / want to do about that.

Perhaps the info could be added as a note to the installation instructions here:
http://weasyprint.readthedocs.io/en/latest/install.html#windows

I'd really and sincerely appreciate a PR with kind installation instructions and some useful hints.

[michelesandroni]

Yes I got the point already, a few windows users accidentally mixed up components designed to work on different architectures.
Now that's pretty good if you compare the weasyprint installation process between linux / osx (copy-pasting a line in terminal) and windows (convoluted and prone to errors).
The explanation is fragmented (go to website A, download tool X, reboot, go to website B, read paragraph Y, etc.).

Feel free to blame the OS as well but weasyprint is one of the few exceptions in Windows where a tool is harder to install than in linux, perhaps because of some deliberate development design choices (no interest in providing a pre-built binary) or lack of better deployment options provided by python (not sure about this).

As for the hint, you could simply add a note that says:

In Windows check in "System Settings > Apps & Features" if you have a GTK framework already installed because it might conflict with the GTK+ for Windows Runtime Environment Installer. If another GTK framework is present, it might need to be removed.

[liZe]

I don't like to be blamed for the work I don't do when I spend so much time providing an open source tool for free.

When there's something wrong on Wikipedia, you have two options:

• blame the Wikipedia contributors for their poor work, or
• become a contributor.

It's the same choice with WeasyPrint. You can blame me for my poor work and my "deliberate development design choices", or you can become a contributor.

As I said earlier, I'd really appreciate a pull request with better documentation.

[michelesandroni]

First of all thanks for the good work you have put into this project.
I think everyone really appreciates it.

As for the documentation PR request, like stated in my 2nd post above, the documentation works as is and the issue was caused by another version of GTK installed by some other software.
If the installation process remains the same, there's not much more to add, don't you think?

Of course I am not going to redact your jokes, that would be weird.
You had a laugh about windows users, it's fine.
I am ok with your humor as long as you can take some criticism about it without reacting like this.
You are free to imply that windows users are "cheating" (as in "careless" or "lazy") but I am not free to reply it might have to do with something else?

Not sure if relevant but, for your information, I also put my free time in free software work (released under MIT license elsewhere / not on github).
Finally I don't get the connection with Wikipedia (to whom I regularly donate) because they try to be as objective as possible. If a wikipedia article contains a block titled "criticism", "controversy", etc. you will find sources and informations, not personal opinions.

[Tontyna]

Indeed, I was contemplating on a PR explaining to Windows users how to install a working environment. On Linux and OS X that's almost part of the system. The average user never tinkers with that.

The really hard part is the GTK runtime.
The really hard part is to build a GTK-For-Windows-Installer-for-the-average-Windows-user that works out-of-the- box and doesn't conflict with other GTKs already present.

Your advice not to cheat because You're on your own! recalled the lessons learned from my various attempts to install GTK -- MinGW? MinGW-w64? MSYS? MSYS2? Pacman? Anybody please tell me: Which package? library? do I need? There should be a manpage! What? Requires groff and Perl and and and.... Yes, you're on your own and kittens will die.

I really enjoyed that sentence. Please, please never remove it!

Ok, WeasyPrint requires an appropriate GTK Runtime.

In principle, it's easy:

• Unzip an up-to-date folder structure, containig the required binaries and config files to a folder of your choice.
• This runtime should contain a use-this-runtime.cmd which adds the path to the binaries (temporarily) to the %PATH%.
• When the runtime is out-of-date, delete the folder and download the updated one.

That should be enough for users used to work in the command prompt. Such users, I suppose, know how to persist that path in their PATH. And know how to force that path being the one that's found when Windows searches for the GTK binaries.

Not-so-advanced (!?) users know nothing about PATHs and expect that checking "Set up PATH environment variable to include GTK+" does the trick. And indeed, it does. In principle.

@mchlsndrn -- I don't know much about other GTK frameworks and whether they all manifest themselves in the "System Settings". But I know that it's not about finding a "GTK framework" but about finding DLLs. If WeasyPrint requires, for example, gdk_pixbuf, the first 'gdk_pixbuf-2.0.dll' or 'gdk_pixbuf-2.0-0.dll' found in your PATH is the winner, not necessarily at the same location like the previously found cairo.
Aka DLL hell.

If WeasyPrint was a standalone application it could provide and force Windows to use its own local GTK-For-WeasyPrint-On-Win32-Win64 [just kidding].

[micsanbr]

@Tontyna: I dont know much about GTK in general mainly because GTK-based UIs are not really that popular in windows, in part because they tend to give a low-quality feel compared to other alternatives available on Windows.
If I am not mistaken, Gimp and Monodevelop are some examples but most users (including myself) prefer Photoshop and Visual Studio anyways.

As for DLL Hell, there are some solutions: https://en.wikipedia.org/wiki/DLL_Hell#Solutions
For example, could weasyprint provide its own copy of the DLLs it needs? I guess not.
Another solution could be application virtualization embedding again the DLLs, but if you can't or don't want to provide a binary, well, not much can be done.

Anyway I tried weasyprint because I am looking for a simple command line tool to convert an html5 page to a PDF. After seeing that media queries are not supported and I could not convert a page layout based on bootstrap 4, I switched to another tool which so far seems be able to handle the task.

Still good luck with the project as it looks very promising.

[Kim-Petersen]

I posted this issue #590. The error in my case was that zlib1.dll was present in a different folder.

>>>import ctypes.util
>>>ctypes.util.find_library('zlib1')
"C:\\Program Files\\Intel\\WiFi\\bin\\zlib1.dll"

So it turns out that the ctypes.util.find_library was returning the path for a dll not in the GTK runtime bin folder.

>>>import os
>>>for item in os.environ['PATH'].split(';'):
...    print(item)
...
[Bunch of paths]
C:\\Program Files\\Intel\\WiFi\\bin\\zlib1.dll
[Bunch of paths]
C:\\Program Files\\GTK3-Runtime Win64\\bin
[Even more paths]

In my PATH variable i put GTK/bin before Intel/wifi/bin

>>>import ctypes.util
>>>ctypes.util.find_library('zlib1')
"C:\\Program Files\\GTK3-Runtime Win64\\bin\\zlib1.dll"

Now weasyprint executes as expected.

[Tontyna]

Yepp, DLL hell at its best.

BTW: Most of the libraries/DLLs required by WeasyPrint aren't loaded by WeasyPrint itself.

[liZe]

I've updated the documentation with a small paragraph about this error and a link to this issue.

Pull requests are welcome for documentation too 😉.

[Tontyna]

More on dll hell.

OSError: dlopen() failed to load a library: cairo / cairo-2

This Error not necessarily states that there is no cairo.dll in your PATH. It is also raised when the cairo library can't load other libraries it depends on -- e.g libfontconfig -- dunno how and where cairo.dll itself looks for its dependencies, definitely not via pythonic dlopen() and ctypes.util.find_library, probably not in the PATH, probably next to itself.

OMG! Contemplating this I can imagine more and more really bad constellations ... at least on Windows.

@micsan13br: WeasyPrint can't escape from Windows DLL hell, as long as the required Cairo/Pango libraries are loaded by cairocffi, which only scans the PATH, no way to dictate a full-path-to-cairo.dll

[michelesandroni]

@Tontyna: Speaking of windows and DLL hell, I've installed THOUSANDS of softwares (from large IDEs to tiny utilities like weasyprint), giant suites of visual effects softwares, etc.
I never had a problem with DLLs / DLL Hell or a software installation in the last 15 years, but again those were all softwares that people actually wanted to work on Windows, including some open-source ones.
Perhaps the priority here is to prove a point? windows is bad, windows equals DLL Hell, windows users are dumb or cheaters?

If you cannot statically link against whatever library you need,
If cannot provide a copy of the DLL that goes in the same folder of your software,
If you can't use or ship library X because the license is not FOSS/FLOSS/GNU/ETC-compatible,
If you can't use library Y or deployment system Z because they go against the spirit of open source,

well, enjoy DLL hell.

This attitude reminds me of software wars from a decade ago and so does the fact that you blame the OS or the user for failing to install something.
In the last decade design & usability rules have drastically changed: the simple fact that installation instructions are needed to install something is considered a bug or a design mistake.
I do 2D/3D software development, have dozens of IDEs and build tools installed but I understand that end-users (for example, an artist or a graphic designer or an accountant or my grandma) don't need/want to know how to compile or build an executable in order to use a tool. Even in linux this idea is starting to be accepted, as usual with some exceptions.

[michelesandroni]

@Tontyna and if Cairocffi (whatever that is) only scans the path (which, I guess, implies also that it can't find a DLL sitting in the same folder), then according to you the problem is obviously DLL hell and not that Cairocffi is limited / could use some improvements?

[Tontyna]

Cairocffi is a Python package that's imported and used by the WeasyPrint package -- like cffi, cssselect2, html5lib, pdfrw, tinycss2 etc.

As @mchlsndrn said, avoiding DLL hell, its quite easy. Supposed you are the one who controls the code that loads the libraries.

I didn't blame Windows or the average user for anything. If I cursed anybody in the last days (and I'm cursing a lot when programming), it was Python. I was tempted to curse the Linux-centric maintainer of cairocffi, which happens to be @liZe 😄 , until I changed my mind and instead, in the near future, when time allows, I'll create a PR, or at least comment on Kozea/cairocffi#103

[ay1man4]

After a lot of tries following http://weasyprint.org steps, I found that weasyprint is working in windows using command line without issues but it is not working using Git Bash which I was working with!!!
I spent too much time and discovered this by chance 👍

[nicknagels]

The order of the items in PATH variable is important. I had to put C:\Program Files\GTK3-Runtime Win64\bin at the top.

[zhaoxin111]

I also encountered this problem, and finally I was able to use cairosvg on the command line, and I can't always use it in the IDE, which is really a strange library.
I have encountered several possible problems when I solved it, and it may be useful to you.

1. Follow the installation tutorial above https://weasyprint.readthedocs.io/en/latest/install.html#step-5-run-weasyprint
   2.GTK confirms that it is installed version 3
2. Add C:\Program Files\GTK3-Runtime Win64\bin to the system and user environment variables and pin them all

[oddMLan]

OS: Windows 10 Enterprise x64 20H2
Python 3.9.7
Shell: cmd
Installed Python from the Microsoft Store listing as instructed.
I put C:\Program Files\GTK3-Runtime Win64\bin at the top of my PATH and restarted. python3 -m weasyprint --info still fails with cannot load library 'gobject-2.0-0': error 0x7e.
With the help of Process Monitor I found that it is finding libgobject-2.0-0.dll, and loads the image succesfully. However, after that it looks for libglib-2.0.0.dll in the python running dir and in C:\Windows\System32, NEVER in C:\Program Files\GTK3-Runtime Win64\bin, and when it doesn't find it gives up and thinks libgobject-2.0-0.dll is bad and tries looking for other variants such as libgobject-2.0.dll gobject-2.0-0.dll libgobject-2.0-0.dylib etc.

The only solution I found was making symlinks in the System32 directory with all the DLLs in the C:\Program Files\GTK3-Runtime Win64\bin folder. Then python3 -m weasyprint --info works.

This is absolutely ridiculous.

EDIT: This is a Python issue. Apparently Python 3.8+ changed the way it looks for modules. https://bugs.python.org/issue43173
You need to specify a DLL running dir using os.add_dll_directory() in your script to fix it.

[Tompickett21]

Ok I figure this out. you can have a 64 bit version of python that doesn't work. What I have found to work and this could change is the installing the 64 bit version of python from python's website, not from the Microsoft store!

1. remove any version of python you have installed
2. download https://www.python.org/ftp/python/3.8.10/python-3.8.10-amd64.exe
3. install
4. download and install https://github.com/tschoonj/GTK-for-Windows-Runtime-Environment-Installer/releases
   1. exact link is https://github.com/tschoonj/GTK-for-Windows-Runtime-Environment-Installer/releases/download/2021-04-29/gtk3-runtime-3.24.29-2021-04-29-ts-win64.exe
   2. note that link is from https://doc.courtbouillon.org/weasyprint/stable/first_steps.html
5. add bin folder from that (sorry it was somebody else's machine, I use Ubuntu) in your environment path.
6. run through the first steps on weasyprint and you should be good to go!

[Tompickett21]

Ok I figure this out. you can have a 64 bit version of python that doesn't work. What I have found to work and this could change is the installing the 64 bit version of python from python's website, not from the Microsoft store!

1. remove any version of python you have installed
2. download https://www.python.org/ftp/python/3.8.10/python-3.8.10-amd64.exe
3. install
4. download and install https://github.com/tschoonj/GTK-for-Windows-Runtime-Environment-Installer/releases
   1. exact link is https://github.com/tschoonj/GTK-for-Windows-Runtime-Environment-Installer/releases/download/2021-04-29/gtk3-runtime-3.24.29-2021-04-29-ts-win64.exe
   2. note that link is from https://doc.courtbouillon.org/weasyprint/stable/first_steps.html
5. add bin folder from that (sorry it was somebody else's machine, I use Ubuntu) in your environment path.
6. run through the first steps on weasyprint and you should be good to go!