- 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