Print warnings when bold or italic fonts are missing

[claell]

Currently, when unsupported elements in HTML are in the input, there is no warning that WeasyPrint can not render them correctly.

This leads to issues like #1470 and #1684 easily slipping through and not getting discovered by the user. Basically, in such cases, the user might not be aware that something is wrong with the output.

My suggestion is to print well visible warnings in such cases (and possibly also showing how to fix some of them).

[liZe]

Hi!

Do you mean that WeasyPrint should print a warning when it doesn’t find a font that corresponds to the font-family, font-weight or font-style properties? (<em> tags just set font-style: italic, for example.)

If that’s your request, I don’t think that other browsers do this. I don’t think that there’s an easy way to detect that a font doesn’t correspond to the required CSS without getting a lot of false positive messages. Font management is based on fallbacks, that’s not a bug, that’s a feature 😄. If an emoji is not in a given font, your system will automatically provide a emoji from another font, and that’s normal. If you define a CSS rule of font-weight: 500 and your system has only a font with a weight of 400, it will use it, and that’s normal. And there are many other cases where the chosen font doesn’t follow perfectly the CSS rules and where it’s intended.

When you create a "normal" website, you generally have two choices for fonts:

• You use standard font families, sizes, styles and hope that the user’s browser has the correct font on its system, otherwise the user will use fallback fonts, with no error and no warning. You depend on what’s installed on your user’s system: if they don’t have an italic font installed, italic won’t work (or will be synthetized, in a browser).
• You define @font-face rules for all the different variants that are in your site. You’ll then be sure that the user will get the correct fonts and don’t depend on what’s installed on the system.

With WeasyPrint, it’s even easier: you generally manage the "user"’s system, as it’s the system where WeasyPrint is installed. It’s then often possible to install all the fonts you want on the system.

So, I’m not sure that we can do this easily, and I even think that we actually don’t want to do this.

[claell]

Hm, the thing is: Browsers have a different target group than WeasyPrint. The latter is for people generating documents. And there, it can be pretty relevant to get the rendering in the expected way (while browsers are also used by end users, not only developers).

So I'd argue that it is important to get such kind of warnings. By the way, this is not only true for the mentioned font issues, but also for general unsupported things like #1972 or #577. These are real issues that I ran into and when setting up the HTML, some hint that this is something that WeasyPrint doesn't support would have been helpful, as it would have saved me time debugging and researching on the internet, why the rendered output differed from the Browser rendering.

With WeasyPrint, it’s even easier: you generally manage the "user"’s system, as it’s the system where WeasyPrint is installed. It’s then often possible to install all the fonts you want on the system.

If we'd take the software development as reference: There, the compiler throws errors or warnings in case the build machine is missing requirements for successful build. I argue that WeasyPrint is used in a similar way to a compiler (it generates artifacts based on given input). Thus, it can be helpful to get appropriate warnings in case the build system is not set up correctly.

[liZe]

By the way, this is not only true for the mentioned font issues, but also for general unsupported things like #1972 or #577.

There are warnings when CSS properties are unsupported. You can see them by default in the console when you use the command-line interface, and you can configure logs if you use WeasyPrint as a library.

[claell]

I am using WeasyPrint as a library. Maybe then, it is not wanted to print error messages, although as a user, I'd welcome that functionality (including warnings for not found fonts). Setting up log files is not really straightforward (probably same reason as why compilers that I know of also print their warnings to the console).

[claell]

Or can this be achieved with:

import logging
logger = logging.getLogger('weasyprint')

(without adding)

logger.addHandler(logging.FileHandler('/path/to/weasyprint.log'))

?

[liZe]

Setting up log files is not really straightforward (probably same reason as why compilers that I know of also print their warnings to the console).

This question has already been discussed before, see #412. Printing them by default when used in CLI and hide them by default when used as a library is considered to be a best practice.

Or can this be achieved with:

These 3 lines are an example if you want to store logs in a file, which is quite common.

We can’t cover all the different use cases to filter according to a given level (debug, errors, etc.) or where to print logs (stdout, stderr, rotated files, TCP, mail, syslog, etc.) Everybody has a different use case. Please, see the documentation of the logging module for details.

[claell]

This question has already been discussed before, see #412. Printing them by default when used in CLI and hide them by default when used as a library is considered to be a best practice.

Alright, fine with me, then.

These 3 lines are an example if you want to store logs in a file, which is quite common.

I know, my question was how to achieve logging to the terminal.

I had a quick look at the logging module before, already. Unfortunately, that documentation is pretty long and it doesn't show how to use it in combination with WeasyPrint (which might require specific configurations).

Thus, I asked, whether the two first lines were enough to achieve logging to the terminal. I assume, they are not, as probably the logger needs to be assigned to a handler, first?

Then, does #412 (comment) do what I want? Or is this not needed and the logger is set up with a handler already on initialization? This question seems to be WeasyPrint related, as the Python logging module seems to support a versatile variety of different configurations.

Edit: Ah, I didn't read carefully enough, that comment was about deactivating the logging.

Edit 2: Probably the StreamHandler is the correct one to use: https://docs.python.org/3/library/logging.handlers.html#streamhandler

[liZe]

Edit 2: Probably the StreamHandler is the correct one to use:

Yes, you can use

logger.addHandler(logging.StreamHandler())

instead of FileHandler.

Does everything work correctly for you?

[claell]

I'll need to test and am currently time constrained, that is why I was asking these more theoretical questions.

Then, most things are good for me. The only remaining issue is whether warnings should also be logged in case fonts are missing. I still think that this is a good idea (at least on some logger level), as this will make spotting errors much easier.

[liZe]

The only remaining issue is whether warnings should also be logged in case fonts are missing.

As explained earlier, we don’t want to warn users each time there’s a font fallback, because that’s an intended behaviour in many cases. What we can do is to is to detect when we miss italic and bold variants, as they are the most obvious situations when there’s a problem.

[claell]

Sure, sounds good! I'd also argue that with different log levels available, one can warn about all problems, and only warn for missing bold and italic fonts when the log level is set to less details. But depending on implementation, that might be more work.