See also: IRC log
<trackbot> Date: 17 August 2010
<ChrisL> action-1?
<trackbot> ACTION-1 -- Vladimir Levantovsky to draft something about embedding bits -- due 2010-05-12 -- OPEN
<trackbot> http://www.w3.org/Fonts/WG/track/actions/1
<ChrisL> http://www.w3.org/Fonts/WG/track/actions/
<ChrisL> hi jonathan. we just closed some old actions, some on you, we believe they are done
<cslye> WOFF Working Draft: http://dev.w3.org/webfonts/WOFF/spec/
<jfkthame> ChrisL: thanks
<ChrisL> dev.w3.org/webfonts/WOFF/spec/Overview.html
<ChrisL> updated seconds ago
<TabAtkins_> [appendices B and C of the spec have not been updated yet]
<ChrisL> recent changes as coloured diffs http://dev.w3.org/cvsweb/webfonts/WOFF/spec/Overview.html.diff?r1=1.12&r2=1.13&f=h
<jfkthame> skype dropped off....
<TabAtkins_> jdaggett: Section 3, WOFF header, "total sfnt size", you now have it as ""total size needed for the uncompressed font header... as padded".". That seems like slightly awkward phrasing.
<ChrisL> jdaggett: "Total size needed for the uncompressed font data, including the sfnt header, directory, and font tables (as padded)." as padded?
<TabAtkins_> jdaggett: I'm assuming you mean "including padding"?
<TabAtkins_> John: That's made explicit in the font table field.
<TabAtkins_> John: But it seemed like clarifying that as "including padding" would be fine.
<TabAtkins_> John: It's "including" now.
<TabAtkins_> ChrisL: I have a minor editorial issue.
<ChrisL> change "storing the tables in uncompressed" to "storing some or all the tables in uncompressed"
<ChrisL> scribenick: TabAtkins_
<jdaggett> http://lists.w3.org/Archives/Public/www-font/2010JulSep/0027.html
jdaggett: Under "checksums", the wording in section 4 didn't completely match section 8.
... My feeling was that UAs should not be required to check the checksum.
jfkthame: A tool creating WOFF files might treat a checksum error as a fatal error and refuse to proceed.
jdaggett: I don't think what you just said is completely captured by the spec.
<ChrisL> authoring tools conformance and user agent requirements should be clearly distinguished
jdaggett: Section 8 should say that UAs have slightly different requirements from tool requirements.
ChrisL: In general, requirements should specify what they apply to. Authoring tools, display tools, etc. have different requirements and should be clearly distinguished.
... So "must be correct for the original table data" sounds like an authoring tool requirement.
jfkthame: Yes.
jdaggett: But it's in a section making it seem that it applies to both authoring tools and UAs.
... I suggest we create an action for you to come up with a proposed wording change.
jfkthame: In section 4, the conformance requirements are for the *file format*. Creation tools need to generate valid files.
jdaggett: But the next line is where it appears to bind UAs to doing validity checking.
jfkthame: Ah, yes.
jdaggett: The checksums that are in fonts aren't really indicators of validity, so to put the burden on UAs to do full checksum validation is silly.
... And it's incompatible with incremental unpacking.
<ChrisL> if section 8 is only about conformance of the files, then " Summary of Conformance Requirements" should be " Summary of Conformance Requirements for WOFF files"
jdaggett: Appendix B and C are kind of a mix of "best practices" and "informative requirements". I think "best practices" should be by themselves, and MUSTs should be in one place.
<ChrisL> The "musts"s in appendix B and C should be removed and put in different conformance requirements for authoring tools and for browsers
jfkthame: I think the conformance requirements are coming from the request that we had (Vlad or Sylvain?) to collect together the key points for people creating WOFF tools.
... The MUSTs in the appendices should be just drawn directly from the rest of the spec.
jdaggett: I think we should maybe just put all the MUSTs into section 8, and in the Best Practices just put suggestions.
ChrisL: If we do that, section 8 needs to be split into multiple pieces, to split up the conformance requirements according to group: tools, UAs, etc.
jdaggett: I think moving it out of the appendices establishes that this is normative, required behavior.
jfkthame: Wrapping my head about this... In my mind this spec is solely about the file format. The requirements on the creator are just to create valid files.
... For UAs it's a little trickier. If we say that, frex, creators have to ensure that checksums are valid in the font, but we don't want to require UAs to revalidate that, we're walking a balancing act between wanting to mandate interop behavior between user agents.
... If you're presented with a WOFF file that's not completely correct, we don't want some browsers to accept and some to reject.
ChrisL: You do get that conformity if you say browsers don't have to check it.
jfkthame: Do you say just that? Does this leave details to UA-specific error handling?
jdaggett: I think there is a set of mandated behavior, and a set of validation requirements that are independent of this that we can't define. There are platform-specific issues.
ChrisL: This is only about unpacking WOFF into sfnt. Any errors in the sfnt are out of scope.
Vlad: I think it's perfectly okay to require tools to validate checksums. It just helps authors to produce good files. Rejecting files at this point doesn't hurt anyone.
... But once you hit browsers, you shouldn't reject the font just because it's slightly invalid.
TabAtkins_: I agree with John that we want to specify WOFF unpacking as precisely as possible, so that invalid WOFF files get unpacked in the same way by all browsers.
jdaggett: That might be untestable, though. There are 2 steps - WOFF unpacking and then sfnt decoding. These steps are indistinguishable from a testing perspective. We can't test the sfnt part.
TabAtkins_: I overstated, then. Arbitrary bags of bits, even if decoded the same way, may then result in sfnt data that is decoded differently by browsers, and there's no way to tell where the difference in behavior occurred.
jdaggett: As long as there's no requirement on browsers checking the checksum.
... I think there are adequate conformance requirements otherwise in there.
ChrisL: If there exists some opentype fonts with invalid checksums, we can either say the WOFF transformation preserves that data, or it corrects the checksum. We can't do both.
... We either go the lossless route, or we fix things.
<ChrisL> but not both
ChrisL: What's the scope of the problem? Are there fonts out there right now with invalid checksums?
jfkthame: Yes.
ChrisL: And they work, so let's preserve that.
<jfkthame> but note that fixing the checksums will not break such fonts
Vlad: WOFF is supposed to take some sfnt data in, and later push sfnt data out.
... The checksum is just part of that data.
<jfkthame> the WOFF transformation is lossless for correct, "normalized" sfnt data - it is explicitly NOT lossless for "peculiar" sfnts - e.g. with extraneous data
Adam: The tool producing a WOFF may fiddle with the checksum, if may subset the font, etc. We don't have to say something about that.
Vlad: You can always go back to the font vendor if they give you a bad font. That's the benefit of tools doing conformance checking.
TabAtkins_: So are you saying that creation tools should fix invalid checksums?
Vlad: No, creation tools should reject the font and not produce a WOFF from it.
ChrisL: So browsers don't have to worry about it, because they never receive the bad font in the first place.
Vlad: Subsetting is something that can happen on the fly, or whatever. As far as WOFF is concerned, whatever happens to the font before it reaches the converter is irrelevant.
jdaggett: When we make statements about checksums, we can make tests that verify tools are doing the right thing. If we say "we don't care", we can't put anything in the test suite about it.
... So what we're saying now is that creation tools should reject a font if its checksum is incorrect, and not produce a WOFF?
ChrisL: Yes.
Vlad: And an author, if they got the font from a foundry, they can go back to the foundry and complain about it. If the font is ownerless, then you can just fix the font using existing tools before giving it to the foundry.
jdaggett: Also recall that WOFF creation tools aren't required to be *just* WOFF creators. They can package font-editting features as well, and fix checksums or do subsetting or something before handing the font to the WOFF-creator part.
ChrisL: So from a user point of view it doesn't matter, but from a spec point of view requiring rejection allows clear, crisp languages.
jdaggett: So we're agreeing on that text?
[general agreement]
ChrisL: Spec currently says that the checksum must be correct for the sfnt data.
TabAtkins_: So let's make it explicit that that means the creation tool must reject fonts which don't match that requirement.
Vlad: One procedural comment - those of us that are official members of the WG can speak your mind whenever, but observers I think aren't allowed procedurally to offer ideas?
... We all agreed to all the requirements re: patent licensing, etc. I don't think non-members are probably high enough up to make the same commitments.
[discussion of the Bitstream people, turns out they're all covered and everyone's shiny and happy]
ChrisL: Where are we on the list of comments?
jdaggett: I think we've talked about all of them. I'm not sure what we've decided about appendices B & C.
... I think we should move the conformance requirements to section 8, maybe in multiple subsections.
... Have one section listing requirements common to both creation tools and UAs, then a section listing conformance requirements just for creation tools, and one just for UAs.
ChrisL: I heard some resistance from John about this. Does this sound okay?
jfkthame: No, I think I can edit it into that shape.
jdaggett: I think that all of the appendix B&C should be moved into 8. Once you remove the MUSTs, there's not much left in the appendix. Also, it sort of becomes "Do Not Read", and runs the risk of becoming stale.
<ChrisL> trackbot, status
<scribe> ACTION: Jonathan to Merge appendix B & C into section 8. [recorded in http://www.w3.org/2010/08/18-webfonts-minutes.html#action01]
<trackbot> Created ACTION-14 - Merge appendix B & C into section 8. [on Jonathan Kew - due 2010-08-24].
<ChrisL> action john to explode
<trackbot> Sorry, amibiguous username (more than one match) - john
<trackbot> Try using a different identifier, such as family name or username (eg. jhudson, jdaggett)
ChrisL: We had some other comments on the spec?
... One about why are we creating a new metadata scheme instead of using RDF.
... I responded sorta robustly rejecting that, but also said that there exists W3C tech that lets you produce RDF out of more arbitrary data.
... We could even have an appendix over how to do that, but it's not something we need to care about directly.
... Since we had people like Hakon recommending an extremely pared-down plain text key-value syntax, I think we did all right with an extremely simple XML format.
John: Eric Mueller (sp?) had some comments along similar lines, too.
ChrisL: I think that was more about duplication, that if we're adding new metadata it should just go into the font directly.
tal: Which was ironic, since the OT people were complaining that doing that would take too long.
<br type=coffee duration=15m>
<jfkthame> milk but no sugar in mine, please
<Adam> Hello IRC
<crossland> scribenick
<crossland> scribenic
<scribe> ScribeNick: crossland
ChrisL: ill take on the test suite stuff
Vlad: this means testable assertions for what the spec says
... how is it in css?
Chris: beter go trhough the document and figure it out, now :)
ChrisL: First pass with the MUSTs
Vlad: we can distinguish MUST in the english phrasing and MUST as a specification requirement
... by having MUST in caps when its a spec req
ChrisL: we can alo just rephrase things so it only happens when its a spec req
TabAtkins_: we want to be more specific about tool outputing WOFF file?
Vlad: we agree to use uppercase MUST when its a spec req
er
oop
Vlad: we agree to NOT use uppercase MUST when its a spec req, we will rephrase things so all uses of that word are spec req
we are discussing this para:
User agents supporting the WOFF file format for downloadable fonts MUST respect the requirements of the CSS Fonts specification[6]. In particular, such downloaded fonts are only available to the documents that reference them; they MUST NOT be made available to other applications or documents on the user's system.
question is, is this testable? worth testing, and can it be tested automatically?
John Daggett: fonts not being available to other programs or documents is testable
Adam: we should reference other specs (CSS3) which also mandate this. S1 is more than an introduction, it deserves a section, to say how this spec interacts with other specs
... not longer, maybe shorter, but more clearly defined
Vlad: "normative references" section is typical name for this
Adam: if we dont test for the validatity of opentype data, should we test other dependenceie - cross document availablity, etc
... clearly defining "dependencie testing" leads to different kinds of tests to consistency checking of the file format
... user agents that implement woff should test cross origin, cross document, and maybe OFF testing
ChrisL: 3 kinds of tests: file format, authoring tools, user agents behaviour
... usres expect user agents to do tings with woff, we should make these testable things
Vlad: no one expects us to do exhastive tests for all areas, so we can rely on css having more thorouh testing
... we crafted this section with the requests of font developers in mind
john daggett: the requirement in this area from font vendor are weaker than what UAs need
John daggett: we need to word this more tightly
scribe: if we have a test file, we are not testing all the subtlites of the @font-face mechanism
chrisl: a simple test with 2 iframes, one doesnt link a font and one does, both refer to the same font, and if the 2 frames look the same, test fails
Adam: there are 2 spec deps here: cross domain in html5, cross document in css3, these 2 first,
Vlad: 'must respect' is normative, so move that to the normative section
?
john daggett: we should have tests based on revised language here, yes
Adam: 'the primary purpose of the WOFF format' implies secondary formats; SVG and XSL want to use it
... some gnu/linux vendors added woff as an installable format, i dont know specific vendors
... may be fontconfig?
action for jonathan: split intro to remove these requirements and insert them into a new section, "normative references"
<trackbot> Sorry, couldn't find user - for
action for jonathan kew: split intro to remove these requirements and insert them into a new section, "normative references"
<trackbot> Sorry, couldn't find user - for
action for jfkthame: split intro to remove these requirements and insert them into a new section, "normative references"
<trackbot> Sorry, couldn't find user - for
action for chrisl: make a simple test with 2 iframes, one doesnt link a font and one does, both refer to the same font, and if the 2 frames look the same, test fails
<trackbot> Sorry, couldn't find user - for
<scribe> ACTION: jfkthame to split intro to remove these requirements and insert them into a new section, "normative references" [recorded in http://www.w3.org/2010/08/18-webfonts-minutes.html#action02]
<trackbot> Sorry, couldn't find user - jfkthame
chrisl: next MUSt is in S2P3
... we need a special bad font to test this
"A complete WOFF file consists of a 44-byte header, immediately followed (in this order) by a variable-size table directory, a variable number of font tables, an optional block of extended metadata, and an optional block of private data. Except for padding with a maximum of three null bytes in places where 4-byte alignment of a table length or data block is specified, there MUST NOT be any extraneous data between the font tables and data blocks as po
chris: 3 tests, for validating tools, for authoring (conversion) tools, and for user agents to reject bad woff
... "this file has 12 bytes of padding, error." style output
... conformance checks with authoring and UA tool
s
john dagget: same test, in 2 tools
Adam: take an invalid SFNT is one
... take in invalid WOFF and see its rejected is another
... error reporting should not be a conformance requirement
Vlad: UAs dont say anything about decisionthey make, if some put error messages then thats up to them
<erik> @Dave: "Jonathan" is jfkthame.
erik: i figured that out but it still didnt work?
but rssagent seemed to get it
<erik> Did you try "ACTION Jonathan: "
<scribe> ACTION: Jonathan to split intro to remove these requirements and insert them into a new section, "normative references" [recorded in http://www.w3.org/2010/08/18-webfonts-minutes.html#action03]
<trackbot> Created ACTION-15 - Split intro to remove these requirements and insert them into a new section, "normative references" [on Jonathan Kew - due 2010-08-24].
yay: )
thank erik!
<erik> :)
Vlad: so, there are 2 conformance requirements
<Vlad> sec 2, 3rd para - split the wording the wording to have two conformance req - extra padding to be rejected on the conversion side and extra padding to be rejected by the UA in the WOFF itself
calling jfkthame now
jdaggett: the concern is you have data between tables
... woff ought to have clearer statement that extraneou data i rejected
... both to original SFNT and to WOFF files loaded by UAs
jfkthame: that UAs reject WOFFs wwith extra data is in S8
chrisl; is it mentioned twice?
Adam: its mentioned in the summary, so it ought to be in the body of the pec
... summaries are not for new facts
<scribe> ACTION: Jonathan to S3 Woff header, first entry, add "must be" [recorded in http://www.w3.org/2010/08/18-webfonts-minutes.html#action04]
<trackbot> Created ACTION-16 - S3 Woff header, first entry, add "must be" [on Jonathan Kew - due 2010-08-24].
<scribe> ACTION: Jonathan to sec 2, 3rd para - split the wording the wording to have two conformance requirements - extra padding to be rejected on the conversion side and extra padding to be rejected by the UA in the WOFF itself [recorded in http://www.w3.org/2010/08/18-webfonts-minutes.html#action05]
<trackbot> Created ACTION-17 - Sec 2, 3rd para - split the wording the wording to have two conformance requirements - extra padding to be rejected on the conversion side and extra padding to be rejected by the UA in the WOFF itself [on Jonathan Kew - due 2010-08-24].
jdaggett: in the definitoin of 'reserved' say 'reserved, set to 0'
<scribe> ACTION: Jonathan to S3 Woff header, first entry, actually dont add "must be", instead add "must" to the decriptoin in the following text [recorded in http://www.w3.org/2010/08/18-webfonts-minutes.html#action06]
<trackbot> Created ACTION-18 - S3 Woff header, first entry, actually dont add "must be", instead add "must" to the decriptoin in the following text [on Jonathan Kew - due 2010-08-24].
Vlad: now its 13:15 so we'll break for lunch soon
jfkthame: all sounds good!
<erik> Resuming.
<scribe> ScribeNick: crossland
TabAtkins_: "
... "If the offset and length fields pointing to the metadata or private data block are out of range, indicating a byte range beyond the physical size of the file, a conforming user agent MUST reject the file as invalid." isnt good
... if they dont exist it must be 0
ChrisL: 4 cases, 0 then has one, or non-0, or beyond file, or in the file that isnt theright block
TabAtkins_: 2 are correct and good, 2 are bad
ChrisL: so the 'must be set to 0' doent need to be "must"
jdaggett: need to tighten this language so its testable
... put "if metadata, theoffset must be valid, based on the order of table"?
adam: section 2 decirbes the chunks
... the delcared value in S4 isnt about how the file is built, but about the offset field
jdaggett: ipropse to action 'specify exact algo for verifying a vlid offset for metadata and private data'
ACTION for jdaggett: specify exact algorithm for verifying a valid offset for metadata and private data of S3P5
<trackbot> Sorry, couldn't find user - for
ACTION John Daggett: specify exact algorithm for verifying a valid offset for metadata and private data of S3P5
<trackbot> Sorry, amibiguous username (more than one match) - John
<trackbot> Try using a different identifier, such as family name or username (eg. jhudson, jdaggett)
<scribe> ACTION: jdaggett to specify exact algorithm for verifying a valid offset for metadata and private data of S3P5 [recorded in http://www.w3.org/2010/08/18-webfonts-minutes.html#action07]
<trackbot> Created ACTION-19 - Specify exact algorithm for verifying a valid offset for metadata and private data of S3P5 [on John Daggett - due 2010-08-24].
jdaggett: jfkthame and i discussed that roundtripping is important
... in S4P5
ChrisL: this is testable
... for "In cases where checksum recalculation is necessary or changes to the original font data are made, e.g., to subset the glyphs in the font or add special tables, conformant tools MUST either remove any digital signature (i.e., a DSIG table) or regenerate the signature (if the necessary credentials are available), and MUST correct all affected checksum values and table offsets, both for individual tables and the overall font data checksum c
Vlad: i think a recommendations section helps
TabAtkins_: remove that whole para
ChrisL: and the finalone
jdaggett: not remove?
ChrisL: move it to where?
jdaggett: change the wording.
... being informative is fine
TabAtkins_: so remove all the musts
Vlad: best practices of vendors do this
jdaggett: implementors look at this document, not best practices
Vlad: in a separate section things get lost, but here we can separate things
jdaggett: it should be in this section, thats where an implementor will look at
... DSIG relate to the data of the font; if the tools change the font data, they must be removed a theyre invalid
ChrisL: you start witha valid sfnt with no extra padding, tables, and you should get bit for bit the same thing
... we shouldnt loose sight of that
adam: this seems like it belongs in the 'normative references' section as it relates to the OT spe
c
scribe: "HEAD" table and "DSIG" table are OT tables
... this is the type of thing, not a CORE woff test, it might be a conformance test but of a different tpe
Vlad: out of spec?
(this is S5P5)
adam: "it is recommended that the following requirements of the OT specification are observed"
... "a new signature may be added"
... so that its saying _we remind_ rather than _we state_
(tab has an action for this.)
section 6!
ChrisL: "If no extended metadata is present, the metaOffset, metaLength and metaOrigLength fields in the WOFF header MUST be set to zero." is a refinement of an earlier MUST
jdaggett: should be either here or there
adam: S6 says all 3, S3 is okay
jdaggett: it should be in the headers
adam: S6P2 should be in Section 3
cslye: why must metadata be compressed (s2p2.1)
... my first impression wa that if i make a woff making tool, i dont have to support compression as long as i dont support metadata?
ChrisL: "If the extended metadata is invalid" - invalid sucks
... can say "If the extended metadata cannot be decompressed or not well formed XML"
... make invalidity explicity
TabAtkins_: actioning this to rewrite S6P4
ChrisL: "The presence (or absence) and content of the metadata block MUST NOT affect font loading or rendering behavior of user agents" should be at the start of the section, end of first para
TabAtkins_: so move it to new 2nd paragraph?
... why not MUST the UTF8 S6P6?
ChrisL: i am ok with it
sergeym: hmm
John: can we say utf8 or utf16?
TabAtkins_: xml says you must be able to read utf16, but i prefer to require utf8
cslye: will anyone want utf16 in any scenario?
TabAtkins_: i can imagine people wanting it, but not needing it
Lorp: we should to exclude ascii and latin1 and so on
John: good idea
ChrisL: yes, must be utf8 or utf16 and utf8 is preferred
(this is S6P6)
(TabAtkins_ has this action)
ChrisL: so the dictionary list has a lot of MUSTs
... this is why we get into 'what valid means'
TabAtkins_: there's no "must" that the metadata must use this schema
... to add a new para after the UTF requirement that the metadata must conform so this schema
ChrisL: i can make a relaxNG schema for this
... this prose is okay but its a bit slippery
ACTION ChrisL to make a relaxNG schema for the metadata block schema
<trackbot> Created ACTION-20 - Make a relaxNG schema for the metadata block schema [on Chris Lilley - due 2010-08-24].
section 7!
ChrisL: "No padding is required at the end of the private data block; any following data does not form part of the WOFF file structure, and MUST be ignored." allows any random data in there
(TabAtkins_ takes an action for this)
ChrisL: S7P3 belongs in the header block
TabAtkins_: it could be ok here
Vlad: why not say, all tables are padded?
ChrisL: will that break WOFF already published?
Lorp: sfnt2woff doent pad the end
... actually, if the metadata section compresses to a non-4 byte size, sfnt2woff doesnt check that it does and pad it
ChrisL: does S8 restate earlier ones?
<Lorp> i have not tested what sfnt2woff does with padding after a non-4 private data block
ChrisL: i dont like to have the same conformance thing twice in the spec, updates might not update both section
... S8 says its a summary, and says its about woff files and then talks to UAs
(tab has an action on the md/pdb padding issue)
<TabAtkins_> ACTION: Chris to Check that everything in section 8 correctly references a conformance requirement earlier in the spec. [recorded in http://www.w3.org/2010/08/18-webfonts-minutes.html#action08]
<trackbot> Created ACTION-21 - Check that everything in section 8 correctly references a conformance requirement earlier in the spec. [on Chris Lilley - due 2010-08-24].
<scribe> ACTION: Chris to Appendix A should say this section is non-normative [recorded in http://www.w3.org/2010/08/18-webfonts-minutes.html#action09]
<trackbot> Created ACTION-22 - Appendix A should say this section is non-normative [on Chris Lilley - due 2010-08-24].
ChrisL: lowercae 'must' in app:Bp4
TabAtkins_: move these into section 8?
<TabAtkins_> ACTION: Jonathan to Verify whether, with zlib, it's possible to have a stream that allows an EOF midstream, so extra data can be padded on mid-stream. [recorded in http://www.w3.org/2010/08/18-webfonts-minutes.html#action10]
<trackbot> Created ACTION-23 - Verify whether, with zlib, it's possible to have a stream that allows an EOF midstream, so extra data can be padded on mid-stream. [on Jonathan Kew - due 2010-08-24].
Vlad: that will be a way to have hidden data in woff
... as it will never show in the output after zlib is run to decompress
... we have PDB, allows us to insert any random data, so why are we concerned with other ways to carry extra data?
ChrisL: footnotes section is odd, normally a spec has 2 references, normative and non normative
... these need to be checked for if they are required or not
... matters because we dont want to depend on release schedules of other specs unless we really have to
action for chris to reformat footnotes section into normative and non normative references
<trackbot> Sorry, couldn't find user - for
action for chrisl to reformat footnotes section into normative and non normative references
<trackbot> Sorry, couldn't find user - for
Action for Jonathan to work with Chris L on reformatting footnotes section into normative and non normative references
<trackbot> Sorry, couldn't find user - for
Action Jonathan to work with Chris L on reformatting footnotes section into normative and non normative references
<trackbot> Created ACTION-24 - Work with Chris L on reformatting footnotes section into normative and non normative references [on Jonathan Kew - due 2010-08-24].
doh
TabAtkins_: returning to padding afer MD and PDB, what do we do? there are tools that do both?
... we know many fonts exist from a tool that doe not pad
... so we should say you are allowed to pad, and find out if anyone doe
s
ChrisL: tests vary, some are in a series, some are batched, and some involve human arrangement and action
jdaggett: we need code to programmatically verify fonts
... we need test cases, that are UA tests, pass/fail
... we have testing for css, we can do a similar thing
ChrisL: making fonts for the tests is needed
... the byte checking is easy enough
... we need to produce 'bad' fonts
... id like a filename convention, eg bad-*.ttf
John: we can use libre fonts and corrupt them in various ways, utopia -> distopia :)
adam: 1st sentence of the doc says "the WOFF font format"
... does this effect SIL OFL and Vera style renaming?
... will renaming this a file format mean we dont have to rename OFL/Vera fonts
... can we write the spec to interprit this not as a separate font format but as a archive format
... this is a valid questoin; some eulas prohibit modification
... if a font can be legally put on a wbe server, another isue; but a clause that prevents users from modification is in many freeware licenses and so on
... so rather than make an obscatle, the spec should say this isnt a differnet file format, its a container format for transporting the font data; and not a new font format
... so people can say this isnt a modification
... to me its more like compression
... most EULA doesn't say "you cant zip this"
jdaggett: thats something the EULA needs to define
... the working in the EULA is the only basis for this
adam: its not that we can see "woff doesnt modify fonts" and create reality with words
vlad: we agreed from the start to say file format and not font format
John: when we talk about "WOFF" as a "web font format" and i try to catch myself saying "web font wrapper" or so... it is a lossless compression of another font format
adam: so i think its worth clarifying that this is not a font format, and others can debate it. change the first setence, the rest is fine
Lorp: PDB says "but it has no publically defined format" and what if MS then makes a defacto format for this?
... seems a bit vague
... like say if MS puts image binary data in the font in use , and MSIE starts displaying the images
crossland: update notification via atom feed? could be extension area
jdaggett: should "User agents should make no assumptions about the content of a private block" be a must?
cslye: what if adobe has a UA that makes use of the PDB?
crossland: could a firefox extension do so?
vlad: what about putting a fingerprint in the PDB and crawling the web for it?
jdaggett: that is okay, but right now, a single UA can use this to add functionality for just them and break the standard
adam: right, and then you're not conformant to the public version
jdaggett: it says "The content of this data MUST NOT affect font usage or load behavior. "
cslye: what if you have something a font manager can use, but not a UA?
jdaggett: we're concerned about conformant UAs
cslye: we have this block specified, and as soon as anyone uses it, it out of spec
jdaggett: right, its not for UAs to use, its for font vendor to fingerprint
in
Julio: it should be changed, ye
... the language should be changed in S7P1
eriK: can the update notidication be done by file date and name in the metadata?
John: its the update url?
crossland: yes
<TabAtkins_> ACTION: jdaggett to Tighten the description of the private data block. [recorded in http://www.w3.org/2010/08/18-webfonts-minutes.html#action11]
<trackbot> Created ACTION-25 - Tighten the description of the private data block. [on John Daggett - due 2010-08-25].
ChrisL: <license url=""> is not THE LICENSE
cslye: the advantageof WOFF could attach the actualy license ot the font
ChrisL: <license> is thelicense of the WOFF, not the font
John: its a license for web use
... the font might have a license that says you can link on the web in secondarily licensed domains.
... the WOFF says what those domains are
... you dont want to write the font metadata each time you make a woff, you want on TTF and when you woff it apply metadata simpley
Vlad: when you have 2 documents that claim to be a license, the least restrictive one is what is enforcable, so you dont want anything that can be interpreted as a second license
cslye: you dont want ot say this is for the license of font
John: so do we want ot be clear its a license for the woff file?
cslye: no, some foundries may want to use it in a specific way for the contianed font, and others will want something else
adam: i see WOFF as a ZIP archive; we are making a packaging convention...
John: i prefer "license summary" as "license" implies a legal agreement
erik: what if your license is 2 lines?
adam: "licensing information"
... that could be full license, summary, url...
cslye: if adobe decides its risky to use it, we wont use it
John: in the spec we should not call it a license, "licensing information" is generic and covers an actual license and anything else
cslye: good topic for the panel
Vlad: 1 hour left
<Adam> Section 6, license block: change "The license for the font." to "The licensing information for the font."
action chrisl to Section 6, license block: change "The license for the font." to "The licensing information for the font."
<trackbot> Created ACTION-26 - Section 6, license block: change "The license for the font." to "The licensing information for the font." [on Chris Lilley - due 2010-08-25].
<ChrisL> ACTION: chris to write up a test suite plan [recorded in http://www.w3.org/2010/08/18-webfonts-minutes.html#action12]
<trackbot> Created ACTION-27 - Write up a test suite plan [on Chris Lilley - due 2010-08-25].
Vlad: TPAC, CSS is obvious group, also SVG and XSL
jdaggett: what topics are?
... that determines how long we need
Vlad: topics is after checking for need to discuss
ChrisL: yes, need to ask if they willuse woff and to what extent
jdaggett: by november we hsould have a test suite so everyone in the room can look at the tests
... everyone of us
... it would be better to ask svg who will need to use woff to participate in our meeting at tpuc
ChrisL: people in this gruop could do ueful review of css3-fonts, similarly the other way
Adam: new q: could i change which font is used via js?
cslye: yes, like typekit's js loader doe
Adam: in FontLab 6 i'd like to have a feature for live preview in HTML
... without reloading the whole page
<ChrisL> XSL FO is meeting thu/fri
<ChrisL> http://www.w3.org/2010/11/TPAC/
Vlad: last item is implementation review
ChrisL: i asked adam if FL will support WOFF soon
Adam: certainly
Vlad: reference implementation?
ChrisL: status of woff at opera isnt yet clear
<erik> http://www.flickr.com/photos/letterror/4890870343/in/set-72157624711809860/
jdaggett: when the test suite is ready, we'll need a table of who passes what tests
ChrisL: and maintain it
... and once there are 2 green bars, we can move forward
Lorp: do any clauses prohibit usage on non-web platforms - like ebooks - where they pacakge text+woff
jdaggett: why do this?
... ah, download with a book
erik: woff compressino may be nicer than a raw font?
Lorp: licening might be related for web and ebooks
Vlad: epub can include fonts
Adam: adobe has a dont obfuscation technique like PDF-XML
cslye: i didnt know about that until this year, its old
si daniel: iTunes Album Format might bundle fonts
si daniels: if it uses @font-face doesn't mean font licensing for the web will cover such usage
<Vlad> Acknoledgements
ChrisL: ebook vendors have approached w3c
<Vlad> The WebFonts WG would like to thank Typecon organizers and SoTA for accommodating the attendees of the WG F2F meeting and providing meeting facilities, and would like to thank Adobe Systems and Christopher Slye for providing video projector for our use during the meeting.
jdaggett: comment on css3-font; we dont support TTC, and their typical uses are tricky and dont apply to web fonts context
... any ideas?
Adam: with css font stacking you can do the same thing
... you can slice your fonts into groups that way
... typical ttc allows many kanji and half width or full width or mono latin
... you can just do this with a css font stack
cslye: yes, but will composite fonts become more widely used and think they cant use it as is on the web, and will THEY think to use a cs font stack? or will they want omtehing more convenient?
John: WOFF is a container, having made some TTC i know they are a cmoplicated way to get a small space saving...
Adam: css is a composite format mechanism; unicode ranges, a way of pulling it all together
John: you coul dhave a composite font format with WOFF payloads
Vlad: WOFF2 could accomodate composite fonts
John: composite fonts is just XML wrapping around fonts
Adam: you can have it as one piece of woff data, like the metadata block, and then chunk ALL the tables together
... the CWOFF
Vlad: if you have text in arabic and latin, you want to keep uing the numerals defined in the arabic font
John: european punctuation is used all over the world
... chars in the devanagri block are meant to be used in other indic script
s
Adam: common locale directory; exemplar section of unicode.org
<John> Big thanks to Dave and Tab for scribing.
<ChrisL> Meeting: WebFonts WG f2f, Los Angeles