[KleiKodesh]

PDF.js keeps a stamp's alternate description in the structure tree, not in the annotation: a /Figure element with /Alt and an /OBJR to the stamp, the stamp's /StructParent, and a parent tree entry. An engine that wants to save alt text the way PDF.js reads it back had no API to write that.

New functions in epdf_annot.h:

• EPDFAnnot_GetAltText(annot, buffer, buflen) reads the /Alt of the structure element that lists the annotation, found through its /StructParent and the parent tree (the same walk EPDFAnnot_GetStructurePosition() makes).
• EPDFAnnot_SetAltText(annot, alt) writes it:
  • an annotation already in the tree: the element that lists it gets the /Alt (an empty or NULL text removes it);
  • otherwise a new /Figure element (/P, /Pg, /Alt, /K = the /OBJR), appended to the tree's /Document element when the root's one kid is one, else to the root; the annotation gets /StructParent = the next parent tree key (/ParentTreeNextKey, past every key in use), and the parent tree's /Nums gets the entry in key order;
  • the catalog's /StructTreeRoot and its /ParentTree are created when missing;
  • refused, with nothing written: a direct annotation dictionary, a parent tree with /Kids (only a flat /Nums is written), or a structure root or parent tree that isn't a dictionary.

Every write to an existing object goes through GetMutableIndirectObject() / GetMutableRoot(), so in a layer it promotes exactly the objects it changes.

Tests

• New embedder test EPDFAnnotEmbedderTest.AltTextRoundTripsThroughTheStructureTree: two annotations get alt text on a document without a structure tree, read back, sit at root kids 0 and 1, a second write rewrites the element in place, and NULL removes it.
• epdf_c_api_test.c lists the two new exports.
• Not built or run locally (no emscripten/clang toolchain on the machine this was written on); CI hasn't run yet.