Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inexplicable change of font weight #1778

Closed
castedo opened this issue Dec 20, 2022 · 2 comments · Fixed by #1783
Closed

inexplicable change of font weight #1778

castedo opened this issue Dec 20, 2022 · 2 comments · Fixed by #1783
Labels
bug Existing features not working as expected

Comments

@castedo
Copy link

castedo commented Dec 20, 2022

STEPS:
Run weasyprint (57.1) on
good.html.txt
bad.html.txt

GOT:
good.pdf
bad.pdf

EXPECTED:
The Foo Bar title and text to be the same between the two pdf files, specifically the lighter font weight for both.

COMMENTS:
The only difference between the two HTML files is whether the anchor text has some text or is just spaces. It seems like having text in the anchor triggers the font weight style to get lost.

@castedo castedo changed the title inexpicable change of font weight inexplicable change of font weight Dec 20, 2022
@liZe liZe added the bug Existing features not working as expected label Dec 20, 2022
@liZe
Copy link
Member

liZe commented Dec 20, 2022

Hi!

Thanks for the report.

The problem is actually caused by WeasyPrint thinking that the font-weight: 300 and font-weight: 400 are actually the same font. It picks either the 300 or 400 font to display both. You can see that even the "good" file is wrong because it uses the 300 font in the paragraph (it should be using the 400 one).

The font used is the first one drawn. When the link is displayed at first, it uses 400 everywhere. When the title is the first one, it uses 300.

I suspect that there’s something wrong in the way we give the font weights to FontConfig when we add @font-face fonts. And I really hope that it’s not a behavior of Pango that can’t be configured 🤞️.

liZe added a commit that referenced this issue Dec 20, 2022
The font face introduced by Pango 1.46 was appealing, but its description seems
to be broken. No easy way to know whether it’s broken in Pango, in FontConfig,
in our custom FontConfig configuration, or elsewhere. As it only happens with
@font-face rules, we can easily blame our FontConfig configuration.

Let’s try something else again! This key changes in each version…

Font descriptions have a nice way to unset values, allowing us to only keep
fields that should be unique by font file. This will probably lead us to other
subtle and frightening problems in the future, but we’ll let our dear users and
customers find them for us.

And we don’t require Pango 1.46 anymore to get smaller PDFs. So cool.

Fix #1778.
@liZe
Copy link
Member

liZe commented Dec 20, 2022

A fix has been added on the fix-font-face branch. Feel free to test!

This change looks harmless, but as explained in the commit, finding a reliable key for the fonts cache is a nightmare. Your document is broken only for certain font weights, only with @font-face rules (works with the same fonts installed locally). It’s hard to add related non-regression tests, and each time we change this code we can break other use cases in very subtle ways.

We’ll try this fix on other complex documents and check that everything works fine. We may include it in a 57.2 version, but waiting for 58.0 could be wiser.

liZe added a commit that referenced this issue Dec 23, 2022
The font face introduced by Pango 1.46 was appealing, but its description seems
to be broken. No easy way to know whether it’s broken in Pango, in FontConfig,
in our custom FontConfig configuration, or elsewhere. As it only happens with
@font-face rules, we can easily blame our FontConfig configuration.

Let’s try something else again! This key changes in each version…

Font descriptions have a nice way to unset values, allowing us to only keep
fields that should be unique by font file. This will probably lead us to other
subtle and frightening problems in the future, but we’ll let our dear users and
customers find them for us.

And we don’t require Pango 1.46 anymore to get smaller PDFs. So cool.

Fix #1778.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Existing features not working as expected
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants