Activity

1. KaiPressmar commented on Apr 7, 2020

   

   KaiPressmar

   on Apr 7, 2020

   Contributor

   More actions

   Same issue for custom fonts

   Example code:

   const PDFDocument = require("pdfkit");
   const fs = require("fs");
   
   var doc = new PDFDocument();
   doc.pipe(fs.createWriteStream("out.pdf"));
   
   doc.font("./SourceCodePro-Regular.ttf");
   doc.initForm();
   
   // Dynamic fields do not work
   doc.formText("txt1", 20, 20, 100, 10, {
     value: "Test 01234",
   });
   
   // Normal text elements work
   doc.text("Test 01234", 20, 40, 100, 10);
   
   doc.end();
   

   Output:

   

   Environment

   pdfkit version: 0.11.0
   Browser version: 80.0.3987.163 (Offizieller Build) (64-Bit)
   Operating System: Windows 10
2. bowespublishing commented on Nov 20, 2022

   

   bowespublishing

   on Nov 20, 2022

   More actions

   Is there an update on this at all please?
3. liborm85

   added

   bug

   on Dec 26, 2024
4. KaiPressmar commented on Aug 31, 2026

   

   KaiPressmar

   on Aug 31, 2026

   Contributor

   More actions

   @blikblum I investigated this issue and would be interested in contributing a fix.

   I also looked at #1335, which attempted to solve the problem by adding an option to disable font subsetting globally. I think the issue can be addressed more narrowly: keep the existing subset behavior for normal PDF text, but use a separate complete TrueType font resource for AcroForm "/DR" and "/DA" resources.

   The reason is that Acrobat regenerates editable form appearances and may need glyphs/tables that are not present in PDFKit's subset font. This appears to explain why the same form renders correctly in Chrome but falls back to another font in Acrobat.

   I have prepared an implementation with a regression test, documentation and changelog entry. Before opening a PR, would this form-specific approach be preferable to exposing a general "disable subsetting" option?

   If so, I can submit it as a PR against current master and reference both this issue and #1335.
5. blikblum commented on Sep 3, 2026

   

   blikblum

   on Sep 3, 2026

   Member

   More actions

   Need to look at the PR but would be good to look at what other open source libraries do (iText, QuestPdf, ReportLab)
6. KaiPressmar

   added a commit that references this issue on Sep 5, 2026

   fix: give AcroForm a font readers can resolve field text against

   ...

   This issue will close once commit ee50422 is merged into the 'main' branch.

   ee50422
7. KaiPressmar commented on Sep 5, 2026

   

   KaiPressmar

   on Sep 5, 2026

   Contributor

   More actions

   Update: I opened a PR with the narrower, form-specific fix discussed above: #1789. It embeds a separate, complete, standard-encoding font for the AcroForm's /DR//DA resources instead of reusing the subsetted Identity-H font used in page content, since that font's subset intentionally has no cmap table and readers regenerating a field's appearance (via NeedAppearances) have no way to resolve field text to a glyph in it — which is why the same field renders fine in some viewers but falls back to a substitute font in others.

   @blikblum, flagging for whenever you have a chance to look.
8. KaiPressmar

   added 5 commits that reference this issue on Sep 11, 2026

   fix: give AcroForm a font readers can resolve field text against

   ...

   This issue will close once commit 0ca02e5 is merged into the 'main' branch.

   0ca02e5

   feat: add an embedCompleteFonts option for AcroForm fields

   ...

   This issue will close once commit 490720d is merged into the 'main' branch.

   490720d

   feat: add an embedCompleteFonts option for AcroForm fields

   ...

   This issue will close once commit de3c841 is merged into the 'main' branch.

   de3c841

   feat: add an embedFonts option for AcroForm fields

   ...

   This issue will close once commit cd32a19 is merged into the 'main' branch.

   cd32a19

   feat: add an embedFonts option for AcroForm fields

   ...

   This issue will close once commit a2183fc is merged into the 'main' branch.

   a2183fc
9. blikblum

   closed this as completedin #1789on Sep 14, 2026
10. pull

    added a commit that references this issue on Sep 14, 2026

    feat: add an embedFonts option for AcroForm fields (foliojs#1789)

    ...

    This issue will close once commit d05b18f is merged into the 'master' branch.

    d05b18f