- From: Chris Lilley <chris@w3.org>
- Date: Wed, 2 Jun 2010 18:09:35 +0200
- To: public-webfonts-wg@w3.org
Hello public-webfonts-wg, Minutes in technicolor http://www.w3.org/2010/06/02-webfonts-minutes.html and monochrome WebFonts Working Group Teleconference 02 Jun 2010 See also: [2]IRC log [2] http://www.w3.org/2010/06/02-webfonts-irc Attendees Present Vlad, Tal, Erik, Howcome, Sergei, Dave, Chris, Jonathan, Tab, Christopher, John Regrets Chair Vlad Scribe ChrisL Contents * [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 Administrivia <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 it. [8]http://www.w3.org/1998/12/bridge/info/name.php3 [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 [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 necessary. <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 mechanism 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 [10]http://www.w3.org/2010/06/02-webfonts-minutes.html#action01] <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/0 000.html [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 already ... 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 draft? (general agreement) <scribe> ACTION: jonathan to make an updated woff spec grouping conformance requirements [recorded in [12]http://www.w3.org/2010/06/02-webfonts-minutes.html#action02] <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 [13]http://www.w3.org/2010/06/02-webfonts-minutes.html#action03] <trackbot> Created ACTION-8 - Create non-normative best practices appendix [on Jonathan Kew - due 2010-06-09]. <cslye> I am 1.510.816.aagg adjourned <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 [14]http://www.w3.org/2010/06/02-webfonts-minutes.html#action01] [NEW] ACTION: jonathan to create non-normative best practices appendix [recorded in [15]http://www.w3.org/2010/06/02-webfonts-minutes.html#action03] [NEW] ACTION: jonathan to make an updated woff spec grouping conformance requirements [recorded in [16]http://www.w3.org/2010/06/02-webfonts-minutes.html#action02] [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 16:09:41 UTC