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?
- 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
indocument
objects, and your Proof solutions engineer/Proof Support can also specify it at the account-level for you. The possible values arestandard
andstandard_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 thestandard_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 arepending
,done
, andfailed
. If any errors occurred during document processing, they will be listed in the document objectprocessing_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. Theprocessing_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]
[$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.
- 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.
-
multiline
error: 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]
Updated 24 days ago