Telcon minutes, Wed., Feb. 19

Online at http://www.w3.org/2014/02/19-webfonts-minutes.html and as plain text below:

                               - DRAFT -

                 WebFonts Working Group Teleconference

19 Feb 2014

   See also: [2]IRC log

      [2] http://www.w3.org/2014/02/19-webfonts-irc

Attendees

   Present
          +1.425.882.aaaa, cslye, Vlad, +1.510.717.aabb, raph,
          sergeym, JonhHudson

   Regrets
   Chair
          SV_MEETING_CHAIR

   Scribe
          kuettel

Contents

     * [3]Topics
         1. [4]TTC support
     * [5]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 19 February 2014

   <jfkthame> hi guys - sorry, I'm not able to call in today, but
   will lurk on irc to see any notes

   Vlad: will postpone Brotli / IETF RFC discussions, as Chris
   Lilley is not able to join
   ... big topic of discussion today: TTC support (or not)
   ... no new information from Adobe just yet
   ... Ken Lundy(sp?) historically was eager to see support for
   TTC which contained both CFF and TTF

   <raph> Ken Lunde

   Vlad: TTC collections can be beneficial for CJK
   ... 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

TTC support

   Raph: what would changes to the format look like? TTC has
   notion of table directories
   ... multiple table directories, with each directory having same
   structure (offset + length)
   ... some tables would be unique to the font, some shared across
   fonts within the TTC
   ... one use case: complex scripts (multiple styles)
   ... glyph table is unique, but OpenType (esp. GSUB) is shared
   ... as the shaping logic would be the same for bold or italic
   ... one script where there could be a significant improvement
   is Devanagari

   <Vlad> scribenick: kuettel

   Raph: however fonts that he looked at did not follow this
   pattern -- would need to be reworked
   ... gain in other cases is minor (few percent at best after
   rework)
   ... thus, not an extremely compelling case for TTC support in
   WOFF 2.0
   ... esp. given that the web page might only use some of the
   styles, yet have to pay the transfer cost of all
   ... for CJK -- aware of Han unification using TTC
   ... e.g. font that covers many CJK languages
   ... in this case the glyph table is shared (union of the Han
   unification), however other tables would be different (e.g.
   cmap)
   ... next, device fonts
   ... could make a strong case, as device needs to support the
   worlds languages
   ... combined font could be smaller
   ... that said, in a web context this makes a lot less sense
   ... esp. as a frequent pattern on the web is to serve the most
   optimized font for a given user agent
   ... where here, serving a specific Han language would be a
   bigger win over serving the combined Han TTC
   ... thus, target would be a web page with multiple Han
   languages, which just isn't that likely
   ... rather the common case would be a single Han language
   ... OpenType variant mechanism, is likely a more modern way of
   accomplishing the same thing
   ... OpenType is backwards compatible, unlike TTC
   ... another use case that was proposed on the mailing list
   ... (missed a bit). web has a great fallback mechanism that
   allows fonts to be mixed
   ... other web font features, such as unicode-range enable even
   greater optimizations over TTC
   ... thus, seeing few benefits of TTC support

   Vlad: another use case that came up recently, Japanese family
   of fonts + Latin.
   ... could combine all four fonts in to one TTC, which would be
   handy for device fonts or distribution
   ... but not sure how compelling that would be for the web

   Raph: more likely that for web fonts the font would be split
   up, would combine with font-family + unicode-range as needed
   ... huge file sizes put more pressure to subset, which makes
   the use case for TTC less compelling
   ... how much complexity would TTC add?
   ... 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
   ... would likely involve significant changes for the client.
   security would likely be another big factor (more work to
   harden, more risks, etc)
   ... the open type sanitizer is pretty rigorous today, would
   need to be reworked
   ... not impossible, but definitely not trivial
   ... would really need to go back and rethink the security
   implications
   ... without a significant improvement, hard to justify

   Vlad: for completeness, where would table overlap occur?

   Raph: no, rather multiple references to byte ranges (didn't
   capture everything)
   ... if only extracting a single font (from the TTC), likely
   easier, but would need to skip
   ... extracting multiple fonts is more involved, which is what
   one would want to do in the web case (otherwise, why return a
   collection)
   ... implementation would likely have the option of returning
   multiple fonts or a container

   Vlad: to summarize, Raph made a detailed and compelling case
   for not supporting TTCs on the web

   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

   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
   ... esp. given that some have been eager to see further TTC
   support (e.g. Adobe with CFF)

   Raph: would love to hear from Adobe
   ... we should gather their input prior to making a decision

   Vlad: Sergey, thoughts?

   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
   ... thus, feel that it is not that important
   ... would be more work to support (esp. given existing MTX code
   base)
   ... thus eager to hear from more foundries, to understand their
   needs for TTC

   Vlad: anyone else? Chris?
   ... (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
   ... balance might change for epubs, where many fonts could be
   bundled with the book

   Sergey: would that be the perfect case for subsetting?

   Vlad: yes, but book would likely pull in most of the font
   anyways
   ... that was the only likely compelling use case that I found
   ... also share the desire to see TTC supported, due to the
   OpenType spec -- want to carry it over
   ... from the implementation point of view, single stream
   compression could make it easier (than otherwise)
   ... think that WOFF 2.0 is in a better position to support TTC
   over WOFF 1.0

   Raph: not just a matter of compression, rather there are also
   the table transforms that would complicate things

   Vlad: agree

   Raph: definitely not trivial
   ... e.g. length of data after Brotli compression and transforms
   ... I guess you could do it
   ... would likely involve multiple passes over the data
   ... definitely a multi-step process, would require detecting
   regions in Brotli streams.... enough work to trigger more
   security reviews, etc

   Vlad: additional processing steps not in conflict with single
   stream compression
   ... agree that it would be more work, not a departure from what
   we have today from a compression point of view
   ... summarizing again
   ... have not heard a really compelling use case just yet
   ... mildly compelling use case for epubs (or weak case)
   ... 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)
   ... another weak case, TTC being part of the OpenType spec,
   thus a nice to have, esp. in case we missed something looking
   forward

   David: another potential use case that has been brought up over
   the past few months is color fonts

   Vlad: not seeing this as any different from others

   Sergey: what tables would be shared? eager to learn more

   Vlad: with color fonts, would have shared glyph table
   ... from a compression point of view, not seeing a big
   difference

   Raph: sounds right

   Vlad: to recap, great discussion today
   ... continue active discussions on the mailing list

   <jfkthame> and great note-taking ... thanks David!

   thank you! :)

   Vlad: thank you for starting the editor's draft of the
   specification Raph
   ... once draft is somewhat complete, will take a pass over it

   Raph: hoping to share something soon

   Thank you everyone!

Summary of Action Items

   [End of minutes]