Experimental source-backed text editing prototype in PDF.js

[RabbitHols]

Hi PDF.js maintainers,

I have been experimenting with native text editing directly outside and inside PDF.js, and I wanted to share the prototype to ask whether this direction is interesting or compatible with the project architecture.

Demo:
https://rewirepdf.com/web/viewer.html?file=/web/demo/tracemonkey.pdf

Fork:
https://github.com/RabbitHols/pdf.js

The prototype tries to edit PDF text from the actual PDF content stream instead of drawing a visual overlay on top of the page.

The current scope is intentionally narrow:

• source-backed text edits only
• conservative single-line edits
• tested mostly on tracemonkey.pdf
• rejects edits when the source span cannot be traced/proven safely editable
• no paragraph reflow
• no visual fallback writer

The rough architecture is:

• PDF.js text layer is used as the interaction/hit-test surface
• source references are propagated from parsing/evaluation to text items/spans
• an edit planner verifies that a visible text span maps to a safe source operation
• a rewriter updates the relevant content stream region
• save/reopen validates the changed PDF

I know this is far from a complete PDF edit feature, especially for complex layouts, font encodings, multi-column documents, and reflow. My goal right now is to explore whether PDF.js could expose enough source/layout information to support real edits safely, rather than overlay-based editing.

I’d love feedback on:

1. Is this kind of source-backed editing something PDF.js maintainers would consider in principle?
2. Are there architectural boundaries I should change before going further?
3. Is there prior work or an existing issue I should align with?

Thanks!