-
-
Notifications
You must be signed in to change notification settings - Fork 711
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
Comments
Hi! Thanks for the report. The problem is actually caused by WeasyPrint thinking that the 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 |
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.
A fix has been added on the 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 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. |
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.
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.
The text was updated successfully, but these errors were encountered: