White Text Tags

Add signer and notary designations to your generated documents

Manually applying tags to documents can become a tedious task for your team, especially with increased transaction volume and long, multi-page documents.

White Text Tags allow you to automatically apply tags to documents upon upload. White Text Tags allow you to make the signing process seamless for your signers, and lets your team to do business faster. To enable White Text Tagging on your Proof account, reach out to [email protected].

What is a White Text Tag?

  1. You can tag your documents with white-text placeholders using the preferred syntax defined below. This is actual text in white (invisible to the human eye against a white page, but visible to our platform).
  2. When a document is uploaded to the Proof platform via API or UI, the platform locates white text placeholders and automatically applies the prescribed designations on top of those text tags for signer(s) or a notary to complete the document.

Implementation

  1. Identify the “root” or “seed” document templates used to create the customer-specific documents you will send out.

  2. Update your seed templates with white text tags, and then all of the customer-specific documents created from these will be tagged (you don’t want to tag every individual customer document).

  3. You can enable text tagging on a per doc level by specifying a value for text_tag_syntax in document objects, and your Proof solutions engineer/Proof Support can also specify it at the account-level for you. The possible values are standard and standard_hidden. standard mode indicates that you will be using white text for the tags. standard_hidden indicates you will place the tags in non-white text; this is useful if your document generation system would be able to add the text tags to documents more easily/in a more automated way if the text could be in black or other non-white font. You can enable this by specifying the standard_hidden syntax in API calls. This will cover the text tags with a white box so they will be hidden. Please contact your customer success manager or [email protected] if you need this feature enabled at the account-level.

  4. Document processing happens asynchronously. Document processing_state is accessible in the document objects returned by the transaction retrieval endpoint. The possible values are pending, done, and failed. If any errors occurred during document processing, they will be listed in the document object processing_error field. To enable text tagging for documents uploaded from within the Proof web app, you'll need the text tagging feature enabled in your Proof account, which must be done by your Proof solutions engineer. For example, if a document is uploaded via browser and a processing error is returned, this is most likely due to an incorrectly formatted text tag embedded in the document. The processing_error property will also be included on the document object when queried via API.

White Text Tag Syntax

White Text Tags take on the following standard syntax:

[type|req|user]

Examples include:

[check|req|signer1]

[date|req|witness2]

[sig|req|notary]


The syntax is supported by using both square brackets, [ ], and curly braces, { }. In other words, [sig|req|signer1] and {sig|req|signer1} will be read the same way by our system.

type

prescribes the type of designation to be placed.

TagDescriptionSignerWitnessNotary
texttext designation:white-check-mark::white-check-mark::white-check-mark:
datecurrent date designation:white-check-mark::white-check-mark::white-check-mark:
daycurrent day designation (ex: 8th):white-check-mark::white-check-mark::x:
monthcurrent month designation (ex: March):white-check-mark::white-check-mark::x:
yearcurrent year designation (ex: 2024):white-check-mark::x::x:
sigsignature designation:white-check-mark::white-check-mark::white-check-mark:
printnameprint the signer's name (not a designation, i.e. prints the name directly on the doc pre-meeting):white-check-mark::x::x:
checkcheckmark designation:white-check-mark::white-check-mark::white-check-mark:
initialinitials designation:white-check-mark::white-check-mark::x:
sealseal designation:x::x::white-check-mark:
statestate designation:x::x::white-check-mark:
countycounty designation:x::x::white-check-mark:
namename designation:x::x::white-check-mark:
expiryexpiry designation:x::x::white-check-mark:
idid designation:x::x::white-check-mark:
disclosuredisclosure designation:x::x::white-check-mark:

req

prescribes whether the designation is required (req) or optional (noreq).

ValueResult
reqrequired designation
noreqnon-required designation

user

prescribes who will fulfill the designation…a specific signer, specific witness, or the notary.

ValueResult
signerNassigned to signer N (N can be up to whatever transaction type supports)
witnessNassigned to witness N (N can only be 1 or 2)
notaryassigned to notary

Defining a Variable to Create a Short Designation

This is commonly needed for checkboxes or initials, where there is not enough space to write out a normal type|req|user white text placeholder. Concrete examples of this are shown in the Example White Text Document below.

Defining the variable:

The definition can be made anywhere in the document, and will apply to the rest of the document

[def:$variableName|type|req|user]

Then, using the defined variable:

[$variableName]


Checkbox Groups

To create a group of checkboxes and require a specified number of them to be ticked, you must first create a variable to define the properties of your checkbox group.

Defining a checkbox group variable:

Define a new variable, of type "check". Directly after the "req" parameter, define a range of boxes that are required to be ticked:

[def:$cb1|check|req1-4|signer1]

In this example, we are defining a group of checkboxes that requires no less than one, and no more than four checkboxes to be ticked.

Then, using the defined variable:

[$cb1]

[$cb1]

[$cb1]

[$cb1]

[$cb1]


The number of checkboxes in the group must not be less than the MIN defined in the range specified in the variable declaration. The number of checkboxes in the group may be greater than the MAX of the range defined in the variable declaration. A new variable must be declared for every individual checkbox group in the document.

Radio Button Groups

To create a radio button group, you can start by defining a variable for a radio button:

Defining a radio button group variable:

Define a new variable, of type "radio":

[def:$rb|radio|req|signer1]

Then, using the defined variable:

[$rb]

[$rb]

[$rb]

[$rb]

[$rb]


A new variable must be defined for every individual radio button group in the document.

Prescribing Size of Designations

The size of designations are prescribed by the space inside the square brackets of the white text placeholders. To make the designation box taller, increase font size. To make it wider, add spaces before the closing square bracket.

For Notary seals, we use the width of the brackets for both the width and the height, to create a square designation. Note: the minimum size of the Notary seals is 60x60px.

Height – is prescribed by the height of the square brackets used for white text placeholders.
Note: if the height is less than 6px, we will automatically set height to 10px. This is to handle very small text tags produced by some white text softwares.

Width – is prescribed by the width created by the two square brackets. You can add more width by adding spaces at the end of the tag: [sig|req|signer1 ] as opposed to [sig|req|signer1].

Small signature designation:

[sig|req|signer1 ]

Bigger signature designation:

[sig|req|signer1 ]

Note: while you can prescribe the size of a designation for all designation types, the resulting annotations may not conform to resizing, consistent with Proof designation behavior.

  1. Signatures and Initials – annotations will fill to the maximum size within the
    designation.
  2. Checkboxes – annotations will default to a 16px by 16px checkbox regardless of
    designation size.
  3. Text and Date - always default to 14px font size and the text can stretch beyond the dimensions of the designation.

Common Errors

Here are some common error messages you may receive when adding a white text tagged document to a Proof transaction:

  • [initial|req|notary] - the initial designation type is only available for signers and witness, not notaries. To resolve, please remove.

  • [name|req|signer2] - the name designation type is only available to notaries, not signers or witnesses. To resolve, please remove.

  • [date|req|singer3] - the user has been spelled "singer" rather than "signer". To fix, change the user to signer3, in this case.

  • [def:$text|text|req|signer1 - there is no end bracket on this tag. To resolve, please add an end bracket.

  • Text tag is too close to or overlapping with other text. This could prevent the tag from being detected as other characters could be mixed into the tag. To resolve, add a little extra space between the tag and other text.

  • If square brackets [ ] are not processing, please try using curly braces { }.


For Further Assistance

For further assistance with implementing white text syntax to your seed files and documents, please reach out to [email protected]