General
Where is the Signature SDK sample code
Signature SDK sample code is available on GitHub:
https://github.com/Wacom-Developer/sdk-for-signature-windows
Similary SigCaptX:
https://github.com/Wacom-Developer/sdk-for-signature-sigcaptx-windows
Handling PDF documents
The Signature SDK does not contain any functionality for interfacing with PDF documents - you would need to use a third-party library for this such as PDFNet or PDFium.
For further information please see also Save Signatures to a PDF file
Ensuring signature integrity
The Signature SDK has four built-in methods which help to ensure signature integrity as listed below.
The signature data includes the context of the signature i.e. the "who", "when" and "why" data. It can also contain other identifying information such as details of the driver, operating system and digitizer pad.
The biometric information of the signature can be steganographically encoded within the image data - a proprietary format is used for this which is not disclosed, even to the programmer.
It can only be analysed by using one of our signature analysis tools - this is a deliberate design feature to minimise the possibility of forgery.
It is possible to calculate a hash value from the document being signed and incorporate it into the signature data.
When the document is later revisited the hash value can be extracted from the embedded signature(s) and compared against the current hash value of the document.
If they are not the same then the signature is deemed invalid because either it or the document or both have changed.
There is an option to embed multiple pairs of key values within the signature data after it has been captured. This protects the integrity of the data and provides a means of detecting any changes made within it.
NOTE
The Signature SDK does not provide any means of checking a document for integrity other by generating a hash or key value which is stored in the signature itself.
If there is a requirement to add document integrity checking which is independent of the signature data an alternative mechanism must be used for doing so, e.g. an appropriate third-party library.
Support for Web browsers
The SDK can be used with Internet Explorer directly through the use of ActiveX or with Firefox and Chrome web browsers through the use of a java applet.
In order to support a greater number of browsers directly (i.e. without using an applet) we have developed a sister product called SigCaptX which is based on JSONP.
The installer for SigCaptX is provided in the Signature SDK download file.
SigCaptX works on at least Windows 7, 8, and 10, and Internet Explorer 9 to 11, EDGE, Firefox 2.0 or higher and Chrome 2.0 or higher.
Operating system support
The Signature SDK is available for Windows 7 SP1 and above.
Fully compatible versions of the Signature SDK are also available for iOS and Android.
All three SDKs are available for download under "For signature" at:
https://developer.wacom.com/en-us/developer-dashboard/downloads
Supported input devices
The Signature SDK is available for Windows, Android and iOS platforms. The requirements and devices supported (at time of writing - August 2019) are listed below.
Please note that this list is not exhaustive as new devices are being added all the time and also some older ones are going out of production.
Windows 7 SP1 or higher
Wacom Proprietary Equipment:
- Any Wacom interface device with pen input(except the Cintiq Companion Hybrid and Bamboo pad) - this includes all STU signature pads and the DTU interactive displays.
- Please note that the standard Cintiq Companion is supported, but not the Companion Hybrid.
- Wacom FT203 (Pen Partner)
Equipment from other manufacturers, subject to availability:
This list is not exhaustive and is likely to expand continually over time.
- ASUS Eee Slate B121
- ASUS Vivo Tab TF810C
- ASUS VivoTab Note 8 (excluding ASUS VivoTab RT, ASUS VivoTab Smart)
- Dell Latitude 10 tablet (excluding Dell Latitude 10 essentials)
- Eee Slate EP121 B12
- Fujitsu ARROWS Tab Q548H, QH55M, Q704H and QH77M
- Fujitsu LIFEBOOK T731D, T732, T901D, T904 H, TH90 P and T902 F
- HP Elite x2
- Interlink ePad
- Lenovo ThinkPad Helix (type 3xxx)
- Lenovo ThinkPad Tablet 2 and X220 Tablet
- Microsoft Surface Pro 1 and 2 (but not the Surface Pro 3 or 4)
- Panasonic Toughbook CF-19, CF-C1, CF-H1 and CF-H2
- Samsung ATIV smart PC
- Samsung ATIV Tab 3, 5 and 7
- Toshiba Dynabook Tab
- Toshiba WT310
iOS SDK
- iPad with Retina Display (introduced 2012) or subsequent tablets
- Wacom Bluetooth LE styli using Bluetooth 4.0 LE - currently Intuos Creative Stylus (CS-500), Intuos Creative Stylus 2 (CS-600), Bamboo Stylus fineline (CS-600C) and Fineline 2
- Non-Wacom styli: Apple Pencil and Pencil 2 (license fee payable)
- iOS 6.1 or higher, Xcode 5.1.1 or higher
Android SDK
- Android 4.1.2 or higher
- Wacom Cintiq Companion Hybrid
- Samsung Galaxy Note phone/tablet with Samsung S pen, e.g.* Note
- Note 2
- Note 3
- Note 8.0
- Note 10.1
- Note 10.1 2014 Edition
- Note Pro 12.2
- Samsung Galaxy Tab S3 9,7’
- Samsung Galaxy Tab S4
- Samsung Galaxy Tab A
- Huawei Media Pad M5 Pro
- Huawei Media Pad M5 Lite
- In theory any Android device with a built-in stylus which supports pressure, though we have only tested the Samsung Note series as listed above
Signature devices supported on Citrix
Please see below a list of Wacom pen input products which have been certified as compatible with Citrix as at July 10th 2019.
Check https://citrixready.citrix.com/category-results.html?search=wacom for the latest information.
Technical fact sheets for Wacom signature devices
At http://signature.wacom.eu/products/ there is a list of product categories on the right-hand side.
First select a category and then click on a product - the fact-sheets are available for download in PDF format.
In addition, the CE certificates for all the products are available at https://www.wacom.com/en-us/support/product-support/drivers.
What determines whether encryption is used with the Signature SDK and can I turn it off?
The use of encryption by the Signature SDK depends on whether encryption is enabled on the signature pad.
With the STU pads you can run Identify.exe (one of our STU Utilities) to determine whether or not encryption is enabled. When the signature capture window appears a padlock icon indicates whether encryption is being used.
It is not possible to disable encryption programmatically on a pad which is already enabled for it.
DTUs use encryption all the time because that is what Wintab does - the Signature SDK has no control over this.
How do I change the format of the date of signing in the signature capture window?
The format of the date and time within the Signature capture window is dependent upon the Windows setting (in Control Panel) and cannot be overridden programmatically.
Alignment of the "who", "why" and "when" text in the capture window
It is not possible to alter the alignment of the who, why and when values on the signature capture window.
The ShowWho, ShowWhy and ShowWhen properties given in the reference manual relate to post-capture display in the control on the form in Windows and not the capture window itself.
The positioning of text in the capture window is fixed - one of the main reasons for this is to deliver consistency across all capture devices.
Bitmap dimensions for RenderBitmap when saving a signature to file
If you want to output the signature image only (i.e. without the biometric data) then the bitmap dimensions can be as small or as large as is practical for your purposes.
If you make the image too small the signature will not be legible. If you make it too large the inking may look rough at the edges.
If you want to include the biometric information in the signature image file (using the RenderEncodeData flag of RenderBitmap) then you need to ensure that the dimensions are large enough.
Typically a bitmap size of 150 x 100 should give you plenty of space to encode the average signature and the size of the output file should be less than 3Kb.
The minimum number of pixels required to encode a signature is: 2 * (12 + number of bytes).
The number of bytes varies, depending on the device. Generally, there are 4 bytes each for each of:
- stroke Id
- x coordinate
- y coordinate
- up/down status
In addition:
- if the device provides timing information, there will be 4 bytes for time
- if the device provides pressure, there will be 4 bytes for pressure
Given a device with a constant reporting rate (the current STU pads all generate 200 pen points per second), and knowing the number of bytes of pen data per point,
it would be possible to make a rough estimate of the number of bytes of biometric data per second of signing. The pen data invariably makes up the bulk of the signature data
but there are other factors involved and there is a certain amount of compression within the stream store which will reduce the number of bytes to be encoded.
In the example below taken from our standard CaptureImage.js the bitmap is 300 x 150 = 45,000 pixels and this should be more than ample for encoding most signatures.
filename = "sig.png";
flags = 0x1000 | 0x80000 | 0x400000; //SigObj.outputFilename | SigObj.color32BPP | SigObj.encodeData
rc = sigCtl.Signature.RenderBitmap(filename, 300, 150, "image/png", 0.5, 0xff0000, 0xffffff, 0.0, 0.0, flags );
The amount of biometric data within a signature can however vary substantially depending on the length of the signature (amount of inking) and its speed of execution.
If the same signature is written more slowly it will generate more data because the pen still outputs the same number of points per second (200 on an STU tablet), regardless of how fast the signature is written.
If you are using an eSeal then a much larger bitmap is required because the eSeal image is encoded along with the signature data.
The bitmap therefore needs to be big enough for the eSeal image and the signature data together.
Here is some guidance on calculating an adequate image size (pixel dimensions) when using an eSeal.
Assumptions made for these calculations are:
- You want to render 32-bit pixel colour (using the RenderColor32BPP flag)
- The signature data itself requires 15,000 pixels (this is a fairly high estimate)
- Roughly 2 pixels are required to encode one byte of your eSeal image (this is an approximate guideline)
Here are two examples:
| eSeal size in pixels | Bytes needed per pixel | Bytes needed to encode eSeal | Pixels needed to encode eSeal | Pixels needed for signature | Total pixels needed |
|---|---|---|---|---|---|
| 400x240 | 4 (i.e. 32 bits) | 400 * 240 * 4 = 384,000 | 384,000 / 2 = 192,000 | 15,000 | 192,000 + 15,000 = 207,000 |
| 684x432 | 4 (i.e. 32 bits) | 684 * 432 * 4 = 1,181,952 | 1,181,952 / 2 = 590,976 | 15,000 | 590,976 + 15,000 = 605,976 |
Using a JPG or compressed PNG or a smaller bit depth should substantially help at reducing the size requirement for the output image.
Alternatively you can increase the size (number of pixels) of the requested bitmap to provide more space to encode within it.
Can I imprint information such as the signer name, reason, date and time on the signature image?
There is no inbuilt function within our SDKs to achieve this.
If you are using the Signature SDK you can load the bitmap for the signature image into an image manipulation application of your choice and stamp the extra information on it yourself.
Please note that you should not attempt to do this if you are using the "RenderEncodeData" flag with RenderBitmap() to encode the signature data (i.e. the biometric information) within the signature image.
The embedding of any additional data within the image could compromise the encoded biometric data.
Can I make a signature image transparent?
To make a signature image transparent use the 32 bit image option in order to support the alpha channel required for transparency. For example:
sigObj.RenderBitmap(filename, 300, 150, "image/png", 0.5f, 0xff0000, 0xffffff, 0,0,
RBFlags.RenderOutputFilename | RBFlags.RenderColor32BPP |
RBFlags.RenderBackgroundTransparent | RBFlags.RenderEncodeData);
or in javascript:
flags = 0x1000+0x080000+0x010000+0x400000; //RBFlags.RenderOutputFilename | RBFlags.RenderColor32BPP | RBFlags.RenderBackgroundTransparent| RBFlags.RenderEncodeData);
rc = sigCtl.Signature.RenderBitmap(filename, 300, 150, "image/png", 0.5, 0xff0000, 0xffffff, 0.0, 0.0, flags );
Location and names of the Signature SDK DLLs
The DLLs for the Signature SDK are installed in one of the following directories:
- C:\Program Files\Common Files\WacomGSS (for the 64-bit components)
- C:\Program Files (x86)\Common Files\WacomGSS (for the 32-bit components)
The names of the DLLs are as follows:
- FlSigCapt.dll
- FlSigCOM.dll
- FlWizCOM.dll
There are also interop files for use with .NET applications as follows:
- Florentis.InteropAxFlSigCOM.dll
- Florentis.InteropAxFlWizCOM.dll
- Florentis.InteropFlSigCapt.dll
- Florentis.InteropFlSigCOM.dll
- Florentis.InteropFlWizCOM.dll
If the above files are missing please re-install the SDK, either from the download site or from the MSI which you downloaded last time.
When prompted in the installation wizard make sure that you select the .NET components for installation.
The example screenshot below shows the 32-bit .NET components being installed for a 64-bit SDK.
Location of jar files
The jar file and associated DLL needed for running Java with the Signature SDK are installed in one of the following directories:
- C:\Program Files\Common Files\WacomGSS (for the 64-bit SDK)
- C:\Program Files (x86)\Common Files\WacomGSS (for the 32-bit SDK)
The names of the two files are as follows:
- flsx.dll
- flsx.jar
If the above files are missing please re-install the SDK, either from the download site or from the MSI which you downloaded last time.
When prompted in the installation wizard make sure that you select the Java components for installation.
The example screenshot below shows the 32-bit Java components being installed for a 64-bit SDK.
--
Save signature image to file from HTML
Please note that you cannot create a file from HTML/Javascript in Internet Explorer because of the rules of safe scripting.
Solutions are as follows:
STU SDK
Download the additional HTML samples from GitHub.
Amongst these there is an HTML sample called demobuttons-save which illustrates how to save a signature to a canvas - in particular please see the function generateImage().
Once the signature is on a canvas it can then be extracted in JPEG or PNG format using toDataURL.
You can then create a Base64 encoded string representing the image which can be submitted to the server and converted to an image file.
Signature SDK
To create a file outside IE see CaptureImage.js in the Signature SDK Samples - Jscript folder.
Alternatively in IE you can use RenderBitmap to create a Base64 string representing the image file. This can be submitted to the server where it can be converted to a file.
The Signature SDK samples can be downloaded from GitHub.
HTML signature application will not work with Chrome, Edge or Firefox
Our Signature and STU SDKs make use of ActiveX objects and the only Web browser which is still compatible with ActiveX is Internet Explorer.
Currently our Signature SDK HTML samples only work with IE. Alternatively you can either write a Java applet or use our SigCaptX cross-browser which is compatible with IE, Edge, Chrome and Firefox.
If you need to support Chrome and Firefox with our STU SDK we would recommend using our STU SigCaptX cross-browser component.
Please note that Safari is not currently supported.
Save signatures to a PDF file
There are four options which we would recommend, depending on the business process which you need to implement:
sign pro PDF: this provides a ready-made user interface for editing PDF files allowing you to add signatures as well as sticky notes and free-form drawing
sign pro PDF API: this enables you to automate certain aspects of the signature placement when using sign pro PDF. Instead of the user placing the signature themselves you can predefine where the signature area will appear. Please note that this product is chargeable. For pricing information please contact your regional Wacom Business Development Manager. If you don't know who this is please email solutions@wacom.eu.
Signature SDK: use the SDK to capture the signature(s) and then use a third-party library (examples below) to embed the signature(s) in your PDF file.
The Signature SDK works with a wide range of Wacom input devices and captures signatures in a format which is compatible with sign pro PDF and our signature analysis products.
Here is a list of some PDF libraries which we have used. Please note that this is for information only - it is not an exhaustive list of all those that are available and we cannot provide any support or guarantees for third-party products.
| NAME OF LIBRARY | DOWNLOAD LINK |
|---|---|
| Foxit | https://developers.foxitsoftware.com/pdf-sdk/Windows/ |
| PDFNet | https://www.pdftron.com/pdfnet/ |
| Debenu | https://www.debenu.com/products/development/debenu-pdf-library/windows-pdf-sdk/ |
| iText | https://itextpdf.com/en |
| PDFium | https://opensource.google.com/projects/pdfium |
- STU SDK: Use the SDK to capture the signatures and then use a third-party library (examples above) to embed the signature(s) in your PDF file.
This has the advantage that you can specify your own image format but it limits you to our STU range of signature pads and requires more development effort.
Please note that signatures captured by this means would not be compatible with our analysis tools.
Installation log file location
Installation log files are created in %TEMP%.
Assuming a Windows login ID of "jsmith" this should equate to: C:\Users\jsmith\AppData\Local\Temp
Customising the signature capture window
There are several cosmetic changes which can be made to the standard signature capture window using registry values.
These are documented in section 7 of the Signature SDK reference manual which is supplied with the SDK download.
Below is a summary of the main ones.
BtnsInside
This registry value displays the buttons outside the Windows capture dialog and removes them from the pad display. It only works with STU devices.
Implementing it means that the pen cannot be used to click any buttons - this must be done by the PC operator with the mouse.
The screenshot below shows the capture window as it appears on the PC monitor with the buttons at the bottom.
The display on the STU does not show the buttons at all.
CaptureExtentX, CaptureExtentY
These registry values can be used to set the width and height of the capture area in pixels. The capture area does not include the buttons.
If used with an STU the capture window on the STU is unaffected - the sizing is only applied to the capture window on the PC monitor.
InsideFontFaceName, InsideFontHeight
Name and point size of font to use for text within the capture area (i.e. the who, why and when values)
OutsideFontFaceName, OutsideFontHeight
Name and point size of font to use for text outside the capture area (i.e. on the buttons)
The example below shows the effect of using the following values with an STU 530:
InsideFontFaceName - Broadway
InsideFontHeight - 16
OutsideFontFaceName - Stencil
OutsideFontHeight - 20
SignatureGuideType
This determines what type of graphic is used to indicate where the signature is to be placed. The options are:
| Value | Effect |
|---|---|
| 0 | Horizontal line (the default behaviour as illustrated in screenshot above) |
| 1,2 | Box corners (for more details please see the reference manual) |
| 3 | None |
| 4 | Buttons on the right (as is the default behaviour for the STU 300) |
language
Normally the language used on the signature capture window (mainly on the buttons) is determined by the current system language, or the language of the current application if that is different.
The "language" registry key allows you to override the above default behaviour. The abbreviations are as follows (see also http://www.lingoes.net/en/translator/langcode.htm):
de = German el = Greek en = English es = Spanish fr = French it = Italian ja = Japanese ko = Korean nl = Dutch pl = Polish
pt-BR = Portuguese (Brazil) ru = Russian zh-CN = simplified Chinese zh-TW = traditional Chinese
The registry key should be placed in HKLM\SOFTWARE(Wow6432Node)\Florentis\SigCapt rather than HKLM\SOFTWARE(Wow6432Node)\Florentis\sd as with all the other registry keys shown above.
It should be entered in duplicate, separated by semi-colon or comma, e.g. en; en. See the screenshot below for simplified Chinese.
Please note also that you will probably need to restart your browser for the language setting to take effect - this is not the case with the other registry settings mentioned above.
How do I change font width and colour?
First of all please make sure that you are using a signature device which supports colour if you want to set it.
For example, the STU-500 and STU-430 are monochrome pads and do not support colour.
There are four places where colour and ink width can be defined:
- In the images (text and buttons etc.) which are displayed on the signature pad
- In the inking which is produced on the pad itself when it is signed with the pen
- On the form (e.g. the HTML canvas or Windows image) in the application where the signature is rendered after being captured
- In the image which is generated and saved to disk
Images displayed on the signature device
1) Business Solution Displays such as DTH-1152, DTU-1141B
These pen input devices do not support the wizard control so the setting of font colour and width is limited to the inking on the signature capture window as the pen is writing.
This is done via the sigCtl properties or registry entries CaptureInkWidth and CaptureInkColor.
For further information please see below in the section on "Inking on the pad while signing is in progress".
2) STU pads
- Using the wizard control (WizCtl):
a) Image upload: In this situation the pad will simply render the image as it receives it from the operating system. If font colours or size need to be changed this must be done by editing the original image on disk.
b) Adding objects such as buttons, text, radio or check boxes: colour and font size is controlled by setting the font size and colour as required in the code before adding the objects to the WizCtl.
- Using the signature control (SigCtl):
In the case of the SigCtl (dynamic capture) customisations to the signature capture display on the pad are only possible via registry entries as described in section 7 of the reference manual.
Please see also the screenshot in the following section below.
Inking on the pad while signing is in progress
This can be controlled by means of two properties - CaptureInkWidth and CaptureInkColor as specified in the API reference manual. Here is an example for HTML:
var dc = new ActiveXObject("Florentis.DynamicCapture");
dc.SetProperty("CaptureInkWidth", "5");
dc.SetProperty("CaptureInkColor", "0,0,1");
var rc = dc.Capture(sigCtl, "who", "why");
These properties can also be set in the registry - the disadvantage of this is that they then become permanent values for the current user until they are changed or disabled.
They can however be overridden by setting the corresponding properties in the application as illustrated above.
The registry settings must be placed in HKEY_LOCAL_MACHINE\Software\Florentis\sd or HKEY_LOCAL_MACHINE\Software\WOW6432Node\Florentis\sd if using a 32-bit SDK installation on a 64-bit operating system.
Here is an example of how the registry settings would look in regedit:
The signature as rendered in the application after capture
The ink width and colour of the signature can be set from the application via the InkColor and InkWidth properties of the sigCtl object as defined in the API reference manual.
The colour and font used for other features of the image of the captured signature such as the who, why and why values and the colour of the signature line can be controlled using ForeColor and BackColor properties of the same sigCtl.
Please note that the BackColor property of the SigCtl only has an effect if the BackStyle is set to 0.
Here is an example of JavaScript extracted from an HTML form showing all the types of font width and colour listed above:
var sigCtl = document.getElementById("sigCtl1");
sigCtl.Licence = "AgAkAEy2cKydAQVXYWNvbQ1TaWduYXR1cmUgU0RLAgKBAgJkAACIAwEDZQA";
// Set the ink colour and width displayed on the signature control on the HTML form.
sigCtl.InkColor = 0x0000AA;
sigCtl.InkWidth = 1;
sigCtl.BackStyle = 0; // Force the background style to 0 for opaque so that background colour can also be set on the control.
// The next 3 properties indicate that the who, when and why values should be displayed on the signature control along with the signature
sigCtl.ShowWhen = ShowText.TxtShowLeft;
sigCtl.ShowWho = ShowText.TxtShowRight;
sigCtl.ShowWhy = ShowText.TxtShowCenter;
// BackColor and ForeColor set the background colour of the signature control plus the colour of the signature line
// and the who, when and why text (but not the signature itself)
sigCtl.BackColor = 0x00FF00;
sigCtl.ForeColor = 0x0000FF;
var dc = new ActiveXObject("Florentis.DynamicCapture");
// CaptureInkWidth sets the width of the inking on the capture window which appears on the PC monitor but not the width of ink on the signature capture device itself
dc.SetProperty("CaptureInkWidth", "2");
dc.SetProperty("CaptureInkColor", "0,1,0"); // Sets the colour of the ink on the PC monitor as well as on the capture device
var rc = dc.Capture(sigCtl, "who", "why");
The image which is saved to disk
Signature images are saved to disk using the API method RenderBitmap().
This has three parameters relating to the signature inking - inkWidth, inkColor and backgroundColor - as specified in the API reference manual.
inkWidth - a value in millimetres.
inkColor - a value in OLE_COLOR format e.g. 0x0000FF is red and 0xFFFFFF is white
backgroundColor - as above
Here is an example from one of our JavaScript samples:
rc = sigCtl.Signature.RenderBitmap(filename, 300, 150, "image/png", 0.5, 0xff0000, 0xffffff, 0.0, 0.0, flags );
What development languages are compatible with the Wacom Signature SDK?
In order to benefit from full support we recommend using one of the development languages for which we already provide sample code on GitHub:
- C++
- Delphi
- HTML
- JavaScript
- Java
- C#
- VB.NET
If you wish to use another development language please note that the functionality of the Signature SDK is delivered via ActiveX DLLs, therefore in theory any language which can interface with ActiveX should be able to interact with the Signature SDK.
In terms of Web development our Signature SDK comes with a cross-browser component called SigCaptX which enables compatibility with browsers that don't support ActiveX, e.g. Edge, Firefox and Chrome.