Based
on
experience
with
WOFF
1.0,
which
is
widely
deployed,
this
specification
was
developed
to
provide
improved
compression
and
thus
lower
use
of
network
bandwidth,
while
still
allowing
fast
decompression
even
on
mobile
devices.
This
is
achieved
by
combining
a
content-aware
preprocessing
step
and
improved
entropy
coding,
compared
to
the
Flate
compression
used
in
WOFF
1.0.
Status
of
this
document
This
Document
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
http://www.w3.org/TR/.
Supporting
material,
including
results
of
compression
measurements,
may
be
found
in
the
companion
WOFF
2.0
Evaluation
Report
.
The
Working
Group
has
created
tests
for
WOFF2
encoders
,
decoders
,
browsers
,
and
for
the
format
itself
(a
WOFF2
validator).
The
source
to
build
these
tests
is
available
on
GitHub
.
The
WebFonts
Group
expects
to
request
that
the
Director
advance
this
document
to
Proposed
Recommendation
once
the
Working
Group
has
demonstrated
two
implementations
passing
each
test
in
the
encoder,
decoder,
and
browser
categories.
This
document
is
intended
to
become
a
W3C
Recommendation
on
or
after
15
June
2016.
The
Working
Group
expects
to
update
the
preliminary
implementation
report
over
the
course
of
the
implementation
period.
The
Working
Group
does
not
plan
to
request
to
advance
to
Proposed
Recommendation
prior
to
15
June
2016,
in
order
to
ensure
the
opportunity
for
wide
review.
Publication
as
a
Working
Draft
Candidate
Recommendation
does
not
imply
endorsement
by
the
W3C
Membership.
This
is
a
draft
document
and
may
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
It
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
This
document
specifies
the
WOFF2
font
packaging
format.
This
format
was
designed
to
provide
a
reasonably
easy-to-implement
compression
of
font
data
with
significantly
better
compression
than
previous
techniques,
suitable
for
use
with
CSS
@font-face
rules.
The
improvement
in
compression
rates,
compared
to
previously
developed
WOFF
1.0
format
[
WOFF1
]
are
realized
due
to
improved
entropy
coding
and
font
data
preprocessing
and
optimization
step
that
reduces
built-in
redundancy
of
various
font
data
structures.
The
details
about
WOFF
2.0
development
history
can
be
found
in
the
WOFF
2.0
Evaluation
Report
[
WOFF2ER
].
1.1
Notational
Conventions
The
all-uppercase
key
words
"MUST",
"MUST
NOT",
"REQUIRED",
"SHALL",
"SHALL
NOT",
"SHOULD",
"SHOULD
NOT",
"RECOMMENDED",
"MAY",
and
"OPTIONAL"
in
this
document
are
to
be
interpreted
as
described
in
RFC
2119
[
RFC2119
].
If
these
words
occur
in
lower-
or
mixed
case,
they
should
be
interpreted
in
accordance
with
their
normal
English
meaning.
This
document
includes
sections
of
text
that
are
called
out
as
"Notes"
and
set
off
from
the
main
text
of
the
specification.
These
notes
are
intended
as
informative
explanations
or
clarifications,
to
serve
as
hints
or
guides
to
implementers
and
users,
but
are
not
part
of
the
normative
text.
This
document
also
uses
hexadecimal
numerical
notation
"0x..."
to
define
the
constant
binary
values
such
as
magic
number
or
tag
values,
bitfields
/
flags
format
and
mask
values
used
in
pseudo-code
bitwise
operators.
2. General
Requirements
The
primary
purpose
of
the
WOFF2
format
is
to
efficiently
package
fonts
linked
to
Web
documents
by
means
of
CSS
@font-face
rules.
User
agents
supporting
the
WOFF2
file
format
for
linked
fonts
must
respect
the
requirements
of
the
CSS3
Fonts
specification
([
CSS3-Fonts
]
Section
4.1:
The
@font-face
rule
).
In
particular,
such
linked
fonts
are
only
available
to
the
documents
that
reference
them;
they
MUST
NOT
be
made
available
to
other
applications
or
documents
on
the
user's
system
.
The
input
font
file
may
contain
a
number
of
various
font
data
tables
described
in
the
clause
5
of
the
[
OFF
]
specification.
The
order
of
the
tables
in
a
font
file
may
differ
and,
while
the
entries
in
the
table
directory
are
required
have
to
be
sorted
in
ascending
order
by
tags,
the
actual
tables
can
be
presented
in
a
font
file
in
arbitrary
order.
When
WOFF2
file
is
decompressed,
the
decoder
MUST
must
sort
the
tags
entries
in
the
table
directory
in
ascending
alphabetical
order
by
table
tags
and
SHOULD
should
arrange
the
table
order
in
a
font
file
according
to
the
Recommendations
(subclause
8.1
"Optimized
table
ordering")
of
the
[
OFF
].
3. Overall
file
structure
and
basic
data
types
The
structure
of
WOFF2
files
is
similar
to
that
of
SFNT
and
WOFF
1.0
font
files,
in
that
there
is
a
header
followed
by
a
table
directory,
followed
by
the
data
for
those
tables.
The
SFNT
structure
is
described
fully
in
the
TrueType
[
TrueType
],
OpenType
[
OpenType
],
and
ISO
"Open
Font
Format"
[
OFF
]
specifications.
However,
it
WOFF2
differs
in
some
important
respects
aspects
from
SFNT.
Most
notably,
the
data
for
the
font
tables
is
compressed
in
a
single
data
stream
comprising
all
the
font
tables.
Similar
to
WOFF
1.0
format,
the
optional
extended
metadata
and
private
data
blocks
are
each
presented
as
separate
blocks
of
data,
and
are
concatenated
together
into
the
WOFF
2.0
file.
The
compression
algorithm
used
for
both
the
compressed
font
data
stream
and
extended
metadata
block
is
Brotli
[
Brotli
].
A
complete
WOFF2
file
consists
of
several
blocks
of
data:
a
48-byte
header,
immediately
followed
(in
this
order)
by
a
variable-size
Table
Directory,
an
optional
Collection
Directory
(present
only
if
the
input
font
file
is
a
font
collection),
a
compressed
font
data
block,
an
optional
block
of
Extended
Metadata,
and
an
optional
block
of
Private
Data.
Except
for
padding
with
a
maximum
of
three
null
bytes
in
places
where
4-byte
alignment
of
a
table
length
or
block
offset
is
specified,
there
MUST
NOT
be
any
extraneous
data
between
the
data
blocks
or
WOFF2
header
and
table
directory,
or
beyond
the
last
such
block
or
table
.
If
such
extraneous
data
is
present
a
conforming
user
agent
MUST
reject
the
file
as
invalid
.
The
file
MUST
also
be
rejected
as
invalid
if
the
offsets
and
lengths
of
any
data
blocks
or
font
tables
indicate
overlapping
byte
ranges
of
the
file,
or
ranges
that
would
extend
beyond
the
end
of
the
file
.
WOFF2
File
WOFF2Header
WOFF2Header
File
header
with
basic
font
type
and
version,
along
with
offsets
to
metadata
and
private
data
blocks.
TableDirectory
TableDirectory
Directory
of
font
tables,
containing
size
and
other
info.
CollectionDirectory
CollectionDirectory
An
optional
table
containing
the
font
fragment
descriptions
of
font
collection
entries.
CompressedFontData
CompressedFontData
Contents
of
font
tables,
compressed
for
storage
in
the
WOFF2
file.
ExtendedMetadata
ExtendedMetadata
An
optional
block
of
extended
metadata,
represented
in
XML
format
and
compressed
for
storage
in
the
WOFF2
file.
PrivateData
PrivateData
An
optional
block
of
private
data
for
the
font
designer,
foundry,
or
vendor
to
use.
3.1. Data
types
Data
Types
UInt8
8-bit
unsigned
integer.
Int16
16-bit
signed
integer
in
2's
complement
format,
stored
big-endian.
UInt16
16-bit
unsigned
integer,
stored
big-endian.
255UInt16
Variable-length
encoding
of
a
16-bit
unsigned
integer
for
optimized
intermediate
font
data
storage.
UIntBase128
Variable-length
encoding
of
32-bit
unsigned
integers.
255UInt16
Data
Type
255UInt16
is
a
variable-length
encoding
of
an
unsigned
integer
in
the
range
0
to
65535
inclusive.
This
data
type
is
intended
to
be
used
as
intermediate
representation
of
various
font
values,
which
are
typically
expressed
as
UInt16
but
represent
relatively
small
values.
Depending
on
the
encoded
value,
the
length
of
the
data
field
may
be
one
to
three
bytes,
where
the
value
of
the
first
byte
either
represents
the
small
value
itself
or
is
treated
as
a
code
that
defines
the
format
of
the
additional
byte(s).
The
"C-like"
pseudo-code
describing
how
to
read
the
255UInt16
format
is
presented
below:
Read255UShort( data )
{
UInt8 code;
UInt16 value, value2;
const oneMoreByteCode1 = 255;
const oneMoreByteCode2 = 254;
const wordCode = 253;
const lowestUCode = 253;
code = data.getNextUInt8();
if ( code == wordCode )
{
if ( code == wordCode ) {
/* Read two more bytes and concatenate them to form UInt16 value*/
value = data.getNextUInt8();
value <<= 8;
value &= 0xff00;
value2 = data.getNextUInt8();
value |= value2 & 0x00ff;
}
else if ( code == oneMoreByteCode1 )
{
else if ( code == oneMoreByteCode1 ) {
value = data.getNextUInt8();
value = (value + lowestUCode);
}
else if ( code == oneMoreByteCode2 )
{
else if ( code == oneMoreByteCode2 ) {
value = data.getNextUInt8();
value = (value + lowestUCode*2);
}
else
{
else {
value = code;
}
return value;
}
Note
that
the
encoding
is
not
unique.
For
example,
the
value
506
can
be
encoded
as
[255,
203],
253],
[254,
0],
and
[253,
1,
250].
An
encoder
may
produce
any
of
these,
and
a
decoder
MUST
accept
them
all
.
An
encoder
SHOULD
should
choose
shorter
encodings
,
encodings,
and
must
be
consistent
in
choice
of
encoding
for
the
same
value,
as
this
will
tend
to
compress
better.
UIntBase128
Data
Type
UIntBase128
is
a
different
variable
length
encoding
of
unsigned
integers,
suitable
for
values
up
to
2
32
-1.
A
UIntBase128
encoded
number
is
a
sequence
of
bytes
for
which
the
most
significant
bit
is
set
for
all
but
the
last
byte,
and
clear
for
the
last
byte.
The
number
itself
is
base
128
encoded
in
the
lower
7
bits
of
each
byte.
Thus,
a
decoding
procedure
for
a
UIntBase128
is:
start
with
value
=
0.
Consume
a
byte,
setting
value
=
old
value
times
128
+
(byte
bitwise-and
127).
Repeat
last
step
until
the
most
significant
bit
of
byte
is
false.
UIntBase128
encoding
format
allows
a
possibility
of
sub-optimal
encoding,
where
e.g.
the
same
numerical
value
can
be
represented
with
variable
number
of
bytes
(utilizing
leading
'zeros').
For
example,
the
value
63
could
be
encoded
as
either
one
byte
0x3F
or
two
(or
more)
bytes:
[0x80,
0x3f].
An
encoder
must
not
allow
this
to
happen
and
MUST
must
produce
shortest
possible
encoding
.
encoding.
A
decoder
MUST
reject
the
font
file
if
it
encounters
a
UintBase128-encoded
value
with
leading
zeros
(a
value
that
starts
with
the
byte
0x80),
if
UintBase128-encoded
sequence
is
longer
than
5
bytes,
or
if
a
UintBase128-encoded
value
exceeds
2
32
-1
.
Editor's
note:
We
need
to
figure
out
The
"C-like"
pseudo-code
describing
how
these
conditions
can
be
tested.
Otherwise,
we
may
need
to
edit
statements
that
cannot
be
covered
by
read
the
conformance
tests
and
make
them
plain
English
descriptions
instead.
UIntBase128
format
is
presented
below:
bool ReadUIntBase128( data, *result )
{
UInt32 accum = 0;
for (i = 0; i < 5; i++) {
UInt8 data_byte = data.getNextUInt8();
// No leading 0's
if (i == 0 && data_byte = 0x80) return false;
// If any of top 7 bits are set then << 7 would overflow
if (accum & 0xFE000000) return false;
*accum = (accum << 7) | (data_byte & 0x7F);
// Spin until most significant bit of data byte is false
if ((data_byte & 0x80) == 0) {
*result = accum;
return true;
}
}
// UIntBase128 sequence exceeds 5 bytes
return false;
}
3.2. WOFF2
Header
The
WOFF
2.0
header
includes
an
identifying
signature
and
provides
the
information
about
the
compressed
and
uncompressed
sizes
of
encapsulated
font
data.
It
also
indicates
the
specific
kind
of
font
data
included
in
the
WOFF
2.0
file,
font
version
number
and
provides
offsets
to
additional
data
blocks
included
in
the
file.
WOFF2
Header
UInt32
signature
0x774F4632
'wOF2'
UInt32
flavor
The
"sfnt
version"
of
the
input
font.
UInt32
length
Total
size
of
the
WOFF
file.
UInt16
numTables
Number
of
entries
in
directory
of
font
tables.
UInt16
reserved
Reserved;
set
to
0.
UInt32
totalSfntSize
Total
size
needed
for
the
uncompressed
font
data,
including
the
sfnt
header,
directory,
and
font
tables
(including
padding).
UInt32
totalCompressedSize
Total
length
of
the
compressed
data
block.
UInt16
majorVersion
Major
version
of
the
WOFF
file.
UInt16
minorVersion
Minor
version
of
the
WOFF
file.
UInt32
metaOffset
Offset
to
metadata
block,
from
beginning
of
WOFF
file.
UInt32
metaLength
Length
of
compressed
metadata
block.
UInt32
metaOrigLength
Uncompressed
size
of
metadata
block.
UInt32
privOffset
Offset
to
private
data
block,
from
beginning
of
WOFF
file.
UInt32
privLength
Length
of
private
data
block.
The
interpretation
of
the
WOFF2
Header
is
the
same
as
the
WOFF
Header
in
[
WOFF1
].
],
with
the
addition
of
one
new
totalCompressedSize
field.
The
signature
field
in
the
WOFF2
header
MUST
contain
the
value
of
0x774F4632
('wOF2')
,
which
distinguishes
it
from
WOFF
1.0
files.
If
the
field
does
not
contain
this
value,
user
agents
MUST
reject
the
file
as
invalid
.
A
valid
WOFF
2.0
file
MUST
have
the
reserved
field
set
to
'zero'
,
a
decoder
MUST
NOT
reject
a
downloaded
font
file
if
the
reserved
header
value
is
not
zero
.
User
agents
MUST
NOT
reject
correctly
decoded
font
file
if
the
resulting
font
file
size
doesn't
match
the
totalSfntSize
value
encoded
as
part
of
the
WOFF2
header
.
The
"totalSfntSize"
value
in
the
WOFF2
Header
is
intended
to
be
used
for
reference
purposes
only.
It
may
represent
the
size
of
the
uncompressed
input
font
file,
but
if
the
transformed
'glyf'
and
'loca'
tables
are
present,
the
uncompressed
size
of
the
reconstructed
tables
and
the
total
decompressed
font
size
may
differ
substantially
from
the
original
total
size
specified
in
the
WOFF2
Header.
4. Font
directory
The
font
directory
section
consist
consists
of
the
table
directory,
containing
a
single
entry
for
each
unique
font
table
in
the
input
font
file,
and
may
also
include
an
optional
collection
directory
table,
when
the
input
font
file
is
a
font
collection.
4.1. Table
directory
format
The
table
directory
is
an
array
of
WOFF2
table
directory
entries,
as
defined
below.
The
directory
follows
immediately
after
the
WOFF2
file
header;
therefore,
there
is
no
explicit
offset
in
the
header
pointing
to
this
block.
Its
size
is
dependent
on
the
exact
content;
thus,
the
best
strategy
for
decoding
is
to
process
the
file
as
a
stream,
rather
than
trying
to
access
it
randomly.
Each
table
directory
entry
specifies
the
original
size
of
a
single
font
data
table
and,
for
those
tables
where
an
additional
transform
has
been
applied,
the
size
of
the
transformed
table.
Transformed
tables
can
be
are
identified
either
by
the
their
'flags'
field
that
combines
known
table
tag
as
part
of
tags
(bits
0-5,
see
"Known
Table
Tags")
and
transformation
version
number
(bits
6
and
7,
see
the
flags
field
or
by
description
below)
defining
the
applied
transform.
The
combination
of
the
4-byte
table
tag,
if
present.
tag
and
the
transform
version
number
defines
the
exact
transform
that
was
applied
to
a
table,
currently
defined
transforms
are
specified
in
details
in
clause
5
of
this
specification.
Contrary
to
the
way
how
table
directory
entries
are
specified
in
the
original
input
font
file
(where
table
directory
entires
entries
are
sorted
in
ascending
alphabetical
order),
the
WOFF2
table
directory
entries
define
the
physical
order
of
tables
in
which
they
have
been
processed
and
encoded
as
part
of
the
compressed
font
data
stream.
It
is
a
decoder
responsibility
to
sort
and
reorder
the
reconstructed
table
directory
when
the
font
file
is
decompressed.
In
order
to
simplify
the
font
decoding
process
an
encoder
MUST
reorder
the
transformed
tables
so
that
the
associated
'glyf'
and
'loca'
tables
are
always
present
as
a
pair,
with
'loca'
table
following
the
'glyf'
table
.
Please
keep
in
mind
that
the
entry
for
transformed
'loca'
table
is
just
a
placeholder
indicating
the
size
required
to
reconstruct
the
table
while
consuming
no
bytes
of
the
data
stream.
Therefore,
the
requirement
for
the
'loca'
table
entry
to
immediately
follow
the
transformed
'glyf'
table
in
the
table
directory
makes
it
easier
to
implement
the
'loca'
table
reconstruction
step
when
the
reverse
transofrm
transform
(see
subclause
5.1
for
details)
is
being
applied
to
the
'glyf'
table.
For
more
details
on
table
order
constraints
see
subclause
5.5
.
The
format
of
each
individual
table
directory
entry
is
as
follows:
TableDirectoryEntry
UInt8
flags
table
type
and
flags
UInt32
tag
4-byte
tag
(optional)
UIntBase128
origLength
length
of
original
table
UIntBase128
transformLength
transformed
length
(optional)
(if
applicable)
The
interpretation
of
the
flags
field
is
as
follows.
Bits
[0..5]
contain
an
index
to
the
"known
tag"
table,
which
represents
tags
likely
to
appear
in
fonts.
If
the
tag
is
not
present
in
this
table,
then
the
value
of
this
bit
field
is
63.
Bits
6
and
7
indicate
the
preprocessing
transformation
version
number
(0-3)
that
was
applied
to
each
table.
For
all
tables
in
a
font,
except
for
'glyf'
and
'loca'
tables,
transformation
version
0
indicates
the
null
transform
where
the
original
table
data
is
passed
directly
to
the
Brotli
compressor
for
inclusion
in
the
compressed
data
stream.
For
'glyf'
and
'loca'
tables,
transformation
version
3
indicates
the
null
transform
where
the
original
table
data
was
passed
directly
to
the
Brotli
compressor
without
applying
any
pre-processing
defined
in
subclause
5.1
and
subclause
5.3
.
The
transformed
table
formats
and
their
associated
transformation
version
numbers
are
reserved
described
in
details
in
clause
5
of
this
specification.
If
multiple
transformation
versions
are
defined
for
future
extensions.
a
given
table,
an
encoder
should
normally
choose
the
transformation
version
that
results
in
the
smallest
transformed
table
length,
unless
the
reduction
is
so
slight
as
to
be
insignificant.
Where
more
than
one
transformation
version
is
defined
for
a
given
table
tag,
an
encoder
may
use
any
of
the
defined
transformations
that
is
applicable
to
the
input
data;
a
decoder
MUST
be
prepared
to
accept
any
of
the
defined
transformations
.
If
a
decoder
encounters
a
table
entry
that
specifies
an
unknown
transformation
version
number
the
entire
font
MUST
be
rejected
as
it
cannot
be
correctly
decoded.
Whether
a
font
table
tag
is
encoded
with
a
known
table
tag
or
explicitly
including
the
four-byte
tag
has
no
semantic
semantical
significance;
it
is
simply
a
choice
of
encoding
intended
to
improve
compression
efficiency.
Similarly,
whether
a
particular
four-byte
tag
is
present
or
not
in
the
known
"Known
Table
Tags"
table
is
not
a
normative
statement
about
whether
such
tags
should
be
included
in
web
fonts.
fonts.The
encoder
MUST
use
known
table
flag
when
encoding
an
input
font
table
with
a
tag
that
is
listed
in
the
"Known
Table
Tags"
table
.
There
is
a
predefined
extension
mechanism
for
any
custom
table
tag
that
is
not
included
in
the
known
tag
list
(or
for
any
new
standard
tags
that
may
be
defined
in
the
future).
If
bits
[0..5]
of
the
flags
byte
have
the
value
63
(0x3f),
then
following
the
flag
byte
is
a
4-byte
arbitrary
tag
value.
Otherwise,
the
tag
field
is
omitted
in
the
TableDirectoryEntry
structure,
and
is
derived
from
bits
[0..5]
of
the
flag
byte
from
the
fixed
Known
Table
Tags
table,
given
below.
The
decoder
MAY
accept
a
table
entry
defined
using
a
custom
table
tag
even
if
the
tag
that
follows
is
identified
as
one
of
the
kown
table
tags
.
Known
Table
Tags
Flag
Tag
Flag
Tag
Flag
Tag
Flag
Tag
0
cmap
16
EBLC
32
CBDT
48
gvar
1
head
17
gasp
33
CBLC
49
hsty
2
hhea
18
hdmx
34
COLR
50
just
3
hmtx
19
kern
35
CPAL
51
lcar
4
maxp
20
LTSH
36
SVG
52
mort
5
name
21
PCLT
37
sbix
53
morx
6
OS/2
22
VDMX
38
acnt
54
opbd
7
post
23
vhea
39
avar
55
prop
8
cvt
24
vmtx
40
bdat
56
trak
9
fpgm
25
BASE
01
41
bloc
57
Zapf
10
glyf
26
GDEF
42
bsln
58
Silf
11
loca
27
GPOS
43
cvar
59
Glat
12
prep
28
GSUB
44
fdsc
60
Gloc
13
CFF
29
EBSC
45
feat
61
Feat
14
VORG
30
JSTF
46
fmtx
62
Sill
15
EBDT
31
MATH
47
fvar
63
arbitrary
tag
follows
Please
note
that
according
to
the
SFNT-based
font
format
specifications
all
table
tags
should
consist
of
four
characters.
Table
tags
with
less
then
than
four
letters,
such
as
e.g.
'
cvt
'
(tag
value
0x63767420)
are
padded
with
trailing
spaces.
Following
the
flags
(and
the
optional
tag
field)
are
one
to
or
two
length
values,
each
in
UIntBase128
unsigned
integer
encoding.
The
origLength
field
specifies
the
length
of
the
table
in
an
uncompressed
version
of
the
font.
Optionally,
for
'
glyf
'
and
'
loca
'
For
tables
that
are
subjected
to
additional
transformations
,
the
transformLength
field
that
specifies
the
length
of
the
transformed
version
of
the
table.
table
MUST
be
included
.
The
transformLength
field
is
present
in
the
table
directory
entry
if,
and
only
if,
the
table
has
been
processed
by
a
non-null
transform
prior
to
Brotli
compression.
For
tables
that
are
not
transformed,
no
transformLength
field
is
present
in
the
directory
entry.
The
field
containing
the
transformed
length
provides
information
about
the
transformed
table
size
prior
to
it
being
compressed
by
[
Brotli
].
This
field
is
optional
and
is
present
only
for
certain
tables
(see
below
the
description
of
the
"Compressed
data
format").
Please
note
that
while
the
transformed
length
can
be
relied
upon
to
determined
the
decompressed
table
size,
the
original
table
length
of
the
transformed
font
table
should
be
treated
with
caution.
The
reconstruction
process
of
transformed
tables
guarantees
preserving
the
functionality
of
the
tables
but
may
produce
binary
results
that
are
different
from
the
original
data.
For
example,
'glyf'
table
records
may
have
outline
point
coordinates
encoded
using
one-
or
two-byte
format,
and
the
repetitive
values
can
either
be
explicitly
duplicated
in
the
coordinate
stream
or
omitted
(which
would
be
indicated
by
the
flags
byte
of
the
control
point).
Therefore,
various
representations
of
glyph
oulines
point
outline
points
are
possible
that
would
produce
identical
rendering
results;
however,
the
binary
data
of
reconstructed
glyph
records
may
differ
significantly
from
the
original
data.
See
subclause
5.3.3
of
the
ISO
"Open
Font
Format"
[
OFF
]
specification
for
details.
For
this
reason,
the
value
of
the
origLength
field
of
transformed
table
should
be
treated
only
as
a
reference
and
should
not
be
relied
upon
in
making
memory
allocation
decisions
when
the
WOFF2
data
is
decoded.
4.2. Collection
directory
format
The
collection
directory
tables
are
is
present
only
if
the
input
font
is
a
collection;
i.e.
if
the
value
of
the
WOFF2
file
header
"flavor"
field
is
set
to
0x74746366
('ttcf').
If
present,
the
collection
directory
follows
immediately
after
the
table
directory.
The
collection
directory
consists
of
a
CollectionHeader
and
one
or
more
CollectionFontEntry
records.
If
input
font
is
a
collection,
the
table
directory
contains
a
single
entry
for
each
unique
table
in
the
entire
collection,
regardless
of
whether
a
table
is
shared
among
different
fonts
in
a
collection
or
not.
Thus,
the
table
directory
for
a
font
collection
compressed
with
WOFF2
comprises
all
tables
from
all
fonts
contained
in
the
font
collection
file.
The
Collection
directory
starts
with
the
Collection
Header
folowed
followed
by
an
array
of
Collection
Font
Entries.
CollectionHeader
UInt32
version
The
Version
of
the
TTC
Header
in
the
original
font.
255UInt16
numFonts
The
number
of
fonts
in
the
collection.
Collection
font
entries
specify
each
font
in
the
collection
(defined
by
CollectionHeader
"numFonts"
field).
The
format
of
each
individual
collection
font
entry
is
as
follows:
CollectionFontEntry
255UInt16
numTables
numTables
The
number
of
tables
in
this
font
UInt32
flavor
flavor
The
"sfnt
version"
of
the
font
255UInt16
index[numTables]
index[numTables]
The
index
identifying
an
entry
in
the
Table
Directory
index
of
for
each
table
in
this
font
(a
stream
(where
the
index
of
numTables
255UInt16
values)
the
first
Table
Directory
entry
is
zero.)
A
table
whose
offset
is
referred
to
by
multiple
Offset
Tables
in
the
original
collection
is
considered
"shared".
An
encoder
MUST
emit
a
single
TableDirectoryEntry
for
each
unique
font
table
defined
by
its
offset
,
regardless
of
whether
that
table
is
shared
among
multiple
fonts
in
a
collection
or
not.
I.e.,
if
a
collection
contains
multiple
fonts
with
their
corresponding
Table
Records
referencing
shared
font
tables
with
the
same
offsets,
the
physical
tables
both
in
an
input
font
collection
file
and
table
data
in
the
WOFF2
compressed
data
stream
MUST
be
present
only
once
and
MUST
NOT
be
duplicated
.
If
an
input
font
file
is
a
font
collection
that
contains
multiple
unique
glyf
and
loca
tables,
the
transformations
described
for
the
glyf
and
loca
tables
MUST
be
applied
to
each
pair
of
the
tables
.Sharing
of
glyf
and
loca
tables
is
allowed
and
encouraged
(this
is
one
of
the
major
benefits
of
a
font
collection);
however,
it
is
possible
that
font
collections
may
have
two
or
more
pairs
of
the
glyf
/
loca
tables
that
may
not
be
shared.
When
the
tables
are
shared,
an
encoder
MUST
verify
that
both
tables
are
shared
and
that
both
form
an
associated
pair
(if
more
than
one
pair
of
glyf
/
loca
tables
are
present)
and
MUST
reject
a
collection
containing
fonts
that
share
only
one
of
either
glyf
or
loca
table.
An
encoder,
when
processing
a
font
collection,
MUST
preserve
the
same
order
of
the
nested
fonts
as
they
are
in
the
input
font
collection
and
MUST
record
the
index
of
the
matching
TableDirectoryEntry
into
the
CollectionFontEntry
for
each
font
.
A
decoder
MUST
restore
the
collection
with
the
same
number
of
fonts
and
their
corresponding
Offset
Tables
.
The
Offset
Tables
within
for
each
font
that
comprises
the
output
font
collection
file
MUST
have
either
the
same
numTables
as
the
input
collection,
or
one
less
if
DSIG
was
present
in
the
original
input
Offset
Table
.
Table.
If
the
value
of
the
version
field
for
the
TTC
Header
in
the
CollectionHeader
is
set
to
"2.0",
a
decoder
MUST
either
set
the
TTC
Header
fields
{ulDsigTag,
ulDsigLength,
ulDsigOffset}
in
the
output
collection
to
null
or
convert
the
TTC
header
format
to
version
1
(0x00010000)
.
A
decoder,
when
processing
a
font
collection,
MUST
recreate
the
same
order
of
the
nested
fonts
as
they
were
in
the
input
collection
.
The
tables
within
each
nested
font
can
be
reordered.
When
processing
a
font
collection
with
multiple
pairs
of
'glyf'/'loca'
tables
present,
a
decoder
MUST
check
CollectionFontEntry
indices
to
make
sure
that
referenced
'glyf'
and
'loca'
tables
are
paired
with
each
other,
and
MUST
reject
a
font
collection
if
a
mismatch
in
table
pairing
is
found
.
For
more
details
about
table
pairs
see
the
table
directory
format
description.
A
conforming
user
agent
MUST
be
able
to
load
and
use
properly
formatted
font
collection
file
generated
by
a
WOFF2
decoder.
Retention
of
the
font
order
in
a
font
collection
is
required
for
CSS
fragment
identifiers
to
ever
work.
5. Compressed
data
format
The
CompressedFontData
field
in
a
WOFF2
file
contains
the
concatenation
of
data
for
each
table
in
the
font,
in
the
order
that
entries
appear
in
the
WOFF2
table
directory.
directory
.
There
MUST
NOT
be
any
extraneous
data
between
the
table
entries
in
the
decompressed
data
stream
as
defined
by
the
table
directory
.
If
such
extraneous
data
is
present
a
conforming
user
agent
MUST
reject
the
file
as
invalid
.
The
CompressedFontData
stream
MUST
be
compressed
using
the
Brotli
compression
algorithm
[
Brotli
]
.
If
the
decompression
of
the
data
block
fails
for
any
reason,
the
WOFF2
file
is
invalid
and
MUST
NOT
be
loaded
.
The
process
of
decoding
the
table
data
in
a
WOFF2
font
file
can
be
specified
by
decompressing
the
byte-level
compression
of
the
CompressedFontData
field,
yielding
a
"table
data
block",
then
applying
additional
decoding
steps
as
described
below.
An
actual
implementation
is
free
to
combine
these
steps
or
perform
some
of
the
steps
in
an
incremental
or
streaming
fashion,
but
the
results
must
be
consistent
with
the
sequential
process
as
specified
here.
Certain
tables
(such
as
glyf
,
loca
and
loca
hmtx
tables,
identified
by
their
corresponding
tags),
are
subject
to
additional
transforms.
If
a
font
table
is
not
transformed,
then
the
table
data
appears
in
the
compressed
stream
in
literal
form,
and
occupies
origLength
bytes
of
the
table
data
block.
If
Whether
or
not
the
table
is
transformed,
then
and
the
version
number
of
the
applied
transform
is
defined
by
the
two
most
significant
flag
bits
(see
subclause
4.1
for
details),
and
the
table
data
must
be
additionally
processed
by
a
transformation
specified
below.
In
this
case,
the
transformed
table
occupies
transformLength
bytes
of
the
table
data
block.
The
decompressed
and
reconstructed
table
data
MUST
be
stored
in
the
format
specified
by
the
[
OFF
]
specification.
Each
reconstructed
table
directory
entry
MUST
contain
a
valid
'checkSum'
value,
the
decoder
MUST
recalculate
the
checkSum
value
for
each
decoded
table.
Also,
due
to
modifying
transofrms
transforms
applied
to
glyf
and
loca
tables,
the
decoder
MUST
recalculate
the
checkSumAdjustmentglyf
checkSumAdjustment
value
of
the
entire
font
and
MUST
store
the
updated
value
in
the
head
table.
The
known
table
flag
values
should
not
be
relied
upon
in
determining
the
presense
presence
of
the
transformed
tables,
it
is
feasible
that
e.g.
the
glyf
table
can
be
represented
in
the
table
directory
with
either
flag
=
10
and
no
tag,
or
with
flag
=
63
and
'glyf'
tag
that
follows.
The
combination
of
flags
value
that
defines
a
transform
version
number
and
the
table
tag
should
be
used
to
determine
the
applied
transform.
The
sum
of
the
origLength
(for
non-transformed
tables)
and
transformLength
(for
transformed
tables)
fields
in
the
table
directory
MUST
equal
the
size
of
the
font
data
block
after
it
has
been
decompressed
using
[
Brotli
]
.If
the
size
of
the
decompressed
font
data
block
doesn't
match
the
sum
of
lengths
defined
in
the
table
directory
as
descripbed
described
above,
the
WOFF2
file
MUST
NOT
be
loaded
.
A
According
to
the
curent
version
of
the
WOFF2,
a
transform
MUST
can
be
applied
to
two
three
types
of
tables:
glyf
,
representing
outline
data,
and
loca
,
representing
the
offsets
of
the
individual
glyphs
within
a
glyf
table,
and
hmtx
,
representing
glyph
horizontal
metrics,
if
these
tables
are
present
in
a
font
.
font.
An
authoring
tool
must
transform
the
glyf
and
loca
tables
.
Additional
can
use
any
applicable
transforms
taking
into
consideration
additional
constraints
apply,
as
specified
in
subclause
5.3
and
subclause
5.4
5.5
.
The
glyf
table
transformation
is
specified
in
subclause
5.1
,
and
the
loca
table
transformation
is
specified
in
subclause
5.3
,
and
the
hmtx
table
transformation
is
specified
in
subclause
5.4
.
Editor's
note:
Do
we
need
CFF
table
processing
and
de-subroutinization.
The
majority
of
OpenType
fonts
with
CFF
outlines
have
CFF
data
subroutinized
for
more
compact
data
storage.
The
experiments
conducted
as
part
of
WOFF2
development
and
evaluation
have
shown
that
Brotli
compression
technology
works
more
efficiently
and
produces
better
compression
gains
for
WOFF2
fonts
if
the
CFF
outline
data
is
de-subroutinized
prior
to
add
WOFF2
encoding
-
this
will
on
average
reduce
the
conformance
requirement
compressed
data
size
by
5-10%.
However,
the
CFF
de-subroutinization
will,
at
the
same
time,
increase
the
output
file
size
by
~10%.
Since
the
CFF
pre-processing
/
de-subroutinization
is
considered
an
external
step
that
can
be
implemented
prior
to
WOFF2
encoding,
it
is
not
covered
by
this
specification.
Font
producers
have
an
opportunity
to
optimize
their
production
process
to
either
reduce
the
compressed
font
size
for
UA
regarding
table
transforms?
fastest
webfont
data
transfer
at
the
expense
of
increasing
the
output
CFF
font
size
(which
will
also
improve
rendering
performance)
or
to
keep
subroutinized
CFF
data
to
minimize
input/output
font
size.
The
WOFF
2.0
transformations
applied
to
certain
tables
are
designed
to
reduce
and/or
eliminate
the
built-in
redundancies
of
the
SFNT
format
and
restructure
the
font
data
stream
for
more
efficient
entropy
encoding.
As
a
result,
the
reconstructed
font
data
will
retain
the
exact
functionality
of
the
input
font
file,
but
due
to
certain
possible
encoding
variations
(such
as
e.g.
various
levels
of
optimization
of
outline
point
coordinates
in
the
'glyf'
table,
and/or
difference
in
offset
calculations
of
the
'loca'
table)
different
WOFF2
decoders
may
produce
an
output
file
that
will
not
be
a
bitwise
match
to
the
input
font
file.
The
font
tables
of
the
input
font
file
may
also
be
subjected
to
reordering
operations,
which
may
take
place
either
as
a
part
of
the
encoding
process
or
the
tables
can
be
reordered
by
a
decoder
to
comply
with
the
recommended
table
order
defined
by
the
[
OFF
]
specification
–
as
a
result,
even
if
the
content
of
the
font
data
tables
is
not
affected,
the
table
offsets
may
change.
The
differences
in
binary
font
data
(however
minor,
due
to
significant
extent
to
decoder
optimizations
and
table
reordering)
between
encoded
and
decoded
font
data
structures
will
invalidate
the
'DSIG'
table,
if
one
is
present.
Therefore,
the
compliant
WOFF2
encoder
MUST
remove
the
DSIG
table
from
an
input
font
data
,
prior
to
applying
transformations
and
entropy
coding
steps.
The
WOFF
2.0
encoders
MUST
also
set
bit
11
of
the
'flags'
field
of
the
head
table
(see
[
OFF
]
specification)
to
indicate
that
a
recreated
font
file
was
subjected
to
lossless
modifying
transform.
5.1. Transformed
glyf
table
format
The
glyf
table
data
can
be
presented
in
the
WOFF2
file
in
one
of
two
formats
defined
by
the
transformation
version
number
(encoded
in
the
table
directory
flag
bits,
see
subclause
4.1
for
details).
The
transformation
version
"3"
defines
a
null
transform
where
the
content
of
the
glyf
table
is
presented
in
its
original,
unmodified
format.
The
transformation
version
"0",
specified
below,
is
optional
and
can
be
applied
to
eliminate
certain
redundancies
in
the
glyf
table
data.
The
version
"0"
of
the
glyf
table
transformation
(as
defined
by
the
table
directory
flag
bits,
see
subclause
4.1
for
details)
specified
in
this
subclause
is
intended
to
reduce
redundant
information
and
provide
a
more
efficient
encoding
of
the
actual
TrueType
outlines
of
glyphs.
The
modified
transformation
is
specified
below
and
is
based
on
a
similar
transformation
described
in
MicroType
Express
[
MTX
]
specification.
The
reference
to
MTX
is
informative;
the
details
of
the
modified
transformation
are
stated
below
and
this
section
is
normative.
While
glyf
table
transformation
preserves
the
functionality
and
fidelity
of
rendering
for
every
glyph
in
a
font,
it
will
most
likely
result
in
producing
a
new
set
of
glyph
records
that
will
not
be
a
binary
match
to
the
original
font.
According
to
the
encoding
rules
specified
in
subclause
5.3.3
of
[
OFF
],
there
may
be
multiple
valid
reconstructions
of
a
glyph
record.
It
is
possible
that
depending
on
the
context
and
on
the
level
of
optimizations
being
applied
to
reconstructed
glyf
table
data,
the
size
of
the
reconstructed
table
may
be
greater
than,
less
than,
or
equal
to
the
original
size
of
the
glyf
table
of
the
input
font
compressed
by
WOFF2.
Neither
this
specification
nor
the
[
OFF
]
standard
mandate
specific
optimizations
being
applied
on
the
font
data;
therefore,
it
is
the
responsibility
of
WOFF2
decoder
implementations
to
make
sure
that
an
adequate
amount
of
memory
is
allocated
when
glyph
records
are
being
reconstructed
from
the
WOFF2
file
–
the
original
glyf
table
size
supplied
as
an
origLength
value
for
the
transformed
glyf
table
can
only
be
used
as
a
reference
point.
Regardless
of
the
implementation
details
of
the
glyph
record
reconstruction
process
and
the
level
of
optimizations
applied
to
reconstructed
'glyf'
table
data
User
Agents
MUST
NOT
reject
correctly
decoded
font
file
if
the
size
of
the
reconstructed
'glyf'
table
doesn't
match
the
origLength
value
encoded
as
part
of
the
'glyf'
table
entry
in
WOFF2
Table
Directory
.
For
greater
compression
effectiveness,
the
glyf
table
is
split
into
seven
several
substreams,
to
group
like
data
together.
The
transformed
table
consists
of
a
number
of
fields
speciffying
specifying
the
size
of
each
of
the
substreams,
followed
by
the
substreams
in
sequence.
During
the
decoding
process
the
reverse
transformation
takes
place,
where
data
from
various
separate
substreams
are
recombined
to
create
a
complete
glyph
record
for
each
entry
of
the
original
glyf
table.
Transformed
glyf
Table
Data
Type
Semantic
Description
and
value
type
(if
applicable)
Fixed
version
=
0x00000000
UInt16
numGlyphs
Number
of
glyphs
UInt16
indexFormat
Offset
format
for
loca
table,
should
be
consistent
with
indexToLocFormat
of
the
original
head
table
(see
[
OFF
]
specification)
UInt32
nContourStreamSize
Size
of
nContour
stream
in
bytes
UInt32
nPointsStreamSize
Size
of
nPoints
stream
in
bytes
UInt32
flagStreamSize
Size
of
flag
stream
in
bytes
UInt32
glyphStreamSize
Size
of
glyph
stream
in
bytes
(a
stream
of
variable-length
encoded
values,
see
description
below)
UInt32
compositeStreamSize
Size
of
composite
stream
in
bytes
(a
stream
of
variable-length
encoded
values,
see
description
below)
UInt32
bboxStreamSize
Size
of
bbox
data
in
bytes
representing
combined
length
of
bboxBitmap
(a
packed
bit
array)
and
bboxStream
(a
stream
of
Int16
values)
UInt32
instructionStreamSize
Size
of
instruction
stream
(a
stream
of
UInt8
values)
Int16
nContourStream
nContourStream[]
Stream
of
Int16
values
representing
number
of
contours
for
each
glyph
record
255UInt16
nPointsStream
nPointsStream[]
Stream
of
values
representing
number
of
outline
points
for
each
contour
in
glyph
records
UInt8
flagStream
flagStream[]
Stream
of
UInt8
values
representing
flag
values
for
each
outline
point.
Vary
glyphStream
glyphStream[]
Stream
of
bytes
representing
point
coordinate
values
using
variable
length
encoding
format
(defined
in
subclause
5.2
)
Vary
compositeStream
compositeStream[]
Stream
of
bytes
representing
component
flag
values
and
associated
composite
glyph
data
UInt8
bboxBitmap[n]
bboxBitmap[]
Bitmap
(a
numGlyphs-long
bit
array)
indicating
explicit
bounding
boxes
Int16
bboxStream
bboxStream[]
Stream
of
Int16
values
representing
glyph
bounding
box
data
UInt8
instructionStream
instructionStream[]
Stream
of
UInt8
values
representing
a
set
of
instructions
for
each
corresponding
glyph
The
format
is
best
characterized
by
describing
the
decoding
process,
especially
indications
of
what
are
valid
and
invalid
data.
An
encoder
MUST
produce
transformed
data
that
is
valid
,
it
is
up
to
the
encoder
to
produce
transformed
data
that
decodes
to
the
desired
font
data.
Note
also
that
this
format
specifies
the
decoded
result
at
the
semantic
level,
not
specific
byte
streams.
Included
in
the
Transformed
glyf
Table
is
a
bboxBitmap
indicating
for
each
glyph
whether
it
contains
an
explicitly
encoded
bounding
box,
or
whether
the
bounding
box
is
to
be
inferred
from
the
coordinate
values.
The
relevant
computations
to
determine
the
bounding
box
status
must
be
performed
by
both
an
encoder
and
a
decoder.
For
each
simple
glyph,
an
encoder
MUST
calculate
the
the
xMin,
yMin,
xMax
and
yMax
coordinate
values
using
all
outline
points
(both
on-
and
off-curve
points)
and
compare
the
calculated
values
with
the
encoded
bounding
box
info
for
the
glyph.
If
the
glyph
bounding
box
info
matches
the
calculated
values,
an
encoder
MUST
omit
the
bounding
box
info
.
Otherwise,
if
the
calculated
bounding
box
values
do
not
equal
the
glyph
values
encoded
in
a
font,
an
encoder
MUST
set
the
corresponding
bboxBitmap
flag
and
record
the
original
bounding
box
values
in
the
bboxStream
.
For
glyphs
records
that
contain
zero
contours,
an
encoder
MUST
check
that
the
glyph
bounding
box
values
are
all
zeros
and,
if
this
condition
is
not
met,
MUST
reject
an
input
font
as
invalid.
For
either
an
empty
glyph
or
a
glyph
with
zero
contours,
an
encoder
MUST
always
clear
the
corresponding
bboxBitmap
flag.
For
a
composite
glyph,
an
encoder
MUST
always
set
the
corresponding
bboxBitmap
flag
and
record
the
original
bounding
box
values
in
the
bboxStream
.
A
decoder
MUST
perform
similar
calculations
if
the
bounding
box
is
to
be
inferred.
For
a
given
glyph,
when
a
corresponding
bit
in
bboxBitmap
is
not
set,
the
xMin,
yMin,
xMax
and
yMax
values
MUST
be
calculated
at
the
time
of
decoding
using
all
outline
point
coordinates
.
The
total
number
of
bytes
in
bboxBitmap
is
equal
to
4
*
((numGlyphs
floor((numGlyphs
+
31)
/
32).
The
bits
are
packed
so
that
glyph
number
0
corresponds
to
the
most
significant
bit
of
the
first
byte,
glyph
number
7
corresponds
to
the
least
significant
bit
of
the
first
byte,
glyph
number
8
corresponds
to
the
most
significant
bit
of
the
second
byte,
and
so
on.
A
bit=1
value
indicates
an
explicitly
set
bounding
box.
Upon
reading
the
Transformed
glyf
Table
,
Table,
the
decoding
process
iterates
one
glyph
at
a
time.
For
each
glyph,
it
reads
zero
or
more
bytes
from
each
of
the
streams
referenced
in
the
Transformed
glyf
Table
.
Table.
Also,
at
the
point
of
reconstructing
a
glyph,
a
decoder
MUST
needs
to
store
for
each
glyph
the
corresponding
offset
in
the
new
reconstructed
glyph
table
,
table,
and
this
data
will
collectively
become
the
contents
of
the
reconstructed
loca
table
(see
subclause
5.3
below
for
more
information
about
the
reconstruction
of
the
loca
table).
Reconstruction
of
Glyph
Records
The
reconstruction
process
begins
by
performing
the
following
step
to
determine
the
encoded
glyph
type
(simple,
composite
or
emtpy
empty
glyph):
Read
a
Int16
from
the
nContour
stream.
Store
this
in
the
numberOfContours
field
in
the
reconstructed
TrueType
glyph.
The
interpretation
of
the
field
is
the
same
as
the
TrueType
spec;
if
it
is
zero,
the
glyph
is
empty.
If
it
is
positive,
the
glyph
is
simple
and
the
value
represents
the
number
of
contours
in
the
outline.
If
the
nContour
value
is
equal
to
-1
(0xffff),
then
the
glyph
is
composite.
Decoding
of
Empty
Glyphs
Reconstruction
of
an
empty
glyph
(when
nContour
=
0)
involves
creating
is
a
simple
step
that
involves
incrementing
the
glyph
record
with
no
outlines
where
all
bounding
box
values
are
equal
to
zero.
If
count
and
creating
a
new
entry
in
the
bboxBitmap
loca
flag
indicates
that
the
bounding
box
values
are
to
be
inferred
from
the
outline
point
coordinates,
the
decoder
MUST
generate
the
bounding
box
with
xmin,
xmax,
ymin
and
ymax
values
equal
to
zero
table
where
loca[n]
=
loca[n-1]
.
If
the
bboxBitmap
flag
indicates
that
the
bounding
box
values
are
explicitly
encoded
in
the
bboxStream
the
decoder
MUST
check
that
the
encoded
values
are
all
equal
to
zero
and,
if
they
are
not,
MUST
reject
woff2
WOFF2
file
as
invalid
.
Decoding
of
Simple
Glyphs
For
a
simple
glyph
(when
nContour
>
0),
the
process
continues
as
follows:
1.
Read
numberOfContours
255UInt16
values
from
the
nPoints
stream.
Each
of
these
is
the
number
of
points
of
that
contour.
Convert
this
into
the
endPtsOfContours[]
array
by
computing
the
cumulative
sum,
then
subtracting
one.
For
example,
if
the
values
in
the
stream
are
[2,
4],
then
the
endPtsOfContours
array
is
[1,
5].
Also,
the
sum
of
all
the
values
in
the
array
is
the
total
number
of
points
in
the
glyph,
nPoints.
In
the
example
given,
the
value
of
nPoints
is
6.
2.
Read
nPoints
UInt8
values
from
the
flags
stream.
Each
corresponds
to
one
point
in
the
reconstructed
glyph
outline.
The
interpretation
of
the
flag
byte
is
described
in
details
in
subclause
5.2
.
3.
For
each
point
(i.e.
nPoints
times),
read
a
number
of
point
coordinate
bytes
from
the
glyph
stream.
The
number
of
point
coordinate
bytes
is
a
function
of
the
flag
byte
read
in
the
previous
step:
for
(flag
<
0x7f)
in
the
range
0
to
83
inclusive,
it
is
one
byte.
In
the
range
84
to
119
inclusive,
it
is
two
bytes.
In
the
range
120
to
123
inclusive,
it
is
three
bytes,
and
in
the
range
124
to
127
inclusive,
it
is
four
bytes.
Decode
these
bytes
according
to
the
procedure
specificed
specified
in
the
subclause
5.2
to
reconstruct
delta-x
and
delta-y
values
of
the
glyph
point
coordinates.
Store
these
delta-x
and
delta-y
values
in
the
reconstructed
glyph
using
the
standard
TrueType
glyph
encoding
[
OFF
]
subclause
5.3.3.
4.
Read
one
255UInt16
value
from
the
glyph
stream,
which
is
instructionLength,
the
number
of
instruction
bytes.
5.
Read
instructionLength
bytes
from
instructionStream,
and
store
these
in
the
reconstituted
glyph
as
instructions.
Decoding
of
Composite
Glyphs
For
a
composite
glyph
(nContour
==
-1),
the
following
steps
take
the
place
of
steps
1-5
above:
1a.
Read
a
UInt16
from
compositeStream.
This
is
interpreted
as
a
component
flag
word
as
in
the
TrueType
spec.
Based
on
the
flag
values,
there
are
between
4
and
14
additional
argument
bytes,
interpreted
as
glyph
index,
arg1,
arg2,
and
optional
scale
or
affine
matrix.
2a.
Read
the
number
of
argument
bytes
as
determined
in
step
2a
from
the
composite
stream,
and
store
these
in
the
reconstructed
glyph.
If
the
flag
word
read
in
step
2a
has
the
FLAG_MORE_COMPONENTS
bit
(1
<<
(bit
5)
set,
go
back
to
step
2a.
3a.
If
any
of
the
flag
words
had
the
FLAG_WE_HAVE_INSTRUCTIONS
bit
(1
<<
(bit
8)
set,
then
read
the
instructions
from
the
glyph
and
store
them
in
the
reconstructed
glyph,
using
the
same
process
as
described
in
steps
5
4
and
6
5
above.
Finally,
for
both
simple
and
composite
glyphs,
if
the
corresponding
bit
in
the
bounding
box
bit
vector
is
set,
then
additionally
read
4
Int16
values
from
the
bbox
stream,
representing
xMin,
yMin,
xMax,
and
yMax,
respectively,
and
record
these
into
the
corresponding
fields
of
the
reconstructed
glyph.
For
simple
glyphs,
if
the
corresponding
bit
in
the
bounding
box
bit
vector
is
not
set,
then
derive
the
bounding
box
by
computing
the
minimum
and
maximum
x
and
y
coordinates
in
the
outline,
and
storing
that.
A
composite
glyph
MUST
have
an
explicitly
supplied
bounding
box
.
The
motivation
is
that
computing
bounding
boxes
is
more
complicated,
and
would
require
resolving
references
to
component
glyphs
taking
into
account
composite
glyph
instructions
and
the
specified
scales
of
individual
components,
which
would
conflict
with
a
purely
streaming
implementation
of
font
decoding.
A
decoder
MUST
check
for
presence
of
the
bounding
box
info
as
part
of
the
composite
glyph
record
and
MUST
NOT
load
a
font
file
with
the
composite
bounding
box
data
missing
.
5.2. Decoding
of
variable-length
X
and
Y
coordinates
Simple
glyph
data
structure
defines
all
contours
that
comprise
a
glyph
outline,
which
are
presented
by
a
sequence
of
on-
and
off-curve
coordinate
points.
These
point
coordinates
are
encoded
as
delta
values
representing
the
incremental
values
between
the
previous
and
current
corresponding
X
and
Y
coordinates
of
a
point,
the
first
point
of
each
outline
is
relative
to
(0,0)
point.
To
minimize
the
size
of
the
dataset
of
point
coordinate
values,
each
point
is
presented
as
a
(flag,
xCoordinate,
yCoordinate)
triplet.
The
flag
value
is
stored
in
a
separate
data
stream
and
the
coordinate
values
are
stored
as
part
of
the
glyph
data
stream
using
a
variable-length
encoding
format
consuming
a
total
of
2-5
bytes
per
point.
The
most
significant
bit
of
a
flag
indicates
whether
the
point
is
on-
or
off-curve
point,
the
remaining
seven
bits
of
the
flag
determine
the
format
of
X
and
Y
coordinate
values
and
specify
128
possible
combinations
of
indices
that
have
been
assigned
taking
into
consideration
typical
statistical
distribution
of
data
found
in
TrueType
fonts.
When
X
and
Y
coordinate
values
are
recorded
using
nibbles
(either
4
bits
per
coordinate
or
12
bits
per
coordinate)
the
bits
are
packed
in
the
byte
stream
with
most
significant
bit
of
X
coordinate
first,
followed
by
the
value
for
Y
coordinate
(most
significant
bit
first).
As
a
result,
the
size
of
the
glyph
dataset
is
significantly
reduced,
and
the
grouping
of
the
similar
values
(flags,
coordinates)
in
separate
and
contiguous
data
streams
allows
more
efficient
application
of
the
entropy
coding
applied
as
the
second
stage
of
encoding
process.
Each
of
the
128
index
values
define
the
following
properties
and
specified
in
details
in
the
table
below:
Byte
count
(total
number
of
bytes
used
for
this
set
of
coordinate
values
including
one
byte
for
'flag'
value).
Number
of
bits
used
to
represent
X
coordinate
value
(X
bits).
Number
of
bits
used
to
represent
Y
coordinate
value
(Y
bits).
An
additional
incremental
amount
to
be
added
to
X
bits
value
(delta
X).
An
additional
incremental
amount
to
be
added
to
Y
bits
value
(delta
Y).
The
sign
of
X
coordinate
value
(X
sign).
The
sign
of
Y
coordinate
value
(Y
sign).
Please
note
that
“Byte
Count”
field
reflects
total
size
of
the
triplet
(flag,
xCoordinate,
yCoordinate),
including
‘flag’
value
that
is
encoded
in
a
separate
stream.
Triplet
Encoding
Index
Byte
Count
X
bits
Y
bits
Delta
X
Delta
Y
X
sign
Y
sign
0
2
0
8
N/A
0
N/A
-
1
0
+
2
256
-
3
256
+
4
512
-
5
512
+
6
768
-
7
768
+
8
1024
-
9
1024
+
10
2
8
0
0
N/A
-
N/A
11
0
+
12
256
-
13
256
+
14
512
-
15
512
+
16
768
-
17
768
+
18
1024
-
19
1024
+
20
2
4
4
1
1
-
-
21
1
+
-
22
1
-
+
23
1
+
+
24
17
-
-
25
17
+
-
26
17
-
+
27
17
+
+
28
33
-
-
29
33
+
-
30
33
-
+
31
33
+
+
32
49
-
-
33
49
+
-
34
49
-
+
35
49
+
+
36
2
4
4
17
1
-
-
37
1
+
-
38
1
-
+
39
1
+
+
40
17
-
-
41
17
+
-
42
17
-
+
43
17
+
+
44
33
-
-
45
33
+
-
46
33
-
+
47
33
+
+
48
49
-
-
49
49
+
-
50
49
-
+
51
49
+
+
52
2
4
4
33
1
-
-
53
1
+
-
54
1
-
+
55
1
+
+
56
17
-
-
57
17
+
-
58
17
-
+
59
17
+
+
60
33
-
-
61
33
+
-
62
33
-
+
63
33
+
+
64
49
-
-
65
49
+
-
66
49
-
+
67
49
+
+
68
2
4
4
49
1
-
-
69
1
+
-
70
1
-
+
71
1
+
+
72
17
-
-
73
17
+
-
74
17
-
+
75
17
+
+
76
33
-
-
77
33
+
-
78
33
-
+
79
33
+
+
80
49
-
-
81
49
+
-
82
49
-
+
83
49
+
+
84
3
8
8
1
1
-
-
85
1
+
-
86
1
-
+
87
1
+
+
88
257
-
-
89
257
+
-
90
257
-
+
91
257
+
+
92
513
-
-
93
513
+
-
94
513
-
+
95
513
+
+
96
3
8
8
257
1
-
-
97
1
+
-
98
1
-
+
99
1
+
+
100
257
-
-
101
257
+
-
102
257
-
+
103
257
+
+
104
513
-
-
105
513
+
-
106
513
-
+
107
513
+
+
108
3
8
8
513
1
-
-
109
1
+
-
110
1
-
+
111
1
+
+
112
257
-
-
113
257
+
-
114
257
-
+
115
257
+
+
116
513
-
-
117
513
+
-
118
513
-
+
119
513
+
+
120
4
12
12
0
0
-
-
121
+
-
122
-
+
123
+
+
124
5
16
16
0
0
-
-
125
+
-
126
-
+
127
+
+
For
additional
information
and
background
on
the
triplet
encoding
pleasee
please
see
section
5.11
of
the
MTX
proposal
[
MTX
].
5.3. Transformed
loca
table
format
The
loca
table
data
can
be
presented
in
the
WOFF2
file
in
one
of
two
formats
defined
by
the
transformation
version
number
(encoded
in
the
table
directory
flag
bits,
see
subclause
4.1
for
details).
The
transformation
version
"3"
defines
a
null
transform
where
the
content
of
the
loca
table
is
presented
in
its
original,
unmodified
format.
The
transformation
version
"0",
although
optional,
MUST
be
applied
to
the
loca
table
data
whenever
glyf
table
data
is
transformed.
In
other
words,
both
glyf
and
loca
tables
must
either
be
present
in
their
transformed
format
or
with
null
transform
applied
to
both
tables.
The
version
"0"
of
the
loca
table
transformation
(as
defined
by
the
table
directory
flag
bits,
see
subclause
4.1
for
details)
is
specified
below.
The
transformLength
of
the
transformed
loca
table
MUST
always
be
zero
.
The
origLength
MUST
be
the
appropriate
size
(determined
by
numGlyphs+1,
times
the
size
per
glyph,
where
that
size
per
glyph
is
two
bytes
when
indexFormat
(defined
in
subclause
5.1. Transformed
glyf
table
format
)
is
zero,
otherwise
four
bytes).
If
the
transformLength
of
the
transformed
loca
table
is
not
equal
to
zero,
or
if
the
encoded
origLength
does
not
match
the
calculated
size
defined
above
the
decoder
MUST
reject
the
woff2
WOFF2
file
as
invalid
.
The
loca
table
MUST
be
reconstructed
when
the
glyf
table
is
decoded
.
The
process
for
reconstructing
the
loca
table
is
specified
in
subclause
5.1
as
part
of
the
transformed
glyf
table
decoding
process.
For
reconstructed
glyph
records,
a
decoder
MUST
store
the
corresponding
offsets
for
individual
glyphs
using
a
format
that
is
indicated
by
the
indexFormat
field
of
the
Transformed
glyf
Table
.
5.4. Transformed
hmtx
table
format
The
hmtx
table
data
can
be
presented
in
the
WOFF2
file
in
one
of
two
formats
defined
by
the
transformation
version
number
(encoded
in
the
table
directory
flag
bits,
see
subclause
4.1
for
details).
The
transformation
version
"0"
defines
a
null
transform
where
the
content
of
the
hmtx
table
is
presented
in
its
original,
unmodified
format.
The
transformation
version
"1",
specified
below,
is
optional
and
can
be
applied
to
eliminate
certain
redundancies
in
the
hmtx
table
data.
The
transformation
version
"1"
exploits
the
built-in
redundancy
of
the
TrueType
glyphs
where
the
outlines
of
the
glyphs
designed
according
to
the
TrueType
recommendations
would
likely
have
their
left
side
bearing
values
equal
to
xMin
value
of
the
glyph
bounding
box.
The
hmtx
table
format
is
specified
in
subclause
5.2.4
of
[
OFF
]
and
includes
two
arrays
of
left
side
bearing
information
for
proportional
and
monospaced
glyph
runs.
Each
of
these
arrays
can
be
eliminated
from
the
original
input
font
data
and
reconstructed
from
the
glyph
bounding
box
information
if
certain
conditions
are
met.
Transformed
hmtx
table
format
Data
Type
Semantic
Description
and
value
type
(if
applicable)
UInt8
Flags
Bitfield
indicating
the
specific
details
of
the
applied
transform:
Bit
0
-
when
set,
indicates
that
lsb[]
array
is
not
present
and
needs
to
be
reconstructed
from
the
xMin
values
in
the
glyf
table;
Bit
1
-
when
set,
indicates
that
leftSideBearing[]
array
is
not
present
and
needs
to
be
reconstructed
from
the
xMin
values
in
the
glyf
table.
When
hmtx
transform
is
indicated
by
the
table
directory,
the
Flags
(bits
0
or
1
or
both)
MUST
be
set
.
Bits
2-7
are
reserved
and
MUST
be
zero
.
UInt16
advanceWidth[]
Stream
of
Uint16
values
representing
the
advanceWidth
values
of
the
horizontal
metrics
array
for
proportional
glyphs.
The
stream
size
is
equal
to
numOfHMetrics
defined
in
the
hhea
table.
Int16
lsb[]
Stream
of
Int16
values
representing
the
left
side
bearing
values
of
the
horizontal
metrics
array
for
proportional
glyphs.
The
stream
is
present
only
if
the
bit
0
of
the
"Flags"
field
is
not
set,
otherwise
this
stream
is
missing.
The
stream
size
is
equal
to
numOfHMetrics
defined
by
the
hhea
table.
Int16
leftSideBearing[]
Stream
of
Int16
values
representing
the
left
side
bearing
values
of
the
horizontal
metrics
array
for
monospaced
glyphs.
The
stream
is
present
only
if
the
bit
1
of
the
"Flags"
field
is
not
set,
otherwise
this
stream
is
missing.
The
stream
size
is
equal
to
(numGlyphs
-
numOfHMetrics)
.
The
transformation
version
1
described
in
this
subclause
is
optional
and
can
only
be
used
when
an
input
font
is
TrueType-flavoured
(i.e.
has
a
glyf
table),
and
when
the
leftSideBearing
values
for
each
glyph
in
the
proportional
or
monospaced
glyph
runs
encoded
in
the
hmtx
table
exactly
match
the
corresponding
xMin
values
in
the
glyf
table.
A
special
case
needs
to
be
checked
when
an
encoded
leftSideBearing
value
corresponds
to
an
empty
glyph,
where
hmtx
table
transform
can
only
be
applied
if
leftSideBearing
of
an
empty
glyph
is
set
to
zero.
If
the
hmtx
table
transform
is
both
applicable
and
desired,
the
encoder
MUST
check
that
leftSideBearing
values
match
the
xMin
values
of
the
glyph
bounding
box
for
every
glyph
in
a
font
(or
check
that
leftSideBearing
==
0
for
an
empty
glyph)
and,
for
font
collections,
this
check
MUST
be
performed
on
every
corresponding
pair
of
glyf
and
hmtx
tables
.
If
the
conditions
are
met
for
each
of
the
proportional
or
monospaced
glyph
runs
the
encoder
MUST
set
hmtx
transform
version
number
to
"1",
MUST
eliminate
the
corresponding
array
from
the
hmtx
table
and
MUST
set
the
appropriate
Flags
bits.
In
font
collections
that
have
shared
hmtx
table,
the
match
between
xMin
values
of
glyph
bounding
boxes
and
the
lsftSideBearing
values
MUST
be
checked
for
all
combinations
of
shared
hmtx
and
various
glyf
tables
,
and
if
there
is
a
mismatch
the
hmtx
table
transform
MUST
NOT
be
applied
.
When
the
table
directory
flags
indicate
that
the
hmtx
transform
is
applied,
the
User
Agent
MUST
check
the
Flags
values
and
MUST
reject
the
WOFF2
file
if
Flags
are
invalid
.
The
decoder
MUST
reconstruct
the
lsb[]
and/or
leftSideBearing[]
arrays
from
the
xMin
values
provided
by
the
glyph
bounding
box
information
from
the
glyf
table
.
5.4. Table
5.5. Table
order
constraints
The
following
constraints
on
valid
WOFF2
files
are
intended
to
facilitate
a
memory-efficient
WOFF
2.0
file
transfer
and
decoding
process.
For
a
font
with
TrueType
outlines,
the
glyf
table
MUST
be
encoded
with
the
transform
,
which
results
in
significantly
smaller
file
size.
The
loca
table
MUST
follow
the
glyf
table
in
the
table
directory.
When
WOFF2
file
contains
individually
encoded
font
file,
the
table
directory
MAY
contain
other
tables
inserted
between
glyf
and
loca
tables;
however
when
WOFF2
contains
a
font
collection
file
each
loca
table
MUST
immediately
follow
its
corresponding
glyf
table
.
For
example,
the
following
order
of
tables:
'cmap',
'glyf',
'hhea',
'hmtx',
'loca',
'maxp'
...
is
acceptable
for
individually
encoded
font
files;
however,
font
collection
files
must
have
glyf
/
loca
tables
paired
with
each
other,
although
they
don't
have
to
be
ordered
as
a
contiguous
block
of
tables,
e.g.:
'cmap',
'glyf',
'loca',
'hhea',
'hmtx',
'glyf',
'loca',
'maxp',
'post'
...
would
be
acceptable.
Additional
constraints
on
the
loca
table
are
given
in
subclause
5.3
.
In
addition
to
table
order,
there
is
an
additional
constraint
for
transformed
glyf
tables:
the
origLength
field
MUST
specify
an
adequate
amount
of
space
to
represent
the
reconstructed
glyf
table
.
Typically,
the
origLength
field
value
would
specify
the
actual
glyf
table
size;
however,
since
there
may
be
multiple
valid
reconstructions
of
a
glyph
record,
according
to
the
encoding
rules
specified
in
subclause
5.3.3
of
[
OFF
],
it
is
possible
that
depending
on
the
context
and
on
the
level
of
optimizations
being
applied
to
reconstructed
glyf
table
data,
the
size
of
the
reconstructed
glyf
table
may
be
greater
than,
less
than,
or
equal
to
the
actual
size
of
the
glyf
table
in
the
source
font
compressed
by
WOFF2.
It
is
the
responsibility
of
WOFF2
implementations
to
make
sure
that
an
adequate
amout
of
memory
is
allocated
when
glyph
records
are
being
reconstructed
from
the
WOFF2
file.
Editor's
note:
Is
this
really
a
testable
assertion?
How
one
can
test
for
an
"adequate
amount
of
space"
if
the
decoding
process
allows
multiple
permutations
and
all
of
them
are
equally
valid,
as
far
as
UA
and
font
rendering
engines
are
concerned.
Should
we
simplify
this
by
saying
that
origLength
is
exactly
what
it
means
-
the
original
length
of
the
glyf
table?
Regardless
of
the
relation
between
original
glyf
table
size
and
the
size
of
the
reconstructed
table,
an
encoder
MUST
supply
an
origLength
value
for
the
transformed
glyf
table
.
6. Extended
Metadata
Block
The
WOFF2
file
MAY
contain
a
block
of
extended
metadata
.
The
interpretation
of
this
block
is
exactly
the
same
as
[
WOFF
1
].
However,
while
in
a
WOFF
1
file
the
extended
metadata
block
is
stored
with
zlib
compression,
in
a
WOFF2
file
it
the
metadata
MUST
be
stored
compressed
with
[
Brotli
]
as
a
separate
stream,
if
present.
.
The
rationale
of
this
change
is
to
minimize
the
total
number
of
byte-level
compression
algorithms
needed
to
implement
WOFF2,
and
also
because
Brotli
is
expected
to
achieve
better
compression
ratios
than
zlib
in
most
cases.
If
present,
the
metadata
MUST
be
compressed
,
in
a
separate
Brotli
stream
from
the
main
font
data
;
it
is
never
stored
in
uncompressed
form.
The
metadata
block
MUST
follow
immediately
after
the
compressed
font
data
stream
.
The
beginning
of
the
metadata
block
MUST
always
be
4-byte
aligned;
when
extended
metadata
is
present,
the
end
of
the
compressed
data
block
must
be
padded
with
up
to
three
null
bytes
if
needed
to
reach
a
4-byte
boundary
.
If
the
metadata
block
is
the
last
block
in
the
WOFF
file,
there
SHOULD
be
no
additional
padding
after
the
end
of
the
block
.
7. Private
Data
Block
The
WOFF2
file
MAY
include
a
block
of
arbitrary
data
,
allowing
font
creators
to
include
whatever
information
they
wish.
The
content
of
this
data
MUST
NOT
affect
font
usage
or
load
behavior
of
user
agents
.
User
agents
should
make
no
assumptions
about
the
content
of
a
private
block;
it
may
(for
example)
contain
ASCII
or
Unicode
text,
or
some
vendor-defined
binary
data,
and
it
may
be
compressed
or
encrypted,
but
it
has
no
publicly
defined
format.
Conformant
user
agents
will
not
assume
anything
about
the
structure
of
this
data.
Only
the
font
developer
or
vendor
responsible
for
the
private
block
is
expected
to
understand
its
contents.
The
private
data
block,
if
present,
MUST
be
the
last
block
in
the
WOFF
file,
following
the
compressed
font
data
stream
and
the
extended
metadata
block,
if
one
is
present
.
The
private
data
block
MUST
begin
on
a
4-byte
boundary
in
the
WOFF
file,
with
up
to
three
null
bytes
inserted
as
padding
after
any
preceding
block,
if
needed
to
ensure
this
.
The
end
of
the
private
data
block
MUST
correspond
to
the
end
of
the
WOFF2
file
.
Appendix
A:
Internet
Media
Type
Registration
This
appendix
registers
a
new
top-level
MIME
media
Internet
Media
type,
in
conformance
with
BCP
13
and
W3CRegMedia
.
1.
Abstract
This
document
serves
to
register
and
document
the
top-level
MIME
type
for
fonts,
under
which
the
subtype
representation
formats
for
fonts
may
be
registered.
This
document
also
serves
as
a
registration
application
for
a
set
of
intended
subtypes,
which
are
representative
of
some
existing
subtypes
already
registered
under
"application"
tree
by
their
separate
registrations.
2.
Introduction
The
process
of
setting
type
in
computer
systems
and
other
forms
of
text
presentation
systems
uses
fonts
in
order
to
provide
visual
representations
of
the
glyphs.
Just
as
with
images,
for
example,
there
are
a
number
of
ways
to
represent
the
visual
information
of
the
glyphs.
Early
font
formats
often
used
bitmaps,
as
these
could
have
been
carefully
tuned
for
maximum
readability
at
a
given
size
on
low-resolution
displays.
More
recently,
scalable
vector
outline
fonts
have
come
into
wide-spread
use:
in
these
fonts,
the
outlines
of
the
glyphs
are
described,
and
the
presentation
system
renders
the
outline
in
the
desired
position
and
size.
This
document
defines
a
top-level
MIME
type
"font"
under
which
different
representation
formats
of
fonts
may
be
registered
(e.g.
a
bitmap
or
outline
formats).
It
should
be
emphasized
that,
just
as
under
the
"image"
top-level
type
one
does
not
find
registration
for
a
specific
image,
for
example,
"The
Night-watch"
(by
Rembrandt)
but
instead
"JPEG"
(a
compressed
image
data
representation
format),
so,
under
"font"
one
will
not
find
"Courier"
(the
name
of
a
popular
font)
but
perhaps
"TTF",
"OTF"
or
"SFNT"
(the
names
of
commonly
used
TrueType
and
OpenType
font
formats
as
well
as
their
higher-level
wrapper
format).
3.
Background
and
Justification
Historically
there
has
not
been
a
registration
of
formats
for
fonts.
Most
recently,
there
have
been
several
representation
formats
registered
as
MIME
subtypes
under
the
"application"
top-level
type.
However,
with
the
rapid
adoption
of
web
fonts
(based
on
the
data
from
HTTP
Archive
showing
a
huge
increase
in
web
font
usage
from
1%
in
the
end
of
2010
to
50%
across
all
sites
in
the
beginning
of
2015)
custom
fonts
on
the
web
have
become
a
core
web
resource.
As
the
in-depth
analysis
shows,
the
lack
of
the
intuitive
top-level
font
type
is
causing
a
significant
confusion
among
developers
-
while
currently
defined
font
subtypes
are
severely
under-utilized
there
are
many
more
sites
that
already
use
non-existent
(but
highly
intuitive)
media
types
such
as
"font/woff",
"font/ttf"
and
"font/truetype".
At
the
same
time,
majority
of
sites
resort
to
using
generic
types
such
as
"application/octet-stream",
"application/x-font-ttf",
"text/plain"
and
"text/html",
to
name
a
few.
Contrary
to
our
expectations,
the
officially
defined
IANA
subtypes
such
as
"application/font-woff"
and
"application/font-sfnt"
see
a
very
limited
use
-
their
adoption
rates
trail
far
behind
as
the
actual
use
of
web
fonts
continues
to
increase.
The
members
of
the
W3C
WebFonts
WG
believe
the
use
of
"application"
top-level
type
is
not
ideal.
First,
the
"application"
sub-tree
is
treated
(correctly)
with
great
caution
with
respect
to
viruses
and
other
active
code.
Secondly,
the
lack
of
a
top-level
type
means
that
there
is
no
opportunity
to
have
a
common
set
of
optional
attributes,
such
as
are
specified
here.
Third,
fonts
have
a
unique
set
of
licensing
and
usage
restrictions,
which
makes
it
worthwhile
to
identify
this
general
category
with
a
unique
top-level
type.
The
W3C
WebFonts
WG
believes
that
the
situation
can
be
significantly
improved
if
a
set
of
font
media
types
is
registered
using
"font"
as
a
dedicated
top-level
type.
Based
on
the
data
analysis
presented
above,
we
believe
that
it
is
the
presense
of
simple
and
highly
intuitive
media
types
for
images
that
caused
the
wide-spread
adoption
of
IANA's
recommendations,
where
the
correct
usage
of
existing
media
types
reaches
over
97%
for
all
subtypes
in
the
"image"
tree.
The
WG
believes
that,
considering
a
rapid
adoption
of
fonts
on
the
web,
the
registration
of
the
top-level
media
type
for
fonts
along
with
the
intuitive
set
of
subtypes
that
reflect
popular
and
widely
used
data
formats
would
further
stimulate
the
adoption
of
web
fonts,
significantly
simplify
web
server
configuration
process
and
facilitate
the
proper
use
of
IANA
media
type
recommendations.
4.
Security
considerations:
Fonts
are
interpreted
data
structures
that
represent
collections
of
different
tables
containing
data
that
represent
different
types
of
information,
including
glyph
outlines
in
various
formats,
hinting
instructions,
metrics
and
layout
information
for
multiple
languages
and
writing
systems,
rules
for
glyph
substitution
and
positioning,
etc.
Depending
on
the
format
used
to
represent
the
glyph
data
the
proposed
font
may
contain
TrueType,
PostScript
or
SVG
outlines
and
their
respective
hint
instructions,
where
applicable.
There
are
many
existing,
already
standardized
font
table
tags
and
formats
that
allow
an
unspecified
number
of
entries
containing
predefined
data
fields
for
storage
of
variable
length
binary
data.
Many
existing
(TrueType,
OpenType
and
OFF,
SIL
Graphite,
WOFF,
etc.)
font
formats
are
based
on
the
table-based
SFNT
(scalable
font)
format
which
is
extremely
flexible,
highly
extensible
and
offers
an
opportunity
to
introduce
additional
table
structures
when
needed,
in
a
way
that
would
not
affect
existing
font
rendering
engines
and
text
layout
implementations.
However,
this
very
extensibility
may
present
specific
security
concerns
–
the
flexibility
and
ease
of
adding
new
data
structures
makes
it
easy
for
any
arbitrary
data
to
be
hidden
inside
a
font
file.
There
is
a
significant
risk
that
the
flexibility
of
font
data
structures
may
be
exploited
to
hide
malicious
binary
content
disguised
as
a
font
data
component.
Fonts
may
contain
'hints',
which
are
programmatic
instructions
that
are
executed
by
the
font
engine
for
the
alignment
of
graphical
elements
of
glyph
outlines
with
the
target
display
pixel
grid.
Depending
on
the
font
technology
utilized
in
the
creation
of
a
font
these
hints
may
represent
active
code
interpreted
and
executed
by
the
font
rasterizer.
Even
though
hints
operate
within
the
confines
of
the
glyph
outline
conversion
system
and
have
no
access
outside
the
font
rendering
engine,
hint
instructions
can
be,
however,
quite
complex,
and
a
maliciously
designed
complex
font
could
cause
undue
resource
consumption
(e.g.
memory
or
CPU
cycles)
on
a
machine
interpreting
it.
Indeed,
fonts
are
sufficiently
complex,
and
most
(if
not
all)
interpreters
cannot
be
completely
protected
from
malicious
fonts
without
undue
performance
penalties.
Widespread
use
of
fonts
as
necessary
component
of
visual
content
presentation
warrants
that
a
careful
attention
should
be
given
to
security
considerations
whenever
a
font
is
either
embedded
into
an
electronic
document
or
transmitted
alongside
media
content
as
a
linked
resource.
While
many
existing
font
formats
provide
certain
levels
of
protection
of
data
integrity
(such
mechanisms
include
e.g.
checksums
and
digital
signatures),
font
data
formats
provide
neither
privacy
nor
confidentiality
protection
internally;
if
needed,
such
protection
should
be
provided
externally.
5.
Definition
and
encoding
The
"font"
as
the
primary
media
content
type
indicates
that
the
content
identified
by
it
requires
certain
graphic
subsystem
such
as
font
rendering
engine
(and,
in
some
cases,
text
layout
and
shaping
engine)
to
process
font
data,
which
in
turn
may
require
certain
top
level
of
hardware
capabilities
such
as
certain
levels
of
CPU
performance
and
available
memory.
The
"font"
media
type
does
not
provide
any
specific
information
about
the
underlying
data
format
and
how
the
font
information
should
be
interpreted
-
the
subtypes
defined
within
a
"font"
tree
will
name
the
specific
font
formats.
Unrecognized
sub-types
of
"font"
should
be
treated
as
"application/octet-stream".
Implementations
may
pass
unrecognized
subtypes
to
a
common
font-handling
system,
if
such
system
is
available.
6.
Defined
subtypes
In
this
section
the
initial
entries
under
the
top-level
'font'
MIME
type
are
documented.
They
also
serve
as
examples
for
future
registrations.
6.1.
Generic
SFNT
font
type
Type
name:
font
Subtype
name:
sfnt
Required
parameters:
None.
Optional
parameters:
1)
Name:
Outlines
Value:
TTF,
CFF,
SVG
This
parameter
can
be
used
to
specify
the
type
of
outlines
supported
by
the
font.
Value
"TTF"
shall
be
used
when
a
font
resource
contains
glyph
outlines
in
TrueType
format,
value
"CFF"
shall
be
used
to
identify
fonts
containing
PostScript/CFF
outlines,
and
value
SVG
shall
be
used
to
identify
fonts
that
include
SVG
outlines.
TTF,
CFF
or
SVG
outlines
can
be
present
in
various
combiniations
in
the
same
font
file,
therefore,
multiple
values
for
the
same
optional
parameter
may
be
defined.
2)
Name:
Layout
Value:
OTF,
AAT,
SIL
This
parameter
identifies
the
type
of
implemented
support
for
advanced
text
layout
features.
The
predefined
values
"OTF",
"AAT"
and
"
SIL"
respectively
indicate
support
for
OpenType
text
layout,
Apple
Advanced
Typography
or
Graphite
SIL.
More
than
one
shaping
and
layout
mechanism
may
be
supported
by
the
same
font
file,
therefore,
multiple
values
for
the
same
optional
parameter
may
be
defined.
Encoding
considerations:
Binary.
Interoperability
considerations:
As
it
was
noted
in
the
first
paragraph
of
the
"Security
considerations"
section,
the
same
font
format
wrapper
can
be
used
to
encode
fonts
with
different
types
of
glyph
data
represented
as
either
TrueType
or
PostScript
(CFF)
outlines.
Existing
font
rendering
engines
may
not
be
able
to
process
some
of
the
particular
outline
formats,
and
downloading
a
font
resource
that
contains
unsupported
glyph
data
format
would
result
in
inability
of
application
to
render
and
display
text.
Therefore,
it
would
be
extremely
useful
to
clearly
identify
the
format
of
the
glyph
outline
data
within
a
font
using
an
optional
parameter,
and
allow
applications
to
make
decisions
about
downloading
a
particular
font
resource
sooner.
Similar,
another
optional
parameter
is
suggested
to
identify
the
type
of
text
shaping
and
layout
mechanism
that
is
supported
by
a
font.
Please
note
that
as
new
outline
formats
and
text
shaping
mechanisms
may
be
defined
in
the
future,
the
set
of
allowed
values
for
two
optional
parameters
defined
by
this
section
may
be
extended.
Published
specification:
ISO/IEC
14496-22
"Open
Font
Format"
(OFF)
specification
being
developed
by
ISO/IEC
SC29/WG11.
Applications
that
use
this
media
type:
Any
and
all
applications
that
are
able
to
create,
edit
or
display
textual
media
content.
Additional
information:
Magic
number(s):
The
TrueType
fonts
and
OFF
/
OpenType
fonts
containing
TrueType
outlines
should
use
0x00010000
as
the
'sfnt'
version
number.
The
OFF
/
OpenType
fonts
containing
CFF
data
should
use
the
tag
'OTTO'
as
'sfnt'
version
number.
File
extension(s):
Font
file
extensions
used
for
OFF
/
OpenType
fonts:
.ttf,
.otf
Typically,
.ttf
extension
is
only
used
for
fonts
containing
TrueType
outlines,
while
.otf
extension
can
be
used
for
any
OpenType/OFF
font,
either
with
TrueType
or
CFF
outlines.
Macintosh
file
type
code(s):
(no
code
specified)
@font-face
Format:
none.
Fragment
Identifiers
none.
Person
&
email
address
to
contact
for
further
information:
Vladimir
Levantovsky
(vladimir.levantovsky@monotype.com).
Intended
usage:
COMMON
Restrictions
on
usage:
None
Author:
The
ISO/IEC
14496-22
"Open
Font
Format"
specification
is
a
product
of
the
ISO/IEC
JTC1
SC29/WG11.
Change
controller:
The
ISO/IEC
has
change
control
over
this
specification.
6.2.
TTF
font
type
Type
name:
font
Subtype
name:
ttf
Required
parameters:
None.
Optional
parameters:
Name:
Layout
Value:
OTF,
AAT,
SIL
[
JustFont
].
This
parameter
identifies
the
type
of
support
mechanism
for
advanced
text
layout
features.
The
predefined
values
"OTF",
"AAT"
and
"
SIL"
respectively
indicate
support
for
OpenType
text
layout,
Apple
Advanced
Typography
or
Graphite
SIL.
More
than
one
shaping
and
layout
mechanism
may
be
supported
by
the
same
font
file,
therefore,
multiple
values
for
the
same
optional
parameter
may
be
defined.
Encoding
considerations:
Binary.
Interoperability
considerations:
As
it
was
noted
in
the
first
paragraph
of
the
"Security
considerations"
section,
the
same
font
format
can
be
used
to
encode
fonts
supporting
different
types
of
outlines
and/or
text
shaping
and
layout
mechanisms.
Existing
font
rendering
engine
implementations
may
not
be
able
to
process
some
of
the
particular
layout
table
formats,
and
downloading
a
font
resource
that
contains
unsupported
text
shaping
mechanism
would
result
in
inability
of
applications
to
display
text
properly.
Therefore,
it
would
be
extremely
useful
to
clearly
identify
the
supported
text
shaping
and
layout
data
within
a
font
using
an
optional
parameter,
and
allow
applications
to
make
decisions
about
downloading
a
particular
font
resource
sooner.
Please
note
that
as
new
text
shaping
mechanisms
may
be
defined
in
the
future,
the
set
of
allowed
values
for
the
optional
parameter
defined
by
this
section
may
be
extended.
Published
specification:
ISO/IEC
14496-22
"Open
Font
Format"
(OFF)
specification
being
developed
by
ISO/IEC
SC29/WG11.
Applications
that
use
this
media
type:
Any
and
all
applications
that
are
able
to
create,
edit
or
display
textual
media
content.
Additional
information:
Magic
number(s):
The
TrueType
fonts
and
OFF
/
OpenType
fonts
containing
TrueType
outlines
should
use
0x00010000
as
the
'sfnt'
version
number.
File
extension(s):
Font
file
extensions
used
for
TrueType
/
OFF
/
OpenType
fonts:
.ttf,
.otf
Typically,
.ttf
extension
is
only
used
for
fonts
containing
TrueType
outlines,
while
.otf
extension
may
be
used
for
any
OpenType/OFF
font,
either
with
TrueType
or
CFF
outlines.
Macintosh
file
type
code(s):
(no
code
specified)
@font-face
Format:
truetype
Fragment
Identifiers
none.
Person
&
email
address
to
contact
for
further
information:
Vladimir
Levantovsky
(vladimir.levantovsky@monotype.com).
Intended
usage:
COMMON
Restrictions
on
usage:
None
Author:
The
ISO/IEC
14496-22
"Open
Font
Format"
specification
appendix
is
a
product
of
the
ISO/IEC
JTC1
SC29/WG11.
Change
controller:
The
ISO/IEC
has
change
control
over
this
specification.
6.3.
OTF
font
type
Type
name:
font
Subtype
name:
otf
Required
parameters:
None.
Optional
parameters:
Name:
Outlines
Value:
TTF,
CFF,
SVG
This
parameter
can
be
used
to
specify
the
type
of
outlines
supported
by
the
font.
Value
"TTF"
shall
be
used
when
a
font
resource
contains
glyph
outlines
in
TrueType
format,
value
"CFF"
shall
be
used
to
identify
fonts
containing
PostScript/CFF
outlines,
and
value
SVG
shall
be
used
to
identify
fonts
that
include
SVG
outlines.
TTF,
CFF
or
SVG
outlines
can
be
present
in
various
combiniations
in
the
same
font
file,
therefore,
multiple
values
for
the
same
optional
parameter
may
be
defined.
Encoding
considerations:
Binary.
Interoperability
considerations:
As
it
was
noted
in
the
first
paragraph
of
the
"Security
considerations"
section,
the
same
font
format
can
be
used
to
encode
fonts
with
different
types
of
glyph
data
represented
as
either
TrueType,
PostScript
(CFF)
or
SVG
outlines.
Existing
font
rendering
engines
may
not
be
able
to
process
some
of
the
particular
outline
formats,
and
downloading
a
font
resource
that
contains
unsupported
glyph
data
format
would
result
in
inability
of
application
to
render
and
display
text.
Therefore,
it
would
be
extremely
useful
to
clearly
identify
the
format
of
the
glyph
outline
data
within
a
font
using
an
optional
parameter,
and
allow
applications
to
make
decisions
about
downloading
a
particular
font
resource
sooner.
Please
note
that
as
new
outline
formats
may
be
defined
in
the
future,
the
set
of
allowed
values
for
the
optional
parameter
defined
in
this
section
may
be
extended.
Published
specification:
ISO/IEC
14496-22
"Open
Font
Format"
(OFF)
specification
being
developed
by
ISO/IEC
SC29/WG11.
Applications
that
use
this
media
type:
Any
and
all
applications
that
are
able
to
create,
edit
or
display
textual
media
content.
Additional
information:
Magic
number(s):
The
TrueType
fonts
and
OFF
/
OpenType
fonts
containing
TrueType
outlines
should
use
0x00010000
as
the
'sfnt'
version
number.
The
OFF
/
OpenType
fonts
containing
CFF
data
should
use
the
tag
'OTTO'
as
'sfnt'
version
number.
File
extension(s):
Font
file
extensions
used
for
OFF
/
OpenType
fonts:
.ttf,
.otf
Typically,
.ttf
extension
is
only
used
for
fonts
containing
TrueType
outlines,
while
.otf
extension
can
be
used
for
any
OpenType/OFF
font,
either
conformance
with
TrueType,
CFF
or
SVG
outlines.
Macintosh
file
type
code(s):
(no
code
specified)
@font-face
Format:
opentype
Fragment
Identifiers
none.
Person
&
email
address
to
contact
for
further
information:
Vladimir
Levantovsky
(vladimir.levantovsky@monotype.com).
Intended
usage:
COMMON
Restrictions
on
usage:
None
Author:
The
ISO/IEC
14496-22
"Open
Font
Format"
specification
is
a
product
of
the
ISO/IEC
JTC1
SC29/WG11.
Change
controller:
The
ISO/IEC
has
change
control
over
this
specification.
6.4.
WOFF
1.0
Type
name:
font
Subtype
name:
woff
Required
parameters:
None.
Optional
parameters:
None.
Encoding
considerations:
Binary.
Interoperability
considerations:
None.
Published
specification:
This
media
type
registration
is
extracted
from
the
WOFF
specification
BCP
13
at
W3C.
Applications
that
use
this
media
type:
WOFF
is
used
by
Web
browsers,
often
in
conjunction
with
HTML
and
CSS.
W3CRegMedia
.
Additional
information:
Magic
number(s):
The
signature
field
in
the
WOFF
header
MUST
contain
the
"magic
number"
0x774F4646
File
extension(s):
woff
Macintosh
file
type
code(s):
(no
code
specified)
Macintosh
Universal
Type
Identifier
code:
org.w3c.woff
@font-face
Format:
woff
Fragment
Identifiers
none.
Person
&
email
address
to
contact
for
further
information:
Chris
Lilley
(www-font@w3.org).
Intended
usage:
COMMON
Restrictions
on
usage:
None
Author:
The
WOFF
specification
is
a
work
product
of
the
World
Wide
Web
Consortium's
WebFonts
Working
Group.
Change
controller:
The
W3C
has
change
control
over
this
specification.
6.5.
WOFF
2.0
Type
name:
font
Subtype
name:
woff2
Required
parameters:
None.
Optional
parameters:
None.
Encoding
considerations:
Binary.
Interoperability
considerations:
WOFF
2.0
is
an
improvement
on
WOFF
1.0.
The
two
formats
have
different
Internet
Media
Types
and
may
be
used
in
parallel.
WOFF
2.0
is
used
by
Web
browsers,
often
in
conjunction
with
HTML
and
CSS.
Additional
information:
Magic
number(s):
The
signature
field
in
the
WOFF
header
MUST
contain
the
"magic
number"
0x774F4632
('wOF2')
File
extension(s):
woff2
Macintosh
file
type
code(s):
(no
code
specified)
Macintosh
Universal
Type
Identifier
code:
org.w3c.woff2
@font-face
Format:
woff2
Fragment
Identifiers
none.
Optional,
for
collections
encoded
as
WOFF
2.0.
A
positive
integer.
For
example,
#2
refers
to
the
second
font
in
the
collection.
If
a
fragment
is
not
specified,
it
is
the
same
as
#1
i.e.
the
first
font
in
the
collection
(or
the
only
font,
if
it
is
not
a
collection).
If
a
fragment
is
specified,
and
the
WOFF
does
not
encode
a
collection,
the
fragment
is
ignored.
Person
&
email
address
to
contact
for
further
information:
Chris
Lilley
(www-font@w3.org).
Intended
usage:
COMMON
Restrictions
on
usage:
None
Author:
The
WOFF2
specification
is
a
work
product
of
the
World
Wide
Web
Consortium's
WebFonts
Working
Group.
Change
controller:
The
W3C
has
change
control
over
this
specification.
Clarified
that
the
spec
madates
mandates
table
directory
sorting,
while
the
table
order
itself
should
follow
the
OpenType/OFF
recommended
order.
Added
requirements
for
decoders
to
accept
any
possible
encoding
variations
for
255UInt16
data
type,
recommend
that
encoders
produced
shorter
255UInt16
byte
sequences
whenever
possible.
Replaced
the
table-based
descirption
description
of
the
255UInt16
data
type
with
pseudo-code.
Added
conformance
requirements
for
UIntBase128
data
type.
Added
conformance
requirements
to
WOFF
2.0
Header
description
mandating
the
reserved
value
to
be
set
to
zero.
Added
recommendation
and
conformance
requirement
for
WOFF
2.0
encoders
to
remove
DSIG
table
and
set
the
flag
(bit
11)
of
the
font
'head'
table.
Added
conformance
requirement
for
decoders
to
store
glyph
record
offsets
in
compliance
with
the
specified
indexFormat.
Added
conformance
requirements
to
mandate
implicit
glyph
bounding
box
calculations.
Clarified
the
"Transformed
'glyf'
table"
content
adding
explicit
references
to
every
data
stream
and
their
overall
order.
Modified
the
"Transformed
'glyf'
table"
subclause
adding
detailed
description
of
the
glyph
reconstruction
process
for
empty,
simple
and
composite
glyphs.
Added
support
for
font
collections
in
WOFF
2.0.
As
part
of
font
collection
support,
added
new
requirement
to
encode
'glyf'
and
'loca'
tables
as
pairs,
with
'loca'
immediately
following
the
'glyf'
table.
Removed
the
notion
of
"nominal
size"
conformance
requirements
for
decompressed
WOFF
2.0
font
since
the
font
size
can
vary
dramatically
based
on
applied
data
optimization
steps.
type
definitions
and
reclassified
certain
user
agent
requirements
as
decoder
specific.
Clarified
the
meaning
of
the
uncompressed
font
data
size.
Clarified
the
differences
in
bounding
box
calculations
for
simple
and
composite
glyphs.
Added
4-byte
alignment
requirements
for
Extended
Metadata
and
Private
data
blocks
to
match
WOFF
1.0
Recommendation
requirements.
Added
new
appendix
A
with
the
draft
text
of
top-level
media
type
registration
for
a
new
'font'
type.
Added
this
"Changes"
appendix.
A
color-coded
diff
between
the
editors
draft
used
to
prepare
the
First
Public
Working
Draft
and
the
editors
draft
used
to
prepare
the
Last
Call
Working
Draft
(this
document)
is
available.
Added
a
note
describing
the
reasons
for
possible
variations
of
reconstructed
glyf
table
data
and
clarified
that
determining
an
adequate
size
of
memory
allocations
for
reconstructed
glyf
table
data
is
a
responsibility
of
WOFF2
decoder
implementations.
Added
a
note
describing
the
optional
pre-processing
step
that
can
be
applied
to
OpenType
CFF
fonts,
where
the
process
of
CFF
data
de-subroutinization
can
be
applied
prior
to
WOFF2
encoding
to
minimize
the
compressed
font
size.
Removed
the
notion
of
"nominal
size"
for
decompressed
WOFF
2.0
font
since
the
font
size
can
vary
dramatically
based
on
applied
data
optimization
steps,
and
removed
conformance
requirements
associated
with
the
decoder
memory
allocations
and
the
original
glyf
table
size
definition.
Added
transformation
version
indication
in
Table
directory
flags
and
added
new
subclause
5.4
with
the
description
of
the
'hmtx'
table
transform.
Updated
transformation
version
indication
in
Table
directory
flags
adding
null
trnsform
provisions
for
'glyf'
and
'loca'
tables,
added
clarifications
for
transform
of
shared
'hmtx'
table.
Added
pseudo-code
for
UIntBase128
data
type,
various
editorial
updates.
Updated
the
description
of
empty
glyph
reconstruction
process
in
'glyf'
table
transform,
added
additional
check
in
the
'hmtx'
transform
for
left
side
bearing
value
of
an
empty
glyph,
minor
editorial
updates.
Added
new
confromance
requirements
for
testing
mismatch
conditions
where
total
font
size
and
the
original
size
of
the
'glyf'
table
differ
from
the
sizes
declared
as
part
of
the
WOFF2
file
header
or
table
directory.
Added
Considerations
for
Security
and
Privacy
appendix.
Referenced
new
font/*
top
level
type
being
developed
at
IETF,
trimmed
Internet
Media
Type
registration
appendix
to
just
WOFF
2.0.
Appendix
C.
Considerations
for
Security
and
Privacy
Does
this
specification
deal
with
personally-identifiable
information?
No.
Does
this
specification
deal
with
high-value
data?
No.
Credit
card
information
and
the
like
is
not
stored
in
WOFF2.
Does
this
specification
introduce
new
state
for
an
origin
that
persists
across
browsing
sessions?
No.
Specifically,
WOFF2
fonts
are
only
available
to
the
documents
that
reference
them;
they
do
not
persist
for
use
by
other
applications
or
documents
on
the
user's
system.
Does
this
specification
expose
persistent,
cross-origin
state
to
the
web?
No.
Does
this
specification
expose
any
other
data
to
an
origin
that
it
doesn’t
currently
have
access
to?
No.
Does
this
specification
enable
new
script
execution/loading
mechanisms?
No.
WOFF2
fonts
do
not
contain,
or
link
to,
scripts.
Does
this
specification
allow
an
origin
access
to
a
user’s
location?
No.
Does
this
specification
allow
an
origin
access
to
sensors
on
a
user’s
device?
No.
Does
this
specification
allow
an
origin
access
to
aspects
of
a
user’s
local
computing
environment?
No.
WOFF2
fonts
are
typically
generated
and
stored
on
a
server,
and
have
no
access
to
the
user
environment
when
generated.
Once
decompressed,
they
contain
no
active
code
and
cannot
inspect
the
user
environment.
Does
this
specification
allow
an
origin
access
to
other
devices?
No.
Does
this
specification
allow
an
origin
some
measure
of
control
over
a
user
agent’s
native
UI?
No.
Does
this
specification
expose
temporary
identifiers
to
the
web?
No.
Does
this
specification
distinguish
between
behavior
in
first-party
and
third-party
contexts?
No.
How
should
this
specification
work
in
the
context
of
a
user
agent’s
"incognito"
mode?
No
differently.
Does
this
specification
persist
data
to
a
user’s
local
device?
No.
Does
this
specification
have
a
"Security
Considerations"
and
"Privacy
Considerations"
section?
Yes.
Does
this
specification
allow
downgrading
default
security
characteristics?
No.
The
Security
section
of
the
font
top
level
type
[
JustFont
]
contains
additional
security-related
information
relevant
to
WOFF2.
WOFF2
uses
Brotli
compression.
The
Security
Considerations
section
of
the
Brotli
specification
[
Brotli
]
should
be
consulted,
in
addition
to
this
appendix.
References
Normative
References
[WOFF1]
WOFF
File
Format
1.0
Jonathan
Kew,
Tal
Leming,
Erik
van
Blokland,
Editors.
World
Wide
Web
Consortium,
13
December
2012.
The
latest
version
of
the
WOFF
specification
is
available
at
http://www.w3.org/TR/WOFF/
MicroType®
Express
(MTX)
Font
Format
Sarah
Martin,
Al
Ristow,
Steve
Martin,
Vladimir
Levantovsky,
and
Christopher
Chapman.
W3C
Member
Submission,
5
March
2008.