- From: Chris Lilley <chris@w3.org>
- Date: Tue, 28 Oct 2014 18:52:15 +0100
- To: public-webfonts-wg@w3.org
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 17:52:18 UTC