- From: Chris Lilley <chris@w3.org>
- Date: Wed, 3 Sep 2014 17:14:31 +0200
- To: WebFonts WG <public-webfonts-wg@w3.org>
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:14:45 UTC