RE: Minutes, 3 Sept 2014 webfonts call

Thank you all for a very productive call today and for your active participation!
Let's plan to continue this discussion during the call next week (we'll start with reference [4] of the today's agenda) and follow on with other topics.

Please also send you proposed topics for F2F agenda, and let's continue the discussion on the email list.

Thank you very much,
Vlad


-----Original Message-----
From: Chris Lilley [mailto:chris@w3.org] 
Sent: Wednesday, September 03, 2014 11:15 AM
To: WebFonts WG
Subject: Minutes, 3 Sept 2014 webfonts call

Hello,

Minutes of the 3 Sept call at
http://www.w3.org/2014/09/03-webfonts-minutes.html
and below as text for tracker

                 WebFonts Working Group Teleconference

03 Sep 2014

   See also: [2]IRC log

      [2] http://www.w3.org/2014/09/03-webfonts-irc

Attendees

   Present
          Vlad, jfkthame, +1.425.882.aaaa, [Google],
          +1.408.921.aabb, ChrisL

   Regrets
   Chair
          vlad

   Scribe
          Vlad

Contents

     * [3]Topics
         1. [4]WOFF2 spec clarification for conformance
         2. [5]255Uint16 data type
     * [6]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 03 September 2014

   <scribe> scribenick: Vlad

WOFF2 spec clarification for conformance

   jfkthame: presenting his comments from Aug. 14 (see reference
   [2] in telcon agenda)

      [2] http://www.w3.org/2014/09/03-webfonts-irc

   <ChrisL> is there a benefit to preserving original table order?
   are there font consumers that rely on this?

   jfkthame: table order preservation - does it matter in WOFF2?
   In WOFF1 the table preservation was part of the effort to
   produce a binary compatible output file, WOFF2 output is not
   going to be binary compatible

   sergeym: table order should be compliant with the OpenType
   spec, which recommends certain table order to improve font
   rendering performance.

   Vlad: There is no guarantee that the input font file has the
   correct table order so mandating to preserve that isn't
   sensible.

   sergeym: maybe we should require a decoder to put tables in the
   order that is recommended by the OT spec, regardless of what
   order it was in the original input file.

   <jfkthame> see
   [7]http://www.microsoft.com/typography/otspec/recom.htm

      [7] http://www.microsoft.com/typography/otspec/recom.htm

   <jfkthame> look for "optimized table ordering"

   Vlad: These changes don;t seem to have an effect on the wire
   format of WOFF2, this should be okay as far as existing
   implementations are concerned

   Resolution for table order - decoders to produce the output
   font file that satisfy two conditions:

   1) table directory to be sorted by tag in alphabetic order:

   2) font tables to be placed in the order recommended by the
   OepNType spec.

   jfkthame: table directory entry needs to be edited to tie the
   loose ends.

   action Vlad - edit the spec to reflect the recommended changes

   <trackbot> Created ACTION-134 - - edit the spec to reflect the
   recommended changes [on Vladimir Levantovsky - due 2014-09-10].

   ChrisL: presenting his comments (see [3])

   ChrisL - font tables are compressed in a single stream, need to
   make it explicit and also clarify that a single stream is for
   font tables only, metadata and private data blocks are
   completely separate.

255Uint16 data type

   ChrisL: current definition allow scertain values to be encoded
   in more than one way, we either need to change the data type
   definition to prevent this from happening or add a normative
   statement that can be tested

   action RSheeter check the current reference iomplementation to
   see what is currently implemented

   <trackbot> Created ACTION-135 - Check the current reference
   iomplementation to see what is currently implemented [on
   Roderick Sheeter - due 2014-09-10].

   <ChrisLilley> action-135?

   <trackbot> action-135 -- Roderick Sheeter to Check the current
   reference implementation to see what is currently implemented
   -- due 2014-09-10 -- OPEN

   <trackbot> [8]http://www.w3.org/Fonts/WG/track/actions/135

      [8] http://www.w3.org/Fonts/WG/track/actions/135

   ChrisL: UintBase128 data type must take up to 5 bytes, this can
   be tested.

   jfkthame: there may be multipel ways to encode the same value
   using UintBase128, should we prevent this from happening?

   <RSheeter> second the motion to forbid unlimited streams of 0
   bytes :D

   - E.g., We can disallow leading zeros.

   <ChrisLilley> isn't that just a constraint on the allowed
   values of the 5th byte

   - there is a possible condition for overflow where the encoded
   value in UintBase128 is larger than 2^32-1 - need to specify
   that encoders must not allow this to happen and what the
   decoder should do when it encounters such a condition

   ChrisL - the spec is silent about decoder behavior regarding
   incorrect data encoding or overflow conditions, we need to
   specify that in any case when malformatted data types or
   overflow condition is detected the whole font must be rejected.

   action Vlad - edit the WOFF2 UintBase128 description to
   eliminate possible multiple encoded values and specify that any
   error conditions must invalidate the font file

   <trackbot> Created ACTION-136 - - edit the woff2 uintbase128
   description to eliminate possible multiple encoded values and
   specify that any error conditions must invalidate the font file
   [on Vladimir Levantovsky - due 2014-09-10].

   ChrisL: on WOFF2 header - many conditions and statements from
   WOFF1 spec would apply, we should add them to the WOFF2 spec.

   <ChrisLilley> if its just for word alignment then it can be a
   don't care field

   ChrisL: reserved values must be 'zero', current impelementation
   doesn't check that.

   sergeym if we require decoders to reject the font because of a
   non-zero value - we eliminate the possiblity to use it in the
   future.

   Vlad: we can make it a FF conformance statement but not require
   UA to reject the font. Current WOFF2 files would be checked for
   comformance, UA will be able to adapt for future changes.

   <ChrisLilley> +1

   <RSheeter> looks good to me

   Resolved: add a statement for FF conformance to require
   reserved filed be zero.

   Action ChrisL to edit the spec and implement the changes we
   agreed to during this call (see minutes on Sep. 3, 2014)

   <trackbot> Created ACTION-137 - Edit the spec and implement the
   changes we agreed to during this call (see minutes on sep. 3,
   2014) [on Chris Lilley - due 2014-09-10].

Summary of Action Items

   [End of minutes]

-- 
Best regards,
 Chris                          mailto:chris@w3.org

Received on Wednesday, 3 September 2014 15:21:07 UTC