-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
BUG: Writing German characters into form fields #2047
Conversation
/uniHHHH glyphs seems to be generated in laTeX but is ok for other characters addressed partially in py-pdf#2016
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #2047 +/- ##
==========================================
- Coverage 94.28% 94.17% -0.11%
==========================================
Files 41 41
Lines 7364 7386 +22
Branches 1451 1458 +7
==========================================
+ Hits 6943 6956 +13
- Misses 262 267 +5
- Partials 159 163 +4
☔ View full report in Codecov by Sentry. |
Co-authored-by: Martin Thoma <[email protected]>
Co-authored-by: Martin Thoma <[email protected]>
Test converage is not wonderfull but I miss ideas @MartinThoma all yours |
PS : I will need this PR for a new one (which will deal with full unicode(arabic and asian chararacter sets) ) 😉 |
stdby |
pypdf/_writer.py
Outdated
raise AssertionError("can not find font dictionary") | ||
logger_warning(f"can not find font dictionary for {font_name}", __name__) | ||
font_full_rev = {} |
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.
The code after the exception will never be executed
I would use ValueError instead of AssertionError: https://docs.python.org/3/library/exceptions.html#exception-hierarchy - but I cannot give a good reason why 🤔
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.
I agree that using AssertionErrors usually is a bad approach. Why raising an exception at all when there apparently is a way to continue afterwards after having logged a (recoverable) violation/issue?
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.
The assertion error is here to detect issues when using pytest. In operational condition it is the logger_warning (non blocking) that should be raised
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.
I don't understand that. The Exception will also be raised in prod code, not only in pytest.
When you execute the following with python:
print("First")
raise AssertionError("the exception")
print("Second")
you get:
First
Traceback (most recent call last):
File "/home/moose/foo.py", line 2, in <module>
raise AssertionError("the exception")
AssertionError: the exception
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.
I see my mistake. I originally used assert but ruff changed to the exception only.
I propose this code:
if __debug__:
raise AssertionError("can not find font dictionary")
else:
logger_warning(f"can not find font dictionary for {font_name}", __name__)
your opinion ?
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.
Interesting, I didn't know about __debug__
- thanks for sharing 🙏
Sadly, I think it cannot be used like that. I think more than 90% of all users don't use/know the -O
flag.
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.
Within pytest, we can make warnings which are not captured via with pytest.warns
be treated as errors with pytest -W error
: https://docs.python.org/3/using/cmdline.html#cmdoption-W
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.
I think that is probably a good idea as default as well 🤔
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.
within pyproject.toml there is already:
[tool.pytest.ini_options]
addopts = "--disable-socket"
filterwarnings = ["error"]
isn't this sufficient consider warnings as errors ?
for the moment I removed the raise line
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.
Yes, I think that should do it. Didn't it work?
Co-authored-by: Martin Thoma <[email protected]>
Coverage should improve with further PRs |
conflict solved |
## What's new ### Performance Improvements (PI) - optimize _decode_png_prediction (#2068) ### Bug Fixes (BUG) - Fix incorrect tm_matrix in call to visitor_text (#2060) - Writing German characters into form fields (#2047) - Prevent stall when accessing image in corrupted pdf (#2081) - append() fails when articles do not have /T (#2080) ### Robustness (ROB) - Cope with xref not followed by separator (#2083) [Full Changelog](3.15.0...3.15.1)
closes #2035
closes #2021