14:59:14 <RRSAgent> RRSAgent has joined #webfonts
14:59:14 <RRSAgent> logging to http://www.w3.org/2014/02/19-webfonts-irc
14:59:16 <trackbot> RRSAgent, make logs world
14:59:16 <Zakim> Zakim has joined #webfonts
14:59:18 <trackbot> Zakim, this will be 3668
14:59:18 <Zakim> ok, trackbot; I see IA_Fonts()10:00AM scheduled to start in 1 minute
14:59:19 <trackbot> Meeting: WebFonts Working Group Teleconference
14:59:19 <trackbot> Date: 19 February 2014
14:59:38 <Vlad> zakim, who is here?
14:59:38 <Zakim> IA_Fonts()10:00AM has not yet started, Vlad
14:59:39 <Zakim> On IRC I see RRSAgent, sergeym, kuettel, Vlad, raph, trackbot
14:59:50 <Vlad> zakim, this is 3668
14:59:50 <Zakim> ok, Vlad; that matches IA_Fonts()10:00AM
15:00:10 <Vlad> zakim, who is here?
15:00:10 <Zakim> On the phone I see +1.425.882.aaaa, cslye, Vlad
15:00:11 <Zakim> On IRC I see RRSAgent, sergeym, kuettel, Vlad, raph, trackbot
15:00:11 <Zakim> + +1.510.717.aabb
15:05:00 <Vlad> zakim, aabb is raph
15:05:00 <Zakim> +raph; got it
15:05:52 <Vlad> zakim, aaaa is sergeym
15:05:52 <Zakim> +sergeym; got it
15:07:16 <jfkthame> jfkthame has joined #webfonts
15:07:50 <John_Hudson> John_Hudson has joined #webfonts
15:07:53 <jfkthame> hi guys - sorry, i'm not able to call in today, but will lurk on irc to see any notes
15:08:38 <Zakim> +JonhHudson
15:10:02 <kuettel> Vlad: will postpone Brotli / IETF RFC discussions, as Chris Lilley is not able to join
15:10:27 <kuettel> Vlad: big topic of discussion today: TTC support (or not)
15:10:41 <kuettel> Vlad: no new information from Adobe just yet
15:11:15 <kuettel> Vlad: Ken Lundy(sp?) historically was eager to see support for TTC which contained both CFF and TTF
15:11:34 <raph> Ken Lunde
15:11:36 <kuettel> Vlad: TTC collections can be beneficial for CJK
15:12:16 <kuettel> Vlad: not sure (need more info) if benefits of TTC on the desktop would carry over to the web -- esp. as not being used with web fonts to date
15:13:09 <Vlad> Topic: TTC support
15:14:28 <kuettel> Raph: what would changes to the format look like?  TTC has notion of table directories
15:14:55 <kuettel> Raph: multiple table directories, with each directory having same structure (offset + length)
15:15:09 <kuettel> Raph: some tables would be unique to the font, some shared across fonts within the TTC
15:15:27 <kuettel> Raph: one use case: complex scripts (multiple styles)
15:15:46 <kuettel> Raph: glyph table is unique, but OpenType (esp. GSUB) is shared
15:15:59 <kuettel> Raph: as the shaping logic would be the same for bold or italic
15:16:28 <kuettel> Raph: one script where there could be a significant improvement is Devanagari
15:16:41 <Vlad> scribenick: kuettel
15:16:54 <kuettel> Raph: however fonts that he looked at did not follow this pattern -- would need to be reworked
15:17:15 <kuettel> Raph: gain in other cases is minor (few percent at best after rework)
15:17:32 <kuettel> Raph: thus, not an extremely compelling case for TTC support in WOFF 2.0
15:18:01 <kuettel> Raph: esp. given that the web page might only use some of the styles, yet have to pay the transfer cost of all
15:18:22 <kuettel> Raph: for CJK -- aware of Han unification using TTC
15:18:53 <kuettel> Raph: e.g. font that covers many CJK languages
15:19:20 <kuettel> Raph: in this case the glyph table is shared (union of the Han unification), however other tables would be different (e.g. cmap)
15:19:43 <kuettel> Raph: next, device fonts
15:20:06 <kuettel> Raph: could make a strong case, as device needs to support the worlds languages
15:20:29 <kuettel> Raph: combined font could be smaller
15:20:52 <kuettel> Raph: that said, in a web context this makes a lot less sense
15:21:18 <kuettel> Raph: esp. as a frequent pattern on the web is to serve the most optimized font for a given user agent
15:21:49 <kuettel> Raph: where here, serving a specific Han language would be a bigger win over serving the combined Han TTC
15:22:20 <kuettel> Raph: thus, target would be a web page with multiple Han languages, which just isn't that likely
15:22:37 <kuettel> Raph: rather the common case would be a single Han language
15:23:01 <kuettel> Raph: OpenType variant mechanism, is likely a more modern way of accomplishing the same thing
15:23:39 <kuettel> Raph: OpenType is backwards compatible, unlike TTC
15:23:48 <kuettel> Raph: another use case that was proposed on the mailing list
15:24:49 <kuettel> Raph: (missed a bit).  web has a great fallback mechanism that allows fonts to be mixed
15:25:31 <kuettel> Raph: other web font features, such as unicode-range enable even greater optimizations over TTC
15:25:59 <kuettel> Raph: thus, seeing few benefits of TTC support
15:26:41 <kuettel> Vlad: another use case that came up recently, Japanese family of fonts + Latin.
15:27:09 <kuettel> Vlad: could combine all four fonts in to one TTC, which would be handy for device fonts or distribution
15:27:20 <kuettel> Vlad: but not sure how compelling that would be for the web
15:27:53 <kuettel> Raph: more likely that for web fonts the font would be split up, would combine with font-family + unicode-range as needed
15:29:41 <kuettel> Raph: huge file sizes put more pressure to subset, which makes the use case for TTC less compelling
15:30:38 <kuettel> Raph: how much complexity would TTC add?
15:31:22 <kuettel> Raph: cost is non-trivial.  wire format has a strong stream processing flavor (process and then forget), where more complicated structure with multiple references would require more complex logic
15:32:21 <kuettel> Raph: would likely involve significant changes for the client.  security would likely be another big factor (more work to harden, more risks, etc)
15:33:03 <kuettel> Raph: the open type sanitizer is pretty rigorous today, would need to be reworked
15:33:17 <kuettel> Raph: not impossible, but definitely not trivial
15:33:32 <kuettel> Raph: would really need to go back and rethink the security implications
15:33:47 <kuettel> Raph: without a significant improvement, hard to justify
15:34:08 <kuettel> Vlad: for completeness, where would table overlap occur?
15:35:11 <kuettel> Raph: no, rather multiple references to byte ranges (didn't capture everything)
15:36:08 <kuettel> Raph: if only extracting a single font (from the TTC), likely easier, but would need to skip
15:36:42 <kuettel> Raph: extracting multiple fonts is more involved, which is what one would want to do in the web case (otherwise, why return a collection)
15:37:48 <kuettel> Raph: implementation would likely have the option of returning multiple fonts or a container
15:38:09 <kuettel> Vlad: to summarize, Raph made a detailed and compelling case for not supporting TTCs on the web
15:39:26 <kuettel> John Hudson: TTC has been a historical part of the sfnt structure.  However as Raph noted, there are other (better) ways of doing the same on the web
15:40:31 <kuettel> John: have agreed with Jonathan where we should look at how it would be used, just want to make sure that we don't miss something
15:41:03 <kuettel> John: esp. given that some have been eager to see further TTC support (e.g. Adobe with CFF)
15:41:11 <kuettel> Raph: would love to hear from Adobe
15:41:29 <kuettel> Raph: we should gather their input prior to making a decision
15:41:48 <kuettel> Vlad: Sergey, thoughts?
15:43:03 <kuettel> Sergey: for Microsoft, having seeing savings for CJK (on desktop), but don't see the savings carrying over to web fonts (esp. given the other mechanisms).  Not sure about web apps
15:43:14 <kuettel> Sergey: thus, feel that it is not that important
15:43:45 <kuettel> Sergey: would be more work to support (esp. given existing MTX code base)
15:44:03 <kuettel> Sergey: thus eager to hear from more foundries, to understand their needs for TTC
15:44:19 <kuettel> Vlad: anyone else?  Chris?
15:45:14 <kuettel> Vlad: (wearing Monotype hat): reached out internally to find a compelling case, but was not able to.  In the larger scope (e.g. epubs), there could be compelling use cases
15:45:36 <kuettel> Vlad: balance might change for epubs, where many fonts could be bundled with the book
15:45:49 <kuettel> Sergey: would that be the perfect case for subsetting?
15:46:07 <kuettel> Vlad: yes, but book would likely pull in most of the font anyways
15:46:59 <kuettel> Vlad: that was the only likely compelling use case that I found
15:47:30 <kuettel> Vlad: also share the desire to see TTC supported, due to the OpenType spec -- want to carry it over
15:48:07 <kuettel> Vlad: from the implementation point of view, single stream compression could make it easier (than otherwise)
15:48:55 <kuettel> Vlad: think that WOFF 2.0 is in a better position to support TTC over WOFF 1.0
15:49:46 <kuettel> Raph: not just a matter of compression, rather there are also the table transforms that would complicate things
15:50:11 <kuettel> Vlad: agree
15:51:10 <kuettel> Raph: definitely not trival
15:51:48 <kuettel> Raph: e.g. length of data after Brotli compression and transforms
15:52:08 <kuettel> Raph: I guess you could do it
15:52:40 <kuettel> Raph: would likely involve multiple passes over the data
15:53:48 <kuettel> Raph: definitely a multi-step process, would require detecting regions in Brotli streams.... enough work to trigger more security reviews, etc
15:55:04 <kuettel> Vlad: additional processing steps not in conflict with single stream compression
15:55:54 <kuettel> Vlad: agree that it would be more work, not a departure from what we have today from a compression point of view
15:56:26 <kuettel> Vlad: summarizing again
15:56:41 <kuettel> Vlad: have not heard a really compelling use case just yet
15:57:00 <kuettel> Vlad: mildly compelling use case for epubs (or weak case)
15:57:28 <kuettel> Vlad: believe that if we do decide to support TTC, additional complexity would be marginal (could have been a lot more complex with per-table compression)
15:58:05 <kuettel> Vlad: another weak case, TTC being part of the OpenType spec, thus a nice to have, esp. in case we missed something looking forward
15:58:45 <kuettel> David: another potential use case that has been brought up over the past few months is color fonts
15:59:15 <kuettel> Vlad: not seeing this as any different from others
15:59:52 <kuettel> Sergey: what tables would be shared?  eager to learn more
16:00:19 <kuettel> Vlad: with color fonts, would have shared glyph table
16:01:10 <kuettel> Vlad: from a compression point of view, not seeing a big difference
16:03:37 <kuettel> Raph: sounds right
16:03:47 <kuettel> Vlad: to recap, great discussion today
16:04:22 <kuettel> Vlad: continue active discussions on the mailing list
16:04:28 <jfkthame> and great note-taking ... thanks David!
16:04:47 <kuettel> thank you! :)
16:06:00 <kuettel> Vlad: thank you for starting the editor's draft of the specification Raph
16:06:22 <kuettel> Vlad: once draft is somewhat complete, will take a pass over it
16:07:24 <kuettel> Raph: hoping to share something soon
16:10:12 <kuettel> Thank you everyone!
16:10:34 <Zakim> -JonhHudson
16:12:30 <Zakim> -raph
16:12:37 <Zakim> -cslye
16:12:39 <Vlad> zakim, list attendees
16:12:39 <Zakim> As of this point the attendees have been +1.425.882.aaaa, cslye, Vlad, +1.510.717.aabb, raph, sergeym, JonhHudson
16:12:45 <Zakim> -sergeym
16:12:51 <Vlad> rrsagent, make minutes
16:12:51 <RRSAgent> I have made the request to generate http://www.w3.org/2014/02/19-webfonts-minutes.html Vlad
16:12:56 <Zakim> -Vlad
16:12:58 <Zakim> IA_Fonts()10:00AM has ended
16:12:58 <Zakim> Attendees were +1.425.882.aaaa, cslye, Vlad, +1.510.717.aabb, raph, sergeym, JonhHudson
16:13:07 <Vlad> rrsagent, make minutes
16:13:07 <RRSAgent> I have made the request to generate http://www.w3.org/2014/02/19-webfonts-minutes.html Vlad
16:24:04 <Zakim> restarting zakim-bot in 3 minutes to recover bridge state; please save your agendas
16:27:37 <Zakim> zakim-bot restarting