Telcon reminder and agenda for Apr. 23

Hello WG,

We will have our regularly scheduled telcon today at

US West Coast - 13:00
US East Coast - 16:00
Central Europe - 22:00



Zakim telephone bridge:

+1.617.761.6200 (Boston)

or

>From your SIP phone: zakim@voip.w3.org<sip:zakim@voip.w3.org>

with conference code 3668 ("FONT") followed by '#' sign.

(Instructions on how to connect using SIP:

     http://www.w3.org/2006/tools/wiki/Zakim-SIP)


IRC channel is #webfonts, irc://irc.w3.org:6665/webfonts

or http://irc.w3.org/?channels=webfonts

Agenda:

-          Review and discuss the updated version of the WOFF2 spec [1], and get it ready for publication as FPWD (see [2] for the list of discussion points );

-          AOB

Thank you,
Vlad

[1] http://dev.w3.org/webfonts/WOFF2/spec/
[2] For WG discussion:

-          Now that the transform for glyf and loca tables is mandatory - do we need to use bit 7 of table directory flag to indicate transform, or should we simply mark it as reserved? These are the only two tables that can/will be transformed, and they are explicitly identified by their "known tag" encoding (bits 0-6 of the flag).

[Note to editors - if we decide to eliminate the use of bit 7 as a transform flag - modify section 3 and second and third paragraphs of section 4.]

-          Since the current version of the spec includes all known tables and the list fits perfectly in 6-bit field of the flag - should we still keep extensible format and have one more bit allocated for future table tags, or should we simply allocate entry #63 as arbitrary tag flag and have one or two unspecified bits reserved for future use?

-          [Note to editors - in section 4.1, indexFormat field needs description and/or clarification.]

-          In transformed glyf header - Why do we use SHORT data type for nContour stream? The possible alternative would be to use 255USHORT and introduce another bitmask (e.g. cgBitmap, similar to bboxBitmap) that would simply be 'sign' of 255USHORT  nContours value for composite glyphs. It would almost guarantee the savings of one byte of data per glyph for the majority of simple glyphs, and for all composite glyphs.

-          In section 4.4 "Table order constraints" - I am not sure if the discussion of the relationship between the original glyph table size and the concept of a 'nominal' size is useful. Yes, the glyph table data can be reconstructed in more than one way, and depending on how it's done the resulting size may vary but I think we only confuse developers by  introducing the concept of nominal size of the table, which may differ from the original size or the reconstructed size. Why don't we just say that the original size is to be encoded in the WOFF2 table directory, and that reconstructed size may differ due to possible variations in reconstructing the values of glyph outline point coordinates. Then we simply refer to the original OT/OFF spec and let them figure things out on their own.