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

Make it possible to set WeasyPrint options #79

Merged
merged 1 commit into from
Feb 23, 2024

Conversation

dekkers
Copy link
Collaborator

@dekkers dekkers commented Jan 22, 2024

WeasyPrints can be given an options dict in the render and write_pdf methods. This PR makes it possible to do that with django-weasyprin by setting the pdf_options attribute on the view class or by implementing the get_pdf_options method.

Copy link

semanticdiff-com bot commented Jan 22, 2024

Review changes with SemanticDiff.

Analyzed 3 of 4 files.

Overall, the semantic diff is 11% smaller than the GitHub diff.

Filename Status
README.rst Unsupported file format
✔️ django_weasyprint/tests/__init__.py 28.57% smaller
✔️ django_weasyprint/tests/test_views.py 7.69% smaller
✔️ django_weasyprint/views.py 4.71% smaller

Copy link
Contributor

@liZe liZe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the overall idea.

I can’t comment the Django part (@fdemmer can provide better feedback on this point!), but there are some details to change regarding WeasyPrint’s API in order to make this PR work correctly.

@@ -82,6 +83,7 @@ def get_document(self):
return html.render(
stylesheets=self.get_css(base_url, url_fetcher, font_config),
font_config=font_config,
option=self._options,
Copy link
Contributor

@liZe liZe Jan 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn’t we pass options as separate keyword arguments? The API asks for **options, not option. Something like **self._options instead of option=self._options is probably appropriate.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you for your comments! i think you accidentally pasted the wrong link, @liZe ;)

API: https://doc.courtbouillon.org/weasyprint/stable/api_reference.html#weasyprint.HTML.render

yes, if we want to pass the "options" all at once, the kwarg should definitely be called options. it is a dict of potentially multiple options.

however, that may be cause for confusion/bugs, as we already provide a stylesheets kwarg, which actually is a DEFAULT_OPTIONS parameter.

a good way around this may be using setdefault to add stylesheets to self._options before passing it to render() using **-unpacking. maybe a copy of the options dict is a good idea (similar to weasyprint's render()).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you for your comments! i think you accidentally pasted the wrong link, @liZe ;)

🤣

@@ -90,7 +92,7 @@ def rendered_content(self):
Returns rendered PDF pages.
"""
document = self.get_document()
return document.write_pdf()
return document.write_pdf(options=self._options)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, should use **; no need for copy/setdefault, i think, since we do not provide any other kwargs here (valid kwargs other than options here are: target, zoom, finisher).

Copy link
Owner

@fdemmer fdemmer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the suggestion and contribution, @dekkers ! ❤️

Please add a test, where the new pdf_options attribute of WeasyTemplateResponseMixin is used and make sure it still works, with pdf_stylesheets provided aswell.

An update to the example in the README would also be much apprechiated.

@@ -82,6 +83,7 @@ def get_document(self):
return html.render(
stylesheets=self.get_css(base_url, url_fetcher, font_config),
font_config=font_config,
option=self._options,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you for your comments! i think you accidentally pasted the wrong link, @liZe ;)

API: https://doc.courtbouillon.org/weasyprint/stable/api_reference.html#weasyprint.HTML.render

yes, if we want to pass the "options" all at once, the kwarg should definitely be called options. it is a dict of potentially multiple options.

however, that may be cause for confusion/bugs, as we already provide a stylesheets kwarg, which actually is a DEFAULT_OPTIONS parameter.

a good way around this may be using setdefault to add stylesheets to self._options before passing it to render() using **-unpacking. maybe a copy of the options dict is a good idea (similar to weasyprint's render()).

@dekkers
Copy link
Collaborator Author

dekkers commented Feb 14, 2024

Thanks for the feedback. Took me a while to find the time to properly fix this, but I've fixed the passing of the options and used setdefault to set stylesheets as suggested. I have also added a unit test that checks whether the stylesheets still work with pdf_options given and checks whether the generated PDF has the PDF version specified in the pdf_options.

@hveis
Copy link

hveis commented Feb 23, 2024

This is brilliant!! An awesome fix
I was looking into the API and wondered how this wasn't implemented/documented for django-weasyprint
Hoping this pull request gets merged soon
Thanks to all that helped

@fdemmer fdemmer merged commit 053b0b2 into fdemmer:main Feb 23, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants