►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
On
a
new
transfer
mechanism
for
fonts
and
then
so,
maybe
just
to
start
I'll,
give
a
little
bit
of
like
justification
for
why
this
is
something
that
we're
working
on.
So
a
really
good
example
is
with
things
like
cjk
fonts,
so
that's
chinese,
japanese
and
green.
So
these
are
fonts
that
have
you
know
over
could
be.
You
know
as
much
as
like
say:
60
000,
characters
in
a
font,
and
so
when
you're
using
the
you
want
to
use
these
web
fonts
on
your
page.
A
Typically
most
pages,
maybe
you
only
need
say
a
thousand
of
those
characters
at
any
given
time
so
kind
of
the
really
naive
way
to
approach.
This
is
to
just
load
the
whole
font,
which
is
probably
several
megabytes,
but
you
only
actually
use
some
small
part
of
it.
So
this
is
quite
wasteful,
and
so
there
has
been
some
attempts
to
solve
this
over
the
years.
A
The
most
notable
one
is
unicode
range
where
you
can
segment
the
font
up
into
you
know
some
different
subsets,
so
just
pieces
that
have
less
than
the
full
set
of
characters,
and
then
the
unicode
range
mechanism
allows
you
to
download
just
those
pieces
that
you
need.
So
this
certainly
is
better
than
kind
of
just
sending
the
whole,
but
it's
still
not
ideal.
A
It
still
usually
ends
up
sending
way
more
than
you
need
and
there's
also
a
lot
of
issues
that
come
up
when
there's
interactions
between
characters
that
are
in
different
subsets,
since
those
no
longer
work.
So
in
you
know
some
scripts
like
say,
arabic,
there's
a
lot
of
interactions
between
characters,
so
you
can't
break
those
characters
up
into
different
subsets.
A
So
incremental
font
transfer
is
an
attempt
to
kind
of
solve
this
problem.
Kind
of
you
know
really
well,
and
so
the
the
general
idea
of
how
it
works
is
you
leave
the
font
as
one
full
googly
unit
and
then
your
client
loads
parts
of
the
font.
You
know
so
you
have
a
page.
You
have
some
characters,
you
load
just
the
characters
needed
for
for
that
page
and
then,
when
you
go
to
say
another
page
or
see
new
content,
you
can
patch
in
more
data
from
that
font.
A
So
this
allows
you
to
grab
just
what
you
need
at
any
given
time
and
it
keeps
all
those
two
inter-character
interactions
intact.
So
the
font
works
exactly
the
way
it's
supposed
to,
and
so
maybe
before
diving
into
the
kind
of
a
bit
more
of
the
details
of
what
we're
actually
doing
in
the
spec.
I
can
give
a
quick.
We
have
a
demo
that
we
built
in
webassembly
of
this
kind
of
working
in
a
browser,
so
I'll
do
a
quick
demo
of
that
just
to
show
how
that's
going
to
work.
A
Okay,
all
right,
so
what
this
this
demo
does
is
it
just
goes
through
a
few
different
pages
of
content.
It
loads
the
fonts
needed
to
show
that
content
using
both
the
incremental
transfer
and
then
the
old.
The
unicode
range
approach
that
I
talked
about,
and
then
it
shows
you
a
comparison
of.
You
know
how
you
know
how
much
data
each
one
loaded-
and
this
is
this-
has
actually
loaded
the
font
from
the
server
it's
patching
it
in
and
creating
fonts.
A
Okay,
so
we
can
go
to
the
we
go
to
the
first
page
here,
so
we
can
see
so
you
know
good
range
grabbed.
A
font
file
that
was
32,
kilobytes
incremental
transfer,
grabs,
11
kilobytes
for
the
fonts,
and
you
can
actually
see
here
in
the
inspect
tab.
These
are
the
incremental
requests.
So
there's
two
fonts
on
here
both
about
five
kilobytes
of
data
were
loaded
for
those.
A
Okay
and
then
so
I
went
to
another
page,
so
this
introduces
a
few
characters
that
weren't
in
that
last
subset
that
were
graphed.
So
you
can
see
incremental
transfer
now
sent
out
a
couple,
much
smaller
requests.
Just
to
add
in
that
extra
data.
That's
missing,
whereas
something
like
unicode
range
here,
since
it
already
kind
of
grabbed
one
big
subset
didn't
do
anything
and
then
we
can
kind
of
carry
on
and
it
can
grab
a
little
grab
additional
data.
A
As
you
get
new
things
and
then
now
we
hit
a
new
language
and
so
unicode
rage,
since
this
has
needed
a
new
subset
grabbed
a
whole
new
subset,
whereas
incremental
transfer
just
patched
in
a
small
amount
of
data
to
add
the
all
these
accented
characters
and
then
same
with
cyrillic.
A
Here's
the
next
one
yeah
so
this
so
this
button
here
allows
me
to
toggle
between
displaying
the
font,
both
with
you
know,
the
font
built
from
the
patch
and
the
font
built
from
unicode
range
and
there's
something.
This
demonstrates
a
little
interesting
thing
and
this
touches
on
the
problem.
I
mentioned
about
inter-character
interactions.
A
So
if
you
look
at
the
the
period
and
the
and
the
y
character
in
the
title
here,
you'll
notice
that
when
we
go
to
unicode
range,
things
are
shifting
around
and
that's
because
the
cyrillic
characters
earn
a
different
subset
than
the
latin
characters
within
a
good
range.
So
the
kerning
rules
between
those
characters
don't
work,
whereas
with
incremental
transfer,
we've
managed
to
retain
them,
and
so
we
get
the
proper
carding.
A
Okay,
now
we
can
move
on
to
something
much
harder,
and
this
is
chinese,
and
so
here
we
can
see
this
is
this
is
using
our
production
unicode
range
solution
that
we
use
on
google
fonts,
and
you
can
see
you
know
just
for
this
small
amount
of
text.
It's
grabbed.
A
I
think
you
know
about
six
or
seven
hundred
kilobytes
of
data
just
to
show
this,
whereas
with
incremental
transfer
we're
able
to
grab
a
much
smaller
amount,
and
then
this
gets
worse
as
we
introduce
new
characters
where
synchrometer
transfer
is
able
to
usually
patch
in
small
amounts.
A
Okay
and
then
the
last
one
we
think
another
really
interesting
application
for
this
is
with
emoji.
So
there
are
lots
of
emoji
and
you
know
in
any
given
context.
You
probably
only
need
a
small
handful
of
them,
so
you
know
with
incremental
transfer
we
can
grab
just
you
know
the
emojis
that
we
need
for
any
given
situation
instead
of
grabbing
the
entire
font,
which,
as
you
can
see
from
the
unicode
range
site,
is
quite
large.
A
Okay,
so
that's
the
the
that's
it
for
the
demo
here
so
I'll,
just
close
that
out
and
then
okay.
So
let's
talk
about
what's
actually
going
on
under
the
hood
here,
what
the
the
specification
kind
of
is
specifying,
so
the
specification
actually
gives
two
different
methods
for
doing
incremental
transfer,
and
so
maybe
first
off
we'll
talk
about
why
we
have
two.
A
So
the
the
first
method
which
we
call
patch
subset
is
was
shown
you
know
through
simulations
and
stuff
to
be
pretty
much.
You
know,
as
far
as
you
know,
in
terms
of
how
much
data
transferring
is
superior
to
the
other
method,
but
it
has
a
pretty
significant
downside
in
that
it
requires
a
fairly.
A
You
know:
intelligent
server
to
be
run.
You
know.
So,
if
you're,
you
know
you're
somebody
who's,
just
running
your
content
on
a
cdn
and
you,
you
know,
you
can't
have
them
run
a
complicated
server
for
you.
This
sort
of
option
is
not
going
to
work,
even
though
you
know
it's
more
efficient.
A
So
then
we
also
including
a
second
method
range
request,
which
you
know
the
server
side
just
needs
to
be
any
old
http
server.
That
supports
range
requests
for
tall
work
and
it
won't
be
as
efficient
as
the
first
one,
but
at
least
it
will
give
options
for
people
to
use
this
technology.
You
know
if
they're,
you
know
restricted
in
what
they
can
do,
okay.
A
So
then
I
probably
should
talk
about
the
two
methods,
and
I
think
I
see
miles
on
here,
so
he
can
probably
talk
about
range
requests
after
me,
if
he's
up
for
it,
okay,
suddenly
yeah
yeah,
okay,
great,
so
the
the
first
method,
the
kind
of
the
more
efficient
one
is
patch
subset,
and
so
how
this
works
is
the
client
sends
a
request
that
says:
okay,
I've
got
a
font
that
has
these
specific
code
points
in
it,
and
I
need
it
to
also
cover
these
additional
code
points
and
then
the
server
side
and
in
real
time
we'll
create
two
subsets
of
the
font.
A
One
at
the
state
client
is
currently
at
and
one
at
the
state
where
they
want
to
be
then
we'll
generate
a
binary
patch
in
this
case,
using
shared
broadly
and
then
send
that
to
the
client
and
then
the
client
will
apply
that
to
their
font
and
that
will
upgrade
their
font
to
that
extended
subset.
So
that's
the
the
gist
of
how
that
works,
and
then
miles.
If
you
want,
you
can
talk
about
range.