White Text Tags

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?

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).
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

Identify the “root” or “seed” document templates used to create the customer-specific documents you will send out.
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).
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.
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.

Tag	Description	Signer	Witness	Notary
text	text designation	✅	✅	✅
date	current date designation	✅	✅	✅
day	current day designation (ex: 8th)	✅	✅	✅
month	current month designation (ex: March)	✅	✅	✅
year	current year designation (ex: 2024)	✅	✅	✅
sig	signature designation	✅	✅	✅
printname	Prints the user's name if known pre-meeting. For witnesses, creates a designation.	✅	✅	❌
check	checkmark designation	✅	✅	✅
initial	initials designation	✅	✅	❌
seal	seal designation	❌	❌	✅
state	state designation	❌	❌	✅
county	county designation	❌	❌	✅
name	name designation	❌	❌	✅
expiry	expiry designation	❌	❌	✅
id	id designation	❌	❌	✅
disclosure	disclosure designation	❌	❌	✅

req

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

Value	Result
req	required designation
noreq	non-required designation

user

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

Value	Result
signerN	assigned to signer N (N can be up to whatever transaction type supports)
witnessN	assigned to witness N (N can only be 1 or 2)
notary	assigned 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]

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]

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.

Signatures and Initials – annotations will fill to the maximum size within the
designation.
Checkboxes – annotations will default to a 16px by 16px checkbox regardless of
designation size.
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.
multilineerror: We validate WTT to ensure the overlaid tags do not span more than a single line. This can also be caused by intentionally or unintentionally rotating the placement of the embedded WTT. When inspecting tags in a PDF editor, tags should be set with 0 degrees of rotation. Proof validates that the y coordinate of the first character of the tag is no more than 0.1 points from the y coordinate or the last character of the tag. A multiline error will be thrown if the tag is rotated.
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]