- From: Chris Lilley <chris@w3.org>
- Date: Mon, 23 Aug 2010 17:47:34 +0200
- To: www-font@w3.org
Hello,
The previously posted minutes were incomplete, because the IRC logger started a new log at midnight (UTC). I have merged the two days logs and created new minutes.
http://www.w3.org/2010/08/18-webfonts-minutes-correct.html
or below as text
WebFonts Working Group Meeting, Los Angeles
17 Aug 2010
See also: [2]IRC log
[2] http://www.w3.org/2010/08/17-webfonts-irc
Attendees
Present
Vlad, Chris, JDaggett, Sylvain, Christopher, John, Lurence,
Dave, Adam, Sergei, Julio, Tab, Tal, Erik
Regrets
Chair
Vlad
Scribe
TabAtkins_, crossland
Contents
* [3]Topics
1. [4]comments
2. [5]Testable Assertions
3. [6]Preparing for TPAC
4. [7]Implementation Review
* [8]Summary of Action Items
_________________________________________________________
<trackbot> Date: 17 August 2010
<ChrisL> action-1?
<trackbot> ACTION-1 -- Vladimir Levantovsky to draft something about
embedding bits -- due 2010-05-12 -- OPEN
<trackbot> [9]http://www.w3.org/Fonts/WG/track/actions/1
[9] http://www.w3.org/Fonts/WG/track/actions/1
<ChrisL> [10]http://www.w3.org/Fonts/WG/track/actions/
[10] http://www.w3.org/Fonts/WG/track/actions/
<ChrisL> hi jonathan. we just closed some old actions, some on you,
we believe they are done
<cslye> WOFF Working Draft:
[11]http://dev.w3.org/webfonts/WOFF/spec/
[11] http://dev.w3.org/webfonts/WOFF/spec/
<jfkthame> ChrisL: thanks
comments
<ChrisL> dev.w3.org/webfonts/WOFF/spec/Overview.html
<ChrisL> updated seconds ago
<TabAtkins_> [appendices B and C of the spec have not been updated
yet]
<ChrisL> recent changes as coloured diffs
[12]http://dev.w3.org/cvsweb/webfonts/WOFF/spec/Overview.html.diff?r
1=1.12&r2=1.13&f=h
[12] http://dev.w3.org/cvsweb/webfonts/WOFF/spec/Overview.html.diff?r1=1.12&r2=1.13&f=h
<jfkthame> skype dropped off....
<TabAtkins_> jdaggett: Section 3, WOFF header, "total sfnt size",
you now have it as ""total size needed for the uncompressed font
header... as padded".". That seems like slightly awkward phrasing.
<ChrisL> jdaggett: "Total size needed for the uncompressed font
data, including the sfnt header, directory, and font tables (as
padded)." as padded?
<TabAtkins_> jdaggett: I'm assuming you mean "including padding"?
<TabAtkins_> John: That's made explicit in the font table field.
<TabAtkins_> John: But it seemed like clarifying that as "including
padding" would be fine.
<TabAtkins_> John: It's "including" now.
<TabAtkins_> ChrisL: I have a minor editorial issue.
<ChrisL> change "storing the tables in uncompressed" to "storing
some or all the tables in uncompressed"
<ChrisL> scribenick: TabAtkins_
<jdaggett>
[13]http://lists.w3.org/Archives/Public/www-font/2010JulSep/0027.htm
l
[13] http://lists.w3.org/Archives/Public/www-font/2010JulSep/0027.html
jdaggett: Under "checksums", the wording in section 4 didn't
completely match section 8.
... My feeling was that UAs should not be required to check the
checksum.
jfkthame: A tool creating WOFF files might treat a checksum error as
a fatal error and refuse to proceed.
jdaggett: I don't think what you just said is completely captured by
the spec.
<ChrisL> authoring tools conformance and user agent requirements
should be clearly distinguished
jdaggett: Section 8 should say that UAs have slightly different
requirements from tool requirements.
ChrisL: In general, requirements should specify what they apply to.
Authoring tools, display tools, etc. have different requirements and
should be clearly distinguished.
... So "must be correct for the original table data" sounds like an
authoring tool requirement.
jfkthame: Yes.
jdaggett: But it's in a section making it seem that it applies to
both authoring tools and UAs.
... I suggest we create an action for you to come up with a proposed
wording change.
jfkthame: In section 4, the conformance requirements are for the
*file format*. Creation tools need to generate valid files.
jdaggett: But the next line is where it appears to bind UAs to doing
validity checking.
jfkthame: Ah, yes.
jdaggett: The checksums that are in fonts aren't really indicators
of validity, so to put the burden on UAs to do full checksum
validation is silly.
... And it's incompatible with incremental unpacking.
<ChrisL> if section 8 is only about conformance of the files, then "
Summary of Conformance Requirements" should be " Summary of
Conformance Requirements for WOFF files"
jdaggett: Appendix B and C are kind of a mix of "best practices" and
"informative requirements". I think "best practices" should be by
themselves, and MUSTs should be in one place.
<ChrisL> The "musts"s in appendix B and C should be removed and put
in different conformance requirements for authoring tools and for
browsers
jfkthame: I think the conformance requirements are coming from the
request that we had (Vlad or Sylvain?) to collect together the key
points for people creating WOFF tools.
... The MUSTs in the appendices should be just drawn directly from
the rest of the spec.
jdaggett: I think we should maybe just put all the MUSTs into
section 8, and in the Best Practices just put suggestions.
ChrisL: If we do that, section 8 needs to be split into multiple
pieces, to split up the conformance requirements according to group:
tools, UAs, etc.
jdaggett: I think moving it out of the appendices establishes that
this is normative, required behavior.
jfkthame: Wrapping my head about this... In my mind this spec is
solely about the file format. The requirements on the creator are
just to create valid files.
... For UAs it's a little trickier. If we say that, frex, creators
have to ensure that checksums are valid in the font, but we don't
want to require UAs to revalidate that, we're walking a balancing
act between wanting to mandate interop behavior between user agents.
... If you're presented with a WOFF file that's not completely
correct, we don't want some browsers to accept and some to reject.
ChrisL: You do get that conformity if you say browsers don't have to
check it.
jfkthame: Do you say just that? Does this leave details to
UA-specific error handling?
jdaggett: I think there is a set of mandated behavior, and a set of
validation requirements that are independent of this that we can't
define. There are platform-specific issues.
ChrisL: This is only about unpacking WOFF into sfnt. Any errors in
the sfnt are out of scope.
Vlad: I think it's perfectly okay to require tools to validate
checksums. It just helps authors to produce good files. Rejecting
files at this point doesn't hurt anyone.
... But once you hit browsers, you shouldn't reject the font just
because it's slightly invalid.
TabAtkins_: I agree with John that we want to specify WOFF unpacking
as precisely as possible, so that invalid WOFF files get unpacked in
the same way by all browsers.
jdaggett: That might be untestable, though. There are 2 steps - WOFF
unpacking and then sfnt decoding. These steps are indistinguishable
from a testing perspective. We can't test the sfnt part.
TabAtkins_: I overstated, then. Arbitrary bags of bits, even if
decoded the same way, may then result in sfnt data that is decoded
differently by browsers, and there's no way to tell where the
difference in behavior occurred.
jdaggett: As long as there's no requirement on browsers checking the
checksum.
... I think there are adequate conformance requirements otherwise in
there.
ChrisL: If there exists some opentype fonts with invalid checksums,
we can either say the WOFF transformation preserves that data, or it
corrects the checksum. We can't do both.
... We either go the lossless route, or we fix things.
<ChrisL> but not both
ChrisL: What's the scope of the problem? Are there fonts out there
right now with invalid checksums?
jfkthame: Yes.
ChrisL: And they work, so let's preserve that.
<jfkthame> but note that fixing the checksums will not break such
fonts
Vlad: WOFF is supposed to take some sfnt data in, and later push
sfnt data out.
... The checksum is just part of that data.
<jfkthame> the WOFF transformation is lossless for correct,
"normalized" sfnt data - it is explicitly NOT lossless for
"peculiar" sfnts - e.g. with extraneous data
Adam: The tool producing a WOFF may fiddle with the checksum, if may
subset the font, etc. We don't have to say something about that.
Vlad: You can always go back to the font vendor if they give you a
bad font. That's the benefit of tools doing conformance checking.
TabAtkins_: So are you saying that creation tools should fix invalid
checksums?
Vlad: No, creation tools should reject the font and not produce a
WOFF from it.
ChrisL: So browsers don't have to worry about it, because they never
receive the bad font in the first place.
Vlad: Subsetting is something that can happen on the fly, or
whatever. As far as WOFF is concerned, whatever happens to the font
before it reaches the converter is irrelevant.
jdaggett: When we make statements about checksums, we can make tests
that verify tools are doing the right thing. If we say "we don't
care", we can't put anything in the test suite about it.
... So what we're saying now is that creation tools should reject a
font if its checksum is incorrect, and not produce a WOFF?
ChrisL: Yes.
Vlad: And an author, if they got the font from a foundry, they can
go back to the foundry and complain about it. If the font is
ownerless, then you can just fix the font using existing tools
before giving it to the foundry.
jdaggett: Also recall that WOFF creation tools aren't required to be
*just* WOFF creators. They can package font-editting features as
well, and fix checksums or do subsetting or something before handing
the font to the WOFF-creator part.
ChrisL: So from a user point of view it doesn't matter, but from a
spec point of view requiring rejection allows clear, crisp
languages.
jdaggett: So we're agreeing on that text?
[general agreement]
ChrisL: Spec currently says that the checksum must be correct for
the sfnt data.
TabAtkins_: So let's make it explicit that that means the creation
tool must reject fonts which don't match that requirement.
Vlad: One procedural comment - those of us that are official members
of the WG can speak your mind whenever, but observers I think aren't
allowed procedurally to offer ideas?
... We all agreed to all the requirements re: patent licensing, etc.
I don't think non-members are probably high enough up to make the
same commitments.
[discussion of the Bitstream people, turns out they're all covered
and everyone's shiny and happy]
ChrisL: Where are we on the list of comments?
jdaggett: I think we've talked about all of them. I'm not sure what
we've decided about appendices B & C.
... I think we should move the conformance requirements to section
8, maybe in multiple subsections.
... Have one section listing requirements common to both creation
tools and UAs, then a section listing conformance requirements just
for creation tools, and one just for UAs.
ChrisL: I heard some resistance from John about this. Does this
sound okay?
jfkthame: No, I think I can edit it into that shape.
jdaggett: I think that all of the appendix B&C should be moved into
8. Once you remove the MUSTs, there's not much left in the appendix.
Also, it sort of becomes "Do Not Read", and runs the risk of
becoming stale.
<ChrisL> trackbot, status
<scribe> ACTION: Jonathan to Merge appendix B & C into section 8.
[recorded in
[14]http://www.w3.org/2010/08/18-webfonts-minutes.html#action01]
[14] http://www.w3.org/2010/08/18-webfonts-minutes.html#action01
<trackbot> Created ACTION-14 - Merge appendix B & C into section 8.
[on Jonathan Kew - due 2010-08-24].
<ChrisL> action john to explode
<trackbot> Sorry, amibiguous username (more than one match) - john
<trackbot> Try using a different identifier, such as family name or
username (eg. jhudson, jdaggett)
ChrisL: We had some other comments on the spec?
... One about why are we creating a new metadata scheme instead of
using RDF.
... I responded sorta robustly rejecting that, but also said that
there exists W3C tech that lets you produce RDF out of more
arbitrary data.
... We could even have an appendix over how to do that, but it's not
something we need to care about directly.
... Since we had people like Hakon recommending an extremely
pared-down plain text key-value syntax, I think we did all right
with an extremely simple XML format.
John: Eric Mueller (sp?) had some comments along similar lines, too.
ChrisL: I think that was more about duplication, that if we're
adding new metadata it should just go into the font directly.
tal: Which was ironic, since the OT people were complaining that
doing that would take too long.
<br type=coffee duration=15m>
<jfkthame> milk but no sugar in mine, please
<Adam> Hello IRC
<crossland> scribenick
<crossland> scribenic
<scribe> ScribeNick: crossland
ChrisL: ill take on the test suite stuff
Testable Assertions
Vlad: this means testable assertions for what the spec says
... how is it in css?
Chris: beter go trhough the document and figure it out, now :)
ChrisL: First pass with the MUSTs
Vlad: we can distinguish MUST in the english phrasing and MUST as a
specification requirement
... by having MUST in caps when its a spec req
ChrisL: we can alo just rephrase things so it only happens when its
a spec req
TabAtkins_: we want to be more specific about tool outputing WOFF
file?
Vlad: we agree to use uppercase MUST when its a spec req
er
oop
Vlad: we agree to NOT use uppercase MUST when its a spec req, we
will rephrase things so all uses of that word are spec req
we are discussing this para:
User agents supporting the WOFF file format for downloadable fonts
MUST respect the requirements of the CSS Fonts specification[$1\47].
In particular, such downloaded fonts are only available to the
documents that reference them; they MUST NOT be made available to
other applications or documents on the user's system.
question is, is this testable? worth testing, and can it be tested
automatically?
John Daggett: fonts not being available to other programs or
documents is testable
Adam: we should reference other specs (CSS3) which also mandate
this. S1 is more than an introduction, it deserves a section, to say
how this spec interacts with other specs
... not longer, maybe shorter, but more clearly defined
Vlad: "normative references" section is typical name for this
Adam: if we dont test for the validatity of opentype data, should we
test other dependenceie - cross document availablity, etc
... clearly defining "dependencie testing" leads to different kinds
of tests to consistency checking of the file format
... user agents that implement woff should test cross origin, cross
document, and maybe OFF testing
ChrisL: 3 kinds of tests: file format, authoring tools, user agents
behaviour
... usres expect user agents to do tings with woff, we should make
these testable things
Vlad: no one expects us to do exhastive tests for all areas, so we
can rely on css having more thorouh testing
... we crafted this section with the requests of font developers in
mind
john daggett: the requirement in this area from font vendor are
weaker than what UAs need
John daggett: we need to word this more tightly
scribe: if we have a test file, we are not testing all the subtlites
of the @font-face mechanism
chrisl: a simple test with 2 iframes, one doesnt link a font and one
does, both refer to the same font, and if the 2 frames look the
same, test fails
Adam: there are 2 spec deps here: cross domain in html5, cross
document in css3, these 2 first,
Vlad: 'must respect' is normative, so move that to the normative
section
?
john daggett: we should have tests based on revised language here,
yes
Adam: 'the primary purpose of the WOFF format' implies secondary
formats; SVG and XSL want to use it
... some gnu/linux vendors added woff as an installable format, i
dont know specific vendors
... may be fontconfig?
action for jonathan: split intro to remove these requirements and
insert them into a new section, "normative references"
<trackbot> Sorry, couldn't find user - for
action for jonathan kew: split intro to remove these requirements
and insert them into a new section, "normative references"
<trackbot> Sorry, couldn't find user - for
action for jfkthame: split intro to remove these requirements and
insert them into a new section, "normative references"
<trackbot> Sorry, couldn't find user - for
action for chrisl: make a simple test with 2 iframes, one doesnt
link a font and one does, both refer to the same font, and if the 2
frames look the same, test fails
<trackbot> Sorry, couldn't find user - for
<scribe> ACTION: jfkthame to split intro to remove these
requirements and insert them into a new section, "normative
references" [recorded in
[15]http://www.w3.org/2010/08/18-webfonts-minutes.html#action02]
[15] http://www.w3.org/2010/08/18-webfonts-minutes.html#action02
<trackbot> Sorry, couldn't find user - jfkthame
chrisl: next MUSt is in S2P3
... we need a special bad font to test this
"A complete WOFF file consists of a 44-byte header, immediately
followed (in this order) by a variable-size table directory, a
variable number of font tables, an optional block of extended
metadata, and an optional block of private data. Except for padding
with a maximum of three null bytes in places where 4-byte alignment
of a table length or data block is specified, there MUST NOT be any
extraneous data between the font tables and data blocks as po
chris: 3 tests, for validating tools, for authoring (conversion)
tools, and for user agents to reject bad woff
... "this file has 12 bytes of padding, error." style output
... conformance checks with authoring and UA tool
s
john dagget: same test, in 2 tools
Adam: take an invalid SFNT is one
... take in invalid WOFF and see its rejected is another
... error reporting should not be a conformance requirement
Vlad: UAs dont say anything about decisionthey make, if some put
error messages then thats up to them
<erik> @Dave: "Jonathan" is jfkthame.
erik: i figured that out but it still didnt work?
but rssagent seemed to get it
<erik> Did you try "ACTION Jonathan: "
<scribe> ACTION: Jonathan to split intro to remove these
requirements and insert them into a new section, "normative
references" [recorded in
[16]http://www.w3.org/2010/08/18-webfonts-minutes.html#action03]
[16] http://www.w3.org/2010/08/18-webfonts-minutes.html#action03
<trackbot> Created ACTION-15 - Split intro to remove these
requirements and insert them into a new section, "normative
references" [on Jonathan Kew - due 2010-08-24].
yay: )
thank erik!
<erik> :)
Vlad: so, there are 2 conformance requirements
<Vlad> sec 2, 3rd para - split the wording the wording to have two
conformance req - extra padding to be rejected on the conversion
side and extra padding to be rejected by the UA in the WOFF itself
calling jfkthame now
jdaggett: the concern is you have data between tables
... woff ought to have clearer statement that extraneou data i
rejected
... both to original SFNT and to WOFF files loaded by UAs
jfkthame: that UAs reject WOFFs wwith extra data is in S8
chrisl; is it mentioned twice?
Adam: its mentioned in the summary, so it ought to be in the body of
the pec
... summaries are not for new facts
<scribe> ACTION: Jonathan to S3 Woff header, first entry, add "must
be" [recorded in
[17]http://www.w3.org/2010/08/18-webfonts-minutes.html#action04]
[17] http://www.w3.org/2010/08/18-webfonts-minutes.html#action04
<trackbot> Created ACTION-16 - S3 Woff header, first entry, add
"must be" [on Jonathan Kew - due 2010-08-24].
<scribe> ACTION: Jonathan to sec 2, 3rd para - split the wording the
wording to have two conformance requirements - extra padding to be
rejected on the conversion side and extra padding to be rejected by
the UA in the WOFF itself [recorded in
[18]http://www.w3.org/2010/08/18-webfonts-minutes.html#action05]
[18] http://www.w3.org/2010/08/18-webfonts-minutes.html#action05
<trackbot> Created ACTION-17 - Sec 2, 3rd para - split the wording
the wording to have two conformance requirements - extra padding to
be rejected on the conversion side and extra padding to be rejected
by the UA in the WOFF itself [on Jonathan Kew - due 2010-08-24].
jdaggett: in the definitoin of 'reserved' say 'reserved, set to 0'
<scribe> ACTION: Jonathan to S3 Woff header, first entry, actually
dont add "must be", instead add "must" to the decriptoin in the
following text [recorded in
[19]http://www.w3.org/2010/08/18-webfonts-minutes.html#action06]
[19] http://www.w3.org/2010/08/18-webfonts-minutes.html#action06
<trackbot> Created ACTION-18 - S3 Woff header, first entry, actually
dont add "must be", instead add "must" to the decriptoin in the
following text [on Jonathan Kew - due 2010-08-24].
Vlad: now its 13:15 so we'll break for lunch soon
jfkthame: all sounds good!
<erik> Resuming.
<scribe> ScribeNick: crossland
TabAtkins_: "
... "If the offset and length fields pointing to the metadata or
private data block are out of range, indicating a byte range beyond
the physical size of the file, a conforming user agent MUST reject
the file as invalid." isnt good
... if they dont exist it must be 0
ChrisL: 4 cases, 0 then has one, or non-0, or beyond file, or in the
file that isnt theright block
TabAtkins_: 2 are correct and good, 2 are bad
ChrisL: so the 'must be set to 0' doent need to be "must"
jdaggett: need to tighten this language so its testable
... put "if metadata, theoffset must be valid, based on the order of
table"?
adam: section 2 decirbes the chunks
... the delcared value in S4 isnt about how the file is built, but
about the offset field
jdaggett: ipropse to action 'specify exact algo for verifying a vlid
offset for metadata and private data'
ACTION for jdaggett: specify exact algorithm for verifying a valid
offset for metadata and private data of S3P5
<trackbot> Sorry, couldn't find user - for
ACTION John Daggett: specify exact algorithm for verifying a valid
offset for metadata and private data of S3P5
<trackbot> Sorry, amibiguous username (more than one match) - John
<trackbot> Try using a different identifier, such as family name or
username (eg. jhudson, jdaggett)
<scribe> ACTION: jdaggett to specify exact algorithm for verifying a
valid offset for metadata and private data of S3P5 [recorded in
[20]http://www.w3.org/2010/08/18-webfonts-minutes.html#action07]
[20] http://www.w3.org/2010/08/18-webfonts-minutes.html#action07
<trackbot> Created ACTION-19 - Specify exact algorithm for verifying
a valid offset for metadata and private data of S3P5 [on John
Daggett - due 2010-08-24].
jdaggett: jfkthame and i discussed that roundtripping is important
... in S4P5
ChrisL: this is testable
... for "In cases where checksum recalculation is necessary or
changes to the original font data are made, e.g., to subset the
glyphs in the font or add special tables, conformant tools MUST
either remove any digital signature (i.e., a DSIG table) or
regenerate the signature (if the necessary credentials are
available), and MUST correct all affected checksum values and table
offsets, both for individual tables and the overall font data
checksum c
Vlad: i think a recommendations section helps
TabAtkins_: remove that whole para
ChrisL: and the finalone
jdaggett: not remove?
ChrisL: move it to where?
jdaggett: change the wording.
... being informative is fine
TabAtkins_: so remove all the musts
Vlad: best practices of vendors do this
jdaggett: implementors look at this document, not best practices
Vlad: in a separate section things get lost, but here we can
separate things
jdaggett: it should be in this section, thats where an implementor
will look at
... DSIG relate to the data of the font; if the tools change the
font data, they must be removed a theyre invalid
ChrisL: you start witha valid sfnt with no extra padding, tables,
and you should get bit for bit the same thing
... we shouldnt loose sight of that
adam: this seems like it belongs in the 'normative references'
section as it relates to the OT spe
c
scribe: "HEAD" table and "DSIG" table are OT tables
... this is the type of thing, not a CORE woff test, it might be a
conformance test but of a different tpe
Vlad: out of spec?
(this is S5P5)
adam: "it is recommended that the following requirements of the OT
specification are observed"
... "a new signature may be added"
... so that its saying _we remind_ rather than _we state_
(tab has an action for this.)
section 6!
ChrisL: "If no extended metadata is present, the metaOffset,
metaLength and metaOrigLength fields in the WOFF header MUST be set
to zero." is a refinement of an earlier MUST
jdaggett: should be either here or there
adam: S6 says all 3, S3 is okay
jdaggett: it should be in the headers
adam: S6P2 should be in Section 3
cslye: why must metadata be compressed (s2p2.1)
... my first impression wa that if i make a woff making tool, i dont
have to support compression as long as i dont support metadata?
ChrisL: "If the extended metadata is invalid" - invalid sucks
... can say "If the extended metadata cannot be decompressed or not
well formed XML"
... make invalidity explicity
TabAtkins_: actioning this to rewrite S6P4
ChrisL: "The presence (or absence) and content of the metadata block
MUST NOT affect font loading or rendering behavior of user agents"
should be at the start of the section, end of first para
TabAtkins_: so move it to new 2nd paragraph?
... why not MUST the UTF8 S6P6?
ChrisL: i am ok with it
sergeym: hmm
John: can we say utf8 or utf16?
TabAtkins_: xml says you must be able to read utf16, but i prefer to
require utf8
cslye: will anyone want utf16 in any scenario?
TabAtkins_: i can imagine people wanting it, but not needing it
Lorp: we should to exclude ascii and latin1 and so on
John: good idea
ChrisL: yes, must be utf8 or utf16 and utf8 is preferred
(this is S6P6)
(TabAtkins_ has this action)
ChrisL: so the dictionary list has a lot of MUSTs
... this is why we get into 'what valid means'
TabAtkins_: there's no "must" that the metadata must use this schema
... to add a new para after the UTF requirement that the metadata
must conform so this schema
ChrisL: i can make a relaxNG schema for this
... this prose is okay but its a bit slippery
ACTION ChrisL to make a relaxNG schema for the metadata block schema
<trackbot> Created ACTION-20 - Make a relaxNG schema for the
metadata block schema [on Chris Lilley - due 2010-08-24].
section 7!
ChrisL: "No padding is required at the end of the private data
block; any following data does not form part of the WOFF file
structure, and MUST be ignored." allows any random data in there
(TabAtkins_ takes an action for this)
ChrisL: S7P3 belongs in the header block
TabAtkins_: it could be ok here
Vlad: why not say, all tables are padded?
ChrisL: will that break WOFF already published?
Lorp: sfnt2woff doent pad the end
... actually, if the metadata section compresses to a non-4 byte
size, sfnt2woff doesnt check that it does and pad it
ChrisL: does S8 restate earlier ones?
<Lorp> i have not tested what sfnt2woff does with padding after a
non-4 private data block
ChrisL: i dont like to have the same conformance thing twice in the
spec, updates might not update both section
... S8 says its a summary, and says its about woff files and then
talks to UAs
(tab has an action on the md/pdb padding issue)
<TabAtkins_> ACTION: Chris to Check that everything in section 8
correctly references a conformance requirement earlier in the spec.
[recorded in
[21]http://www.w3.org/2010/08/18-webfonts-minutes.html#action08]
[21] http://www.w3.org/2010/08/18-webfonts-minutes.html#action08
<trackbot> Created ACTION-21 - Check that everything in section 8
correctly references a conformance requirement earlier in the spec.
[on Chris Lilley - due 2010-08-24].
<scribe> ACTION: Chris to Appendix A should say this section is
non-normative [recorded in
[22]http://www.w3.org/2010/08/18-webfonts-minutes.html#action09]
[22] http://www.w3.org/2010/08/18-webfonts-minutes.html#action09
<trackbot> Created ACTION-22 - Appendix A should say this section is
non-normative [on Chris Lilley - due 2010-08-24].
ChrisL: lowercae 'must' in app:Bp4
TabAtkins_: move these into section 8?
<TabAtkins_> ACTION: Jonathan to Verify whether, with zlib, it's
possible to have a stream that allows an EOF midstream, so extra
data can be padded on mid-stream. [recorded in
[23]http://www.w3.org/2010/08/18-webfonts-minutes.html#action10]
[23] http://www.w3.org/2010/08/18-webfonts-minutes.html#action10
<trackbot> Created ACTION-23 - Verify whether, with zlib, it's
possible to have a stream that allows an EOF midstream, so extra
data can be padded on mid-stream. [on Jonathan Kew - due
2010-08-24].
Vlad: that will be a way to have hidden data in woff
... as it will never show in the output after zlib is run to
decompress
... we have PDB, allows us to insert any random data, so why are we
concerned with other ways to carry extra data?
ChrisL: footnotes section is odd, normally a spec has 2 references,
normative and non normative
... these need to be checked for if they are required or not
... matters because we dont want to depend on release schedules of
other specs unless we really have to
action for chris to reformat footnotes section into normative and
non normative references
<trackbot> Sorry, couldn't find user - for
action for chrisl to reformat footnotes section into normative and
non normative references
<trackbot> Sorry, couldn't find user - for
Action for Jonathan to work with Chris L on reformatting footnotes
section into normative and non normative references
<trackbot> Sorry, couldn't find user - for
Action Jonathan to work with Chris L on reformatting footnotes
section into normative and non normative references
<trackbot> Created ACTION-24 - Work with Chris L on reformatting
footnotes section into normative and non normative references [on
Jonathan Kew - due 2010-08-24].
doh
TabAtkins_: returning to padding afer MD and PDB, what do we do?
there are tools that do both?
... we know many fonts exist from a tool that doe not pad
... so we should say you are allowed to pad, and find out if anyone
doe
s
. . .
ChrisL: tests vary, some are in a series, some are batched, and some
involve human arrangement and action
jdaggett: we need code to programmatically verify fonts
... we need test cases, that are UA tests, pass/fail
... we have testing for css, we can do a similar thing
ChrisL: making fonts for the tests is needed
... the byte checking is easy enough
... we need to produce 'bad' fonts
... id like a filename convention, eg bad-*.ttf
John: we can use libre fonts and corrupt them in various ways,
utopia -> distopia :)
adam: 1st sentence of the doc says "the WOFF font format"
... does this effect SIL OFL and Vera style renaming?
... will renaming this a file format mean we dont have to rename
OFL/Vera fonts
... can we write the spec to interprit this not as a separate font
format but as a archive format
... this is a valid questoin; some eulas prohibit modification
... if a font can be legally put on a wbe server, another isue; but
a clause that prevents users from modification is in many freeware
licenses and so on
... so rather than make an obscatle, the spec should say this isnt a
differnet file format, its a container format for transporting the
font data; and not a new font format
... so people can say this isnt a modification
... to me its more like compression
... most EULA doesn't say "you cant zip this"
jdaggett: thats something the EULA needs to define
... the working in the EULA is the only basis for this
adam: its not that we can see "woff doesnt modify fonts" and create
reality with words
vlad: we agreed from the start to say file format and not font
format
John: when we talk about "WOFF" as a "web font format" and i try to
catch myself saying "web font wrapper" or so... it is a lossless
compression of another font format
adam: so i think its worth clarifying that this is not a font
format, and others can debate it. change the first setence, the rest
is fine
Lorp: PDB says "but it has no publically defined format" and what if
MS then makes a defacto format for this?
... seems a bit vague
... like say if MS puts image binary data in the font in use , and
MSIE starts displaying the images
crossland: update notification via atom feed? could be extension
area
jdaggett: should "User agents should make no assumptions about the
content of a private block" be a must?
cslye: what if adobe has a UA that makes use of the PDB?
crossland: could a firefox extension do so?
vlad: what about putting a fingerprint in the PDB and crawling the
web for it?
jdaggett: that is okay, but right now, a single UA can use this to
add functionality for just them and break the standard
adam: right, and then you're not conformant to the public version
jdaggett: it says "The content of this data MUST NOT affect font
usage or load behavior. "
cslye: what if you have something a font manager can use, but not a
UA?
jdaggett: we're concerned about conformant UAs
cslye: we have this block specified, and as soon as anyone uses it,
it out of spec
jdaggett: right, its not for UAs to use, its for font vendor to
fingerprint
in
Julio: it should be changed, ye
... the language should be changed in S7P1
eriK: can the update notidication be done by file date and name in
the metadata?
John: its the update url?
crossland: yes
<TabAtkins_> ACTION: jdaggett to Tighten the description of the
private data block. [recorded in
[24]http://www.w3.org/2010/08/18-webfonts-minutes.html#action11]
[24] http://www.w3.org/2010/08/18-webfonts-minutes.html#action11
<trackbot> Created ACTION-25 - Tighten the description of the
private data block. [on John Daggett - due 2010-08-25].
ChrisL: <license url=""> is not THE LICENSE
cslye: the advantageof WOFF could attach the actualy license ot the
font
ChrisL: <license> is thelicense of the WOFF, not the font
John: its a license for web use
... the font might have a license that says you can link on the web
in secondarily licensed domains.
... the WOFF says what those domains are
... you dont want to write the font metadata each time you make a
woff, you want on TTF and when you woff it apply metadata simpley
Vlad: when you have 2 documents that claim to be a license, the
least restrictive one is what is enforcable, so you dont want
anything that can be interpreted as a second license
cslye: you dont want ot say this is for the license of font
John: so do we want ot be clear its a license for the woff file?
cslye: no, some foundries may want to use it in a specific way for
the contianed font, and others will want something else
adam: i see WOFF as a ZIP archive; we are making a packaging
convention...
John: i prefer "license summary" as "license" implies a legal
agreement
erik: what if your license is 2 lines?
adam: "licensing information"
... that could be full license, summary, url...
cslye: if adobe decides its risky to use it, we wont use it
John: in the spec we should not call it a license, "licensing
information" is generic and covers an actual license and anything
else
cslye: good topic for the panel
Vlad: 1 hour left
<Adam> Section 6, license block: change "The license for the font."
to "The licensing information for the font."
action chrisl to Section 6, license block: change "The license for
the font." to "The licensing information for the font."
<trackbot> Created ACTION-26 - Section 6, license block: change "The
license for the font." to "The licensing information for the font."
[on Chris Lilley - due 2010-08-25].
<ChrisL> ACTION: chris to write up a test suite plan [recorded in
[25]http://www.w3.org/2010/08/18-webfonts-minutes.html#action12]
[25] http://www.w3.org/2010/08/18-webfonts-minutes.html#action12
<trackbot> Created ACTION-27 - Write up a test suite plan [on Chris
Lilley - due 2010-08-25].
Preparing for TPAC
Vlad: TPAC, CSS is obvious group, also SVG and XSL
jdaggett: what topics are?
... that determines how long we need
Vlad: topics is after checking for need to discuss
ChrisL: yes, need to ask if they willuse woff and to what extent
jdaggett: by november we hsould have a test suite so everyone in the
room can look at the tests
... everyone of us
... it would be better to ask svg who will need to use woff to
participate in our meeting at tpuc
ChrisL: people in this gruop could do ueful review of css3-fonts,
similarly the other way
Adam: new q: could i change which font is used via js?
cslye: yes, like typekit's js loader doe
Adam: in FontLab 6 i'd like to have a feature for live preview in
HTML
... without reloading the whole page
<ChrisL> XSL FO is meeting thu/fri
<ChrisL> [26]http://www.w3.org/2010/11/TPAC/
[26] http://www.w3.org/2010/11/TPAC/
Implementation Review
Vlad: last item is implementation review
ChrisL: i asked adam if FL will support WOFF soon
Adam: certainly
Vlad: reference implementation?
ChrisL: status of woff at opera isnt yet clear
<erik>
[27]http://www.flickr.com/photos/letterror/4890870343/in/set-7215762
4711809860/
[27] http://www.flickr.com/photos/letterror/4890870343/in/set-72157624711809860/
jdaggett: when the test suite is ready, we'll need a table of who
passes what tests
ChrisL: and maintain it
... and once there are 2 green bars, we can move forward
Lorp: do any clauses prohibit usage on non-web platforms - like
ebooks - where they pacakge text+woff
jdaggett: why do this?
... ah, download with a book
erik: woff compressino may be nicer than a raw font?
Lorp: licening might be related for web and ebooks
Vlad: epub can include fonts
Adam: adobe has a dont obfuscation technique like PDF-XML
cslye: i didnt know about that until this year, its old
si daniel: iTunes Album Format might bundle fonts
si daniels: if it uses @font-face doesn't mean font licensing for
the web will cover such usage
<Vlad> Acknoledgements
ChrisL: ebook vendors have approached w3c
<Vlad> The WebFonts WG would like to thank Typecon organizers and
SoTA for accommodating the attendees of the WG F2F meeting and
providing meeting facilities, and would like to thank Adobe Systems
and Christopher Slye for providing video projector for our use
during the meeting.
jdaggett: comment on css3-font; we dont support TTC, and their
typical uses are tricky and dont apply to web fonts context
... any ideas?
Adam: with css font stacking you can do the same thing
... you can slice your fonts into groups that way
... typical ttc allows many kanji and half width or full width or
mono latin
... you can just do this with a css font stack
cslye: yes, but will composite fonts become more widely used and
think they cant use it as is on the web, and will THEY think to use
a cs font stack? or will they want omtehing more convenient?
John: WOFF is a container, having made some TTC i know they are a
cmoplicated way to get a small space saving...
Adam: css is a composite format mechanism; unicode ranges, a way of
pulling it all together
John: you coul dhave a composite font format with WOFF payloads
Vlad: WOFF2 could accomodate composite fonts
John: composite fonts is just XML wrapping around fonts
Adam: you can have it as one piece of woff data, like the metadata
block, and then chunk ALL the tables together
... the CWOFF
Vlad: if you have text in arabic and latin, you want to keep uing
the numerals defined in the arabic font
John: european punctuation is used all over the world
... chars in the devanagri block are meant to be used in other indic
script
s
Adam: common locale directory; exemplar section of unicode.org
<John> Big thanks to Dave and Tab for scribing.
<ChrisL> Meeting: WebFonts WG f2f, Los Angeles
Summary of Action Items
[NEW] ACTION: Chris to Appendix A should say this section is
non-normative [recorded in
[28]http://www.w3.org/2010/08/18-webfonts-minutes.html#action09]
[NEW] ACTION: Chris to Check that everything in section 8 correctly
references a conformance requirement earlier in the spec. [recorded
in [29]http://www.w3.org/2010/08/18-webfonts-minutes.html#action08]
[NEW] ACTION: chris to write up a test suite plan [recorded in
[30]http://www.w3.org/2010/08/18-webfonts-minutes.html#action12]
[NEW] ACTION: jdaggett to specify exact algorithm for verifying a
valid offset for metadata and private data of S3P5 [recorded in
[31]http://www.w3.org/2010/08/18-webfonts-minutes.html#action07]
[NEW] ACTION: jdaggett to Tighten the description of the private
data block. [recorded in
[32]http://www.w3.org/2010/08/18-webfonts-minutes.html#action11]
[NEW] ACTION: jfkthame to split intro to remove these requirements
and insert them into a new section, "normative references" [recorded
in [33]http://www.w3.org/2010/08/18-webfonts-minutes.html#action02]
[NEW] ACTION: Jonathan to Merge appendix B & C into section 8.
[recorded in
[34]http://www.w3.org/2010/08/18-webfonts-minutes.html#action01]
[NEW] ACTION: Jonathan to S3 Woff header, first entry, actually dont
add "must be", instead add "must" to the decriptoin in the following
text [recorded in
[35]http://www.w3.org/2010/08/18-webfonts-minutes.html#action06]
[NEW] ACTION: Jonathan to S3 Woff header, first entry, add "must be"
[recorded in
[36]http://www.w3.org/2010/08/18-webfonts-minutes.html#action04]
[NEW] ACTION: Jonathan to sec 2, 3rd para - split the wording the
wording to have two conformance requirements - extra padding to be
rejected on the conversion side and extra padding to be rejected by
the UA in the WOFF itself [recorded in
[37]http://www.w3.org/2010/08/18-webfonts-minutes.html#action05]
[NEW] ACTION: Jonathan to split intro to remove these requirements
and insert them into a new section, "normative references" [recorded
in [38]http://www.w3.org/2010/08/18-webfonts-minutes.html#action03]
[NEW] ACTION: Jonathan to Verify whether, with zlib, it's possible
to have a stream that allows an EOF midstream, so extra data can be
padded on mid-stream. [recorded in
[39]http://www.w3.org/2010/08/18-webfonts-minutes.html#action10]
[28] http://www.w3.org/2010/08/18-webfonts-minutes.html#action09
[29] http://www.w3.org/2010/08/18-webfonts-minutes.html#action08
[30] http://www.w3.org/2010/08/18-webfonts-minutes.html#action12
[31] http://www.w3.org/2010/08/18-webfonts-minutes.html#action07
[32] http://www.w3.org/2010/08/18-webfonts-minutes.html#action11
[33] http://www.w3.org/2010/08/18-webfonts-minutes.html#action02
[34] http://www.w3.org/2010/08/18-webfonts-minutes.html#action01
[35] http://www.w3.org/2010/08/18-webfonts-minutes.html#action06
[36] http://www.w3.org/2010/08/18-webfonts-minutes.html#action04
[37] http://www.w3.org/2010/08/18-webfonts-minutes.html#action05
[38] http://www.w3.org/2010/08/18-webfonts-minutes.html#action03
[39] http://www.w3.org/2010/08/18-webfonts-minutes.html#action10
[End of minutes]
--
Chris Lilley Technical Director, Interaction Domain
W3C Graphics Activity Lead, Fonts Activity Lead
Co-Chair, W3C Hypertext CG
Member, CSS, WebFonts, SVG Working Groups
Received on Monday, 23 August 2010 15:46:31 UTC