W3C home > Mailing lists > Public > public-webfonts-wg@w3.org > December 2010

Minutes, 8 December WebFonts WG meeting

From: Chris Lilley <chris@w3.org>
Date: Wed, 8 Dec 2010 23:04:45 +0100
Message-ID: <164958088.20101208230445@w3.org>
To: WOFF Working Group FONT <public-webfonts-wg@w3.org>
Hello WOFF WG,

Minutes at 

and below as text

                 WebFonts Working Group Teleconference

08 Dec 2010


      [2] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Dec/0006.html

   See also: [3]IRC log

      [3] http://www.w3.org/2010/12/08-webfonts-irc


          vlad, erik, jdaggett, jfkthame, chris, tal, cslye, sgalineau




     * [4]Topics
         1. [5]epub
         2. [6]Test suite development
     * [7]Summary of Action Items

   <trackbot> Date: 08 December 2010

   oh yes it has, Zakim


   Vlad: strong opposition to consider woff for epub. prefer opentype
   font embedding plus font obfuscation
   ... woff as a second option would be good. Monotype ok with
   Adobe-proposed mangling as well
   ... Adobe rep offered to join WebFonts WG telcon to explain his
   opposition to WOFF for epub
   ... will invite him after consulting with this group

   cslye: good idea
   ... good for Peter to speak for himself

   Vlad: we can't make them do it, we can only influence them

   ChrisL: in favour too, maybe early in new year

Test suite development

   cslye: we did reword woff a bit to acomodate epub, is there any
   better wording we could add?

   Vlad: current wording is generic and is not specific to epub. local
   saved offline web pages for example

   ChrisL: I agree

   cslye: do not disagree

   Vlad: great progress from tal on test suite development

   <cslye> Nice job Tal! :)

   <tal> [8]http://www.w3.org/Fonts/WG/wiki/TestPlan-UserAgent

      [8] http://www.w3.org/Fonts/WG/wiki/TestPlan-UserAgent

   tal: working on UA test plan
   ... need resolution on some questions 9in red)
   ... no testable assertion on proper structure

   jdaggett: what do you mean here

   tal: .woff containing just null bytes for example

   jdaggett: lack of the lead sequence makes it invalid already. can
   test one assertion multiple ways

   tal: another one, ciorrect signature but then junk, also just
   unparseable garbage
   ... second one was a conflict between sfnt data and flavour, decided
   not to do that

   Vlad: justification was that woff is not responsible for input file

   tal: but the flavor in the header would be wrong, packaged font ok
   ... next is numtables in header. we could put zero in there
   ... does this need a testcase

   jdaggett: yes, sensible to test

   tal: maybe a spec change, assertion on


      [9] http://dev.w3.org/webfonts/WOFF/spec/#conform-metaprivate-overlap-reject


     [10] http://dev.w3.org/webfonts/WOFF/spec/#conform-overlap-reject

   tal: reject overlap and its twice, need to duplicate tests?
   ... or lowercase the second must

   ChrisL: prefer each assertion staed only once

   tal: some ff assets could be UA asserts too
   ... should UAs tes these or not worry about them?

   Vlad: we have metadata length set to zero but its not zero - likely
   not attempt to read it

   ChrisL: the ua is required to ignore meta and private anyway, so ok
   that ua does not care here

   tal: (reads spec)
   ... ok

   Vlad: what if they read starting at offset zero?

   tal: then the decompression fails anyway
   ... next one, ff asserts on ordering. could be us assert but thend
   to think not, now

   jdaggett: its to assure that files with gaps between tables are

   tal: extraneous data tests cover that

   cslye: so extraneous data can be harmful?

   tal: mainly for clarity, but see below


     [11] http://dev.w3.org/webfonts/WOFF/spec/#conform-tablesize-longword

   tal: must being on 4byte boundary and be zero padded
   ... are we requiring the padding be nul?
   ... have atestcase with non-nul padding. should ua check this?

   ChrisL: ua gets no value from checking the padding content for nulls

   tal: would also force us to pull whole file over to check the
   ... haqv ea test with 1 instead of 0 for padding

   ChrisL: good validator test but not a ua test

   tal: also covers testing padding of final table
   ... maybe a ua test for decompressed data not matching original

   ChrisL: good to check for buffer overuns on that sort of thing
   ... need to change the spec?

   tal: worried about having to pull over all the tables

   ChrisL: could say "if on decompression the length is found to be

   cslye: sounds good

   <scribe> ACTION: jfkthame to add a ua assert for decompressed length
   found to be not what it should be [recorded in

   <trackbot> Created ACTION-53 - Add a ua assert for decompressed
   length found to be not what it should be [on Jonathan Kew - due

   tal: we say if compress is larger, it should not be compressed in
   woff. this is tagged ff
   ... shoudl ua test this?

   cslye: how would that affect the ua

   jfkthame: if it finds the error it should reject, but should not
   need to check all tables

   cslye: why would the ua care? its mainly a file size efficiency

   jfkthame: in general we want to reject invalid files

   cslye: what is the point of requiring it?

   tal: check if compressed data is too large

   Vlad: we have text that says the font table must be stored
   uncompressed in this case
   ... if header shows uncompressed length was smaller, should the font
   be rejected?
   ... but the fnt may well be vsalid

   ChrisL: it helps avoid there being woff compressors that don't check

   jfkthame: and that might be a problem, if the compressed and
   uncompressed are the same size it doesn't know if the table is
   compressed or not

   Vlad: se we need to add that language to the spec
   ... if uncompressed is less than compressed

   jdaggett: we need to be clear here

   ChrisL: good point if compressed==uncompressed length

   jfkthame: we have language that says must not load for this case

   tal: need to tag it as an assert then

   jfkthame: section 4, 5th para

   Vlad: that is a different case

   jfkthame: sentence before that

   Vlad: ok

   <scribe> ACTION: jfkthame mark sec 4 5th para as ua assert [recorded
   in [13]http://www.w3.org/2010/12/08-webfonts-minutes.html#action02]

   <trackbot> Created ACTION-54 - Mark sec 4 5th para as ua assert [on
   Jonathan Kew - due 2010-12-15].

   tal: must have a dir in asending order - ua check or not?
   ... this is carried over from OT spec

   jfkthame: yes

   (ascending means alphabetical)

   tal: could be an issue of the ua assumes they are in order

   ChrisL: could be an issue

   jdaggett: this is an underlying font format issue
   ... so the ua should not check. validator can check it

   tal: ok

   vlad: agree

   tal: require zlib or compat, if table is not decompressible, reject

   (several): yes

   <tal> [14]http://dev.w3.org/webfonts/WOFF/spec/#conform-mustzlib

     [14] http://dev.w3.org/webfonts/WOFF/spec/#conform-mustzlib

   <scribe> ACTION: jfkthame tag decompressible as a ua assert
   [recorded in

   <trackbot> Created ACTION-55 - Tag decompressible as a ua assert [on
   Jonathan Kew - due 2010-12-15].

   tal: same wording as before, only on tables that the ua attempts to
   ... next one for doisplaying metadata, orig length

   ChrisL: same reasoning, buffer overrun is a security issue


     [16] http://dev.w3.org/webfonts/WOFF/spec/#conform-private-padalign

   <scribe> ACTION: jfkthame tag wrng size compressed meta as a ua
   assert [recorded in

   <trackbot> Created ACTION-56 - Tag wrng size compressed meta as a ua
   assert [on Jonathan Kew - due 2010-12-15].

   tal: next one is a ff assert, private not on 4 byte boundary? ua
   should not care right

   ChrisL: supposed to ignore private anyway

   tal: schema validity issues now
   ... one overall assert about ignoring if not matching schema
   ... but then we have individual assertions scattered throughout

   ChrisL: prefer each assert stated once only


     [18] http://dev.w3.org/webfonts/WOFF/spec/#conform-invalid-mustignore


     [19] http://dev.w3.org/webfonts/WOFF/spec/#conform-metadataversion-required

   tal: these are tagged as testable assertions. leave or remove?

   "A conforming user agent MUST ignore an invalid metadata block, as
   if the block were not present.":

   Vlad: so is it a good idea to require failing on invalid metadata?

   sgalineau: depends on what the conformance critera is

   tal: currently tested, some tests with invalid metadat

   (we realise that the spec does not require the whole font to be
   rejected, only the metadata not displayed, if its invalid)

   tal: issue is that we have an overall assert on reject if meta is
   invalid, then some inconsistent tests for specific types of

   ChrisL: spec traceability is better with finer grained asserts

   <erik> I'm sorry, I need to run.


   <erik> thank Tal!

Summary of Action Items

   [NEW] ACTION: jfkthame mark sec 4 5th para as ua assert [recorded in
   [NEW] ACTION: jfkthame tag decompressible as a ua assert [recorded
   in [21]http://www.w3.org/2010/12/08-webfonts-minutes.html#action03]
   [NEW] ACTION: jfkthame tag wrng size compressed meta as a ua assert
   [recorded in
   [NEW] ACTION: jfkthame to add a ua assert for decompressed length
   found to be not what it should be [recorded in

   [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 Wednesday, 8 December 2010 22:05:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:14 UTC