W3C home > Mailing lists > Public > public-webfonts-wg@w3.org > November 2010

Minutes, Lyon TPAC WebFonts WG meeting day 2.

From: Chris Lilley <chris@w3.org>
Date: Wed, 17 Nov 2010 18:26:56 +0100
Message-ID: <1995600896.20101117182656@w3.org>
To: WOFF Working Group <public-webfonts-wg@w3.org>
Hello,

I notice the minutes for the second day of the Lyon f2f were not sent out, so
http://www.w3.org/2010/11/05-webfonts-minutes.html

(the list of attendees is totally incomplete, not sure why)

                 WebFonts Working Group Teleconference

05 Nov 2010

   See also: [2]IRC log

      [2] http://www.w3.org/2010/11/05-webfonts-irc

Attendees

   Present
          timeless

Real Present: (from memory and IRC)

Vlad, jdaggett, Chris, John, cslye, jfkthame, dsinger, timeless, Sylvaing, and some observers too.

   Regrets
   Chair
          Vlad

   Scribe
          ChrisL

Contents

     * [3]Topics
         1. [4]woff processing model
     * [5]Summary of Action Items
     _________________________________________________________

   <trackbot> Date: 05 November 2010

woff processing model

   <jdaggett> discussion about chris l's email

   <Vlad> If anyone wnats to join via Zakim bridge, please announce
   your intention to join in the WG email list

   <jdaggett>
   [6]http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/00
   10.html

      [6] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/0010.html

   <John> Suggestion to review uses of the term 'original font' and
   specify 'input font'.

   <John> Proposal: change last sentence of first paragraph of
   introduction to read: 'User agents decode the WOFF file to restore
   the input font data such that it will display identically to that
   input font.'

   <John> or: 'User agents decode the WOFF file to restore the font
   data such that it will display identically to the input font.'

   <jdaggett> Vlad: based on defn of input file from chris

   <jdaggett> Vlad: what if we add "no overlapping tables" to what
   chris has proposed

   <Vlad> I suggest that the input should be defined as a "well-formed
   sfnt file" which conforms to the following requirements: no hidden
   data, non-overlapping tables, all tables padded to long boundaries
   and correct checksums

   <jdaggett> John: get rid of "in general" in third para of
   introduction

   <jdaggett> cslye: do we want to restrict woff to truetype, opentype
   etc.

   <jdaggett> chris lilley arrives, bands play

   <jdaggett> discussion of how far to push definition of "well-formed"
   opentype font

   <jdaggett> attempting live editing of spec to define processing
   model

   <jdaggett> discussion of whether diagrams are really necessary or
   not

   <John> 'User agents decode the WOFF file to restore the font data
   such that it will display identically to the input font.'

   <jdaggett> working on transforming "original" to "input"

   <cslye> Let's define the term "input font" at the top (as any sfnt
   font, blah blah) and then use that term throughout the spec.

   <John> The WOFF format is a container for the table-based sfnt
   structure used in e.g. TrueType [TrueType], OpenType [OpenType] and
   Open Font Format [OFF] fonts, hereafter referred to as sfnt fonts.

   <John> The structure and contents of decoded font data exactly match
   those of a well-formed input font file.

   <jdaggett> more discussion of round-tripping

   <John> Suggested: 'The main body of the file consists of the same
   collection of font data tables as a well-formed input sfnt font,
   stored in the same order, except that each table MAY be compressed,
   and the sfnt table directory is replaced by the WOFF table
   directory.'

   <Vlad> Doing spec edits to replace references to "original" font
   with input file.

   This means that the overall font checksum of a

   font decompressed from a conformant WOFF file will always match the
   checksum

   in a well-formed input font

   A well-formed input font does not have structural anomalies such as

   incorrect padding, overlapping font tables, or

   extraneous data between tables (which will be discarded by the WOFF

   generator).

   <jdaggett> break

   [7]http://www.w3.org/2002/06/registering-mediatype

      [7] http://www.w3.org/2002/06/registering-mediatype

   [8]http://www.ietf.org/rfc/rfc4288.txt

      [8] http://www.ietf.org/rfc/rfc4288.txt

   Registration Template

   action chris to write to iesg suggesting font/ top level type

   <trackbot> Created ACTION-39 - Write to iesg suggesting font/ top
   level type [on Chris Lilley - due 2010-11-12].

   [9]http://www.w3.org/2002/06/registering-mediatype

      [9] http://www.w3.org/2002/06/registering-mediatype

   action chris to add a media type registration remplate for woff,
   omitting the top level type

   <trackbot> Created ACTION-40 - Add a media type registration
   remplate for woff, omitting the top level type [on Chris Lilley -
   due 2010-11-12].

   <dsinger> have a look at the draft
   [10]http://tools.ietf.org/html/draft-singer-font-mime-00

     [10] http://tools.ietf.org/html/draft-singer-font-mime-00

   <dsinger> have a look at
   [11]http://www.iana.org/assignments/media-types/index.html

     [11] http://www.iana.org/assignments/media-types/index.html

   [12]http://dev.w3.org/webfonts/WOFF/spec/Overview.html#mediatype

     [12] http://dev.w3.org/webfonts/WOFF/spec/Overview.html#mediatype

   <jfkthame_afk> for the Magic Number field:

   <jfkthame_afk> The signature field in the WOFF header MUST contain
   the "magic number" 0x774F4646

   <timeless> fwiw css => application/x-pointplus can be found in
   [13]http://lists.w3.org/Archives/Public/www-style/1998Mar/0000.html

     [13] http://lists.w3.org/Archives/Public/www-style/1998Mar/0000.html

   <Vlad> [14]http://dev.w3.org/webfonts/WOFF/spec/

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

   <dsinger> suggested text: Note that user agents need not necessarily
   reconstitute the original sfnt as a whole, and may reorder tables
   when decoding the WOFF file to sfnt form; they may access individual
   tables directly as needed. Under these circumstances the resulting
   sfnt will no longer be an exact copy of the original, and checksums
   or digital signature data may be invalidated as a result.

   <jfkthame_afk> No overlapping tables: The offset and length values
   in the input sfnt table directory must not indicate overlapping byte
   ranges of the input font.

   RESOLUTION: Proceed to Last Call on this document, final review of
   recent edits by Weds 10 Nov. publication aimed at 11 Nov.

Summary of Action Items

   [End of minutes]
     __________________________________
  

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups
Received on Wednesday, 17 November 2010 17:27:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 17 November 2010 17:27:45 GMT