Some further progress! On 18 Nov 2019, at 13:56, Hans Hagen wrote:
the problem with calculate is that there are also settings related to it (plus some built-in addition stuff, at least that's what i see in the viewer preferences and such, which is likely to interfere)
From what I've been able to gather, there are three ways to get JavaScript into a PDF using Acrobat (or other software that uses the Acrobat way of doing things): - Predefined Calculations (use a UI to build a simple recipe) - Calculations built with Simplified Field Notation (operators and field names - I don't understand this one too well) - Custom Calculation Script (Acrobat JavaScript) I _think_ these are relatively exclusive: I don't believe there's anything about the first two systems that interferes with the third (and I'm not sure how the UI would work for the first two in an LMTX context, anyway?).
(and calculate doens't seem to be called at all)
After digging around in the spec and comparing output, it looks like adding the CO (Calculation Order, PDF Spec 12.7.2) key and an array: /CO [15 0 R] ...to the AcroForm object is enough for the indicated field(s) to react to the internal calculation event. The way I tested this is I inserted the above stanza (with the appropriate object ID) into the uncompressed LMTX PDF, and that was all it took for the calculate JS to start working for the total field. (I likely wrecked the xref table in the process, but the PDF was still functional...) I then built a form with a chained calculation (a second field that doubled the total field) and ended up with a CO entry like this: /CO [13 0 R 19 0 R] ...and I believe that the order of the objects in this array is how the calculation precedence is determined. So! This is bigger than just adding the CO array to enable calculations; there needs to be enough of an interface to also indicate calculation order somehow in the .tex file. I'd love to have this as a feature, but I will cheerfully defer if this has become ridiculous... -Paul