Telcon minutes, March 26

Thank you all for joining the call and for interesting and engaging discussion.

The minutes are available online @ http://www.w3.org/2014/03/26-webfonts-minutes.html
and as plain text below:

                               - DRAFT -

                 WebFonts Working Group Teleconference

26 Mar 2014

   See also: [2]IRC log

      [2] http://www.w3.org/2014/03/26-webfonts-irc

Attendees

   Present
          Vlad, [Microsoft], jfkthame, [Google], +1.250.668.aaaa

   Regrets
   Chair
          SV_MEETING_CHAIR

   Scribe
          rapph_, raph_

Contents

     * [3]Topics
     * [4]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 26 March 2014

   <raph_> first agenda item: applause

   <Vlad> scribenick: rapph_

   <raph_> scribenick: raph_

   going from discussion to first editor's draft is major progress

   now that we have it written down, there'll be plenty to talk
   about

   who has reviewed the spec?

   kuettel, jfkthame, and sergeym have done cursory review

   vlad has done a full pass over the spec, and has a number of
   comments, both editorial and deeper

   introduction should have reference to woff 2 evaluation report

   datatypes

   should, as much as possible, use same datatypes as opentype and
   off specs

   mixed used of USHORT and UINT16, should settle on one

   this is a terminology question

   raph: agree, should use opentype terminology for these types

   datatype uintbase128

   what is the motivation for introducing it?

   used only in table directory

   is there a real statistical importance that there are many
   lengths that are <=127

   in original opentype spec, 4 byte values

   <kuettel> raph: one use case, really small subsets

   <kuettel> raph: for these fonts, the overhead of the table
   header is a large %

   <kuettel> raph: also see other fonts, where many tables have a
   small length (e.g. heea)

   <kuettel> raph: most tables, except for Glyph, will have a two
   byte encoding

   <kuettel> raph: original proposal had a long and short table
   format (similar to WOFF 1.0)

   <kuettel> raph: difference was typically 200 bytes

   <kuettel> vlad: would be good to elaborate on this particular
   data type

   <kuettel> raph: sounds good, should be easy to quantify the
   size reduction

   <kuettel> vlad: going further, paragraph with the flags

   <kuettel> vlad: e.g. known table tags

   <kuettel> vlad: would we regret this later, esp. as new tables
   are added (e.g. color fonts)

   <kuettel> raph: right, great question

   <kuettel> raph: the thinking is, that the list of tables -- we
   will see more fonts with additional tables

   <kuettel> raph: but, the majority of the tables will still be
   in the OpenType spec

   <kuettel> raph: vast majority of tables on the list were from
   the standard

   <kuettel> raph: have to come up with a set (justification is
   the number of bytes saved)

   <kuettel> raph: any new table would get passed through, it just
   wouldn't benefit from this particular four-byte per table
   savings

   <kuettel> jonathan: asking about the number of bits required to
   encode...

   <kuettel> raph: original motivation, was to support multiple
   compression formats

   <kuettel> raph: proposal is to only support Brotli (and not
   gzip)

   <kuettel> vlad: as a follow up, did not appear as if the last
   to bits were not for the compression type

   <kuettel> raph: yes, compression type proposal (Brotli) only,
   is encoded in the draft

   <kuettel> vlad: both bit allocation for table tags, and bit 5
   for pre-processing, identified for future discussions

   <kuettel> vlad: wouldn't it be easier to always process all
   tables

   <kuettel> raph: minimizing option is a good goal. motivations
   was to allow trade-off between processing time/memory

   <kuettel> raph: another would be to preserve byte level data

   jfkthame: similar tradeoff as in choice of entropy coder

   vlad: transform is much less computation than entropy coding

   jfkthame: impact on encode time is one reason people may choose
   less expensive processing

   <kuettel> vlad: bringing discussion back to preprocessing

   <kuettel> raph: reconstructing the bounding boxes is not trivial

   <kuettel> raph: could be good to review the data

   <kuettel> raph: use cases for fast encoding, or want to enable
   fast decode (e.g. for mobile)

   <kuettel> raph: complexity of not having the transform (e.g.
   the bit) is trivial

   <kuettel> vlad: agree, rather wondering if preprocessing could
   always be kept

   <kuettel> vlad: would like to give the working group more time
   to review, and then once decided would likely want to elaborate

   vlad: section 4 should be "compressed data format" rather than
   "general table format
   ... description of bitmask should be part of glyph header

   raph: agree, was concerned about the fact that bitmask is
   variable size, but having it part of header is cleaner

   vlad: "explicity bitmap" seems like typo

   raph: yes, should read "explicitly set bounding box" instead

   <kuettel> raph: would like to ask working group, does the draft
   look pretty complete

   vlad: reasonably complete, we know some pieces are missing
   (like triplet encoding)

   <kuettel> vlad: looks pretty complete, noting the few sections
   called out in the document that we need to fill in

   vlad: some more things that need to be discussed

   will need to go through and make sure all normative statements
   are properly defined

   that may happen after public working draft

   <kuettel> raph: update from the Compression Team on Brotli.

   <kuettel> raph: they consider the format final now, and will
   next focus on publishing the IETF draft

   kuettel: how many compression formats should we support?

   can we standardize on just Brotli?

   vlad: woff 1 offers no compression and gzip

   so need to offer these options in woff 2 doesn't make much
   sense

   significant improvement in compression efficiency was main
   motivation for woff 2

   vlad: votes for "keep it simple"

   kuettel: compression team provided numbers on compression
   performance

   fast brotli encoder gets 10% better compression than gzip at no
   additional cost in encode time

   numbers to be pasted into chat

   <kuettel> Some numbers from the Compression Team on the Brotli
   fast version:

   <kuettel> woff2/gzip: 60,844,848 bytes, 13.6 Mb/s encoding
   speed, 104.2 Mb/s decoding speed

   <kuettel> woff2/brotli: 54,232,880 bytes, 13.2 Mb/s encoding
   speed, 84.4 Mb/s decoding speed

   <kuettel> And then an update on the slow version:

   <kuettel> the decoding speed of woff2 produced with a slow
   brotli encoder got faster as well, it is now 80.6 Mb/s, while
   the total corpus size is 50,112,368 bytes.

   vlad: extra bit freed up for compression type may help expand
   known tags
   ... we should consider the question of whether to make glyf
   transform optional (current draft) or required

   implementation an option to give less than maximal compression
   seems counterintuitive

   vlad: doesn't like optional stuff
   ... would rather avoid it

   jfkthame: that decision needs more time to think through

   vlad: raising issue, not expecting a decision today

   jfkthame: another change to wire format to propose

   flags in table directory entry

   only thing doing with bits 6 and 7 is noting whether table is
   first in the font

   and the only thing that's used for is whether to include
   compressed stream length

   would be simpler to move into woff header, and this would also
   free up an additional bit

   vlad: what is value of having table directory preserved?
   ... compressed data stream might include table directory

   in mtx, everything was part of compressed stream, including
   table directory

   <kuettel> Sorry, I have to join another meeting

   jfkthame: woff2 header could also (mostly) be inside

   raph: metadata could also be inside compressed stream

   vlad: makes sense for metadata to be separately accessible

   use cases where you want to read metadata without having to
   decompress entire font

   jfkthame: metadata should be brotli-encoded

   raph: yes, already in spec

   vlad: will be traveling next week for iso/mpeg meeting,
   finalizing 3rd edition of OFF spec
   ... let's have more discussion over email

   then telcon will be more productive

   next conference call in 2 weeks, have discussion of specific
   items during that time

   raph: i hope to check spec into W3C CVS soon

   end of call

Summary of Action Items

   [End of minutes]