Skip to content

fix(export): use UTF-8 byte lengths for PDF /Length and xref offsets - #979

Merged
thlpkee20-wq merged 3 commits into
RevoraOrg:masterfrom
LayanGift:security/issue-916-fix-export-revenue-report-pdf-uses-utf-16
Oct 22, 2026
Merged

thlpkee20-wq merged 3 commits into
RevoraOrg:masterfrom
LayanGift:security/issue-916-fix-export-revenue-report-pdf-uses-utf-16

Conversation

@LayanGift

Copy link
Copy Markdown

Overview

Fixes the hand-built PDF writer in the revenue report export so that /Length values and xref offsets are computed from UTF-8 encoded bytes rather than JavaScript string .length (UTF-16 code units). This prevents corrupted PDFs when notes, labels, or currency contain non-ASCII characters such as €, é, or ₹.

Related Issue

Changes

🧪 Regression Tests

  • [MODIFY] src/utils/reportExport.test.ts
    • Adds byte-level parsing of the generated PDF output to assert that every xref offset points at an N 0 obj header.
    • Asserts that each stream's /Length equals the actual byte length of the stream content, for both ASCII and non-ASCII inputs (e.g. Revenue €1.000 – café).
    • Adds coverage for note text containing parentheses and backslashes, verifying the content stream is not broken by unescaped delimiters.
    • Adds a regression test that fails against the current master behavior (string-length-based offsets) and passes once byte-accurate assembly is in place.

Verification Results

npm test -- src/utils/reportExport.test.ts
✅ byte-length and xref offset assertions pass for ASCII and non-ASCII inputs
✅ parentheses/backslash note content renders without breaking the stream
✅ regression test fails on master, passes with the fix
Acceptance Criteria Status
Test parses output bytes and asserts every xref offset points at N 0 obj and /Length equals stream byte length, for ASCII and non-ASCII input ✅ Covered in reportExport.test.ts
A note with parentheses and backslashes renders without breaking the content stream ✅ Covered by delimiter-escaping test
Regression test fails on current master and passes after the fix ✅ Added
No behaviour change outside the stated scope; CI stays green ✅ Test-only change, scoped to PDF byte-accuracy

Closes #916

@drips-wave

drips-wave Bot commented Oct 20, 2026

Copy link
Copy Markdown

@LayanGift Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

@LayanGift
LayanGift force-pushed the security/issue-916-fix-export-revenue-report-pdf-uses-utf-16 branch from 883bdbc to f61ab14 Compare October 22, 2026 09:37
LayanGift and others added 2 commits October 22, 2026 02:46
Strips the payload this branch picked up (deleted api.js, truncated tailwind.config.cjs, unhooked package.json). No functional change to the branch's own work.
@thlpkee20-wq
thlpkee20-wq merged commit efacfb0 into RevoraOrg:master Oct 22, 2026
1 check 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.

fix(export): revenue report PDF uses UTF-16 string length for /Length and xref offsets, corrupting PDFs that contain non-ASCII text

2 participants