<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

TTC

<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

brotli and ietf

<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: