Re: Telcon reminder and agenda for Apr. 23

Hi Vlad,

I don't think I'll be able to make today's telcon, or if I can call in 
it'll certainly be late... I'll try to look over the discussion issues 
listed in [2], however, and respond via email if I have any comments.

Thanks,

Jonathan

On 23/4/14 16:58, Levantovsky, Vladimir wrote:
> 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.
>

Received on Wednesday, 23 April 2014 19:20:35 UTC