Commit 6ba4640
fix: redact.js ignored non-zero MediaBox origin, misplacing redaction rects and missing text on such PDFs
addRectBtn's page-size hint tells users coordinates are relative to the page's
visible bottom-left corner (origin bottom-left), but redactPdf() passed the
raw x/y straight into page.drawRectangle() and redactContentStream() with no
adjustment for the page's actual MediaBox origin. For any PDF whose MediaBox
doesn't start at (0,0) -- a real, if less common, pattern from scanned/
print-production PDFs, the same precedent that motivated the crop.js/
border.js/watermark.js MediaBox-origin fixes -- the black box landed in the
wrong absolute position and the underlying text was not matched/removed,
while the tool still reported success.
Fixed by capturing each page's box.x/box.y at load time and offsetting the
rect before both the text-removal pass and the visual rectangle draw, so
the two stay consistent and match what the size hint promises. Reproduced
and verified against the real vendored pdf-lib: a text run invisible to the
un-offset rect (0 removed) is correctly matched once the offset is applied
(1 removed); the common zero-origin case is unaffected.1 parent 98eb3dd commit 6ba4640
1 file changed
Lines changed: 15 additions & 3 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
124 | 124 | | |
125 | 125 | | |
126 | 126 | | |
127 | | - | |
128 | | - | |
| 127 | + | |
| 128 | + | |
| 129 | + | |
| 130 | + | |
| 131 | + | |
| 132 | + | |
| 133 | + | |
| 134 | + | |
129 | 135 | | |
130 | 136 | | |
131 | 137 | | |
| |||
222 | 228 | | |
223 | 229 | | |
224 | 230 | | |
| 231 | + | |
| 232 | + | |
| 233 | + | |
| 234 | + | |
| 235 | + | |
| 236 | + | |
225 | 237 | | |
226 | | - | |
| 238 | + | |
227 | 239 | | |
228 | 240 | | |
229 | 241 | | |
| |||
0 commit comments