W3C home > Mailing lists > Public > www-font@w3.org > July to September 2010

Minutes, 17 Aug WebFonts f2f (corrected)

From: Chris Lilley <chris@w3.org>
Date: Mon, 23 Aug 2010 17:47:34 +0200
Message-ID: <190209103.20100823174734@w3.org>
To: www-font@w3.org
Hello,

The previously posted minutes were incomplete, because the IRC logger started a new log at midnight (UTC). I have merged the two days logs and created new minutes.

http://www.w3.org/2010/08/18-webfonts-minutes-correct.html

or below as text

              WebFonts Working Group Meeting, Los Angeles

17 Aug 2010

   See also: [2]IRC log

      [2] http://www.w3.org/2010/08/17-webfonts-irc

Attendees

   Present
          Vlad, Chris, JDaggett, Sylvain, Christopher, John, Lurence,
          Dave, Adam, Sergei, Julio, Tab, Tal, Erik

   Regrets

   Chair
          Vlad

   Scribe
          TabAtkins_, crossland

Contents

     * [3]Topics
         1. [4]comments
         2. [5]Testable Assertions
         3. [6]Preparing for TPAC
         4. [7]Implementation Review
     * [8]Summary of Action Items
     _________________________________________________________

   <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> [9]http://www.w3.org/Fonts/WG/track/actions/1

      [9] http://www.w3.org/Fonts/WG/track/actions/1

   <ChrisL> [10]http://www.w3.org/Fonts/WG/track/actions/

     [10] 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:
   [11]http://dev.w3.org/webfonts/WOFF/spec/

     [11] http://dev.w3.org/webfonts/WOFF/spec/

   <jfkthame> ChrisL: thanks

comments

   <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
   [12]http://dev.w3.org/cvsweb/webfonts/WOFF/spec/Overview.html.diff?r
   1=1.12&r2=1.13&f=h

     [12] 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>
   [13]http://lists.w3.org/Archives/Public/www-font/2010JulSep/0027.htm
   l

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

     [14] 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

Testable Assertions

   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[$1\47].
   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
   [15]http://www.w3.org/2010/08/18-webfonts-minutes.html#action02]

     [15] 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
   [16]http://www.w3.org/2010/08/18-webfonts-minutes.html#action03]

     [16] 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
   [17]http://www.w3.org/2010/08/18-webfonts-minutes.html#action04]

     [17] 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
   [18]http://www.w3.org/2010/08/18-webfonts-minutes.html#action05]

     [18] 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
   [19]http://www.w3.org/2010/08/18-webfonts-minutes.html#action06]

     [19] 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
   [20]http://www.w3.org/2010/08/18-webfonts-minutes.html#action07]

     [20] 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
   [21]http://www.w3.org/2010/08/18-webfonts-minutes.html#action08]

     [21] 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
   [22]http://www.w3.org/2010/08/18-webfonts-minutes.html#action09]

     [22] 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
   [23]http://www.w3.org/2010/08/18-webfonts-minutes.html#action10]

     [23] 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
   [24]http://www.w3.org/2010/08/18-webfonts-minutes.html#action11]

     [24] 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
   [25]http://www.w3.org/2010/08/18-webfonts-minutes.html#action12]

     [25] 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].

Preparing for TPAC

   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> [26]http://www.w3.org/2010/11/TPAC/

     [26] http://www.w3.org/2010/11/TPAC/

Implementation Review

   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>
   [27]http://www.flickr.com/photos/letterror/4890870343/in/set-7215762
   4711809860/

     [27] 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

Summary of Action Items

   [NEW] ACTION: Chris to Appendix A should say this section is
   non-normative [recorded in
   [28]http://www.w3.org/2010/08/18-webfonts-minutes.html#action09]
   [NEW] ACTION: Chris to Check that everything in section 8 correctly
   references a conformance requirement earlier in the spec. [recorded
   in [29]http://www.w3.org/2010/08/18-webfonts-minutes.html#action08]
   [NEW] ACTION: chris to write up a test suite plan [recorded in
   [30]http://www.w3.org/2010/08/18-webfonts-minutes.html#action12]
   [NEW] ACTION: jdaggett to specify exact algorithm for verifying a
   valid offset for metadata and private data of S3P5 [recorded in
   [31]http://www.w3.org/2010/08/18-webfonts-minutes.html#action07]
   [NEW] ACTION: jdaggett to Tighten the description of the private
   data block. [recorded in
   [32]http://www.w3.org/2010/08/18-webfonts-minutes.html#action11]
   [NEW] ACTION: jfkthame to split intro to remove these requirements
   and insert them into a new section, "normative references" [recorded
   in [33]http://www.w3.org/2010/08/18-webfonts-minutes.html#action02]
   [NEW] ACTION: Jonathan to Merge appendix B & C into section 8.
   [recorded in
   [34]http://www.w3.org/2010/08/18-webfonts-minutes.html#action01]
   [NEW] 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
   [35]http://www.w3.org/2010/08/18-webfonts-minutes.html#action06]
   [NEW] ACTION: Jonathan to S3 Woff header, first entry, add "must be"
   [recorded in
   [36]http://www.w3.org/2010/08/18-webfonts-minutes.html#action04]
   [NEW] 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
   [37]http://www.w3.org/2010/08/18-webfonts-minutes.html#action05]
   [NEW] ACTION: Jonathan to split intro to remove these requirements
   and insert them into a new section, "normative references" [recorded
   in [38]http://www.w3.org/2010/08/18-webfonts-minutes.html#action03]
   [NEW] 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
   [39]http://www.w3.org/2010/08/18-webfonts-minutes.html#action10]

     [28] http://www.w3.org/2010/08/18-webfonts-minutes.html#action09
     [29] http://www.w3.org/2010/08/18-webfonts-minutes.html#action08
     [30] http://www.w3.org/2010/08/18-webfonts-minutes.html#action12
     [31] http://www.w3.org/2010/08/18-webfonts-minutes.html#action07
     [32] http://www.w3.org/2010/08/18-webfonts-minutes.html#action11
     [33] http://www.w3.org/2010/08/18-webfonts-minutes.html#action02
     [34] http://www.w3.org/2010/08/18-webfonts-minutes.html#action01
     [35] http://www.w3.org/2010/08/18-webfonts-minutes.html#action06
     [36] http://www.w3.org/2010/08/18-webfonts-minutes.html#action04
     [37] http://www.w3.org/2010/08/18-webfonts-minutes.html#action05
     [38] http://www.w3.org/2010/08/18-webfonts-minutes.html#action03
     [39] http://www.w3.org/2010/08/18-webfonts-minutes.html#action10

   [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 Monday, 23 August 2010 15:46:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:42 UTC