fix(text): patch @libpdf/core pour extraire le texte des form XObjects#4
Open
Xusifob wants to merge 1 commit into
Open
fix(text): patch @libpdf/core pour extraire le texte des form XObjects#4Xusifob wants to merge 1 commit into
Xusifob wants to merge 1 commit into
Conversation
Documenso's placeholder-based field positioning (POST /envelope/field/create-many with a "placeholder") relies on findText() locating the marker in the PDF. Our medical documents are sealed via TCPDF/FPDI, which wraps the whole page inside a form XObject. @libpdf/core 0.3.3 does not follow the `Do` operator during text extraction, so findText() returns nothing and field placement silently falls back to default coordinates. This backports the upstream fix (LibPDF-js/core PR #85, commit f391d90 "feat(text): extract text from form XObjects") onto the pinned 0.3.3 build via patch-package: TextExtractor now recurses into form XObjects using their own /Resources with the form's /Matrix concatenated onto the CTM. Only the text-extraction subsystem is touched; signing/sealing code is byte-identical to 0.3.3. Remove this patch once @libpdf/core ships the fix in a released version and the dependency is bumped.
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
1 participant
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.
Problème
Le placement de champ par
placeholder(POST /envelope/field/create-many) repose surfindText()pour localiser le marqueur dans le PDF. Les documents médicaux Instamed sont scellés via TCPDF/FPDI, qui importe toute la page dans un form XObject. Or@libpdf/core0.3.3 ne suit pas l'opérateurDopendant l'extraction de texte : il ne voit rien du contenu réel.Mesuré sur un document réel scellé :
findText("{POSITION_SIGNATURE}")Conséquence côté Instamed :
create-manyrenvoyait 400 « Placeholder not found », le repli en coordonnées s'appliquait, et le champ de signature atterrissait toujours au même endroit arbitraire au lieu de la zone déclarée dans le document.Solution
Backport du correctif amont — LibPDF-js/core#85, commit
f391d90« feat(text): extract text from form XObjects » — sur le 0.3.3 épinglé, viapatch-package(déjà en place dans ce dépôt, etpatches/est explicitement copié dans les deux stages du Dockerfile).TextExtractordescend désormais dans les form XObjects en utilisant leurs propres/Resources, avec la/Matrixdu form concaténée à la CTM.Le cherry-pick sur
v0.3.3s'applique sans conflit : la PR amont ne touche que 3 fichiers du sous-système d'extraction de texte (text-extractor.ts,text-state.ts,pdf-page.ts), aucun dans la signature. Le code de signature/scellement — utilisé parpackages/signing,seal-document,generate-certificate-pdf,normalize-pdf— reste identique au bit près au 0.3.3 déployé. C'est délibéré : vendorer le build 0.4.2 de la PR aurait fait sauter deux versions mineures sur le chemin cryptographique.Vérification
@libpdf/core@0.3.3vierge,patch-packageapplique le patch (@libpdf/core@0.3.3 ✔) et le marqueur est retrouvé.distpatché présent dans l'image finale.create-manyavecplaceholderrenvoie 200 (au lieu de 400) et crée le champ à X=39,7 % / Y=34,2 % — la position du marqueur.Retrait
Ce patch est temporaire. Le supprimer dès que
@libpdf/corepublie le correctif dans une version releasée et que la dépendance est bumpée (la PR amont n'est pas encore mergée).Lien
Nécessaire au bon fonctionnement de instamedsolutions/Instamed#2692. Sans cette PR déployée, le repli en coordonnées s'applique — pas de régression, mais pas de gain.
🤖 Generated with Claude Code
https://claude.ai/code/session_01CSpvLGq8AdWLwXEVEUBF5a