See also: IRC log
<trackbot> Date: 03 September 2014
<scribe> scribenick: Vlad
jfkthame: presenting his comments from Aug. 14 (see reference [2] in telcon agenda)
<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 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.
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> 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].
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/1)/2)/ Succeeded: s/iomplementation/implementation/ Succeeded: s/should/must/ Succeeded: s/adopt/adapt/ Found ScribeNick: Vlad Inferring Scribes: Vlad Default Present: Vlad, jfkthame, +1.425.882.aaaa, [Google], +1.408.921.aabb, ChrisL Present: Vlad jfkthame +1.425.882.aaaa [Google] +1.408.921.aabb ChrisL Found Date: 03 Sep 2014 Guessing minutes URL: http://www.w3.org/2014/09/03-webfonts-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]