-
Notifications
You must be signed in to change notification settings - Fork 254
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
Allow for using wrapmode='CHAR' in templates #1176
Conversation
… wrapping for multiline text)
…ouldn't have too long lines, so had to split up)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice and simple feature addition, thanks!
As you probably already noticed, creating tests for something like that is more work than the actual fix. And even more of those are needed here...
PS: There's this annoying failure in the test suite that keeps popping up, apparently from running black, without actually telling us what the problem is... This is most likely not your fault, but something that we need to fix in the internal pipeline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once we can sort out the issues with the test suite, then this looks ready for merging.
Thanks for the contribution, @carlhiggs !
test/template/test_template.py
Outdated
"y1": 100, | ||
"x2": 170, | ||
"y2": 105, | ||
"text": "If multiline is True and the wrapmode argument is provided, it should result in " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor nitpick: instead of
the wrapmode argument is provided
this whould read
the wrapmode is "CHAR"
or it might confuse some future reader.
While this is technically test data, it also serves as a code comment here, and those should never contradict the actual code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @gmischler I've just made this update!
@allcontributors please add @carlhiggs for code |
I've put up a pull request to add @carlhiggs! 🎉 |
…duplicate elements in template and flextemplate tests for optional charwrap functionality, as per py-pdf#1176
…mode is CHAR, as per @gmischler review request in py-pdf#1176
I've just addressed latest round of review requests: more accurately referring to when 'wrapmode is "CHAR"' in one specific test's self-descriptive text (and updated test pdfs used to validate this to have the changed text too), and externalising duplicate text to a shared python file containing elements now used in both template and flextemplate tests of the optional wrapmode functionality. Black and pylint were run using CLI, and through pre-commit hook. The pylint warnings that remained did not relate to my tests or modifications, but to various "pylint.extensions" that apparently were impossible to load ("bad_plugin-value"?). I believe that is not an issue with this pull request, but something upstream. If this passes checks, do you think this could be could to merge @gmischler ? |
Thanks for the contribution, @carlhiggs ! |
Fixes #1159
Checklist:
The GitHub pipeline is OK (green),
meaning that both
pylint
(static code analyzer) andblack
(code formatter) are happy with the changes of this PR.A unit test is covering the code added / modified by this PR
This PR is ready to be merged
In case of a new feature, docstrings have been added, with also some documentation in the
docs/
folderA mention of the change is present in
CHANGELOG.md
In the flextemplate test for the wrapmode functionality, I tested a range of possibilities described in text of each template element. The first three elements test that the new code doesn't do anything strange to existing funcitonality; the last one specifically tests that wrapmode='CHAR' wraps accordingly:
The output of the above looks correct to me:
I ran black and checked pylint in vscode; I believe the changes I made should be all fine for these requirements.
By submitting this pull request, I confirm that my contribution is made under the terms of the GNU LGPL 3.0 license.