17:15:32 RRSAgent has joined #webfonts 17:15:32 logging to http://www.w3.org/2010/08/17-webfonts-irc 17:15:34 RRSAgent, make logs world 17:15:34 Zakim has joined #webfonts 17:15:36 Zakim, this will be 3668 17:15:36 I do not see a conference matching that name scheduled within the next hour, trackbot 17:15:37 Meeting: WebFonts Working Group Teleconference 17:15:37 Date: 17 August 2010 17:15:56 zakim, remind me in 9 hours to be at a party 17:15:56 ok, ChrisL 17:16:13 action-1? 17:16:13 ACTION-1 -- Vladimir Levantovsky to draft something about embedding bits -- due 2010-05-12 -- OPEN 17:16:13 http://www.w3.org/Fonts/WG/track/actions/1 17:17:33 http://www.w3.org/Fonts/WG/track/actions/ 17:22:05 jfkthame has joined #webfonts 17:22:40 hi jonathan. we just closed some old actions, some on you, we believe they are done 17:22:49 WOFF Working Draft: http://dev.w3.org/webfonts/WOFF/spec/ 17:22:55 ChrisL: thanks 17:23:43 topic: comments 17:26:08 dev.w3.org/webfonts/WOFF/spec/Overview.html 17:26:12 updated seconds ago 17:27:48 [appendices B and C of the spec have not been updated yet] 17:28:04 recent changes as coloured diffs http://dev.w3.org/cvsweb/webfonts/WOFF/spec/Overview.html.diff?r1=1.12&r2=1.13&f=h 17:29:58 skype dropped off.... 17:30:36 jdaggett: Section 3, WOFF header, "total sfnt size", you now have it as "[...]". That seems like slightly awkward phrasing. 17:30:51 jdaggett: "Total size needed for the uncompressed font data, including the sfnt header, directory, and font tables (as padded)." as padded? 17:30:55 s/[...]/"total size needed for the uncompressed font header... as padded". 17:31:06 jdaggett: I'm assuming you mean "including padding"? 17:31:23 John: That's made explicit in the font table field. 17:31:38 John: But it seemed like clarifying that as "including padding" would be fien. 17:31:45 s/fien/fine/ 17:31:54 John: It's "including" now. 17:32:48 ChrisL: I have a minor editorial issue. 17:33:10 change "storing the tables in uncompressed" to "storing some or all the tables in uncompressed" 17:33:29 rrsagent, here 17:33:29 See http://www.w3.org/2010/08/17-webfonts-irc#T17-33-29 17:34:15 scribenick: TabAtkins_ 17:34:19 http://lists.w3.org/Archives/Public/www-font/2010JulSep/0027.html 17:35:13 jdaggett: Under "checksums", the wording in section 4 didn't completely match section 8. 17:35:23 sergeym has joined #webfonts 17:35:39 jdaggett: My feeling was that UAs should not be required to check the checksum. 17:36:14 jfkthame: A tool creating WOFF files might treat a checksum error and refuse to proceed. 17:36:34 s/error and/error as a fatal error and/ 17:36:38 jdaggett: I don't think what you just said is completely captured by the spec. 17:36:46 authoring tools conformance and user agent requirements should be clearly distinguished 17:36:51 jdaggett: Section 8 should say that UAs have slightly different requirements from tool requirements. 17:37:30 ChrisL: In general, requirements should specify what they apply to. Authoring tools, display tools, etc. have different requirements and should be clearly distinguished. 17:37:46 ChrisL: So "must be correct for the original table data" sounds like an authoring tool requirement. 17:37:49 jfkthame: Yes. 17:38:06 jdaggett: But it's in a section making it seem that it applies to both authoring tools and UAs. 17:38:25 jdaggett: I suggest we create an action for you to come up with a proposed wording change. 17:38:58 jfkthame: In section 4, the conformance requirements are for the *file format*. Creation tools need to generate valid files. 17:39:39 jdaggett: But the next line is where it appears to bind UAs to doing validity checking. 17:39:39 jfkthame: Ah, yes. 17:39:50 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. 17:40:14 jdaggett: And it's incompatible with incremental unpacking. 17:40:29 if section 8 is only about conformance of the files, then " Summary of Conformance Requirements" should be " Summary of Conformance Requirements for WOFF files" 17:41:39 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. 17:42:03 The "musts"s in appendix B and C should be removed and put in different conformance requirements for authoring tools and for browsers 17:42:25 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. 17:42:26 jfkthame: The MUSTs in the appendices should be just drawn directly from the rest of the spec. 17:42:50 jdaggett: I think we should maybe just put all the MUSTs into section 8, and in the Best Practices just put suggestions. 17:43:21 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. 17:43:47 jdaggett: I think moving it out of the appendices establishes that this is normative, required behavior. 17:44:33 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. 17:44:44 xulio has joined #webfonts 17:45:18 jfkthame: 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. 17:45:43 jfkthame: 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. 17:45:57 ChrisL: You do get that conformity if you say browsers don't have to check it. 17:46:23 jfkthame: Do you say just that? Does this leave details to UA-specific error handling? 17:46:49 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. 17:47:34 ChrisL: This is only about unpacking WOFF into sfnt. Any errors in the sfnt are out of scope. 17:48:19 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. 17:48:39 Vlad: But once you hit browsers, you shouldn't reject the font just because it's slightly invalid. 17:52:09 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. 17:53:59 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. 17:55:08 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. 17:55:28 jdaggett: As long as there's no requirement on browsers checking the checksum. 17:55:49 jdaggett: I think there are adequate conformance requirements otherwise in there. 17:57:04 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. 17:57:17 ChrisL: We either go the lossless route, or we fix things. 17:57:42 but not both 17:58:45 ChrisL: What's the scope of the problem? Are there fonts out there right now with invalid checksums? 17:58:48 jfkthame: Yes. 17:58:57 ChrisL: And they work, so let's preserve that. 17:59:07 but note that fixing the checksums will not break such fonts 17:59:13 Vlad: WOFF is supposed to take some sfnt data in, and later push sfnt data out. 17:59:21 Vlad: The checksum is just part of that data. 18:00:15 the WOFF transformation is lossless for correct, "normalized" sfnt data - it is explicitly NOT lossless for "peculiar" sfnts - e.g. with extraneous data 18:00:15 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. 18:01:12 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. 18:01:30 TabAtkins_: So are you saying that creation tools should fix invalid checksums? 18:01:42 Vlad: No, creation tools should reject the font and not produce a WOFF from it. 18:01:57 ChrisL: So browsers don't have to worry about it, because they never receive the bad font in the first place. 18:02:38 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. 18:03:53 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. 18:04:39 jdaggett: So what we're saying now is that creation tools should reject a font if its checksum is incorrect, and not produce a WOFF? 18:04:41 ChrisL: Yes. 18:05:27 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. 18:06:42 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. 18:07:27 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. 18:07:35 jdaggett: So we're agreeing on that text? 18:07:40 [general agreement] 18:08:14 ChrisL: Spec currently says that the checksum must be correct for the sfnt data. 18:09:06 TabAtkins_: So let's make it explicit that that means the creation tool must reject fonts which don't match that requirement. 18:10:31 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? 18:12:24 Vlad: 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. 18:12:42 [discussion of the Bitstream people, turns out they're all covered and everyone's shiny and happy] 18:13:09 ChrisL: Where are we on the list of comments? 18:13:22 jdaggett: I think we've talked about all of them. I'm not sure what we've decided about appendices B & C. 18:13:39 jdaggett: I think we should move the conformance requirements to section 8, maybe in multiple subsections. 18:14:11 jdaggett: 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. 18:14:23 ChrisL: I heard some resistance from John about this. Does this sound okay? 18:14:36 jfkthame: No, I think I can edit it into that shape. 18:18:49 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. 18:19:13 trackbot, status 18:19:19 ACTION Jonathan: Merge appendix B & C into section 8. 18:19:19 Created ACTION-14 - Merge appendix B & C into section 8. [on Jonathan Kew - due 2010-08-24]. 18:20:01 action john to explode 18:20:01 Sorry, amibiguous username (more than one match) - john 18:20:01 Try using a different identifier, such as family name or username (eg. jhudson, jdaggett) 18:20:18 crossland has joined #webfonts 18:20:45 ChrisL: We had some other comments on the spec? 18:21:35 danlssorc has joined #webfonts 18:21:47 ChrisL: One about why are we creating a new metadata scheme instead of using RDF. 18:22:20 ChrisL: I responded sorta robustly rejecting that, but also said that there exists W3C tech that lets you produce RDF out of more arbitrary data. 18:22:43 ChrisL: We could even have an appendix over how to do that, but it's not something we need to care about directly. 18:24:01 ChrisL: 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. 18:26:02 John: Eric Mueller (sp?) had some comments along similar lines, too. 18:26:29 ChrisL: I think that was more about duplication, that if we're adding new metadata it should just go into the font directly. 18:26:59 tal: Which was ironic, since the OT people were complaining that doing that would take too long. 18:27:47
18:27:59 milk but no sugar in mine, please 18:35:14 tal has joined #webfonts 18:36:12 crossland has joined #webfonts 18:37:56 crossland has left #webfonts 18:38:13 crossland has joined #webfonts 19:07:20 jdaggett has joined #webfonts 19:07:33 John_Hudson has joined #webfonts 19:09:47 lorp_ has joined #webfonts 19:11:01 Adam has joined #webfonts 19:11:08 Hello IRC 19:13:21 Laurence has joined #webfonts 19:13:21 scribenick 19:13:27 scribenic 19:14:04 ScribeNick: crossland 19:15:28 ChrisL: ill take on the test suite stuff 19:15:52 Vlad: this means testable assertions for what the spec says 19:16:58 Vlad: how is it in css? 19:18:04 Chris: beter go trhough the document and figure it out, now :) 19:18:14 ChrisL: First pass with the MUSTs 19:18:50 Vlad: we can distinguish MUST in the english phrasing and MUST as a specification requirement 19:19:32 Vlad: by having MUST in caps when its a spec req 19:19:48 ChrisL: we can alo just rephrase things so it only happens when its a spec req 19:20:12 TabAtkins_: we want to be more specific about tool outputing WOFF file? 19:23:38 Vlad: we agree to use uppercase MUST when its a spec req 19:24:11 er 19:24:11 oop 19:24:37 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 19:32:33 we are discussing this para: 19:32:36 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. 19:33:17 question is, is this testable? worth testing, and can it be tested automatically? 19:33:55 John Daggett: fonts not being available to other programs or documents is testable 19:36:34 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 19:36:42 Adam: not longer, maybe shorter, but more clearly defined 19:36:54 Vlad: "normative references" section is typical name for this 19:38:47 Adam: if we dont test for the validatity of opentype data, should we test other dependenceie - cross document availablity, etc 19:39:10 Adam: clearly defining "dependencie testing" leads to different kinds of tests to consistency checking of the file format 19:39:44 Adam: user agents that implement woff should test cross origin, cross document, and maybe OFF testing 19:40:19 ChrisL: 3 kinds of tests: file format, authoring tools, user agents behaviour 19:40:35 ChrisL: usres expect user agents to do tings with woff, we should make these testable things 19:42:13 Vlad: no one expects us to do exhastive tests for all areas, so we can rely on css having more thorouh testing 19:42:48 Vlad: we crafted this section with the requests of font developers in mind 19:43:20 john daggett: the requirement in this area from font vendor are weaker than what UAs need 19:43:53 John daggett: we need to word this more tightly 19:45:42 ... if we have a test file, we are not testing all the subtlites of the @font-face mechanism 19:46:20 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 19:46:51 Adam: there are 2 spec deps here: cross domain in html5, cross document in css3, these 2 first, 19:47:32 Vlad: 'must respect' is normative, so move that to the normative section 19:47:38 ? 19:47:57 john daggett: we should have tests based on revised language here, yes 19:49:40 Adam: 'the primary purpose of the WOFF format' implies secondary formats; SVG and XSL want to use it 19:50:09 Adam: some gnu/linux vendors added woff as an installable format, i dont know specific vendors 19:50:19 Adam: may be fontconfig? 19:51:43 action for jonathan: split intro to remove these requirements and insert them into a new section, "normative references" 19:51:43 Sorry, couldn't find user - for 19:51:52 action for jonathan kew: split intro to remove these requirements and insert them into a new section, "normative references" 19:51:52 Sorry, couldn't find user - for 19:53:01 action for jfkthame: split intro to remove these requirements and insert them into a new section, "normative references" 19:53:01 Sorry, couldn't find user - for 19:53:57 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 19:53:57 Sorry, couldn't find user - for 19:54:17 action jfkthame: split intro to remove these requirements and insert them into a new section, "normative references" 19:54:17 Sorry, couldn't find user - jfkthame 19:55:02 chrisl: next MUSt is in S2P3 19:55:26 chrisl: we need a special bad font to test this 19:55:40 "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 19:56:52 chris: 3 tests, for validating tools, for authoring (conversion) tools, and for user agents to reject bad woff 19:57:20 chris: "this file has 12 bytes of padding, error." style output 19:58:21 chris: conformance checks with authoring and UA tool 19:58:22 s 19:58:41 john dagget: same test, in 2 tools 19:58:48 Adam: take an invalid SFNT is one 19:59:01 Adam: take in invalid WOFF and see its rejected is another 19:59:15 Adam: error reporting should not be a conformance requirement 19:59:37 Vlad: UAs dont say anything about decisionthey make, if some put error messages then thats up to them 19:59:45 @Dave: "Jonathan" is jfkthame. 19:59:58 erik: i figured that out but it still didnt work? 20:00:26 but rssagent seemed to get it 20:01:04 Did you try "ACTION Jonathan: " 20:01:53 ACTION Jonathan: split intro to remove these requirements and insert them into a new section, "normative references" 20:01:53 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]. 20:01:58 yay :) 20:02:00 thank erik! 20:02:11 :) 20:02:39 Vlad: so, there are 2 conformance requirements 20:04:19 sec 2, 3rd para - split the wording the wording to have two confrmance req - extra padding to be rejected on the conversion side and extra padding to be rejected by the UA in the WOFF itself 20:04:36 s/frm/form 20:05:37 calling jfkthame now 20:07:50 jdaggett: the concern is you have data between tables 20:10:54 jdaggett: woff ought to have clearer statement that extraneou data i rejected 20:11:06 ... both to original SFNT and to WOFF files loaded by UAs 20:11:23 jfkthame: that UAs reject WOFFs wwith extra data is in S8 20:11:33 chrisl; is it mentioned twice? 20:11:47 Adam: its mentioned in the summary, so it ought to be in the body of the pec 20:11:56 Adam: summaries are not for new facts 20:13:09 sergeym has joined #webfonts 20:13:21 ACTION Jonathan: S3 Woff header, first entry, add "must be" 20:13:21 Created ACTION-16 - S3 Woff header, first entry, add "must be" [on Jonathan Kew - due 2010-08-24]. 20:14:23 ACTION Jonathan: 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 20:14:23 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]. 20:15:05 jdaggett: in the definitoin of 'reserved' say 'reserved, set to 0' 20:15:49 ACTION Jonathan: S3 Woff header, first entry, actually dont add "must be", instead add "must" to the decriptoin in the following text 20:15:49 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]. 20:17:00 Vlad: now its 13:15 so we'll break for lunch soon 20:17:27 jfkthame: all sounds good! 20:17:39 cslye_ has joined #webfonts 20:30:13 cslye has joined #webfonts 21:27:45 TabAtkins_ has joined #webfonts 21:27:47 tal has joined #webfonts 21:30:21 erik has joined #webfonts 21:30:49 jdaggett has joined #webfonts 21:34:58 sylvaing has joined #webfonts 21:44:03 sergeym has joined #webfonts 21:46:36 John_Hudson has joined #webfonts 21:47:16 abattis has joined #webfonts 21:49:56 Lorp has joined #webfonts 21:50:05 Resuming. 21:51:27 cslye has joined #webfonts 21:52:23 cslye has joined #webfonts 22:01:46 ChrisL has joined #webfonts 22:01:58 rrsagent, here 22:01:58 See http://www.w3.org/2010/08/17-webfonts-irc#T22-01-58 22:05:31 Julio has joined #webfonts 22:05:35 ScribeNick: crossland 22:06:09 TabAtkins_: " 22:06:18 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 22:06:47 TabAtkins_: if they dont exist it must be 0 22:07:54 ChrisL: 4 cases, 0 then has one, or non-0, or beyond file, or in the file that isnt theright block 22:08:06 TabAtkins_: 2 are correct and good, 2 are bad 22:09:13 ChrisL: so the 'must be set to 0' doent need to be "must" 22:11:45 jdaggett: need to tighten this language so its testable 22:13:13 Vlad has joined #webfonts 22:13:46 jdaggett: put "if metadata, theoffset must be valid, based on the order of table"? 22:13:57 adam: section 2 decirbes the chunks 22:14:12 adam: the delcared value in S4 isnt about how the file is built, but about the offset field 22:14:46 jdaggett: ipropse to action 'specify exact algo for verifying a vlid offset for metadata and private data' 22:16:21 ACTION for jdaggett: specify exact algorithm for verifying a valid offset for metadata and private data of S3P5 22:16:21 Sorry, couldn't find user - for 22:16:37 ACTION John Daggett: specify exact algorithm for verifying a valid offset for metadata and private data of S3P5 22:16:37 Sorry, amibiguous username (more than one match) - John 22:16:37 Try using a different identifier, such as family name or username (eg. jhudson, jdaggett) 22:16:45 ACTION jdaggett: specify exact algorithm for verifying a valid offset for metadata and private data of S3P5 22:16:45 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]. 22:19:14 jdaggett: jfkthame and i discussed that roundtripping is important 22:19:37 ... in S4P5 22:20:46 ChrisL: this is testable 22:21:36 ChrisL: 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 22:21:59 Vlad: i think a recommendations section helps 22:22:07 TabAtkins_: remove that whole para 22:22:13 ChrisL: and the finalone 22:22:22 jdaggett: not remove? 22:22:27 ChrisL: move it to where? 22:22:46 jdaggett: change the wording. 22:23:24 jdaggett: being informative is fine 22:23:27 TabAtkins_: so remove all the musts 22:23:49 Vlad: best practices of vendors do this 22:23:51 jdaggett: implementors look at this document, not best practices 22:25:10 Vlad: in a separate section things get lost, but here we can separate things 22:25:23 jdaggett: it should be in this section, thats where an implementor will look at 22:26:05 jdaggett: DSIG relate to the data of the font; if the tools change the font data, they must be removed a theyre invalid 22:29:49 ChrisL: you start witha valid sfnt with no extra padding, tables, and you should get bit for bit the same thing 22:30:07 ChrisL: we shouldnt loose sight of that 22:33:32 adam: this seems like it belongs in the 'normative references' section as it relates to the OT spe 22:33:35 c 22:33:46 ... "HEAD" table and "DSIG" table are OT tables 22:34:13 ... this is the type of thing, not a CORE woff test, it might be a conformance test but of a different tpe 22:35:18 Vlad: out of spec? 22:37:48 (this is S5P5) 22:38:22 adam: "it is recommended that the following requirements of the OT specification are observed" 22:38:41 ... "a new signature may be added" 22:38:55 ... so that its saying _we remind_ rather than _we state_ 22:39:56 (tab has an action for this.) 22:40:47 section 6! 22:41:27 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 MUT 22:41:33 s/MUT/MUST 22:41:51 jdaggett: should be either here or there 22:42:31 adam: S6 says all 3, S3 is okay 22:42:41 jdaggett: it should be in the headers 22:42:48 adam: S6P2 should be in Section 3 22:44:34 cslye: why must metadata be compressed (s2p2.1) 22:45:33 cslye: 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? 22:46:13 ChrisL: "If the extended metadata is invalid" - invalid sucks 22:46:40 ChrisL: can say "If the extended metadata cannot be decompressed or not well formed XML" 22:46:46 ... make invalidity explicity 22:47:23 TabAtkins_: actioning this to rewrite S6P4 22:48:48 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 22:49:40 TabAtkins_: so move it to new 2nd paragraph? 22:51:00 TabAtkins_: why not MUST the UTF8 S6P6? 22:51:20 ChrisL: i am ok with it 22:51:27 sergeym: hmm 22:52:59 John: can we say utf8 or utf16? 22:53:40 TabAtkins_: xml says you must be able to read utf16, but i prefer to require utf8 22:53:50 cslye: will anyone want utf16 in any scenario? 22:53:58 TabAtkins_: i can imagine people wanting it, but not needing it 22:54:51 Lorp: we should to exclude ascii and latin1 and so on 22:54:56 John: good idea 22:55:10 ChrisL: yes, must be utf8 or utf16 and utf8 is preferred 22:55:34 (this is S6P6) 22:56:01 (TabAtkins_ has this action) 22:58:57 ChrisL: so the dictionary list has a lot of MUSTs 22:59:11 ChrisL: this is why we get into 'what valid means' 23:00:11 TabAtkins_: there's no "must" that the metadata must use this schema 23:00:29 ... to add a new para after the UTF requirement that the metadata must conform to this schema 23:00:35 s/to/so 23:00:44 ChrisL: i can make a relaxNG schema for this 23:00:55 ChrisL: this prose is okay but its a bit slippery 23:01:32 ACTION ChrisL to make a relaxNG schema for the metadata block schema 23:01:32 Created ACTION-20 - Make a relaxNG schema for the metadata block schema [on Chris Lilley - due 2010-08-24]. 23:02:11 section 7! 23:03:27 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 23:03:48 (TabAtkins_ takes an action for this) 23:04:06 ChrisL: S7P3 belongs in the header block 23:05:48 TabAtkins_: it could be ok here 23:07:12 Vlad: why not say, all tables are padded? 23:08:13 ChrisL: will that break WOFF already published? 23:10:16 Lorp: sfnt2woff doent pad the end 23:11:49 Lorp: actually, if the metadata section compresses to a non-4 byte size, sfnt2woff doesnt check that it does and pad it 23:12:18 ChrisL: does S8 restate earlier one? 23:12:23 s/one/ones 23:12:47 i have not tested what sfnt2woff does with padding after a non-4 private data block 23:12:49 ChrisL: i dont like to have the same conformance thing twice in the spec, updates might not update both section 23:13:50 ChrisL: S8 says its a summary, and says its about woff files and then talks to UAs 23:15:46 (tab has an action on the md/pdb padding issue) 23:17:07 Action Chris: Check that everything in section 8 correctly references a conformance requirement earlier in the spec. 23:17:07 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]. 23:18:09 Action Chris: Appendix A should say this section is non-normative 23:18:09 Created ACTION-22 - Appendix A should say this section is non-normative [on Chris Lilley - due 2010-08-24]. 23:19:30 ChrisL: lowercae 'must' in app:Bp4 23:20:32 TabAtkins_: move these into section 8? 23:25:04 ACTION Jonathan: 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. 23:25:04 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]. 23:26:33 Vlad: that will be a way to have hidden data in woff 23:26:46 Vlad: as it will never show in the output after zlib is run to decompress 23:28:03 ... we have PDB, allows us to insert any random data, so why are we concerned with other ways to carry extra data? 23:29:09 ChrisL: footnotes section is odd, normally a spec has 2 references, normative and non normative 23:29:37 ChrisL: these need to be checked for if they are required or not 23:30:03 ... matters because we dont want to depend on release schedules of other specs unless we really have to 23:30:59 action for chris to reformat footnotes section into normative and non normative references 23:30:59 Sorry, couldn't find user - for 23:31:03 action for chrisl to reformat footnotes section into normative and non normative references 23:31:03 Sorry, couldn't find user - for 23:31:21 Action for Jonathan to work with Chris L on reformatting footnotes section into normative and non normative references 23:31:21 Sorry, couldn't find user - for 23:31:26 Action Jonathan to work with Chris L on reformatting footnotes section into normative and non normative references 23:31:26 Created ACTION-24 - Work with Chris L on reformatting footnotes section into normative and non normative references [on Jonathan Kew - due 2010-08-24]. 23:31:30 doh 23:33:46 TabAtkins_: returning to padding afer MD and PDB, what do we do? there are tools that do both? 23:34:50 TabAtkins_: we know many fonts exist from a tool that doe not pad 23:35:05 TabAtkins_: so we should say you are allowed to pad, and find out if anyone doe 23:35:08 s 23:38:50 . . . 23:39:09 ChrisL: tests vary, some are in a series, some are batched, and some involve human arrangement and action 23:39:17 jdaggett: we need code to programmatically verify fonts 23:39:34 jdaggett: we need test cases, that are UA tests, pass/fail 23:39:47 jdaggett: we have testing for css, we can do a similar thing 23:40:51 ChrisL: making fonts for the tests is needed 23:41:12 ChrisL: the byte checking is easy enough 23:41:20 ChrisL: we need to produce 'bad' fonts 23:41:56 ChrisL: id like a filename convention, eg bad-*.ttf 23:42:19 John: we can use libre fonts and corrupt them in various ways, utopia -> distopia :) 23:42:58 adam: 1st sentence of the doc says "the WOFF font format" 23:44:09 ... does this effect SIL OFL and Vera style renaming? 23:44:34 ... will renaming this a file format mean we dont have to rename OFL/Vera fonts 23:44:57 ... can we write the spec to interprit this not as a separate font format but as a archive format 23:45:19 ... this is a valid questoin; some eulas prohibit modification 23:45:38 ... 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 23:46:06 ... 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 23:46:13 ... so people can say this isnt a modification 23:46:18 ... to me its more like compression 23:46:39