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

Weasyprint logging is missconfigured #412

Closed
PamelaM opened this issue Jan 18, 2017 · 6 comments
Closed

Weasyprint logging is missconfigured #412

PamelaM opened this issue Jan 18, 2017 · 6 comments
Labels
feature New feature that should be supported
Milestone

Comments

@PamelaM
Copy link

PamelaM commented Jan 18, 2017

From the python docs https://docs.python.org/2/howto/logging.html#library-config :

Note It is strongly advised that you do not add any handlers other than NullHandler to your 
library’s loggers. This is because the configuration of handlers is the prerogative of the 
application developer who uses your library. The application developer knows their target 
audience and what handlers are most appropriate for their application: if you add handlers 
‘under the hood’, you might well interfere with their ability to carry out unit tests and 
deliver logs which suit their requirements.

The default handler should be the NullHandler.

@liZe liZe added the feature New feature that should be supported label Jan 18, 2017
@liZe
Copy link
Member

liZe commented Jan 18, 2017

I agree. Silent logs have been asked before (at least #300 and #312) and that should be the default when WeasyPrint used as a library. We should log to stderr only when it's the "normal" way to handle logs, i.e. when WeasyPrint is launched from the CLI.

@PamelaM
Copy link
Author

PamelaM commented Jan 18, 2017

For those hitting this problem before it's fixed, here's how I've disabled the weasyprint logging handler - the logger needs to be set up before the first import of weasyprint

import logging

logger = logging.getLogger("weasyprint")
if not logger.handlers:
    logger.addHandler(logging.NullHandler())

from weasyprint import HTML

@hoIIer
Copy link

hoIIer commented Mar 20, 2017

possibly related, I think all of the WARNING messages are coming from this package?

image

@liZe liZe added this to the v0.37 milestone Mar 24, 2017
@liZe liZe closed this as completed in 210b738 Mar 24, 2017
netbsd-srcmastr referenced this issue in NetBSD/pkgsrc Aug 1, 2017
Version 0.39
------------

Released on 2017-06-24.

Bug fixes:

* Fix the use of WeasyPrint's URL fetcher with CairoSVG.


Version 0.38
------------

Released on 2017-06-16.

Bug fixes:

* `#477 <https://github.com/Kozea/WeasyPrint/issues/477>`_:
  Don't crash on font-face's src attributes with local functions.


Version 0.37
------------

Released on 2017-06-15.

WeasyPrint now depends on tinycss2 instead of tinycss.

New features:

* `#437 <https://github.com/Kozea/WeasyPrint/issues/437>`_:
  Support local links in generated PDFs.

Bug fixes:

* `#412 <https://github.com/Kozea/WeasyPrint/issues/412>`_:
  Use a NullHandler log handler when WeasyPrint is used as a library.
* `#417 <https://github.com/Kozea/WeasyPrint/issues/417>`_,
  `#472 <https://github.com/Kozea/WeasyPrint/issues/472>`_:
  Don't crash on some line breaks.
* `#327 <https://github.com/Kozea/WeasyPrint/issues/327>`_:
  Don't crash with replaced elements with height set in percentages.
* `#467 <https://github.com/Kozea/WeasyPrint/issues/467>`_:
  Remove incorrect line breaks.
* `#446 <https://github.com/Kozea/WeasyPrint/pull/446>`_:
  Let the logging module do the string interpolation.
xusy2k added a commit to vilamatica/WeasyPrint that referenced this issue Feb 15, 2019
If you want to use Weasyprint under django, you can configure
weasyprint's logger via django, but this setting never is set
liZe added a commit that referenced this issue Feb 15, 2019
@alacret
Copy link

alacret commented Feb 17, 2020

This hack doesn't work for Django applications. Neither in the settings.py nor before the import of the library.

Use this instead:

settings.py

import logging

...

logger = logging.getLogger("weasyprint")
logger.addHandler(logging.NullHandler())
logger.setLevel(40) # Only show errors, use 50

@conformist-mw
Copy link

For those who use Django internal LOGGING dict-like config:

LOGGING = {
    'version': 1,
    ...
    'handlers': {
        ...
        'null_handler': {
            'level': 'ERROR',
            'class': 'logging.NullHandler',
        },
    },
    'loggers': {
        ...
        'weasyprint': {
            'level': 'ERROR',
            'handlers': ['null_handler'],
        },
    }
}

@florianm
Copy link

florianm commented Sep 19, 2023

Using

  • weasyprint==59.0
  • django_weasyprint==2.2.1
  • django==4.2.5

I was still getting log messages such as __init__ glyf pruned.
The following logging config silences them:

LOGGING = {
    "version": 1,
    "disable_existing_loggers": False,
    "formatters": {
         ...
        "terse": {
            "format": "%(levelname)s %(asctime)s %(name)s %(message)s"
        },
    },
    "handlers": {
        "null_handler": {
            "level": "ERROR",
            "class": "logging.NullHandler",
        },
        "console": {
            "level": "DEBUG",
            "class": "logging.StreamHandler",
            "formatter": "terse",
        },
    },
    "loggers": {
       ...
        "fontTools.subset": {
            "level": "ERROR",
            "handlers": ["null_handler"],
        },
    },
}

Salient points:

  • The offensively chatty logger's name is fontTools.subset, not weasyprint.
  • I found the offending logger's name by including %(name)s in the formatter (formatter docs). The default %(module)s gave me only the filename __init__ which was not too useful.
  • This setting completely silences the fonttools logger (null handler) AND only allows errors. YMMV - you could adjust the level to WARN and send to the console, so you get warnings like missing dependencies but silence the chatty info logs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature that should be supported
Projects
None yet
Development

No branches or pull requests

6 participants