You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implement PDF anonymisation in OpenRegister via byte-level text replacement through the SAPP library — Approach H from the pdf-anonymisation-discovery research.
PDFs currently fall through to DocumentProcessingHandler::replaceWordsInTextDocument, which calls str_ireplace on binary content and produces an unopenable file. PDFs are binary containers with FlateDecode-compressed content streams, font-encoded text (Identity-H + ToUnicode CMaps in Word-generated documents), and kerning-split text-showing operators (TJ arrays). The current implementation breaks every real-world Woo PDF.
Approach
SAPP byte-level text replacement with Helvetica fallback. The required SAPP primitives don't exist upstream — we've forked dealfonso/sapp at ConductionNL/sapp and implemented the missing pieces as an 8-PR series on the work/text-replacement integration branch:
Helvetica fallback + parameter validation + stable API
The OR-side consumer integration is what this issue tracks.
Specs
Already drafted on feat/pdf-anonymisation — proposal, design (10 decisions D1-D10), spec.md with normative requirements, tasks.md (13 sections including the composer-VCS wiring as §10). Will move to the new feature branch.
Tasks (high level)
Bring in the pdf-anonymisation OpenSpec change from feat/pdf-anonymisation
Wire ddn/sapp via composer VCS repository (pinned to feat/text-replacement-api SHA 25db760 for now; moves to work/text-replacement once the 8 PRs merge there; eventually upstream tag)
Path B (Collabora ODT round-trip fallback) — deferred to a follow-up issue once Path A is in operators' hands and we have fall-through-rate data from real Woo PDFs.
Summary
Implement PDF anonymisation in OpenRegister via byte-level text replacement through the SAPP library — Approach H from the
pdf-anonymisation-discoveryresearch.PDFs currently fall through to
DocumentProcessingHandler::replaceWordsInTextDocument, which callsstr_ireplaceon binary content and produces an unopenable file. PDFs are binary containers with FlateDecode-compressed content streams, font-encoded text (Identity-H + ToUnicode CMaps in Word-generated documents), and kerning-split text-showing operators (TJarrays). The current implementation breaks every real-world Woo PDF.Approach
SAPP byte-level text replacement with Helvetica fallback. The required SAPP primitives don't exist upstream — we've forked
dealfonso/sappatConductionNL/sappand implemented the missing pieces as an 8-PR series on thework/text-replacementintegration branch:The OR-side consumer integration is what this issue tracks.
Specs
Already drafted on
feat/pdf-anonymisation— proposal, design (10 decisions D1-D10), spec.md with normative requirements, tasks.md (13 sections including the composer-VCS wiring as §10). Will move to the new feature branch.Tasks (high level)
pdf-anonymisationOpenSpec change fromfeat/pdf-anonymisationddn/sappvia composer VCS repository (pinned tofeat/text-replacement-apiSHA25db760for now; moves towork/text-replacementonce the 8 PRs merge there; eventually upstream tag)lib/Service/File/Pdf/PdfTextReplacerwrappingPDFDoc::replaceTextInDocumentlib/Service/File/Pdf/PdfMetadataSanitizer(parity with the sisteroffice-document-sanitizationchange)DocumentProcessingHandler::anonymizeDocumenttoPdfTextReplacerinstead of the brokenstr_ireplacepathsmalot/pdfparser, assert no residual entity text, fail-closed on miss[P:7] [P:7]→[P:7])Out of scope
References
openspec/changes/pdf-anonymisation-discovery/discovery.md(onfeat/pdf-anonymisation)openspec/changes/pdf-anonymisation/(onfeat/pdf-anonymisation)