Pdf-lib: [Question] keys for PDFNames and PDFCatalog

[jboxxx]

form_8949.pdf
form_8949.pdf

Hi - I have been referencing other closed issues which have been helpful such as https://github.com/Hopding/pdf-lib/issues/109

Hopding and others are getting objects out of the pdfDoc.index with various getMaybe(key) calls from the catalog with keys such as 'AcroForm' as in the below code from the above issue. Is there any documentation that explains what all of these keys are? Although I can see them in catalog.validKeys, it feels like I'm arbitrarily pulling down these names, and I'm curious what they all do for me. For example, I'm following along with the code in the above issue, and the 'AcroForm' doesn't seem to give me all of the fields in my pdf, it only returns 6 fields as opposed to close to a hundred fields on the form.

const getAcroFields = pdfDoc => {
  if (!pdfDoc.catalog.getMaybe('AcroForm')) return [];
  const acroForm = pdfDoc.index.lookup(pdfDoc.catalog.get('AcroForm'));

  if (!acroForm.getMaybe('Fields')) return [];
  const acroFields = pdfDoc.index.lookup(acroForm.get('Fields'));

  return acroFields.array.map(pdfDoc.index.lookup);
};

Similarly once a field is targeted say in an acroField, is there documentation stating what all of the keys are for an acroField? For a particular field I'm looking at, I see keys with names of 'T', 'F', 'Subtype', 'DA', 'MK' etc, and have no idea what they each represent.

Thank you. For reference, the form I have been looking at is attached if that helps.

[Hopding]

Hello @jboxxx!

The documentation for all of the keys you mentioned can be found in the PDF specification. These keys are not defined by pdf-lib itself (if they were, they'd have more meaningful names than DA 😉). For this reason, they are not documented as part of pdf-lib.

Ideally, users of pdf-lib would never need to read the PDF specification or deal with these low-level PDF keys. The library should contain higher level APIs that abstract away the low level stuff. However, feature requests and issues come in faster than these higher level APIs can be developed. This is why some of the code snippets you've seen seem opaque and poorly documented.

I'll take a look at the form fields in the document you shared and get back with you.

[Hopding]

I did a bit of investigation into the PDF you shared. It turns out that:

• The 6 acroform fields correspond to the 6 check boxes in the document (3 per page).
• The 238 are not part of the acroform. They're just "loose" text fields attach to the pages.

I wrote a function to extract the text fields, and used it to populate each of them with their index number. Here's the resulting document: filled_form_8949.pdf.

And here's the script I used to create it:

// ...imports omitted...

const getTextFields = (pdfDoc) => {
  const indirectObjects = Array.from(pdfDoc.index.index.entries());
  return indirectObjects
    .filter(
      ([ref, object]) =>
        object instanceof PDFDictionary &&
        object.getMaybe('FT') === PDFName.from('Tx'),
    )
    .map(([ref, object]) => object);
};

const pdfDoc = PDFDocumentFactory.load(fs.readFileSync('./form_8949.pdf'));

const textFields = getTextFields(pdfDoc);

textFields.forEach((field, idx) => {
  field.delete('AP');
  field.set('V', PDFString.fromString(`Field ${idx}`));
});

const pdfBytes = PDFDocumentWriter.saveToBytes(pdfDoc);

fs.writeFileSync('./filled_form_8949.pdf', pdfBytes)

I hope this helps. Please let me know if you have any further questions!

[Naryck]

Hi, I need to edit the same form, but looks like the code in the answer belongs to the older version. Now there's no pdfDoc.index.index.entries(). Should I use the older version or the code can be fixed for the latest version?

Question is no longer relevant

[Hopding]

For future reference, the pdfDoc.index.index.entries() call can be replaced with pdfDoc.context.enumerateIndirectObjects().