<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

new proposed charter

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: