Notes from the f2f meeting in Portland

Took some notes from the F2F meeting in Portland. Mostly paraphrasing, yell
at me if I misrepresented something :)

(The presentation used here will be shared later)

Fil, David, Raph and Kenji from Google presenting status on WOFF 2.0

Fil: Woff 2.0 implementation is currently behind the experimental flag
This is part of our move to Blink as opposed to WebKit where we decided to
avoid vendor specific prefix and use this experimental flag instead

Re webfonts, took a step back and thought about what we are actually
looking for in terms of serving fonts. File size is obviously one. Speed of
compression is less important for us. Decompression on the other hand is
important. Especially on mobile (CPU, battery).

Fil: in order to get Woff 2.0 enabled by default we ran into issues. First
one is issues inherent with LZMA. Lack of documentation is one. If you go
to wikipedia and try to find out how it works, you only get a couple of
bullet points. Another point where the lack of documentation was security
review. Reach out to the author (Igor Pavlov) and pitch the idea of getting
a specification but didn't work out

Another issue with LZMA is that it is slow to decompress (20-30MB/s).

Question (from ?): is the speed for mobile, high end desktop?

Raph: this is for desktop. On mobile this would be even more a concern.
Decompression is typically single core code so that the diff between high
end and mid range desktop would not be significant.


Raph: getting LZMA on track would have taken a lot of time

Fil: so we reached out to our internal mailing list for misc engineering
topics and reach out to find an alternative. Got feedback from a
compression team in Zurich. They considered modifying an existing algorithm
(Flate). This already has a specification. This team was behind Zopfli,
this is the new proposal named Brotli. All of those are named after swiss
bread. They also worked on webp. Trade some file size for faster
decompression speed and specification.

Raph: basically, brotli is a variant of Flate. First thing, a larger
window. Even mobile phones can afford a larger window size. This is a very
simple change. Zip has an inefficient switching between compressable and
non compressable parts. Has LZ4 which helps on that front. Borrows from
LZMA for short distance codes.

Fil: the prototype already has the first 3 bullets

Raph: 4.5. (...entropy  explanation...)

Raph: 6. 7. those would probably not end up in the specification.
zopflication is trying to do an exhaustive search => 5% gains but extremely
slow.

Myfont: the compression is complex but the decompression is much simpler
and fast

Raph: yes

Chris (w3c): (similar to png tools)

Raph: yes, but it goes even deeper.

Fli: in the current proto the first 3 bullets are implemented. Here we have
initial results from that prototype. So this is not representative yet but
thought it would be nice to have some numbers

Fil: next step is to have a spreadsheet covering all our fonts with
different algo and summarize our findings. Large window flate is 16%
higher, our current Brotli is a bit smaller (13%) but we are confident that
we can brought this number down some more.

Raph: this is just important to get a sense of where things are going.

Vlad: which font was used?

Fil: this is for the whole directory

Chris: comparison with WOFF 1?

Raph: should not be hard to beat

Fil: don't have it but could have something by dinner time

David: reference font compression is available and what we did in hte past
was to ask other fonts services to run the tool and share number

Fil: (decompression performance slide). those should have ~ in front but
typically we see 20-30MB/s for LZMA and 120-300MB/s NewFlate

Raph: decompression is not easily optimizable for multi core scenario;
compression on the other hand is.

Vlad: would be interesting to see best case worst case scenario

Raph: the difference is inherent to how Flate and LZMA work on
decompression. For LZMA the decoding is done bit by bit so we would not
expect huge breakthroughs to close the gap.

David: one direction with LZMA that we considered explore down the road was
to cache the decompressed fonts but then it makes the implementation more
complex and you have questions about how you protect the fonts in case it's
licensed. With this proposal, optimizations of that kind are not needed
since decompression is fast.

Raph: original spec for WOFF 2 has room for specifying the compression
algorithm. The use case was for mobile where you might want to use gzip to
save on CPU/battery at decompression time. But since brotli dominates in
both file size and decompression time this is probably not needed.

Kenji: (talked about Chrome commitment and metrics; couldn't take notes
while speaking ;)

Chris: about the name Brotli. Is this a trademark?

Fil: this is a swiss bread.

David: we will be able to get download measurement on a couple of file size
bins for fonts. This is important to balance file size vs. decompression
time.

Fil: timeline, tentative. Soon: more performance data. Next 6 weeks: ref
implementaiton should be done. Following 6 weeks: jyrki works on
specification. Told me he already has something going.

Raph: yirki has the experience. he's done this twice. We also have
experienced folks.

Fil: in parallel, we want to have this behind the flag in Chrome for the
november release.

(discussion about referencing exisiting spec)

Raph: (yes). Also brotli has potentially other implications for other use
cases. This is general compression work that has the potential to be useful
elsewhere. Webfonts is a way to fast track this and get insights. From
there we could take a look at other opportunities. This is probably beyond
the scope of this group (but the potential is there).

Vlad: (compression is indeed in scope).

Chris: "we could have it here" doesn't necesseraly means that this is
correct. It could be in IETF etc. Also, talking about additional
opportunities might results in lots of opinions (possibly pushing the
timeline).

Raph: the specification will probably support both assymetric and symmetric
modes. but we need to experiment first.

Adam or Joe: what about the LZMA woff 2.0

Raph: LZMA should be considered as the experiment; LZMA does indeed
produces smaller file size but there are downsides. We believe that
NewFlate/Brotli is the right direction.

Chris: (pointing the security issue with LZMA)

Raph: (repointing that the security aspects were indeed concerning since
without a spec we would not have an easy way to tell this is valid input
and this is not).

Chris: also decompression times was a concern...

Raph: yes. No promise but we think we will be able to get within a 5% delta
of LZMA in terms of file size.

Daniel: would we have comparison with microtype?

Raph: (yes, doable).

Chris: needs to be careful in presenting the data


-- 
Kenji BAHEUX
Product Manager - Chrome
Google Japan