With Release 178 in April 2025, SIGNiX supports the use of pure x,y coordinates on uploaded PDF documents to create tasks for reviewers and signers in a SubmitDocument call. This is in addition to use of PDF fields, text anchor tags and manual drag-and-drop tagging of a document while in MyDoX or in a GetAccessLink-Submitter session.
SIGNiX supports the use of x,y coordinates in PDF documents to place actual PDF fields (tasks) on a document for users to sign / fill, etc. The origin point for the coordinate system is based on a similar coordinate system to other e-signature platforms. We start our coordinates in the upper left corner of the document (0,0) of the x,y offset system, with positive values moving to the right and down of that initial point. That initial coordinate becomes the lower left corner of the field border from which we then define height and width. All coordinates are based on 1/72 inch points. For a typical 8.5 x 11 page, that means the maximum x,y coordinates are approximately 612,792. Note that integrators should be aware of the total inclusive x,y volume of their indicated fields. That is, a field that needs to be 112 pixels wide must be x<600.
These fields would be included in the <Form> section of the SubmitDocument call, like other fields, after the <MimeType> element and prior to the <Length> and <Data> elements. They replace the normal SubmitDoc elements for fields, etc.
The page number (<Page>) on which the field is to be assigned must be included. The type (<Type>) of tag being placed must be identified, as well as the position (<XPosition> and <YPosition>), the size of the field (<Width> and <Height>), whether the field is required or optional (<IsRequired>), and an internal ‘name’ (<TagName>) for the field that can be referenced elsewhere in the SubmitDocument call.
Text and other input fields that are NOT signatures or initials are represented by the <FixedPositioningField> section.
...
<FixedPositioningField> Occurs once only
<Type>TextField</Type> Mandatory. The possible options are TextField, Checkbox, DateSigned, NotarySeal, endorsementinfo. The last entry is used for elements such as printed name and 21CFR11 specific reason fields.
<Page>1</Page> Mandatory.
<XPosition>150</XPosition> Mandatory.
<YPosition>500</YPosition> Mandatory.
<Width>120</Width> Mandatory. Be sure to provide sufficient width and height to display the contents of the field.
<Height>30</Height> Mandatory. Be sure to provide sufficient width and height to display the contents of the field.
<IsRequired>yes</IsRequired> Mandatory.
<TagName>EditableField1</TagName> Mandatory. Internal name that can be referenced elsewhere in SubmitDocument call.
</FixedPositioningField>
...
Signatures and initials are represented by the <FixedPositioningSignature> field.
...
<FixedPositioningSignature> Occurs once only
<MemberInfoNumber>1</MemberInfoNumber> Mandatory. The signer who will perform this task.
<Type>signature</Type> Mandatory. The possible options are signature or initial.
<Page>1</Page> Mandatory.
<XPosition>150</XPosition> Mandatory.
<YPosition>500</YPosition> Mandatory.
<Width>120</Width> Mandatory.
<Height>30</Height> Mandatory.
<IsRequired>yes</IsRequired> Mandatory.
<TagName>EditableField1</TagName> Mandatory. Internal name that can be referenced elsewhere in SubmitDocument call.
<DateSignedTagName>DateField1</DateSignedTagName> Optional. The TagName of the 'DateSigned' field, if provided.<DateSignedFormat>MM/dd/yy</DateSignedFormat> Optional.
<EditableFieldTagName>EditableField1</EditableFieldTagName> Optional. The TagName of any other text, checkbox or radio field to be covered and assigned to this signature and signer. Include additional <EditableFieldTagName> elements for other tasks assigned to this signer. Effectively the cover element from the normal Submit Document.
<PrintedNameTagName>printedName</PrintedNameTagName> Optional. The TagName of the field being used to print the signer's name, if provided.
<NotarySealTagName>NotarySeal1</NotarySealTagName> Mandatory - if this is a notarial transaction. Reference the TagName of the field holding the notary seal.
</FixedPositioningSignature>
...
IMPORTANT: All non-signature fields (<FixedPositioningField>) must be placed in the XML before all signature fields (<FixedPositioningSignature>) within the Form section.
...
<MimeType>pdf</MimeType>
<Fixed PositioningField>...</FixedPositioningField>
<Fixed PositioningField>...</FixedPositioningField>
<Fixed PositioningField>...</FixedPositioningField>
<FixedPositioningSignature>...</FixedPositioningSignature>
<FixedPositioningSignature>...</FixedPositioningSignature>
<FixedPositioningSignature>...</FixedPositioningSignature>
<Length>...</Length>
...
When the SubmitDocument is submitted, if a coordinate-based field will fall outside the bounds of the page, a verbose error will appear explaining what needs to be fixed. Example: "For form #01, FixedPositionField 'DateField1': FixedPositioningField 'DateField1' in Form #01 is out of PDF content area. Please adjust the values in the FixedPositioningField."
The coordinate system is similar to platforms such as DocuSign, so those coordinates should be able to be re-used, even though the API structure of course is different.
Please use unique, explicit tags for each field / task to be implemented.
When implementing, it may be best to define a ‘standard’ for how large signatures will be, initials, date fields, etc and explain that to the users who will be adding tags to the documents. That way, it need not be a back-and-forth testing process to get the tags just right.
NOTE: Please replace the account information and signer email addresses in your usage.
- Sample Submit Document with coordinate tags
- Sample Submit Document - Multi-Party Coordinate Tags with Notary Seal
- Sample Submit Document - Multi-Document Coordinate Tags
