Fonts breaking in v62

[LukasKlement]

With v62, fonts appear to randomly break when rendering a PDF, but not consistently. Here is a screenshot of the same PDF being rendered twice in a row, once the result is wrong, once correct:

#1 Wrong: https://share.zight.com/L1ub4Oko
#2 Correct: https://share.zight.com/12ul5KDP

It happens with all kinds of fonts, it's not limited to a single font family.

[liZe]

Hi!

Could you please share the PDF files, generated with the --uncompressed-pdf option if possible? The result of weasyprint --info could be useful too.

[schneebuzz]

I've found a similar issue with these cases:

1. a special font not getting loaded/rendered at all, seemingly random
2. everything seems to be bold (font-weight) as if it could not find the regular font, also seemingly random

I attached the files for the second case with a combination of good/bad/compressed/uncompressed, also see 2nd page.

TestDocument-bad.pdf
TestDocument-good.pdf

TestDocument-26-good-uncompressed.pdf
TestDocument-27-bad-uncompressed.pdf

$ weasyprint -info
System: Linux
Machine: x86_64
Version: #1 SMP Thu Jan 11 04:09:03 UTC 2024
Release: 5.15.146.1-microsoft-standard-WSL2

WeasyPrint version: 62.0
Python version: 3.11.9
Pydyf version: 0.10.0
Pango version: 14602

[liZe]

@schneebuzz Could you please share the HTML, CSS and fonts for your example? I’m not sure that your problem is the same as the original one.

@LukasKlement Do you use WeasyPrint on WSL2 too?

[schneebuzz]

I am using weasyprint's python API to render my PDF files. My application is running in a docker container with an image based on python:3.11-slim-bullseye, the behavior is the same on Docker for Windows (through WSL2) and on a linux host.

💡 After some testing, I observed that when I cache the FontConfiguration object and reuse it for each call to HTML.write_pdf() I can consistently generate ~50 consecutive documents with "good" font presentation. If font_config is unset, a new FontConfiguration object is created for each document. This leads to at least one in five "bad" documents.

@liZe see attached zip for the sources, I used the following url_fetcher:

import mimetypes
import weasyprint


def _local_fetcher(url):
    if url.startswith('local://'):
        filepath = url.lstrip('local://')
        with open(filepath, 'rb') as f:
            file_data = f.read()
        return {
            'string': file_data,
            'mime_type': mimetypes.guess_type(filepath)[0],
        }
    return weasyprint.default_url_fetcher(url)

repr.zip

[liZe]

We’ve found where the problem comes from, it looks like the bug is the same for both of you.

[liZe]

@LukasKlement @schneebuzz Could you please test the fix-font-cache branch? If it fixes your problem, we’ll release a 62.1 version soon.

This bug only happens when we render multiple documents in the same process (ie not from the command line). I couldn’t reproduce it on my computer, it never happened on CI, but it was quite easy to reproduce on your Docker image. As it depends on the way Pango manages the memory, it can happen randomly depending on many factors (OS, Pango version, Python version, etc.)

Sorry for the inconvenience.

[schneebuzz]

@liZe using the fix-font-cache branch the issue did not show up when generating ~30 documents.

Thanks for fixing it in just a couple of hours 🥳

[liZe]

(For the record: this issue is related to #2130.)