<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 trival

<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 trival

<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

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: rapph_
WARNING: No scribe lines found matching ScribeNick pattern: <rapph_> ...
Found ScribeNick: raph_
Inferring Scribes: rapph_, raph_
Scribes: rapph_, raph_
ScribeNicks: rapph_, raph_

WARNING: No "Topic:" lines found.

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

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 26 Mar 2014
Guessing minutes URL: http://www.w3.org/2014/03/26-webfonts-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report