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

Font synthesis (bold, oblique…) no longer works #1470

Open
patbakdev opened this issue Oct 12, 2021 · 15 comments
Open

Font synthesis (bold, oblique…) no longer works #1470

patbakdev opened this issue Oct 12, 2021 · 15 comments
Labels
bug Existing features not working as expected

Comments

@patbakdev
Copy link

There seems to be a regression when it comes to faux bold / weight synthesis. Using a font without any additional weights should fake out at least the bold weight when asked, but this is no longer the case. I am using version 53.0. I have confirmed this does not repro with v52.5

Steps to Reproduce

Font

Download: https://www.ffonts.net/EB-Garamond-12-Regular.font

repro.css

@charset "utf-8";
@font-face {
  font-family: Garamond;
  font-style: normal;
  font-weight: normal;
  src: url(EBGaramond12-Regular.otf) format("opentype");
}
body {
  font-family: Garamond;
}
#bold-section {
  font-weight: bold;
}
#no-bold-section {
  font-weight: normal;
}

repro.html

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title>Weasyprint Bug Repo</title>
<link rel="stylesheet" href="repro.css" />
</head>
<body>
<div id="bold-section"><p>This should be bold</p></div>
<div id="no-bold-section"><p>This should not be bold</p></div>
</body>
</html>

command

weasyprint repro.html repro.pdf

Expected

This should be bold
This should not be bold

Actual

This should be bold
This should not be bold

@liZe liZe added the bug Existing features not working as expected label Oct 12, 2021
@liZe
Copy link
Member

liZe commented Oct 12, 2021

Hello!

There seems to be a regression when it comes to faux bold / weight synthesis.

You’re right, it’s a regression of version 53. I don’t know if it’s possible to fix that right now with the new stack (directly using Pango to get Harfbuzz font), but as for #1454 we have to find a solution.

@btsunjin
Copy link

btsunjin commented Nov 9, 2022

I try to use some version of weasyprint, but just 52.5 is ok

@patbakdev
Copy link
Author

@btsunjin I have been running WeasyPrint version 52.5 since I opened this issue without any problems. But it looks like v57.1 is available and according to #1454 this might be fixed with that version. I'll need to test this out myself.

@patbakdev
Copy link
Author

patbakdev commented Nov 9, 2022

@btsunjin So, I tried with v57.1 and I am still seeing this issue. Reverting back to 52.5. It looks like this issues is not fixed with #1454.

@liZe
Copy link
Member

liZe commented Nov 9, 2022

#1454 gives the possibility to use variable fonts, but it doesn’t generate bold fonts out of regular fonts.

Note that you can just use the bold font corresponding to your regular font, and everything will work correctly. This issue is about automatically creating (poor quality) bold fonts out of regular fonts when the bold font is not available.

@patbakdev
Copy link
Author

patbakdev commented Nov 9, 2022

Thanks for the clarification. I hadn't looked at this issue in quite a while. Do you think it will ever get resolved? I have an older project that uses this functionality (no bold fonts available) and have been pinned to v52 ever since. But I don't want to get too far behind. So if this isn't likely to be fixed anytime soon I will probably try to avoid using fonts that don't have bold for future projects and hope I don't have to rebuild this older project (or roll back to v52 just in that instance).

@liZe
Copy link
Member

liZe commented Nov 9, 2022

Thanks for the clarification.

No problem!

Do you think it will ever get resolved?

To be honest, that’s currently not our priority because our users generally use fonts that include a bold variant, or don’t use bold in their documents. The quality of automatically generated bold fonts are often not that good.

If someone is interested in fixing this issue, the first step is to find a way to do this using Pango, Harfbuzz and/or FontConfig.

I have an older project that uses this functionality (no bold fonts available) and have been pinned to v52 ever since. But I don't want to get too far behind.

Another solution would be to use a tool like FontForge to generate a bold font face. The result will probably not be perfect, but you’ll get a better font that what Cairo was able to do in 52.x.

So if this isn't likely to be fixed anytime soon I will probably try to avoid using fonts that don't have bold for future projects and hope I don't have to rebuild this older project (or roll back to v52 just in that instance).

That’s a good idea, even if this issue is fixed!

@patbakdev
Copy link
Author

I'd be happy to fix it if I had any experience in this area, but I don't. :) I wasn't aware that bold fonts could be generated like this. That sounds like a good way forward for me for any of my projects that are affected by this issue. Thanks for that. Going forward I will make sure that I use fonts with bold variants and avoid this issue altogether. I'll leave this issue open for you to decide, but for me I think this is a reasonable comprise now that I am more aware.

@liZe liZe changed the title Synthesis of Font Weight (Bold) No Longer Works Font synthesis (bold, oblique…) no longer works Dec 17, 2023
@claell
Copy link
Contributor

claell commented Feb 29, 2024

I ran into this issue quite some time ago and only now found out what causes this (together with #1949). To me, this really looks like a regression and seems a basic requirement for WeasyPrint. While there is an easy workaround for #1949 (requesting the italic font faces), there doesn't seem to be one existing for this issue, correct?

@liZe
Copy link
Member

liZe commented Feb 29, 2024

To me, this really looks like a regression

You’re right, it’s a regression of version 53. That’s exactly what I wrote in my first comment. 😄

there doesn't seem to be one existing for this issue, correct?

If you install the different weight variants on your system, or if you use @font-face rules for the variants you need, it will work.

seems a basic requirement for WeasyPrint

The quality of automatic font synthesis is often pretty bad, that’s why it’s not a big problem for many users: installing font variants on the system or using @font-face is often easy and give better results.

But we would be really grateful too if someone took the time to solve this "basic" requirement. 😄

@claell
Copy link
Contributor

claell commented Mar 1, 2024

Ah, alright.

Possibly, I also have a special use case that doesn't occur too often.

I'd like to avoid installing font variants on the system, as it makes portability and ease of deployment worse. However, I am curious about @font-face rules. Do they work in a way that <strong> tags in HTML work? Or is there another workaround I can use for that? I got the <em> tag working based on the workaround suggested in #1684 (comment) (explicitly requesting also italic faces; and it actually is a good workaround, since the font looks better that way).

@liZe
Copy link
Member

liZe commented Mar 1, 2024

Do they work in a way that <strong> tags in HTML work? Or is there another workaround I can use for that? I got the <em> tag working based on the workaround suggested in #1684 (comment) (explicitly requesting also italic faces; and it actually is a good workaround, since the font looks better that way).

Yes, if you define different @font-face rules for regular, bold, italic, etc, it will work with HTML tags like <strong> or <em>.

The easy way to get correct CSS is to use online services like Google Fonts: you’ll get an URL such as https://fonts.googleapis.com/css2?family=Roboto:ital,wght@0,400;0,700;1,400;1,700 that you can use as CSS stylesheet in your HTML document (don’t copy the CSS of these URLs, use the URLs directly, because its content can change with time and depends on the browser).

If you don’t want to use Google Fonts, you can of course read the content of this CSS and adapt it to your needs.

@claell
Copy link
Contributor

claell commented Mar 1, 2024

Perfect, that sounds good! I'll look into this more closely again, then. Unfortunately, I didn't find how to do it during a quick web search.

Currently, I use Google fonts like this:

<link href="https://fonts.googleapis.com/css?family=Arimo:normal,italic" rel="stylesheet" />

I just saw that this only includes the 400 weight (thought without specifying the weight, all weights will automatically get included). I'll try to include more weights, explicitly like

https://fonts.googleapis.com/css?family=Arimo:400,700,italic

Ah, alright, that seems to solve it. Perfect, then that's a good solution for me!

@liZe
Copy link
Member

liZe commented Jul 11, 2024

I’ve tried again to tackle this issue, but I don’t know what’s wrong. Using Fontconfig with default synthesized fonts doesn’t work.

If anyone knows Fontconfig, we’d really love to get your help!

@dedalusMohantyMa
Copy link

I had some issues with fonts in my configuration together with Docker.

What I am doing now is installing the fonts with my apk like so:

apk add cairo-dev \
    pango-dev \
    libffi \
    curl \
    fontconfig \
    ttf-freefont \
    font-noto \
    font-roboto \
    font-liberation \
    font-opensans

and for additional fonts, that are not available I wrote a script which installs them:

#!/bin/sh

mkdir -p /usr/share/fonts/truetype/

for FILE in path_to_fonts/*.ttf; do
  echo "INFO: Installing font ${FILE}"
  install -m644 ${FILE} /usr/share/fonts/truetype/
done

This works for my container :-)

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

No branches or pull requests

6 participants