See also: IRC log
<trackbot> Date: 30 May 2012
<scribe> Scribe: ChrisL2
Vlad: Chris sent email to a draft charter today
ChrisL2: lets do that after the woff 1.0 item
Vlad: Sylvain says IE10 builds
should pass all the test cases
... if that is the case then we have two implementations,
validator is the second one
... found a minor inconsistency. Section 5 padding requirement
says tables must begin on 4 byte boundaries and be zero
padded.
... however metadata section says that, as its optional, must
follow immediately the last font table which is expected to be
zero padded. if its the last block there should be no
additional padding
... private data says it must be last, begin on 4 byte
boundary, (so expressed as a tool requirement) and no
requirement on padding at the end
... so for any block, if its the last one, no need to pad. To
be consistent
... and test case becomes invalid
tal: changing that will break the implementations that are passing
ChrisL2: OT spec end padding is optional
Vlad: OT says padding is 'strongly recommended' not a must
tal: found the bug in fonttools.
long discussion with Just van Rossum. Spec is very vasgue and
contradictory
... would need to look through emails from 5 years ago to
check
Vlad: (quotes from spec) "highly recommended"
tal: is it worth breaking the
passing implementations by changing this
... so making padding on last table optional if there is no
meta and no private
http://dev.w3.org/webfonts/WOFF/tests/UserAgent/Tests/xhtml1/testcaseindex.xht#directory-4-byte-002
http://dev.w3.org/webfonts/WOFF/spec/#conform-tablesize-longword
tal: changes in the authoring and validator tests as well
ChrisL2: opera, webkit and firefox all fail this while IE10 might pass it (and the validator does so)
tal: odd to change the spec because one font is badly made
jfkthame: have the OT sanitiser folks said thwey would refuse a patch that fixes it for woff and does not change anything for OT?
(we don't know)
tal: don't mind changing it but we discussed a long time ago
jfkthame: spec as originally
drafted only required padding if there was something
following
... then we changed it in the font tables so padding always
happens
... discrepancies in behaviour either way
cslye: why did we write that tools needed padding at the end table?
tal: found that bug in
fonttools
... due to differing interpretations of OT spec
jfkthame: it came from the definition of a well formed sfnt that was round trippable
ChrisL2: yes that is right
tal: and we were trying to make it good data coming in
jfkthame; and that is what other tools seem to be converging on
(we really need some representation from Microsoft to comment authoritatively on IE10)
jfkthame: would be happy to write
the patch for OTS but it might not be accepted upstream
... could do it as a firefox patch but prefer to see it adopted
upstream
tal: is there any indication to OTS where the font came from?
jfkthame: yes
(commercial break - a word from our sponsors)
(we fail to contact Sylvain)
Vlad: consistency of implementation is the most important thing
ChrisL2; we can't make a decision withouthard data o what IE10 does
(decision deferred to next week)
(discussion on who the OTS maintainers are)
jfkthame: adam langley, but half a dozen other folks also involved
http://lists.w3.org/Archives/Public/public-webfonts-wg/2012May/0002.html
<Vlad> http://www.w3.org/2012/05/WebFonts/draft-charter.html
ChrisL2: there is a risk of old vs new implementations
Vlad: mainly heard positive
opinions, mainly because of asian font size. Android also
interested, for mobile
... bandwidth on mobile still expensive
jfkthame: draft says it adds new
method
... should the deliverable be to "do" it or to "evaluate it,
and do it if it evaluates well"
... how does it compare to optimising structure and then
applying woff 1.0?
Vlad: optimisation also gets rid
of data that can be reconstructed. so woff does not have the
reconstruction phase
... loca, bounding box data can be reconstructed on the fly
tal: better to break the proposal
into two parts, optmisation and compression
... and measure where the benefits come from
Vlad; google did that and presented their findings, repository of code and sample fonts , fine grained report on where the benefits come from
scribe: optimisations give
15-30%, lzma givea an additional 30% over gzip
... depends on what can be optimised, unhinted vs hinted, size
of original font etc
... data from Google is from around a thousand Google
webfonts
ChrisL2: suggestion to evaluate and then maybe do it. is a good one
(general agreement)
(adjourned)
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: ChrisL2 Inferring ScribeNick: ChrisL2 Default Present: ChrisL, +1.410.370.aaaa, +44.845.397.aabb, +1.510.816.aacc, +1.781.970.aadd, tal, jfkthame, Christopher, Vlad Present: ChrisL +1.410.370.aaaa +44.845.397.aabb +1.510.816.aacc +1.781.970.aadd tal jfkthame Christopher Vlad Found Date: 30 May 2012 Guessing minutes URL: http://www.w3.org/2012/05/30-webfonts-minutes.html People with action items:[End of scribe.perl diagnostic output]