Setting font-family for AcroFrom not working properly

[r4tz52]

Bug Report

Description of the problem

Setting custom font for text AcroForm has no effect if PDF file opened in Adobe Acrobat Reader, but works fine in Google Chrome:

PDF file example: aladin.pdf

Code sample

doc.font('aladin.regular.ttf');
doc.formText('InputField1', 10, 10, 200, 20, { value: 'Aladin' });

Your environment

• pdfkit version: 0.11.0
• Browser version: Google Chrome 80.0.3987.122
• Operating System: Windows 10

[KaiPressmar]

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

[bowespublishing]

Is there an update on this at all please?

[KaiPressmar]

@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.

[blikblum]

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

[KaiPressmar]

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.