Message-ID: <1804107962.8823.1576284276367.JavaMail.confluence@de-030-willconf> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8822_616461148.1576284276367" ------=_Part_8822_616461148.1576284276367 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html WILL File Format

# WILL Overview

WILL data primarily represents pen strokes a= s digital ink. A pen stroke in its simplest form consists of a series of po= sitional points but to achieve a high quality digital ink experience additi= onal information is needed including stroke colour, width and appearance. T= he WILL SDK employs sophisticated techniques to record and render stroke da= ta, applying smoothing algorithms to enhance the experience.

The WILL data file is packaged using the Ope= n Packaging Convention (OPC) ISO standard. OPC describes conventions for th= e use of XML, ZIP and other openly available technologies to organize the c= ontent and resources within a package.

The data stored in a WILL file is based on t= he Scalable Vector Graphics (SVG) open standard with extensions applie= d to cater for WILL requirements. SVG is the language based on XML for desc= ribing two-dimensional vector and mixed vector/raster graphics.

The SVG data is encoded in binary form using= Google protocol buffers. The technique provides cross platform compatibili= ty with rapid encoding and decoding. Protocol buffers are Google's open sta= ndard for serializing structured data using an extensible mechanism which i= s both language and platform neutral.

# WILL File Format

The WILL file format uses an OPC formatted Z= IP archive as a container. A typical WILL file expands as follows:

=20
```Example=
.will
|
=E2=94=9C=E2=94=80 [Content_Types].xml
=E2=94=9C=E2=94=80=E2=94=80props
=E2=94=82  =E2=94=9C  app.xml
=E2=94=82  =E2=94=94  core.xml
=E2=94=9C=E2=94=80=E2=94=80sections
=E2=94=82  =E2=94=9C=E2=94=80=E2=94=80media
=E2=94=82  =E2=94=82  =E2=94=9C  image2049281480.jpeg
=E2=94=82  =E2=94=82  =E2=94=94  strokes387757975.protobuf
=E2=94=82  =E2=94=9C  section0.svg
=E2=94=82  =E2=94=94=E2=94=80=E2=94=80_rels
=E2=94=82     =E2=94=94  section0.svg.rels
=E2=94=94=E2=94=80=E2=94=80_rels
=E2=94=94  .rels```
=20
Section Description
/props/app.xml=

contains informat= ion about the application that originally created the file.

/props/core.xm= l

contains general = information and meta-data about the file.

/sections/medi= a/image.jpeg contains raste= r data that is part from the multi-media content.
= /sections/media/strokes.protobuf = contains all strokes (paths) encoded using WILL encoding scheme (based on <= /span>Google Pro= tocol Buffers).
= /sections/section.svg = contains the multi-media content encoded using SVG.

Examples of the section contents follow:

<= a class=3D"unresolved" href=3D"#">Conten= t_Types.xml

=20
```<?xml=
version=3D"1.0" encoding=3D"UTF-8"?>
<Types xmlns=3D"http://schemas.openxmlformats.org/package/2006/content-t=
ypes">
<Default Extension=3D"rels" ContentType=3D"application/vnd.openxmlform=
ats-package.relationships+xml"/>
<Default Extension=3D"svg" ContentType=3D"image/svg+xml"/>
<Default Extension=3D"jpg" ContentType=3D"image/jpeg"/>
<Default Extension=3D"jpeg" ContentType=3D"image/jpeg"/>
<Default Extension=3D"png" ContentType=3D"image/png"/>
<Default Extension=3D"protobuf" ContentType=3D"application/vnd.willfil=
eformat.path+protobuf"/>
<Override PartName=3D"/props/core.xml" ContentType=3D"application/vnd.=
openxmlformats-package.core-properties+xml"/>
<Override PartName=3D"/props/app.xml" ContentType=3D"application/vnd.w=
illfileformat.extended-properties+xml"/>
<Override PartName=3D"/style/paints.protobuf" ContentType=3D"applicati=
on/vnd.willfileformat.paint+protobuf"/>
</Types>```
=20

props/app.xml

=20
```<?xml=
version=3D"1.0" encoding=3D"UTF-8"?>
<Properties=20
xmlns=3D"http://schemas.willfileformat.org/2015/relationships/extended-=
properties">
<Application>Bamboo Spark</Application>
<AppVersion>1.0</AppVersion>
</Properties>```
=20

props/core.xml

=20
```<?xml=
version=3D"1.0" encoding=3D"UTF-8"?>
<coreProperties=20
xmlns=3D"http://schemas.openxmlformats.org/package/2006/relationships/m=
xmlns:dc=3D"http://purl.org/dc/elements/1.1/"=20
xmlns:dcterms=3D"http://purl.org/dc/terms/"=20
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance">
<dcterms:created xsi:type=3D"dcterms:W3CDTF">2016-05-12T16:46:34Z=
</dcterms:created>
<dc:title>WCM0074</dc:title>
</coreProperties>```
=20

/sections/media/image.jpeg

image data

/sections/media/strokes.protob= uf

Binary protobuf data

/sections/section.svg

=20
```<?xml=
version=3D"1.0" encoding=3D"UTF-8"?>
<svg xmlns=3D"http://www.w3.org/2000/svg" xmlns:r=3D"http://schemas.will=
fileformat.org/2015/relationships" width=3D"328.0" height=3D"439.0">
<defs>
<pattern id=3D"background" patternUnits=3D"userSpaceOnUse" width=3D"328.=
0" height=3D"439.0"><image r:id=3D"image1" x=3D"0.0" y=3D"0.0" preser=
veAspectRatio=3D"xMidYMid slice"/>=09=09=09         </pattern>
</defs>
<rect id=3D"willfileformat.background.rect" x=3D"0" y=3D"0" width=3D"328=
.0" height=3D"0.0" fill=3D"url(#background)"/><g r:id=3D"image0"/>
</svg>```
=20

_rels/rels

=20
```<?xml=
version=3D"1.0" encoding=3D"UTF-8"?>
<Relationships=20
xmlns=3D"http://schemas.openxmlformats.org/package/2006/relationships"&=
gt;
<Relationship Id=3D"core-properties" Type=3D"http://schemas.openxmlf=
props/core.xml"/>
<Relationship Id=3D"extended-properties" Type=3D"http://schemas.will=
fileformat.org/2015/relationships/extended-properties" Target=3D"/props/app=
.xml"/>
<Relationship Id=3D"section0" Type=3D"http://schemas.willfileformat.=
org/2015/relationships/section" Target=3D"/sections/section0.svg"/>
</Relationships>```
=20

# Will Data Format

## Path Model

The Path entity is the fundamental building = block in digital ink. Every stroke is represented by a Path instance. =

The conceptual model used in the WILL data f= ormat is described using an entity-relationship model:

=20 =20 =20 =20
=20 =20 =20 =20 =20 =20 =20

### Path style

• Stroke Colour - the colour used to render the stroke
• Stroke Widths - list of positive values used to calculate= the width of the stroke at different points along the path. If the list co= ntains a single value, then the path has constant stroke width. If the list= contains less values that the number of the control points used to define = the path, the last value is taken multiple time to match the number of cont= rol points.

### Path geometry

Path geometry is based on Catmull-Rom spline= s formulated such that the tangent at each point is calculated using the pr= evious and next point on the spline: • Start Parameter - Specifies the t-value of the first segm= ent from which the path should start.
• End Parameter - Specifies the t-value of the last segment= in which the path should end.

The geometry of the path is defined by a col= lection of path segments represented by Catmull-Rom curves:

A Catmull-Rom curve is represented as a coll= ection of two-dimensional positions P0, P1, P2, ... Pn , where each four points Pi-1, Pi, Pi+1, Pi+2 define one segment using C= atmull-Rom interpolation method to define the curve between Pi&n= bsp;and Pi+1. ## Path Data

### Data encoding

The technique of delta encoding is applied t= o all control point coordinates within a stroke, as well as the correspondi= ng width values for strokes with variable width. To enable further optimiza= tion, these values are represented in integer form (as fixed-point numbers)= before the delta encoding procedure.

Coordinates, width values, and other propert= ies for every stroke are encoded in a binary form using Google pro= tocol buffers. This allows rapid encoding and decoding, and the result= ing binary code is highly-portable and compact because the techniques used = for representing repeated stroke values greatly improve the efficiency of t= he varint technique used.

Values are encoded according to the followin= g schema:

``````package WacomInkFormat;

option optimize_for =3D LITE_RUNTIME;

message Path {
optional =
float startParameter =3D 1 [default =3D 0];
optional =
float endParameter =3D 2 [default =3D 1];
optional uint32 decimalPrecision =3D 3 [default =3D 2];
repeated sint32 points =3D 4 [packed =3D true];
repeated sint32 strokeWidths =3D 5 [packed =3D tr=
ue];
repeated sint32 strokeColor =3D 6 [packed =3D tru=
e];
}``````

### Data properties

Every Path message in the= schema represents a single stroke and its properties as described below:

• A value in the interval [0, 1] that specifies the exact beginning of th= e path:
``    optional float startParameter =3D 1 [default =3D 0];``
• A value in the interval [0, 1] that specifies the exact ending of the p= ath:
``    optional float endParameter =3D 2 [default =3D 1];``
• The number of digits after the radix point for values stored in data and strokeWidth properties:
``    optional uint32 decimalPrecision =3D 3 [default =3D 2];``
``` An encoded list of the x and y va= lues of all control points for a particular stroke: repeated sint32 data =3D 4 [packed =3D true]; A delta encoded list of width values for all control points for a strok= e with a variable stroke width: repeated sint32 strokeWidth =3D 5 [packed =3D true]; For a stroke of constant width, this list co= ntains a single value: A delta encoded list of color values in RGBA format:= repeated sint32 strokeColor =3D 6 [packed =3D true]; For a stroke of constant color, this list co= ntains a single value. Most commonly, any variation in stroke color is in t= he opacity (the alpha channel of the RGBA format). In ot= her words, the same RGB values apply throughout, but the=  A value changes. Data list The Path messages that de= fine all of the encoded strokes is represented as a length-delimited list a= s follows: Description Bytes sequence 128 bit varint Path 1 = ;message length Bytes Path 1 = ;message bytes 128 bit varint Path 2 = ;message length Bytes Path 2 = ;message bytes ... ... 128 bit varint Path N = ;message length Bytes Path N = ;message bytes ```
``` ------=_Part_8822_616461148.1576284276367-- ```
{"ft_lang_label":"__label__en","ft_lang_prob":0.6015109,"math_prob":0.79265666,"size":8666,"snap":"2019-51-2020-05","text_gpt3_token_len":2533,"char_repetition_ratio":0.12052644,"word_repetition_ratio":0.063541666,"special_character_ratio":0.2942534,"punctuation_ratio":0.13229814,"nsfw_num_words":0,"has_unicode_error":false,"math_prob_llama3":0.995389,"pos_list":[0,1,2,3,4,5,6],"im_url_duplicate_count":[null,1,null,2,null,2,null],"WARC_HEADER":"{\"WARC-Type\":\"response\",\"WARC-Date\":\"2019-12-14T00:44:36Z\",\"WARC-Record-ID\":\"<urn:uuid:9176b210-c26c-4d69-9272-fd9c8b776ef4>\",\"Content-Length\":\"29533\",\"Content-Type\":\"application/http; msgtype=response\",\"WARC-Warcinfo-ID\":\"<urn:uuid:c33c499b-a0cd-4f86-b413-f477c11232b8>\",\"WARC-Concurrent-To\":\"<urn:uuid:701dd630-2d5d-4908-b374-e05bef992744>\",\"WARC-IP-Address\":\"50.225.61.115\",\"WARC-Target-URI\":\"https://developer-docs.wacom.com/exportword?pageId=14680152\",\"WARC-Payload-Digest\":\"sha1:EQRMZNHXN3TWESK4PVINF5D2XRSNVQCB\",\"WARC-Block-Digest\":\"sha1:NKV6REUMO7RCMCQ2ZNHMFQAUIHUF2332\",\"WARC-Identified-Payload-Type\":\"message/rfc822\",\"warc_filename\":\"/cc_download/warc_2019/CC-MAIN-2019-51/CC-MAIN-2019-51_segments_1575540569332.20_warc_CC-MAIN-20191213230200-20191214014200-00458.warc.gz\"}"}