Minutes, 26 feb 2014 webfonts telcon

Hello,

http://www.w3.org/2014/02/26-webfonts-minutes.html

and below as text for bots


                 WebFonts Working Group Teleconference

26 Feb 2014

   See also: [2]IRC log

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

Attendees

   Present
          Vlad, [Google], ChrisL, AWK, +1.650.214.aaaa, kenji,
          david, +1.650.214.aabb, Google

   Regrets
   Chair
          vlad

   Scribe
          ChrisL

Contents

     * [3]Topics
         1. [4]TTC
         2. [5]brotli and ietf
     * [6]Summary of Action Items
     __________________________________________________________

   <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
   [7]https://pastebin.mozilla.org/4404194

      [7] 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)

Summary of Action Items

   [End of minutes]

-- 
Best regards,
 Chris                          mailto:chris@w3.org

Received on Wednesday, 26 February 2014 22:02:42 UTC