See also: IRC log
<trackbot> Date: 26 February 2014
<jfkthame> hi guys - sorry, i'm not able to call in today, but will lurk on irc
scribenick ChrisL
<scribe> scribenick: ChrisL
<sergeym__> Note, there is actually only one sergeym on IRC
cslye: (recap of discussions from
email) collections are a real part of font formats and working
to make that easier for developers
... agree its hard to apply to webfonts today
... concern that if it misses the boat are we missing an
opportunity, making TTC harder to use
... want to see TTC support eventually, if not now
Vlad: We are talking about a
delivery format. does not imply any rendering requirement, just
to transport it as needed
... being unable to deliver a certain class certainly stops it
being used
... being able to allows it to be supported sooner or
later
... want to avoid cutting something out needlessly. Orthogonal
to rendering of TTC
raph: (also recapping
email)
... have not been focussed on whether todays user agents can
render TTC/OTC more theoretical assumption
... TTC/OTC deliver functionality, but is there a better way
for example unicode-range and multiple pieces that can be
recombined
... also, looking at css3 fonts, it does not mandate or exclude
TTC but does give a fragment syntax that would work with
it
... agree with cslye that this is the opportunity to lay the
groundwork. still prefer simplification and want to explore
that
... do the use cases overlap the web at all. last week in
retrospect i was a bit narrow, need to also consider epub as
well for example
<jfkthame> the use case for TTC might be more interesting if we had an extension to @font-face that would allow an author to directly specify multiple faces from within a single resource
cslye: happy to help with that, ask Ken Lunde for example or David Lemon
raph: wanted to describe my email
proposal, summed up ideas from last week, more streamlined
way
... to reconstruct an OTC font.
... instead of dealing directly with offsets like sfnt, that we
reference the tables by an index number which is the same
object except it can contain duplicates with the same
tagg
... consider wether to explicitly disallow in the single font
case
... in the collection case you do have multiples, index
counting from zero, reconstruct by lists of indices from the
combined block
... similar to original but with less security implications
compared to direct offsets
... can reconstruct a TTC or extract one font from a
container
... no additional concern about offset in a compressed or
transformed data block
... for a single font its clear what to throw away
... so overall a better proposal. still worth discussing wether
to standardize or not, but more comfortable with it now
kuettel: glyph and loca would be paired. what about CFF?
raph: bothare subject to
trandsform, but not for CFF which is not much
preprocessed
... so no corresponding rule for CFF table
kuettel: ok
... nice thing about it is that if it is not a collection there
are no changes to the wire format
... good to get more data. could buy us some time and then over
te next months gather more use cases for collections
... as we have to date, all based on hard data
(general agreement)
Vlad: like the recent proposal
for the reasons mentioned
... low impact
... little additional complexity
... wanted to gauge efficiency
... not clear the use cases could be quantified
... one reason to support is for web-related or offline apps
like epub, where ttc would be more used
... also, extra complexity for adding collection support in the
transport is minimal
... eliminate much bigger problems in the future if there was a
call for ttC and the transport does not support it
kuettel: use cases and html/css propogate outside the web and what we want is font support without broken parts
raph: worried about adding
something that does not get used. but its a small amount of
crufy in the ordering, from before we commited to whole-font
compression
... but a preference, would be supported with tests, its
relatively small so the additional burden is slight
kuettel: cslye could you ask the typekit folks about this
<raph> typekit folks
cslye: yes of course, have had casual convesations about it
Vlad: what could be a resolution from discussions so far? strawpoll?
<jfkthame> should we regard this as a distinct format, based on a common structure? - very much like TTC compared to TTF
cslye: yes
kuettel: (scribe can't
hear)
... prefer to omit unless strong use case but can be
convinced
<raph> Chrisl: main use case seems to be large Asian fonts in which non-Han characters are in different styles
<raph> ... but unicode-range is another existing mechanism for achieving the same effect
KenjiBX: like raphs proposal as
it does not block you, can add it easily
... really like this freedom
... want to see a use case for the web
... usrs might serve too much data
<raph> ChrisL: if we implement this, it will be very important to test
Vlad: (personal take) like the
idea of supporting ttc just to be sure its a complete
support
... and because it can be done easily with no penalty
... dont like being put in a corner, rather than defending the
choice to exclude it down the line
... epub packages a lot of content so ther eis not the download
bottleneck
<jfkthame> i suspect applications like epub might really like it as a packaging option
Vlad: many apps based on web tech, want woff2 to work there too. prefer it is capable for any OFF
<jfkthame> e.g. if CSS were extended to allow something like https://pastebin.mozilla.org/4404194
sergey?
<Vlad> sergei, what is your position on the TTC support in WOFF2
<sergeym__> I would support it for completmess, so we dom't need to come back to it later
(seems like a consensus to me)
<sergeym__> But it should come at the same time as @fomt-face support for it
kuettel: also good to hear another implementor opinion
ChrisL: god to put in early even if removed later; patent policy
KenjiBX: impact on cacheing needs to be examined
raph: think there is a cacheing
benefit. imagine a cjk font for a site. ttc avoids having multi
downloads with substantial overlap
... css3 fonts suggests a fragment, jfkthame suggests annding a
face index
... both use the same base uri so cacheability is
improved
... over time it becomes more realistic to serve a cjk font
KenjiBX: concern over collections plus subsets
raph: same base url
... oh, ok, yes
KenjiBX: end up downloading everything to get one part
kuettel: relatively small overhead though
Vlad: consensus is that the spec draft includes raph's proposal, makes it easier to review.
KenjiBX: so it would not make a change in chrome, will not break current woff2 format
raph: correct
... explicit goal
Vlad: we are not even at ED
yet
... good, much more clarity on this now
<cslye> Anyone here can publish a standards-track document.
<raph> (I have a hard stop at 2 btw)
<cslye> In W3C, you can disclose a patent and provide licensing info later.
<cslye> Within a working group.
<cslye> Disclosing a patent and excluding a patent are different things.
<cslye> ChrisL: Will summarize all this in an email to WG.
<cslye> ChrisL: What is the status of the editor's draft?
(status is not ready to share yet)
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/webkit/typekit/ Succeeded: s/ad/at/ Found ScribeNick: ChrisL Inferring Scribes: ChrisL Default Present: Vlad, [Google], ChrisL, AWK, +1.650.214.aaaa, kenji, david, +1.650.214.aabb, Google Present: Vlad [Google] ChrisL AWK +1.650.214.aaaa kenji david +1.650.214.aabb Google Found Date: 26 Feb 2014 Guessing minutes URL: http://www.w3.org/2014/02/26-webfonts-minutes.html People with action items:[End of scribe.perl diagnostic output]