Minutes, TPAC F2F WG meeting

On Thursday, November 1, 2012, 3:54:43 PM, Vladimir wrote:

LV> Chris and Tab - could you please retrieve and
LV> sent out to the WG the IRC notes from today's morning session?

http://www.w3.org/2012/11/01-webfonts-minutes.html    

and below as text


                        WebFonts TPAC f2f, Lyon

01 Nov 2012

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-webfonts-wg/2012Oct/0006.html

   See also: [3]IRC log

      [3] http://www.w3.org/2012/11/01-webfonts-irc

Attendees

   Present
          Vlad, Jonathan, Sylvain, Tab, aaaa, Taichi, Chris

   Regrets
          Raph, JDaggett

   Chair
          Vlad

   Scribe
          TabAtkins

Contents

     * [4]Topics
         1. [5]MIME types
     * [6]Summary of Action Items
     __________________________________________________________

   <TabAtkins_> ScribeNick: TabAtkins

   <TabAtkins_> chrisl: The evaluation report will be joint-edited
   by Chris Lilley and Tab Atkins

   <TabAtkins_> Vlad: Given that we have at least an initial
   breakdown of benefits per feature, plus we can get this extra
   data from Raph I assume.

   <TabAtkins_> ChrisL: Presumably ask other members to run the
   WOFF2 compressor over their own font collections and report
   back data.

   <TabAtkins_> ChrisL: I don't just want a number, but also a
   breakdown of features, like unicode-range, use of opentype
   features, toolchain used to produce,e tc.

   <TabAtkins_> jfkthame: Not sure if toolchain is necessarily
   something we can easily quantify, but getting a lot of data
   seems important.

   <TabAtkins_> ChrisL: Would it be possible to get SIL to run
   this over a lot of their fonts?

   <TabAtkins_> jfkthame: Probably.

   <TabAtkins_> ChrisL: Okay. That would be useful, as the fonts
   are certainly different in their use of OpenType tables.

   <TabAtkins_> ChrisL: And MS has a lot of fonts.

   <TabAtkins_> sylvain: We do.

   <TabAtkins_> ChrisL: So it would be good if someone could
   delegate someone to run the processor over them.

   <TabAtkins_> ChrisL: Is there still someone from the typography
   group?

   <TabAtkins_> sylvain: Yeah, we can ask them.

   <TabAtkins_> [round of introductions]

   <TabAtkins_> ChrisL: Does NTT have a reasonable range of fonts
   that you'd be willing to run things over?

   <TabAtkins_> taichi: My font and standardization work is
   somewhat independent from my work in NTT.

   <TabAtkins_> taichi: I'm working on a project called GlyphWiki,
   which 20k glyphs collected now.

   <TabAtkins_> [7]http://en.glyphwiki.org/wiki/GlyphWiki:MainPage

      [7] http://en.glyphwiki.org/wiki/GlyphWiki:MainPage

   <TabAtkins_> [discussion of glyphwiki]

   <ChrisL> "GlyphWiki" is a shareable kanji (hanzi, hanja) glyph
   database system on the Internet for a solution of using
   unencoded kanji characters in digitizing text resources in
   kanji. "

   <TabAtkins_> taichi: I presented some of the infrastructure of
   glyphwiki at atypi last year.

   <TabAtkins_> Vlad: In preliminary discussions, LZMA was flagged
   as a potential issue. Anything going on there?

   <TabAtkins_> TabAtkins_: I recall Raph talking about that.
   Implementing LZMA properly requires reading a lot of source
   code, and possibly some papers in Russian.

   <TabAtkins_> TabAtkins_: Dunno what his current thinking is,
   but I know that discussion of re-speccing definitely came up
   before.

   <TabAtkins_> jfkthame: Does anyone know about the patent
   situation around LZMA?

   <TabAtkins_> TabAtkins_: I know we're apparently not very
   concerned about it. ^_^

   <TabAtkins_> [discussion of European patent law]

   <TabAtkins_> sylvain: Looks like the code was released to the
   public domain in 2008.

   <TabAtkins_> ChrisL: Being public domain isn't my huge concern
   - it's that the source code appears to be the spec.

   <TabAtkins_> ChrisL: There are a lot of forum posts where
   people discuss weird things in the source code that need to be
   a specific thing, and they're not sure why.

   <TabAtkins_> ChrisL: Which is fine, until you need to port it
   to another architecture and find it was relying on interesting
   platform behavior.

   <TabAtkins_> jfkthame: As well, beyond being public domain,
   there can still be patents in the area.

   <TabAtkins_> ChrisL: And why is LZMA specifically being used
   here? is it just "better than gzip", or does it have unique
   qualities that make it worthwhile?

   <TabAtkins_> taichi: As an entropy encoder, it's a fairly
   general compression technique, which is very good.

   <TabAtkins_> taichi: One of the most common parts of recent
   good compression technique is extracting common parts.

   <TabAtkins_> taichi: Hangul, for example, is particularly good
   for this kind of part-extraction compression, because of its
   unique structure.

   <TabAtkins_> ChrisL: My point is that it seems that, if LZMA
   turns out to be unusable, it's not the end of the road for us -
   we can switch to another entropy coder.

   <TabAtkins_> sylvain: I wonder how much of a loss there would
   be by just reusing gzip as the actual encoder?

   <TabAtkins_> TabAtkins_: I know that Raph has investigated
   that. I don't know the numbers, though.

   <TabAtkins_> ChrisL: Given that the preprocessor step is
   effectively removing redundancy, I would imagine that gzip
   doesn't have as much to work on.

   <TabAtkins_> Vlad: Not necessarily. The preprocessor removes
   redundancy, yes, but in ways that are probably invisible to an
   entropy coder.

   <TabAtkins_> Vlad: For example, I may have a bounding box in
   one table, and a min/max X/Y extents in another table. These
   are equivalent pieces of data.

   <TabAtkins_> Vlad: But they won't compress together if both
   left in.

   <TabAtkins_> ChrisL: If LZMA is generally better than gzip, I
   wonder if http-bis folk have looked into it as a better way to
   pursue general compression.

   <TabAtkins_> Vlad: jdaggett brought that up earlier, when we
   first brought up discussion of compression in webfonts.

   <TabAtkins_> Vlad: But yes, lzma can pick up redundancy in your
   bitstream which would be very different from what your
   preprocessor would extract.

   <TabAtkins_> ChrisL: Speaking of that, I suppose that's
   something else the Evaluation Report should look at - are there
   incremental improvements in compression we can make that would
   greatly increase the computational load? If so, mobile might
   not be happy about that.

   <TabAtkins_> TabAtkins_: I know that Raph has identified
   several specific places where he can tweak the algorithm for
   exactly that kind of incremental gain. He's run numbers, and
   they weren't impressive enough for him to bundle them into his
   default proposal, but the WG can discuss and decide what might
   be worth adding in.

   <TabAtkins_> Vlad: Speaking of computational load, it's really
   the decompress we care about.

   <TabAtkins_> Vlad: With the original MTX compression, the
   difference in compress/decompress load is 10:1.

   <TabAtkins_> Vlad: What, if anything, can we discuss about the
   future plans for the WOFF2 spec?

   <TabAtkins_> Vlad: We have a file format proposal from Raph.

   <TabAtkins_> Vlad: I dont' think we have more to talk about
   beyond that, and dont' know how much more to talk about before
   we get the Evaluation Report to give us confidence we're going
   the right way.

   <TabAtkins_> ChrisL: to some extent, the details of the file
   format are idnependent of the compression choices, so it's
   reasonabl eto talk about it before we have compression data.

   <TabAtkins_> ChrisL: I don't recall seeing anything
   particularly bad in the file format part, but I haven't read it
   overly recently or with my standardization hat on.

   <TabAtkins_> jfkthame: What we have now is more or less a rough
   draft, not yet ready for speccing.

   <TabAtkins_> TabAtkins_: I'm willing to do an editorial pass
   over what we ahve and get it prepped into the right
   form/language for a real spec. That kind of work is fun and
   brainless.

   <TabAtkins_> TabAtkins_: Since Raph isn't familiar with that
   kind of structure we like.

   <TabAtkins_> Vlad: Okay, so of key importance is to confirm
   that some folks can give us help with the LZMA spec.

   <TabAtkins_> Vlad: sylvain, I know you have compression experts
   and a good security team, so it would be good to have
   confirmation that this is something we can use.

   <TabAtkins_> ChrisL: Yeah, because as it stands, this'll be
   mandatory in WOFF2.

   <TabAtkins_> ChrisL: If it's legal, that makes it an Essential
   Requirement, which turns the legal knobs in a particular way.

   <TabAtkins_> Vlad: From past experience, folks like Moz are
   more willing to use open-source code...

   <TabAtkins_> jfkthame: Yeah.

   <TabAtkins_> jfkthame: One thing that nags at me is that if
   LZMA isn't very well specced, how confident are we in its
   security, then, and how confident are we in being able to fix
   security issues that arise when we expose it to data coming
   over the wire?

   <TabAtkins_> jfkthame: WOFF1 is reasoanbly simple enough that
   if a security problem arises, we're confident that someone can
   go in and fix it. LZMA sounds like it might not be in that
   realm.

   <TabAtkins_> ChrisL: Right. That's a reason we used gzip in
   WOFF1 - it was quicker, and it had wide security review already
   and was in wide use.

   <TabAtkins_> ACTION Tab to see what sort of security review has
   been done on LZMA, and to see if any "real" spec work has been
   done internally on it.

   <trackbot> Created ACTION-111 - See what sort of security
   review has been done on LZMA, and to see if any "real" spec
   work has been done internally on it. [on Tab Atkins Jr. - due
   2012-11-08].

   <TabAtkins_> ACTION sylvain to see what sort of security review
   has been done on LZMA, and to see if any "real" spec work has
   been done internally on it.

   <trackbot> Created ACTION-112 - See what sort of security
   review has been done on LZMA, and to see if any "real" spec
   work has been done internally on it. [on Sylvain Galineau - due
   2012-11-08].

   <TabAtkins_> ChrisL: Do any other WG members whose companies
   are large enough to be worth suing want to do a similar review?

   <TabAtkins_> ChrisL: Would Monotype be happy using this and
   deploying it?

   <TabAtkins_> Vlad: Yeah. In that case we'd be using it as the
   controlled input. Generating, not consuming.

   <TabAtkins_> jfkthame: I don't know if the security people in
   Moz have looked at LZMA. I'll see if anyone's done fuzzing on
   it, etc.

   <TabAtkins_> TabAtkins_: I feel like we've done some fuzzing as
   well.

   <TabAtkins_> ACTION Chris to ask http-bis folks if they're
   looked at LZMA, and if so, if they've rejected it as something
   they don't want to touch, or what.

   <trackbot> Created ACTION-113 - Ask http-bis folks if they're
   looked at LZMA, and if so, if they've rejected it as something
   they don't want to touch, or what. [on Chris Lilley - due
   2012-11-08].

   <TabAtkins_> <br dur=15min>

   <TabAtkins_> ChrisL: Talking of chartering, people should
   remember to rejoin the group.

MIME types

   <TabAtkins_> Vlad: When are media types used?

   <TabAtkins_> ChrisL: Sent by the server.

   <TabAtkins_> ChrisL: One place you'd expect to see them is
   @font-face, but not really. Instead, we have a custom registry
   of strings for font-types.

   <TabAtkins_> TabAtkins_: Though we could add the real media
   types later.

   <TabAtkins_> Vlad: Yes, I'm just looking for places where the
   media types would be used but not currently.

   <TabAtkins_> ChrisL: Another one is that the UA can send a list
   of media types it accepts (conneg) and the server can then
   decide which to send.

   <TabAtkins_> Vlad: During the coffee break, we agreed to go
   ahead with the existing plan (register application/font-woff),
   and separately try to register top-level 'font/'.

   <TabAtkins_> ChrisL: At the same time we're doing this,
   opentype/truetype are gearing up to register font types as
   well.

   <TabAtkins_> ChrisL: Regardless, we definitely need to register
   the WOFF1 media type.

   <TabAtkins_> Vlad: Is it as simple as wrapping up the text and
   sending it to ietf?

   <TabAtkins_> ChrisL: Yes, it goes to a different group to
   establish it's been reviewed, etc. plh does that liaisoning.

   <TabAtkins_> Vlad: Since I have to do the same thing in ISO, I
   was just wondering who to contact.

   <TabAtkins_> ACTION chris to finish registration of WOFF1 mime
   type.

   <trackbot> Created ACTION-114 - Finish registration of WOFF1
   mime type. [on Chris Lilley - due 2012-11-08].

   <TabAtkins_> ChrisL: I noticed that you wrote "WOFF1". I was
   under the impression that WOFF2 would use the same string.

   <TabAtkins_> Vlad: I thought the same.

   <TabAtkins_> TabAtkins_, jfkthame: Disagree.

   <TabAtkins_> jfkthame: You lose the ability to do conneg, to
   distinguish in font-face, etc. Defeats the point of having a
   mime type at all, really.

   <TabAtkins_> ChrisL: Okay. That's fine. In the future we'll
   register a "woff2", then. No need to be specific in the
   mimetype right now as "woff1".

   <TabAtkins_> ChrisL: Related to that, as WOFF1 is a PR, and the
   deadline is Nov 8, make sure you've responded favorably.

   <TabAtkins_> ChrisL: MS hasn't responded yet.

   <TabAtkins_> ChrisL: It makes my job presenting this to W3M
   much easier if we don't have to second-guess whether
   non-responses are because they hate it or just forgot it.

   <TabAtkins_> Vlad: Speaking of top-level types, about a year
   ago there was a discussion in ietf about font-type
   registration.

   <TabAtkins_> Vlad: Some people asked why it's not yet
   registered, others complained that prior attempts failed and so
   discouraging new attempts...

   <TabAtkins_> Vlad: I responded that I heard a rumor that it
   takes a lifetime to get it in.

   <TabAtkins_> Vlad: and someone responded with "who said that?
   Just submit it!"

   <TabAtkins_> Vlad: So Chris, do you have an insider info on
   what kind of effort this requires?

   <TabAtkins_> ChrisL: It varies. There is relatively recent
   evidence of adding new types (model).

   <TabAtkins_> ChrisL: A while back there was significant
   pushback from people not wanting to extend any new top-level
   types, because they were laser-focused on their use in email
   clients.

   <TabAtkins_> ChrisL: But now there are other opinions, and they
   recognize that they are useful outside of email.

   <TabAtkins_> ChrisL: but I still estimate it'll take the better
   part of a year.

   <TabAtkins_> Vlad: There's been a new attempt to make a
   proposal.

   <TabAtkins_> Vlad: From the process pov, how much more
   complicated will it be compared to regular subtype
   registratino?

   <TabAtkins_> ChrisL: Fairly more complex. You have to make a
   draft which becomes an RFC, etc.

   <TabAtkins_> Vlad: Would it be outrageous plagiarism to reuse
   some of the text from previous attempts?

   <TabAtkins_> ChrisL: Not at all.

   <TabAtkins_> Vlad: Okay, because Dave Singer tried this last
   time.

   <TabAtkins_> ACTION Chris and Vlad to put together the draft
   for top-level font registration, possibly based on text from
   previous attempts.

   <trackbot> Created ACTION-115 - And Vlad to put together the
   draft for top-level font registration, possibly based on text
   from previous attempts. [on Chris Lilley - due 2012-11-08].

   <TabAtkins_> Vlad: Looking through the mailing list, several
   people have offered to help with this process, such as Martin
   Durst, Thom Phinney, etc.

Summary of Action Items

   [End of minutes]
     ________________

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Received on Thursday, 1 November 2012 15:15:52 UTC