W3C home > Mailing lists > Public > www-font@w3.org > April to June 2010

Minutes, 2 June 2010 WebFonts WG call

From: Chris Lilley <chris@w3.org>
Date: Wed, 2 Jun 2010 16:56:53 +0200
Message-ID: <1764846941.20100602165653@w3.org>
To: www-font@w3.org
Hello www-font,

 Minutes in technicolor

and monochrome

                 WebFonts Working Group Teleconference

02 Jun 2010

   See also: [2]IRC log

      [2] http://www.w3.org/2010/06/02-webfonts-irc


          Vlad, Tal, Erik, Howcome, Sergei, Dave, Chris, Jonathan, Tab,
          Christopher, John




     * [3]Topics
         1. [4]Administrivia
         2. [5]Discuss and finalize metadata extension mechanism
         3. [6]WOFF editorial proposals
     * [7]Summary of Action Items

   <trackbot> Date: 02 June 2010

   <scribe> ScribeNick: ChrisL


   <abattis> hello, sorry i didnt get online sooner, net cafe giving me
   hassle, will try to dial the conf # now

   <erik> it's hard for me to hear anything!

   There is a form to teach Zakim what your phone number is. Please use
   it.zakim, who is noisy?

   There is a form to teach Zakim what your phone number is. Please use


      [8] http://www.w3.org/1998/12/bridge/info/name.php3

Discuss and finalize metadata extension mechanism

   <cslye> I am now on the phone.

   tal: It was in response to things Liam said - localization and
   providing flexibility in extension block
   ... itsmore verbose than what Sylvain proposed but does more


      [9] http://lists.w3.org/Archives/Public/www-font/2010AprJun/0262.html

   chris: looks good to group by language like that

   vlad: aim is to preserve localisation for top level and for vendor
   extensions, seems to do this well
   ... and it can be compressed anyway
   ... so verbosioty not a problem

   <davecrossland> i like tals proposal

   tal: discussed with sylvain, he wndered if localisation was

   <cslye> I think localization is a good option to have.

   <davecrossland> i believe localisation is important

   chris: only overhead with a single language is one set of short
   wrapper elements, seems good to me

   sergei: how often are font vendors adding text in multiple languages

   john: have tried but software did not cooperate. should be possible,
   want to do this
   ... not concewrned about lots and lots of alternatives, more the
   local language plus a couple of others

   tal: not dealing with the font names at all, but the license data
   and copyright. did research and found fonts with localised entries
   for this sort of data
   ... so want to localise all the things we can

   <davecrossland> yeah the UnB Pro fonts Gustavo Ferrier did, and the
   Paratype PT Sans, both had localised libre license texts

   sergei: font often have japaese and english names, display depends
   on user locale

   vlad: localisation in xml is trivial feature, can be used for font
   vendors to publicise their work, will tend to see more use I predict

   <davecrossland> +1

   tal: other thing Liam mentioned was a block that is visible to users
   and one invisible for machine readable stuff
   ... did not address that here

   vlad: cannot prevent anyone from inserting xml that is not part of
   the spec. so arbitrary xml could be found. but UI unlikely to
   display it

   john: isn't that what the private block is for?

   vlad: need not even be xml
   ... vendors may want xml data .... arbitrary xml will not be
   visible. That will satisfy the proposal that liam suggested

   sergei: could disallow any unstandard xml. or provie a specific
   place for this, like a 'private' element
   ... specific place is a good thing

   vlad: agreed already that its not parsed unless user requests.
   ... so only parsed at user option. if there is arbitrary xml it will
   not prevent other items being visible

   john: should be well formed xml

   <davecrossland> didnt we already agree that poorly formed XML will
   be silently dropped?

   chris: xslt or dom will look for kknown elements to display, so by
   default the others will not be shown

   @dave yes we did

   howcome: please say well formed not valid

   vlad: main scope is easily implementable, easy to use extension

   howcome: I see lots of elements and attributes
   ... very verbose

   chris: lang inherits so it can be set higher

   howcome: prefer to see each group by language

   vlad: yes, language inherits. not sure what else needs to be said

   howcome: want to write for any language the text by just declaring
   the language once

   vlad: extra number of bytes is low

   sergei: better if the same value localised is near to each other

   vlad: please send proposals and examples to email list. easier than
   coding on the phone

   <scribe> ACTION: howcome to suggest a regrouping of localised
   extension syntax [recorded in

   <trackbot> Created ACTION-6 - Suggest a regrouping of localised
   extension syntax [on HÃ¥kon Wium Lie - due 2010-06-09].

   jfk: problem is you have to repeat the whole structure even if you
   only want to localise a few items

   howcome: could do both

   christopher: if its a choice to do one way or the other that is the
   most flexxible solution

   sergei: its easier to see nothing is missing if the strings are
   close together

   ??: any argument against allowing both?

   <cslye> That was me. :)

   john: a tool might pick one or the other. no benefit to have both.
   agree with sergeit its better to do it tals way

   vlad: tals suggestion does not precluse using inheritance to set
   language just once
   ... easier to see concrete examples in email

   <davecrossland> so <extensions lang="tag"> will be inherited by
   everything if its all in one language?

   <davecrossland> and <group lang="tag"> will be inherited for all
   tags in that group?

   <jfkthame> @dave: yes

   erik: would need to indicate the group equivalence explicitly with
   the duplicate structures method

   <davecrossland> and <item lang="tag"> will be inherited for all
   children too?

   <davecrossland> if so, i dont quite understand howcome's point

   <davecrossland> "want to write for any language the text by just
   declaring the language once" seems possible with tals suggestion

   chris: yes the grouped structure proosal would need keys to indicate
   linguistic alternates

   erik: easier to get that from the structure

   vlad: extension mechanism as proposed seems to cover what we need.
   ... suggest we accept tal's proposal

WOFF editorial proposals


     [11] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Jun/0000.html

   jfk: not clear what to do with those, needs to be more fleshed out

   vlad: its in response to action from last call
   ... syntax and semsntics from appendixx to section 6 was agreed
   ... second is to group info on woff creation tools all together
   ... rather than have it spread through the spec
   ... even if its duplicated, better to have a summary with all info
   in one place
   ... some paras in section 4 are relevant only to creation step.

   christopher: I agree, different audiences, some will read top to
   bottom and some will look for only the relevant section

   chris: easier to do this by linking

   john: how does this fir with the conformance specs

   <davecrossland> i finally joined the call

   <erik> noise

   <davecrossland> ta

   <davecrossland> shitty callshop in weymouth :(

   vlad: not saying we duplicate everything, but easier to present
   things in a section for creation tools, or renderers, or whatever
   ... my opinion, not as chair

   jfk: are we at the point where the best thing is to do an updated

   (general agreement)

   <scribe> ACTION: jonathan to make an updated woff spec grouping
   conformance requirements [recorded in

   <trackbot> Created ACTION-7 - Make an updated woff spec grouping
   conformance requirements [on Jonathan Kew - due 2010-06-09].

   vlad: consider creating a "Recommendations" section, what tools
   should do, dsig, checksums - useful but its outside woff scope. its
   in the original font
   ... so put it in a non-normative recommendations section
   ... again my opinion, not as chair

   john: would like something like that, could be in this document or a
   separate one. nicely stated for the average font maker and tool
   maker. what we can expect to be done to a font when it is WOFFed

   vlad: could be an appendix, not a chapter

   <davecrossland> i support such a recommendations section of
   "metadata best practices for fonts to be wrapped in WOFF"

   chris: best practices is a good idea

   <davecrossland> yeah, not just metadata is even better

   <erik> paul is trying to keep ben quiet

   <erik> oops, wrong chat :)

   vlad: last para of sections 4 and 5 are useful but outside scope of
   woff spec. collect them and put in an informative appendix. not
   specific to metadata

   <davecrossland> +1

   <erik> family issues. I need to go.

   <scribe> ACTION: jonathan to create non-normative best practices
   appendix [recorded in

   <trackbot> Created ACTION-8 - Create non-normative best practices
   appendix [on Jonathan Kew - due 2010-06-09].

   <cslye> I am 1.510.816.aagg


   <davecrossland> id like to say thanks to tal for inclugin he update
   URL in the XML exmaple

   <tiro_j> 668.aahh is me

   jfk: for next week, could we change topics to access controls to
   give more time for these edits?

   vlad: yes, sure

   Topic; Summer schedule

   vlad: please send in your vacation info so we can schedule
   ... also, maybe a summertime f2f, need to plan now

   <davecrossland> TUGCON in SF at end of June

   vlad: maybe colocate with typecon

   <cslye> TypeCon starts Aug 17

   <davecrossland> TypeCon is in LA in August

   <davecrossland> yeah

   <davecrossland> i could make that

   adjourned really this time

   <Vlad> bye

Summary of Action Items

   [NEW] ACTION: howcome to suggest a regrouping of localised extension
   syntax [recorded in
   [NEW] ACTION: jonathan to create non-normative best practices
   appendix [recorded in
   [NEW] ACTION: jonathan to make an updated woff spec grouping
   conformance requirements [recorded in

   [End of minutes]

 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Wednesday, 2 June 2010 14:56:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:34 UTC