WebFonts Working Group Teleconference -- 08 Dec 2010

<trackbot> Date: 08 December 2010

oh yes it has, Zakim

epub

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> 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 sanitisation

tal: but the flavor in the header would be wrong, packaged font ok though
... 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

<tal> http://dev.w3.org/webfonts/WOFF/spec/#conform-metaprivate-overlap-reject

<tal> 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 rejected

tal: extraneous data tests cover that

cslye: so extraneous data can be harmful?

tal: mainly for clarity, but see below

<tal> 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 padding
... 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 length

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 http://www.w3.org/2010/12/08-webfonts-minutes.html#action01]

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

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 thing

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 already

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 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 file?

(several): yes

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

<scribe> ACTION: jfkthame tag decompressible as a ua assert [recorded in http://www.w3.org/2010/12/08-webfonts-minutes.html#action03]

<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 decompress
... next one for doisplaying metadata, orig length

ChrisL: same reasoning, buffer overrun is a security issue

<tal> http://dev.w3.org/webfonts/WOFF/spec/#conform-private-padalign

<scribe> ACTION: jfkthame tag wrng size compressed meta as a ua assert [recorded in http://www.w3.org/2010/12/08-webfonts-minutes.html#action04]

<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

<tal> http://dev.w3.org/webfonts/WOFF/spec/#conform-invalid-mustignore

<tal> 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 invalidity

ChrisL: spec traceability is better with finer grained asserts

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

adjourned

<erik> thank Tal!

- DRAFT -

WebFonts Working Group Teleconference

08 Dec 2010

Attendees

Contents

epub

Test suite development

Summary of Action Items

Scribe.perl diagnostic output