W3C home > Mailing lists > Public > public-webfonts-wg@w3.org > June 2012

RE: Minutes, 30 May WebFonts WG call

From: Sergey Malkin <sergeym@microsoft.com>
Date: Fri, 1 Jun 2012 18:07:56 +0000
To: WOFF Working Group <public-webfonts-wg@w3.org>
Message-ID: <08C3CBFC163BD343AC19E7C2836C8E1B016E7971@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
Hello everybody,

IE10 requires padding after last table ( this applies to both unpacked SFNT and WOFF file even if there is no metadata and private data after it).
 
Thanks,
Sergey


-----Original Message-----
From: Chris Lilley [mailto:chris@w3.org] 
Sent: Wednesday, May 30, 2012 7:56 AM
To: WOFF Working Group
Subject: Minutes, 30 May WebFonts WG call

Hello ,

 http://www.w3.org/2012/05/30-webfonts-minutes.html

and below as text for tracker


                 WebFonts Working Group Teleconference

30 May 2012

   See also: [2]IRC log

      [2] http://www.w3.org/2012/05/30-webfonts-irc

Attendees

   Present
          ChrisL, +1.410.370.aaaa, +44.845.397.aabb,
          +1.510.816.aacc, +1.781.970.aadd, tal, jfkthame,
          Christopher, Vlad

   Regrets
   Chair
          Vlad

   Scribe
          ChrisL2

Contents

     * [3]Topics
         1. [4]new proposed charter
     * [5]Summary of Action Items
     __________________________________________________________

   <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

   [6]http://dev.w3.org/webfonts/WOFF/tests/UserAgent/Tests/xhtml1
   /testcaseindex.xht#directory-4-byte-002

      [6] http://dev.w3.org/webfonts/WOFF/tests/UserAgent/Tests/xhtml1/testcaseindex.xht#directory-4-byte-002

   [7]http://dev.w3.org/webfonts/WOFF/spec/#conform-tablesize-long
   word

      [7] 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

   [8]http://lists.w3.org/Archives/Public/public-webfonts-wg/2012M
   ay/0002.html

      [8] http://lists.w3.org/Archives/Public/public-webfonts-wg/2012May/0002.html

   <Vlad> [9]http://www.w3.org/2012/05/WebFonts/draft-charter.html

      [9] 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)

Summary of Action Items

   [End of minutes]

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead  Co-Chair, W3C Hypertext CG  Member, CSS, WebFonts, SVG Working Groups
Received on Friday, 1 June 2012 18:08:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 1 June 2012 18:08:36 GMT