See also: IRC log
<trackbot> Date: 08 December 2010
oh yes it has, Zakim
Vlad: strong opposition to
consider woff for epub. prefer opentype font embedding plus
... 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
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: working on UA test
... 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: 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
... 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)
Vlad: what if they read starting at offset zero?
tal: then the decompression fails
... 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: 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
... 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
<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
(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: require zlib or compat, if table is not decompressible, reject file?
<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
<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
... 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: 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.
<erik> thank Tal!
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/essert/assert/ No ScribeNick specified. Guessing ScribeNick: ChrisL Inferring Scribes: ChrisL Present: vlad erik jdaggett jfkthame chris tal cslye sgalineau Agenda: http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Dec/0006.html Found Date: 08 Dec 2010 Guessing minutes URL: http://www.w3.org/2010/12/08-webfonts-minutes.html People with action items: jfkthame[End of scribe.perl diagnostic output]