support @font-face on Windows

[Tontyna]

UPPs, the branch name is a bit ... misleading ...

Since at the moment I have no access to another OS than Windows and the existing code in weasyprint/fonts.py probably was ok for other platfoms, I implemented the fix in a way that only affects sys.platform.startswith('win').

Switching to FreeType rendering not only enables @font-face; suddenly other CSS properties, like font-stretch and font-variant, start to work as expected -- see #587 -- even the killer css font-size: 0 doesn't crash Pango anymore!

There is one minor drawback on Windows: FontConfiguration can't delete the temporary font files it creates during rendering. I think Pango keeps the file handles open (until the Python process is finished), couldn't find a way to persuade it to let them go...

FontConfig and PangoFT2 not only require the proper libraries but also a working font configuration.

Maybe on Nix it never happens that those config files are missing, but Tom Schoonjans' GTK3 Runtime, recommended in the WeasyPrint docs Installing on Windows, though installing all required DLLs, doesn't create the /etc/fonts folder. I created an issue, status == open.

Lucky me having Inkscape installed with an appropriate etc/fonts...

That's why (besides trying and catching dlopen), before actually using FontConfig, the code checks whether it has access to at least one font.
If that's the case, font rendering is done via FreeType, otherwise it falls back to the, @font-face-less, native system fonts rendering mode.

I tried to support the fontconfig library with an os.environ['FONTCONFIG_PATH'] = 'default/etc/fonts/we/could/add/to/weasyprint' when it complains about a missing fonts.conf.
Doesn't work. Probably again due to the way how DLLs are loaded in Python. The DLL only sees the global environment that the python script is running in. Changes during runtime don't reach the DLL.
Contemplated about FcConfigAppFontAddDir(<WINDOWSFONTDIR>) to circumvent such a situation...

Windows-testers welcome!

[liZe]

Thank you ❤️

Since at the moment I have no access to another OS than Windows and the existing code in weasyprint/fonts.py probably was ok for other platfoms, I implemented the fix in a way that only affects sys.platform.startswith('win').

That's a good idea.

Switching to FreeType rendering not only enables @font-face; suddenly other CSS properties, like font-stretch and font-variant, start to work as expected -- see #587 -- even the killer css font-size: 0 doesn't crash Pango anymore!

Great! It would be a good idea in the future to find how to avoid crashes with font-size: 0, but that's another story. There were crashes on Unix too, but they were avoided by fed326d.

There is one minor drawback on Windows: FontConfiguration can't delete the temporary font files it creates during rendering. I think Pango keeps the file handles open (until the Python process is finished), couldn't find a way to persuade it to let them go...

That's not the first time we hit this problem, I'm not sure there's a solution.

Maybe on Nix it never happens that those config files are missing,

True.

but Tom Schoonjans' GTK3 Runtime, recommended in the WeasyPrint docs Installing on Windows, though installing all required DLLs, doesn't create the /etc/fonts folder. I created an issue, status == open.

(tschoonj/GTK-for-Windows-Runtime-Environment-Installer#14 for the record)

That's why (besides trying and catching dlopen), before actually using FontConfig, the code checks whether it has access to at least one font.
If that's the case, font rendering is done via FreeType, otherwise it falls back to the, @font-face-less, native system fonts rendering mode.

It's perfect.

I merge and I'll try to make sure that it doesn't hurt other OSes and Windows users with no usable FontConfig.

[liZe]

Fix #376.

[Tontyna]

As promised, Tom Schoonjans' today's update of the GTK+ for Windows Runtime Environment Installer includes the fontconfig configuration files.