- From: Chris Lilley <chris@w3.org>
- Date: Wed, 8 Dec 2010 23:04:45 +0100
- To: WOFF Working Group FONT <public-webfonts-wg@w3.org>
Hello WOFF WG,
Minutes at
http://www.w3.org/2010/12/08-webfonts-minutes.html
and below as text
WebFonts Working Group Teleconference
08 Dec 2010
[2]Agenda
[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
Attendees
Present
vlad, erik, jdaggett, jfkthame, chris, tal, cslye, sgalineau
Regrets
Chair
Vlad
Scribe
ChrisL
Contents
* [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
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> [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
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>
[9]http://dev.w3.org/webfonts/WOFF/spec/#conform-metaprivate-overlap
-reject
[9] http://dev.w3.org/webfonts/WOFF/spec/#conform-metaprivate-overlap-reject
<tal>
[10]http://dev.w3.org/webfonts/WOFF/spec/#conform-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
rejected
tal: extraneous data tests cover that
cslye: so extraneous data can be harmful?
tal: mainly for clarity, but see below
<tal>
[11]http://dev.w3.org/webfonts/WOFF/spec/#conform-tablesize-longword
[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
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
[12]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 [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
file?
(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
[15]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>
[16]http://dev.w3.org/webfonts/WOFF/spec/#conform-private-padalign
[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
[17]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>
[18]http://dev.w3.org/webfonts/WOFF/spec/#conform-invalid-mustignore
[18] http://dev.w3.org/webfonts/WOFF/spec/#conform-invalid-mustignore
<tal>
[19]http://dev.w3.org/webfonts/WOFF/spec/#conform-metadataversion-re
quired
[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
invalidity
ChrisL: spec traceability is better with finer grained asserts
<erik> I'm sorry, I need to run.
adjourned
<erik> thank Tal!
Summary of Action Items
[NEW] ACTION: jfkthame mark sec 4 5th para as ua assert [recorded in
[20]http://www.w3.org/2010/12/08-webfonts-minutes.html#action02]
[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
[22]http://www.w3.org/2010/12/08-webfonts-minutes.html#action04]
[NEW] ACTION: jfkthame to add a ua assert for decompressed length
found to be not what it should be [recorded in
[23]http://www.w3.org/2010/12/08-webfonts-minutes.html#action01]
[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