This document
describes changes to an updated Webplugin that includes the same pen properties
supported in the older 1.0.x.x version of the Webplugin.Applications may continue to use those
plugins for the present, but it is strongly encouraged that applications update
to the Webplugin described in this document.See section 2.6for details.At some point, support for the older 1.0.x.x
plugins will be discontinued.

The
Wacom Tablet Plugin (Webplugin) is a browser extension that provides supports
for obtaining certain tablet properties, which can be used in web
applications. The plugin works in conjunction with an installed Wacom
tablet driver service to provide pen data such as pressure and pen position
(see section 2) and touch data such as number of fingers touching tablet
and finger data (see section 3).

For example, a web drawing application (such as the one
provided in the 'Scribble' example) can be created that uses tablet pen
pressure and position properties to allow the user to do free-form drawing on a
web page.

This document provides a summary of the plugin API, with
an explanation of how the plugin can be installed and used on either Windows or
Mac OSX systems.

Note that Firefox,
Safari, Chrome and Opera are what’s known as “Netscape” browsers.Use of the Webplugin for these browsers
requires a different API than for Internet Explorer, which uses the “ActiveX”
API.The Webplugin described in this
document supports both API types in the same plugin component.

The Webplugin is supported on these browsers
and operating systems:

Windows
7, Vista, XP

Mac
OSX 10.6, 10.7, 10.8

Firefox

yes

yes

Safari

yes

yes

Chrome

Yes

yes

Internet
Explorer

Yes

n/a

In general, unless specified otherwise, the webplugin will
support the current and previous versions of each browser.

There is one plugin module that supports plugin operation for both Internet
Explorer (IE) and Netscape-plugin (NP) browsers.

When a
user installs the Wacom tablet driver software, all of the necessary Webplugin
components (both 32bit and 64bit versions) are installed on the system, and the
user can immediately create javascript applications that can use Webplugin
properties to get pen and touch data (on supported tablets).See programming examples at http://wacomeng.com/web/index.html.

The Webplugin can be identified in an HTML web app by its mime-type.Here are the mime-types for the older and newer Webplugins:

Version 1.0.x.x Webplugin uses type="application/x-wacom-tablet"

Version 2.0.0.x Webplugin uses type="application/x-wacomtabletplugin"

The IE browser uses the ActiveX API and identifies the Webplugin by a CLASSID (GUID).Here are the older and newer Webplugin GUIDs:

The Wacom Webplugin
pen API (WebPAPI) is a browser plugin interface for pen data access from all
Wacom consumer and professional tablets. The WebPAPI is included in the
Webplugin component that also includes the Wacom Webplugin touch API
(WebTAPI).

WebPAPI can be used by web developers who
want access to Wacom tablet pen data for development of applications that use
pen data.Highlights of WebPAPI include
data reports of:

The necessary
developer components to use WebPAPI are installed with the tablet driver (see Error!
Reference source not found.Error!
Reference source not found. for supported driver versions and tablets);
there are no additional "SDKs"or modules to add to immediately begin programming web applications to
WebPAPI.

The diagram in Figure 1 shows an overview of where the WebPAPI fits into the system
architecture.For simplicity, the plugin
is shown as being within the process space of the browser.In actuality, most browsers have gone to an
"out-of-process" model , in which the plugin instance is launched in
its own process.

The WebPAPI is
accessed from the Webplugin component, which is installed on the user's system
with the tablet driver installation.The
Webplugin caches pen data as it is produced by the user drawing the pen across
the tablet.When a javascript app wants
to read the latest pen data, it simply makes one of the WebPAPI property calls
(see Properties list below).A standard
way to sync up the user’s pen movement with pen data is for the javascript app
to read pen data on system mouse events (see examples below).

All versions
of the plugin expose the same properties. Note, however, that only the
professional Wacom tablets (Intuos, Cintiq) support all properties.
Unsupported properties return a zero value.The following table describes the supported properties:

A javascript
application using the WebPAPI should adopt a mouse event-driven model, in which
the app would query for pen properties upon mouse down, mouse drag and mouse up
events.For example, to get pressure and
pen X and Y position, the following javascript can be used:

The Wacom Webplugin touch API (WebTAPI) is a browser plugin
interface for touch data access from certain Wacom tablets. The WebTAPI is
included in the Webplugin component that also includes the Wacom Webplugin pen
API (WebPAPI).

WebTAPI can
be used by web developers who want access to Wacom raw touch tablet data for
development of touch applications.Note
that WebTAPI gives the developer freedom to use finger data to control web
applications or to define custom gestures for his application.Highlights of WebTAPI include reports of:

The necessary developer components to use WebTAPI are
installed with the tablet driver (see Error! Reference source not found.Error! Reference source not found. for supported driver versions
and tablets); there are no additional "SDKs"or modules to add to immediately begin
programming web applications to WebTAPI.

The diagram in Figure 2
shows an overview of where the WebTAPI fits into the system architecture.For simplicity, the plugin is shown as being
within the process space of the browser.In actuality, most browsers have gone to an "out-of-process"
model , in which the plugin instance is launched in its own process.

The WebTAPI is accessed from the Webplugin component, which
is installed on the user's system with the tablet driver installation.The Webplugin app registers to receive
notification when touch devices are attached and detached from the system, as
well as notifications of when data becomes available (when the user touches the
tablet).When the app receives attach
and detach events, it can query for the current list of devices, select one,
and query for that device's touch device capabilities (eg: how many fingers
supported, tablet dimensions, etc.).Upon receipt of a touch data notification, the app can query WebTAPI for
touch data.

Note that the web app, through use of the Open.PassThru
argument(see section 3.5.5),
can decide whether to consume the data or just observe it and allow it be
passed to other processes on the system.For example, the web app could implement a "scribble" app to
draw touch data, and allow the data to be passed on to the system to move the
system cursor.

A javascript
application using the WebTAPI should adopt an event-driven model, waiting for
notification from the Webplugin on touch device attach, detach and data
events.In pseudo-code, such an
application would be structured similar to the following:

Register
for attach events

Register
for detach events

On
Attach event:

Read
the current list of attached touch devices

Open
a device to receive touch data from

Register
to receive touch data from that device

On
Raw Finger Data event:

Read
the touch data

Use
the data in the app

On
Detach event:

Get
current list of attached touch devices

If
device in use has gone away, close that device

See the examples in the properties
below for actual javascript examples.Complete examples can be found on http://wacomeng.com/web/index.html

For now, the only deviceID
accepted will be -1 or a deviceID returned from TouchDeviceCapabilities, which will mean to return data from the
first touch device found, or the data for that specified device
respectively.If a deviceID other than a valid ID is used, then the Status flag in the
returned FB::VariantMap will indicate an error.

If it is supported in
Firebreath, the size of the returned FB::VariantMap will depend on the number of
fingers in the most recent touch data packet.If dynamic FB::VariantMap is not supported, then the plugin will
pre-allocate a map for 10 fingers, and fill in the number of fingers of data
from the latest touch API data packet.

Status indicates whether the FB::Variant returned contains valid
data.If data is valid then, Status will be zero.If data is not valid, then Status will be the value -1.

PosX and PosY will be
logical units in the range of 0 to 1.0 for opaque tablets.

PosX and PosY will be
pixel screen coordinates in the virtual desktop range for integrated tablets.

FingerState =0 (FingerStateNone),finger's state is unknown

1 (FingerStateDown),finger's state is touching the tablet

2 (FingerStateHold),
finger's state is remaining on tablet
(after Down)

3 (FingerStateUp)
finger's state has left tablet
(after Hold)

Note that
there is no Move state.The Hold state
can be interpreted as a move if the finger position changes.

This is a method that will attach to the specified device
and initialize the touch API for the client so that data from that device will
be sent to the client. The client can elect to connect so that touch data is
NOT passed to the system, or can connect so that touch data is passed to him
(the client) as well as being sent to the system.

This method allows the plugin to be set for different
conditions. The conditions supported at this time are:

1.CHILD_BIT:
Telling the API that the plugin will be run in a browser child process or in
the browser main thread. Using this setting, the API is told that the plugin is
configured to work in a browser that launches plugins either in a child
process, or launches plugins in the main thread. Currently, most browsers
(Internet Explorer, Firefox, Chrome, etc.) launch plugins in a separate
process. This guards against a failing plugin crashing the whole browser.
Although the plugin API assumes that it will be run in a child process by
default, there is a way to switch off that behavior and have the plugin API
assume the webplugin will be run in the main thread.

2.OBSERVER_BIT:
Setting the plugin to run as a touch consumer or touch observer. Using this
setting, the plugin is configured to run in observer or consumer mode. In
observer mode, the plugin processes touch data, and then passes the touch data
on to the system, where it can be used by other applications or by the system
to execute gestures or cursor navigation. In consumer mode, the plugin
processes touch data, but does not let it be passed to the system.

3.5.7.1Params:

modeInt// A bitwise-OR of conditions:

//
CHILD_BIT: 0x00000001 -> plugin assumed to be in a
child browser process