WeasyPrint
WeasyPrint copied to clipboard
Kozea
Fonts with variable weight don’t work
I experienced the same, have been meaning to provide a minimal example. Basically the HMTL page is showing (in browsers or other clients) bold text, but after running
weasyprint file.html file.pdf
The output looks the same but no bold.
Example of HTML:
<style>
table {
border-collapse: collapse;
font-family: Calibri, sans-serif;
font-size: 12px;
border: 2px solid #000;
}
tr.header {
background: black;
color: white;
font-weight: bold;
}
</style>
<body>
<table>
<tr class = "header">
<th style = "text-align: left;">HEADER 1</th>
<th style = "text-align: left;">HEADER METRIC 1 (%)</th>
<th style = "text-align: center;"></th>
<th style = "text-align: center;"></th>
<th style = "text-align: center;"></th>
</tr>
<tr>
<td style = "background: #dbdbdb; font-weight: bold; text-align: left;">BOLD ROW 1</td>
<td style = "background: #dbdbdb; font-weight: bold; text-align: left;">CATEGORY</td>
<td style = "background: #dbdbdb; font-weight: bold; text-align: center;">89.09</td>
<td style = "background: #dbdbdb; font-weight: bold; text-align: center;">91.31</td>
<td style = "background: #dbdbdb; font-weight: bold; text-align: center;">91.18</td>
</tr>
...
This bug is not easy to fix, because:
- there’s probably no way with Harfbuzz to get a non-variable font out of a variable font,
- the PDF specification doesn’t allow variations to be set in PDF,
- I can’t find an easy way in fontTools to reset the default value of a variation setting.
If anyone knows (or want to learn) fontTools, that would be nice to have a way to set the default value of a variation setting in a font.
Just to add some notes from things I've been poking around at this week[end], FontTools' varLib.instancer supports "instancing" a variable font (including fixing variation axes to a specific value). Its documentation implies that it can only remove axes, not set them to specific values, but that appears to be outdated, and fonttools/fonttools#1537 appears to indicate it can indeed do both.
Harfbuzz has had some discussion around the point, and it appears as though Google Fonts would like Harfbuzz to support this as well (see harfbuzz/harfbuzz#1707), but harfbuzz/harfbuzz#2112 is their issue for it and it sounds like there's a fair bit of work to be done before they get there.
Any update on this? I'm using exactly all of the things causing issues mentioned above. It's quite important to me because I have a pretty sophisticated markdown-based typesetting setup, where bold is kinda a must-have. I've worked with HarfBuzz before, so I kinda know my way around, so if I can be of assistance I'll do my best to help, but I'm wondering if anyone has gotten closer to this? Thanks
@J-Cake Hi!
Any update on this?
Unfortunately no.
I've worked with HarfBuzz before, so I kinda know my way around, so if I can be of assistance I'll do my best to help
Then your help could be very useful! I didn’t take the time (yet) to check what’s new in harfbuzz/harfbuzz#2112, but the situation seems to have been improved.
Here’s how we get the Harfbuzz font face out of the Pango font: https://github.com/Kozea/WeasyPrint/blob/67cd41a9dd8c0ebe16b36d8a72d58cefaf2c6ff2/weasyprint/pdf/stream.py#L261-L266
And here’s how we get the font face blob: https://github.com/Kozea/WeasyPrint/blob/67cd41a9dd8c0ebe16b36d8a72d58cefaf2c6ff2/weasyprint/pdf/stream.py#L18-L23
If you have any idea about a way to get here a blob with right variation, that would be very useful!
Hi @liZe. Thanks for the speedy reply
I'll do some experimentation, and get back to you. Unfortunately, I don't have to time available right now, but hopefully soon.
I'll keep you posted, JCake
Also experiencing the same issue as previously outlined by the original poster and other contributors here.
Currently using this workaround as a bandaid — hoping there's a fix in the future, if possible!
Also experiencing the same issue as previously outlined by the original poster and other contributors here.
Currently using this workaround as a bandaid — hoping there's a fix in the future, if possible!
Was about to write exactly the same in the mentioned issue. Something has changed when migrating to pango > 1.44. To be exact everything works up to 52.5. I have bold fonts from exactly the same system-wide installed google ttf's... Oh someone already found out that year ago #1470 .
Something has changed when migrating to pango > 1.44.
The source of the changes is not Pango 1.44 but the removal of Cairo in version 53. We now read and include the fonts ourselves, and it means that we lost some features like variable fonts, font synthesis or bitmap fonts (that’s now fixed).
If anyone knows Harfbuzz and wants to help, that would be very useful!
Something has changed when migrating to pango > 1.44.
The source of the changes is not Pango 1.44 but the removal of Cairo in version 53. We now read and include the fonts ourselves, and it means that we lost some features like variable fonts, font synthesis or bitmap fonts (that’s now fixed).
If anyone knows Harfbuzz and wants to help, that would be very useful!
According to harfbuzz/harfbuzz#2112 and harfbuzz/harfbuzz#3708 something is being done to it, but I have no idea how pinning axis (?!?!?!?!) helps in creating subset font face (!?!!?!?!!) in order to get variable font face.
Hi!
If you’re interested in this feature, please try the variable-fonts branch and add a comment to tell what’s working and what’s not! If we get enough answers quickly, it may me included in the next beta version next week.
(You can also try the font-variation-settings attribute that is now supported.)
It’s included in version 57 beta (that will be released later today), please test!
Finally had the time to test and in my case all of the required functionalities came back. Big thanks!