Re: Minutes, 28 October f2f meeting

Thank you Chris for scribing and once again making our WG work/life so much easier! 

I also would like to thank David and Rod for organizing the meeting and to Google or hosting us. 

Thank you,
Vlad

> On Oct 28, 2014, at 10:52 AM, "Chris Lilley" <chris@w3.org> wrote:
> 
> Hello Public-webfonts-wg,
> 
> Minutes at
> http://www.w3.org/2014/10/28-webfonts-minutes.html
> 
>                 WebFonts Working Group Teleconference
> 
> 28 Oct 2014
> 
>   See also: [2]IRC log
> 
>      [2] http://www.w3.org/2014/10/28-webfonts-irc
> 
> Attendees
> 
>   Present
>   Regrets
>   Chair
>          Vlad
> 
>   Scribe
>          ChrisL
> 
> Contents
> 
>     * [3]Topics
>         1. [4]compression
>         2. [5]nominal size
>         3. [6]ttc
>         4. [7]testing
>         5. [8]ttc
>         6. [9]recap
>     * [10]Summary of Action Items
>     __________________________________________________________
> 
>   <trackbot> Date: 28 October 2014
> 
>   <scribe> Meeting: WebFonts f2f meeting, California
> 
>   <scribe> scribenick: ChrisL
> 
> compression
> 
>   zoltan: excited to see woff progress. http compression is
>   helped by a command line tool separate from font use. compiled
>   and ready to go
>   ... ideas to improve the faster codec
>   ... slower one is the open source one, has better compression
> 
>   vlad: will the faster one be shared also?
> 
>   zoltan: yes
> 
>   vlad: compression is good but slow, people complain
> 
>   zoltan: faster codec uses a lot of ram
> 
>   raph: same wire format?
> 
>   zoltan: yes, but does not use all compression features
> 
>   raph; any spec changes for this?
> 
>   zoltan: no
> 
>   vlad: I have a gift. its a big font. please compress, it
>   crashes on compression
> 
>   ChrisL: good to get the brotli results for monotype, adobe, and
>   the two fond providers
> 
>   zoltan: paged mark adler and asked if he would review it, no
>   response yet
>   ... he reviewed webp lossless, is a great reviewer
> 
>   ChrisL: asked j-l gailly?
> 
>   zoltan: yes, no response
>   ... he is not working on compression since 2006
>   ... mark adler is still actively involved
> 
>   kuettel: show the new top-level brotli site
> 
>   <raph> [11]https://github.com/google/brotli
> 
>     [11] https://github.com/google/brotli
> 
>   <raph> (soft launch for now)
> 
>   (discussion on open sourcing the fast codec as well)
> 
>   <kuettel> Kenji found the following JavaScript wrapper
>   implementation via Google Alerts:
>   [12]https://www.npmjs.org/package/brotli
> 
>     [12] https://www.npmjs.org/package/brotli
> 
>   kbx: there is a javascript one
> 
>   (discussion on whether this is a wrapper, a port or a new impl)
> 
>   links to
>   [13]http://www.ietf.org/id/draft-alakuijala-brotli-02.txt which
>   is the third version
> 
>     [13] http://www.ietf.org/id/draft-alakuijala-brotli-02.txt
> 
>   behedad: want to make sure the chrome deployed code matches the
>   repro
> 
>   Vlad: binary mode should not be used for metatata, myfonts is
>   adding woff metadata
> 
>   zoltan: decompression is the same either way
> 
>   raph: tools should be updated to use the best mode
> 
>   behedad: any plan to adress compression startup time?
> 
>   zoltan: not planned currently but we could do
> 
>   kbx: open bug on chrome to switch to new github brotli, do it
>   now?
> 
>   zoltan: yes
> 
>   behedad: chrome uses the copy in ots
>   ... which gets used in firefox and chrome
>   ... what is the testing plan to avoid regressions over time
> 
>   kuettel: current reference is good at doing round trip sanity
>   checks
> 
>   behedad: hard to see if patches break anything
> 
>   (discussion on open sourcing the brotli test data)
> 
>   kuettel: there is a new project for woff2 which is unpopulated
>   yet
> 
>   behedad: reference should be updated and ots updates from that
> 
>   raph: and right now there is some divergence
> 
>   behedad: firefox uses the github fork, chrome has not updated
>   yet
> 
>   zoltan: mostly encoder changes, minor improvements
> 
>   behedad: brotli we need to get to users for adoption
> 
>   Vlad: best for brotly to have the fast compression released
>   asap otherwise they think its always slow
> 
>   behedad: startup takes two seconds, for the text mode
> 
>   raph: static content can use the slower compression for best
>   compression
>   ... startup hit is for text mode only
> 
>   zoltan: can remove dict transforms to speed it up
>   ... 100 times faster
>   ... loose 0.5% on compression
> 
>   Vlad: for dynamic compression of a font subset, that balances
>   some of the compression loss
> 
>   kbx: is there an advantage to using text encoding?
>   ... for html, css, javascript
> 
>   zoltan: much better for a few k of text
> 
>   Vlad: between text mode and binary mode brotli?
> 
>   zoltan: uses utf-8, using static disctionary or not
>   ... static very good for vocabs like css, html etc
>   ... can give 30% in binary size
>   ... decompress is faster if a dict was used. so slow encode
>   gives fast decode
>   ... memcpy of dict entries
> 
>   Vlad: at some point can brotli be an ISO standard via MPEG,
>   lots of compression experts
> 
>   zoltan: could do but dont want to spend a lot of time there
> 
>   Vlad: ground is prepared, takes about 18 months elapsed,
>   process wise
> 
>   behedad: not clear what the value of ISO standardization is
> 
>   Vlad: iptv for example uses only ISO standards
> 
>   (discussion on value of iso standards)
> 
>   (chris updates woff spec to point to brotli -02)
> 
>   <raph> (shouldn't you point to
>   [14]http://www.ietf.org/id/draft-alakuijala-brotli which is
>   always the latest draft?)
> 
>     [14] http://www.ietf.org/id/draft-alakuijala-brotli
> 
>   (reminiscences on PFR)
> 
>   (hmm maybe)
> 
>   (except the reference needs a date)
> 
>   <raph> (ah)
> 
> nominal size
> 
>   raph: size of reconstructed tt data is tricky as many
>   decompressions with same semantic meaning on point data
>   ... encoding of flags bytes, alighnment and padding
> 
>   Vlad: and coordinate point representation
> 
>   raph: more about the flags than the coordinates
> 
>   behedad: we already aboid unecessary padding
> 
>   raph: goal on nominal size is to allocate a chunk of memory and
>   know how much is required for an unsophisticarted decoder and
>   not reallocate
>   ... and also to decide not to decompress
> 
>   ChrisL: no guarantee its big enough
> 
>   Vlad: incoming size is known, efficiency is not known
>   ... nominal size amy be enough but is not a guarantee
> 
>   raph: can be a guartantee
>   ... its modelling a simple but not brain-dead decoer. always
>   most compact point rept, greedy flags
>   ... recommended alignment (in OT is obselete)
>   ... ultimate gosl is a rel impl will get inside the nominal
>   size without much work
> 
>   its therefor e anominal not a minimal size
> 
>   Vlad: create an open ended environment, impl makes its own
>   choices on how efficient to be
>   ... security aspect of review means buffer overrun is an issue
>   ... conern was a false sense of security about overrun
> 
>   raph: level of guarantee: nominal size is deterministic. algo
>   produces the nominal size. its not the original size.
>   ... and that size is easy to get smaller than
>   ... impl can reallocate, or can ignore and do dynamically. so
>   no harsh requiremment
>   ... can alloc to nominal size and will use some size less than
>   that
>   ... if so its guaranteed not to get larger
>   ... if you do, and exceed it, the font can be rejected as
>   invalid
> 
>   ChrisL: the invalid if over makes me a lot more comfortable
> 
>   behedad: can argue problem outweighs benefits
> 
>   Vlad: if you can modify the text to make it clear that it helps
>   implementors
>   ... that bit is informational
>   ... then define the nominal size and give the algorithm and has
>   no smarts
> 
>   so if you ever go over that the font is invalid
> 
>   raph: ok that makes sense
>   ... first impl just used the original size, as it is known
>   ... decoder used 4byte alignment, and so we tended to run over
>   and fsail
>   ... not so much on flags, but the alignment
>   ... many fonts have tighter alignment
>   ... chrome decoder switched to 2 byte alighnment.
>   ... (long and short loca tables) hyper omptimizer may choose a
>   1 byte alighnment omn larger tables
>   ... so around november 2013 there was a normalizer which
>   computed the nominal sise in the encoder
>   ... except currently specced to 4 byte alignment, should be 2
>   ... released encoder computes true nominal size, so guaranteed
>   not to reject
>   ... deployed decoders use a 2 byte alignment
> 
>   "original" length is actually nominal length
> 
>   raph: original length should be discarded, and encode only
>   nominal length
> 
>   Vlad: only if its a 100% giuarantee
> 
>   raph: it is
> 
>   RSheeter: so we add MUST reject if larger
> 
>   (yes)
> 
>   ACTION raph to work with vlad to clarify all uses of original
>   length
> 
>   <trackbot> Created ACTION-153 - Work with vlad to clarify all
>   uses of original length [on Raph Levien - due 2014-11-04].
> 
>   raph: better to rename rather than clarify. so change it to
>   decoded length
> 
>   behedad: impl may have to go from 2byte to 4byte and then will
>   need to overide that value if its 130k or larger
> 
>   raph: in that case need to rewrite local table
> 
>   behedad: should ignore what head dtable says depending on what
>   you are decoding to
>   ... set to ewhat they are using in the decoder
> 
>   Vlad: if you are right on the boundary)
> 
>   behedad: must not reject the font in tht case
> 
>   raph: agree this is what we should do
> 
>   or make the loca table agree with the nominal
> 
>   Vlad: its decoder specific
> 
>   raph: do want tocheck chrome impl decodes when the loca table
>   format is wrong at the 130k boundary
> 
>   Vlad: proper for spec t glag that
> 
>   raph: easy for an impl to miss
> 
> ttc
> 
>   RSheeter: seemed to work, but should we or not
> 
> testing
> 
>   (explains how woff1 worked)
> 
>   <scribe> ACTION: chris to make a w3c woff2 test repo [recorded
>   in
>   [15]http://www.w3.org/2014/10/28-webfonts-minutes.html#action01
>   ]
> 
>   <trackbot> Created ACTION-154 - Make a w3c woff2 test repo [on
>   Chris Lilley - due 2014-11-04].
> 
> ttc
> 
>   raph: no language for ttc is in the current spec. nice to have,
>   covers all of OT standard
>   ... no browsers do ttc
> 
>   Vlad: concluded earlier its nice to have, forn collections not
>   ttc
> 
>   raph: actually OTC
> 
>   Vlad: iso v3 now just calls them collections
>   ... in woff1 were not supported sand noone cared
>   ... expect collections become more widely used, so should not
>   be impossible
> 
>   raph: expands woff2 over woff1
> 
>   Vlad: any wire format changes?
> 
>   raph: yes
> 
>   RSheeter: same for things that are not collections
>   ... flavor in woff2 header, look for collection
> 
>   (we check about flavor)
> 
>   raph: ttc flavor is not normative
> 
>   Vlad: flavor is sfnt version
> 
>   behedad: first 4 bytes defines collection
> 
>   raph: sfnt version is not as normative way to distinguish ttc
>   ... can use for all fonts we know. ttc tag does not go into
>   woff2 header
> 
>   RSheeter: flavor of the parts of the collection ges elesewhere
> 
>   raph: extended table forma t with duplicated blocks
> 
>   RSheeter: not clear if only one of loca and glyf is shared
> 
>   behedad: what does otc use as a tag?
> 
>   RSheeter: some smaller sample files would help
> 
>   ChrisL: we are ahead of the browsers here. there is no reqt to
>   support ttc in browsers
> 
>   Vlad: ttcf is iused for ot collections as well
> 
>   behedad: is it right to do this now, its less mature. argued
>   for this in woff1. why not do it separately
> 
>   kbx: how do you use it in css
> 
>   (a fragment identifier)
> 
>   (discussion on ttc use cases, mostly on ideographs)
> 
>   Vlad: collections not much in use but increasing, eg for
>   traditional and simplified chinese
>   ... could recharter to add as a new work item.
> 
>   (rechartering risk analysis)
> 
>   Vlad: we can reserve on flavor
> 
>   kuetel: agree with ChrisL its better to do now from a
>   marketing/adoption perspective
> 
>   resolved: we will support collections in WOFF 2.0
> 
>   raph: will do code review on RSheeter prototype
>   ... about a page of spec added
>   ... one para defining what to do on flavor
>   ... there is aproposal in email, uses indices not byte offsets
>   so no overlap
> 
>   behedad: can you load one face without loading the other faces
> 
>   <RSheeter>
>   [16]http://lists.w3.org/Archives/Public/public-webfonts-wg/2014
>   Feb/0018.html
> 
>     [16] http://lists.w3.org/Archives/Public/public-webfonts-wg/2014Feb/0018.html
> 
>   action-154?
> 
>   <trackbot> action-154 -- Chris Lilley to Make a w3c woff2 test
>   repo -- due 2014-11-04 -- OPEN
> 
>   <trackbot> [17]http://www.w3.org/Fonts/WG/track/actions/154
> 
>     [17] http://www.w3.org/Fonts/WG/track/actions/154
> 
>   [18]https://github.com/w3c/woff2-tests
> 
>     [18] https://github.com/w3c/woff2-tests
> 
>   close action-154
> 
>   <trackbot> Closed action-154.
> 
>   kuettel: brotli decompress is all one, but after than you can
>   select
> 
>   raph: 90% is common anyway so no gain there
> 
>   resolved: even for collections, one brotli stream for the whole
>   collection
> 
> recap
> 
>   raph: should nit require adecoder to reject the font if its
>   over nominal size
> 
>   ChrisL: thought the main issue as a malicious font trying to
>   overrun memory
> 
>   raph: that is a concern
> 
>   Vlad: we decoided its a guaranteed largest size. easier to see
>   when we have a firm spec
> 
>   behedad: may be abale to see how far from ideal the nominal is
> 
>   raph: reluctant, might want to aligh on wierd boundaries
> 
>   Vlad: lets start with the spec part and then decide on
>   rejecting oversized fonts
> 
>   raph: decoder MAY reject the font
> 
>   <RSheeter> github is rsheeter
> 
>   <RSheeter> (would also want khaledhosny, or permission to add
>   addtl users [preferred])
> 
>   Vlad: so in short term not going to last call.
>   ... for cts, draft test descriptions are there
> 
>   (adjourned)
> 
> Summary of Action Items
> 
>   [NEW] ACTION: chris to make a w3c woff2 test repo [recorded in
>   [19]http://www.w3.org/2014/10/28-webfonts-minutes.html#action01
>   ]
> 
>   [End of minutes]
> 
> -- 
> Best regards,
> Chris Lilley, Technical Director, W3C Interaction Domain
> 
>

Received on Tuesday, 28 October 2014 19:24:25 UTC