refactor(pdfkit): align object.js, outline.js and reference.js with upstream - #3482
Merged
Conversation
…pstream Replace all three with foliojs/pdfkit master, byte-identical. reference.js was the outlier: the fork still carried the pre-ES6 stream.Writable version with an async zlib.createDeflate, while upstream has buffered chunks and deflated synchronously in finalize() since 2017. Nothing pipes into a ref or listens on it, document.js is already identical to upstream and its _waiting/_ended bookkeeping works either way, and browserify-zlib exports deflateSync for the browser build. The only observable change is that compressed objects are now emitted in call order instead of being deferred to the end of the file. object.js is coupled to that: its instanceof PDFAbstractReference check only works once PDFReference extends it instead of stream.Writable. It also fixes a real bug. The old chain matched instanceof PDFNameTree, but PDFNumberTree extends PDFTree, so it fell through to the [object Object] branch and serialized its own internals. Tagged PDFs emitted /ParentTree << /_items << /0 [10 0 R] >> /limits true >> instead of /ParentTree << /Nums [ 0 [10 0 R] ] >>. outline.js had already been upstreamed, custom fork markers and all. What was left is DEFAULT_OPTIONS.fit and pageNumber != null vs !== null, neither of which reaches react-pdf: addBookmarks always passes an explicit options object with a numeric pageNumber, so DEFAULT_OPTIONS is dead for us. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 483fa9c The changes in this PR will be included in the next version bump. This PR includes changesets to release 12 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
exoego
added a commit
to exoego/react-pdf-renderer
that referenced
this pull request
Aug 9, 2026
…gn-reference Upstream already landed the identical reference.js alignment in diegomura#3482, so that part of this branch is now a no-op. Resolved the remaining conflicts in favor of master's new build layout (document.node.js and document.browser.js entry points, standard-fonts output, no json plugin) while keeping this branch's switch from rollup-plugin-polyfill-node to node-stdlib-browser.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces all three files with foliojs/pdfkit master, byte-identical.
reference.jswas the outlier — the fork still carried the pre-ES6stream.Writableversion with an asynczlib.createDeflate, while upstream has buffered chunks and deflated synchronously infinalize()since 2017; nothing pipes into a ref or listens on it,document.jswas already identical to upstream, andbrowserify-zlibexportsdeflateSyncfor the browser build, so the only observable change is that compressed objects are now emitted in call order rather than deferred to the end of the file (verified pixel-identical output before/after).object.jsis coupled to that (itsinstanceof PDFAbstractReferencecheck only works oncePDFReferenceextends it) and fixes a real bug: the old chain matchedinstanceof PDFNameTree, butPDFNumberTreeextendsPDFTree, so it fell through to the[object Object]branch and tagged PDFs emitted/ParentTree << /_items << /0 [10 0 R] >> /limits true >>instead of/ParentTree << /Nums [ 0 [10 0 R] ] >>.outline.jshad already been upstreamed, custom fork markers and all; what was left isDEFAULT_OPTIONS.fitandpageNumber != nullvs!== null, neither of which reaches react-pdf sinceaddBookmarksalways passes an explicit options object with a numericpageNumber.Full test suite passes (2261 tests, 218 files), including the renderer visual snapshots.
🤖 Generated with Claude Code