A change to one resize call, a regression test shaped by review, and backports to three stable branches.
Kurze Antwort
When a LibreSign user uploaded a PNG as their signature, the signed PDF showed it far larger than the signature box. The image was scaled from its own pixel size rather than fitted into the stamp. The fix resizes it with Imagick's aspect-preserving best fit into the stamp canvas. It was merged as PR #8002, closed issue #7981, and the maintainer requested backports to stable34, stable33 and stable32.
The problem
LibreSign is a Nextcloud app for signing documents. Issue #7981 described the flow. A user uploads a .png signature, it looks right in the sidebar, but after signing, "the uploded .png is not scaled but in true size. Thus the signature is way to big for the defined signature size."
Root cause
JSignPdfHandler::mergeBackgroundWithSignature() resized the signature by multiplying its own width and height by the scale factor. A large uploaded image stayed large, regardless of the stamp box it was supposed to fit.
The fix
$signature->resizeImage(
- (int)round($signature->getImageWidth() * $scaleFactor),
- (int)round($signature->getImageHeight() * $scaleFactor),
+ (int)$canvasWidth,
+ (int)$canvasHeight,
Imagick::FILTER_LANCZOS,
- 1
+ 1,
+ true
);The final true turns on Imagick's best-fit mode, which keeps the aspect ratio while fitting inside the canvas. According to the PR description, this matches the approach the handler already used for the background image.
By the numbers
- Repository: LibreSign/libresign, 841 stars (Nov 3, 2026), PHP, AGPL-3.0
- Files changed: 2 (1 source file, 1 test file)
- Lines: +87 / -3
- Commits: 2
- Opened: Aug 21, 2026. Merged: Aug 25, 2026. Time to merge: 3 days, 21 hours
- Review: changes requested, then merged by a maintainer, with backports requested to three stable branches
How the review went
The maintainer requested changes with two inline suggestions about the regression test. First, read the minimum scale factor from the handler instead of hardcoding it, because "duplicating the value here couples the test to that implementation detail." Second, use a data provider to cover different aspect ratios:
'same aspect ratio' => [1400, 400],
'wider signature' => [1400, 200],
'taller signature' => [700, 800],The follow-up commit did both. The final test builds a PNG with opaque corners, merges it, and checks that the top-left and bottom-right corners of the fitted signature land inside the stamp box for all three shapes. At merge time, the maintainer asked the backport bot to port it to stable34, stable33 and stable32.
Takeaways
- The production change is one call. Most of the diff is a test that proves the image stays inside its box.
- Review made the test better, not just the code: less coupled to internals, and covering more shapes.
FAQ
Does this change signatures drawn in the browser?
The PR targets uploaded signature images that are larger than the stamp box. The merged test covers signatures with the same, wider and taller aspect ratios than the box.
Where can I read more?
See the pull request and the original issue.
Das Ziel
A signature that doesn't fit its box makes a signed document look broken. A fix that is small enough to backport to three release lines on the day it merges is the kind of fix that reaches users quickly.
