IRC log of svg on 2008-10-23

Timestamps are in UTC.

07:17:55 [RRSAgent]
RRSAgent has joined #svg
07:17:55 [RRSAgent]
logging to http://www.w3.org/2008/10/23-svg-irc
07:17:57 [trackbot]
RRSAgent, make logs public
07:17:57 [Zakim]
Zakim has joined #svg
07:17:59 [trackbot]
Zakim, this will be GA_SVGWG
07:17:59 [Zakim]
ok, trackbot; I see GA_SVGWG()2:30AM scheduled to start 48 minutes ago
07:18:00 [trackbot]
Meeting: SVG Working Group Teleconference
07:18:00 [trackbot]
Date: 23 October 2008
07:18:29 [heycam]
heycam has left #svg
07:25:08 [jun]
jun has joined #svg
07:35:29 [ed]
Topic: LC comments
07:36:10 [ed]
http://lists.w3.org/Archives/Member/member-svg-editors/2008Oct/0322.html
07:36:24 [ori]
ori has joined #svg
07:37:22 [ed]
Chair: Erik
07:37:28 [anthony]
scribe: anthony
07:37:58 [ed]
http://www.w3.org/Graphics/SVG/WG/track/products/11
07:38:20 [anthony]
Topic: ISSUE-2085
07:38:29 [anthony]
ISSUE-2085?
07:38:29 [trackbot]
ISSUE-2085 -- Spec unclear where focus should initially go when a document is loaded -- OPEN
07:38:29 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2085
07:38:39 [anthony]
ED: Issue raised by Ikivo
07:38:49 [anthony]
...NH has an action to propose new wording
07:39:18 [anthony]
DS: Perhaps we should make a proposal to him
07:40:07 [fat_tony]
fat_tony has joined #svg
07:40:23 [fat_tony]
scribeNick: fat_tony
07:40:24 [ed]
http://dev.w3.org/SVG/profiles/1.2T/publish/interact.html#navigationbehaviour
07:40:47 [fat_tony]
ED: The thing he is complaining about is the steps for how focus navigation
07:41:05 [ed]
s/navigation/navigation behaves/
07:41:44 [fat_tony]
ED: You can interpreter this in a few ways
07:41:52 [fat_tony]
... that's not necessarily a bad thing
07:42:02 [fat_tony]
DS: Do we talk about document focus vs UA focus
07:42:25 [fat_tony]
ACTION: Doug to Propose wording for document focus vs user agent focus that addresses ISSUE-2085
07:42:25 [trackbot]
Created ACTION-2324 - Propose wording for document focus vs user agent focus that addresses ISSUE-2085 [on Doug Schepers - due 2008-10-30].
07:42:50 [fat_tony]
Topic: ISSUE-2094
07:42:56 [fat_tony]
ISSUE-2094?
07:42:56 [trackbot]
ISSUE-2094 -- accessing rules for traitAccess -- OPEN
07:42:56 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2094
07:43:02 [fat_tony]
ED: We have two open actions there
07:43:04 [fat_tony]
... one is on me
07:43:09 [fat_tony]
... the other on A Emmons
07:43:27 [fat_tony]
... and A Emmons had the action to respond to the commenter
07:43:34 [fat_tony]
DS: Who was this for?
07:43:37 [fat_tony]
ED: Julien R
07:44:19 [fat_tony]
... I'll just check the public mailing list
07:44:26 [fat_tony]
AG: Did you make the change?
07:44:43 [fat_tony]
ED: No he's just asking for an answer
07:44:51 [fat_tony]
... it's not clear that he wants anything changed
07:45:14 [fat_tony]
DS: What's the justification for the ones we chose not to change?
07:45:25 [fat_tony]
ED: I really hoped A Emmons would take care of this
07:45:34 [fat_tony]
... he seemed to have a good grasp on it
07:45:55 [fat_tony]
AG: Can we ping him at lunchtime?
07:46:01 [fat_tony]
DS: We can always send him an email
07:48:27 [fat_tony]
Topic: ISSUE-2107
07:48:32 [fat_tony]
ISSUE-2107?
07:48:32 [trackbot]
ISSUE-2107 -- i18n comment 6: Direction and bidi-override attributes -- RAISED
07:48:32 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2107
07:48:51 [fat_tony]
ED: Is this done?
07:48:58 [fat_tony]
DS: We really need Chris here for this
07:49:10 [fat_tony]
... and the next one 2110
07:49:21 [fat_tony]
... these are both internationalisation issues
07:51:08 [fat_tony]
present: Ori Idan, Fons Kuijk, Jun Fujisawa, Doug Schepers, Erik Dahlstrom, Anthony Grasso
07:51:36 [fat_tony]
OI: Bidi direction is important to the I18N
07:51:44 [fat_tony]
... I think there are issues with RtoL
07:51:59 [fat_tony]
DS: We do not cover vertical text in Tiny
07:52:07 [fat_tony]
... but we do in full
07:53:27 [shepazu]
s/RtoL/Right-to-Left and Tob-to-Bottom/
07:53:51 [fat_tony]
AG: The wording in the specification allows for support for Top-to-Bottom text
07:53:55 [fat_tony]
... but doesn't mandate it
07:54:24 [fat_tony]
DS: Tiny is just subset of features in full
07:54:34 [fat_tony]
s/Tiny/Tiny 1.1/
07:55:10 [fat_tony]
ED: We do have tests for Right-to-Left and Top-to-Bottom
07:55:14 [fat_tony]
... but they are simple tests
07:55:18 [fat_tony]
... we don't test all the tricky cases
07:56:04 [fat_tony]
... so with the issue here I do agree with it
07:56:13 [fat_tony]
... the last comment I believe is a miss understanding
07:56:19 [fat_tony]
OI: [Reads Issue]
07:56:32 [fat_tony]
ED: There is nothing preventing you from doing that
07:56:42 [fat_tony]
... [Explains feature]
07:56:58 [fat_tony]
OI: Is inherited like CSS?
07:57:00 [fat_tony]
ED: Yes it is
07:57:08 [fat_tony]
OI: If it is inherited like CSS that is ok
07:57:16 [fat_tony]
ED: We took the direction property from CSS
07:57:20 [fat_tony]
... so it should be the same
07:57:36 [fat_tony]
OI: The default is Left-to-Right
07:57:45 [fat_tony]
DS: Would it be worth noting that in the spec
07:58:49 [fat_tony]
OI: Could say that the property of RtL is inherited from the top block
07:58:56 [fat_tony]
... then it will be inherited to the terms inside it
07:58:58 [fat_tony]
... that's in CSS
07:59:03 [fat_tony]
... what is it in your terms
07:59:09 [fat_tony]
ED: TextContent
07:59:21 [fat_tony]
DS: I think this is just an authoring note
07:59:27 [ed]
s/TextContent/text content element is the term for it/
07:59:28 [fat_tony]
... if you put direction in the root of the document
07:59:36 [fat_tony]
... it will apply only to text elements
07:59:55 [fat_tony]
... it could confuse people because it's not like "text-direction"
07:59:58 [dbaron]
dbaron has joined #svg
08:00:12 [fat_tony]
ED: It does map to the CSS property
08:00:15 [dino]
dino has joined #svg
08:00:25 [fat_tony]
OI: You should note that it only applies to text blocks
08:00:55 [fat_tony]
... if I have a text block with direction RtL and a nested text block is also RtL
08:01:07 [fat_tony]
DS: And of course override-able
08:01:14 [fat_tony]
ED: That's one of his requests
08:01:17 [fat_tony]
... to have examples
08:01:29 [fat_tony]
... I think it would be useful to have the inheriting thing explained
08:02:14 [fat_tony]
OI: So people know that there is inheritance?
08:02:23 [fat_tony]
... may not be necessary
08:02:33 [fat_tony]
DS: More so for authors rather than implementers
08:02:46 [fat_tony]
... I think I'm going to put in a note
08:03:11 [fat_tony]
... because it's not really clear that direction applies to text
08:03:20 [fat_tony]
OI: The direction property only applies to text
08:03:35 [fat_tony]
... not to graphics
08:04:32 [fat_tony]
ED: Another comment he makes here in this issue
08:05:16 [fat_tony]
... that we say in the spec that authors are discouraged from using direction and unicode-bidi
08:05:41 [fat_tony]
DS: [Reads out issue]
08:06:04 [fat_tony]
... so what this sentence means for people using western languages don't mess with this
08:06:14 [fat_tony]
OI: Do you understand the issue if you place a dot after it
08:06:30 [fat_tony]
... the unicode algorithm doesn't know about the dot if it's LtR or RtL
08:06:55 [fat_tony]
... That's a problem with 'weak directionality'
08:07:03 [fat_tony]
... they don't have a directionality
08:17:44 [ed]
ed has joined #svg
08:26:50 [fat_tony]
ED: Just need to clean up the wording on this issue and make an example or two
08:27:01 [fat_tony]
OI: I can review the wording now if you want
08:27:18 [fat_tony]
ED: So in this issue there was not suggested text (wording)
08:27:32 [fat_tony]
... there's no concrete proposal on this issue
08:27:59 [fat_tony]
OI: I can review this issue, propose wording and make an example
08:28:08 [fat_tony]
ED: If you can make an example sure, that'd be great
08:28:55 [ed]
ed has joined #svg
08:29:47 [fat_tony]
... so he's example for the example of using RtL on the top and unicode-bidi embed
08:31:33 [fat_tony]
DS: Did we decide about the in most cases?
08:31:43 [fat_tony]
ED: Ori said he's happy to review any text proposal we have
08:31:52 [fat_tony]
... if you can propose some new wording that would be great
08:32:19 [fat_tony]
OI: I'm not on the mailing list but I will send you an email
08:32:26 [fat_tony]
... Here's a small HTML example
08:32:40 [fat_tony]
... [shows example]
08:39:30 [ori]
ori has joined #svg
08:39:32 [fat_tony]
ACTION: Doug to Propose wording and examples for ISSUE-2017
08:39:32 [trackbot]
Created ACTION-2325 - Propose wording and examples for ISSUE-2017 [on Doug Schepers - due 2008-10-30].
08:40:08 [fat_tony]
s/ISSUE-2017/ISSUE-2107/
08:40:30 [fat_tony]
Topic: ISSUE-2110
08:40:34 [fat_tony]
ISSUE-2110?
08:40:34 [trackbot]
ISSUE-2110 -- i18n comment 8: Text rendering order -- RAISED
08:40:34 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2110
08:41:04 [fat_tony]
OI: I think this is very similar
08:41:11 [fat_tony]
... oh wait, this is different
08:41:40 [fat_tony]
... that would be great if the direction of RtL that right glyph would be rendered first
08:41:44 [fat_tony]
... I think it would be nice
08:41:48 [fat_tony]
... but it is not a must
08:42:01 [fat_tony]
... that the right most glyph would be rendered first
08:42:20 [fat_tony]
... would be good from slow implementations so you can read the glyphs as they're being rendered
08:42:29 [fat_tony]
ED: I'm not sure that the sentence is saying that
08:42:36 [fat_tony]
OI: That's how I read it
08:42:51 [fat_tony]
... [reads sentence out]
08:43:05 [fat_tony]
DS: So when it says rendering, I don't think the rendering would be slow
08:43:15 [fat_tony]
... if they're overlapping then the order matters
08:43:32 [fat_tony]
OI: If they're not overlapping and the rendering order is not fast enough
08:43:37 [fat_tony]
... then you'll notice it
08:43:55 [fat_tony]
... do you think there'll be any slow implementation?
08:44:18 [fat_tony]
... do you think there'll be a slow application in a hand held device with a slow processor
08:44:39 [fat_tony]
... it only matters if this is a slow rendering device
08:44:51 [fat_tony]
DS: Honestly I'd be very surprised
08:45:03 [fat_tony]
... because the text is processed as a block
08:45:16 [fat_tony]
... and put in order for placing on the canvas
08:47:20 [fat_tony]
ED: I mean rendering part of text content block would be very strange
08:47:48 [fat_tony]
OI: If the user agent that does the rendering to a canvas is it possible
08:48:29 [fat_tony]
... there is actually know mean for the rendering order of blocks
08:48:47 [fat_tony]
DS: Individual characters in the block may over lap due to kerning
08:49:14 [ed]
http://lists.w3.org/Archives/Public/www-svg/2008Oct/0117.html
08:49:18 [fat_tony]
ED: Chris has suggested new wording there
08:49:28 [shepazu]
http://lists.w3.org/Archives/Public/www-svg/2008Oct/0179.html
08:49:34 [fat_tony]
DS: Here is my reply
08:52:01 [fat_tony]
... if the glyphs are reordered in the byte stream what happens?
08:52:07 [fat_tony]
OI: Why would that happen?
08:52:45 [fat_tony]
DS: Richard says it could; for example South East Asian characters
08:53:13 [fat_tony]
... we need Richard for this
08:53:19 [fat_tony]
ED: We may need some tests
08:54:05 [fat_tony]
OI: We need a Hebreu for this
08:54:09 [fat_tony]
... or Arabic
08:54:17 [fat_tony]
... and for South East Asian languages
08:54:38 [fat_tony]
... maybe Richard can supply us an example today
08:55:01 [fat_tony]
DS: There is nothing stopping us for making examples today
08:56:08 [fat_tony]
... but it needs to be done in two days
08:56:18 [fat_tony]
ED: How is this handled in HTML again?
08:56:24 [fat_tony]
... is this already addressed
08:56:29 [fat_tony]
OI: Yes, it works fine
08:56:38 [fat_tony]
... I'm not sure about the rendering order
08:56:48 [fat_tony]
... in HTML it doesn't matter
08:56:52 [fat_tony]
DS: Yes you can
08:56:59 [fat_tony]
... because of CSS
08:57:05 [fat_tony]
... they are adding Opacity in CSS
08:57:14 [fat_tony]
... so they will run into the same issues
08:57:27 [fat_tony]
... with letter spacing
08:57:36 [fat_tony]
... so HTML and CSS has the same problem
08:58:09 [fat_tony]
ED: For consistency we use the same algorithm
08:58:28 [fat_tony]
OI: For consistency can we say it's defined in HTML
08:58:36 [fat_tony]
DS: Probably not
09:02:03 [fat_tony]
OI: The issue is the running order just as Richard sent in ISSUE-2110
09:02:14 [fat_tony]
ED: I mentioned reasons for reordering
09:02:21 [fat_tony]
... so I agree to that one
09:02:27 [fat_tony]
... the one that Chris sent
09:03:26 [fat_tony]
OI: The reason we need to discuss rendering order is for when we have overlap
09:03:29 [fat_tony]
... I agree with Chris
09:04:19 [fat_tony]
ED: So essentially this is rendering the first character you'd read
09:04:29 [dbaron]
dbaron has joined #svg
09:04:36 [fat_tony]
OI: I agree with Chris
09:04:41 [fat_tony]
... not to sure about what Doug is saying
09:04:52 [fat_tony]
... we need a clarification from Richard
09:05:12 [fat_tony]
ED: Does this address the whole issue
09:06:00 [fat_tony]
ACTION: Erik to Add the proposed wording for ISSUE-2110
09:06:01 [trackbot]
Created ACTION-2326 - Add the proposed wording for ISSUE-2110 [on Erik Dahlström - due 2008-10-30].
09:41:40 [fat_tony]
Topic: ISSUE-2130
09:41:44 [fat_tony]
ISSUE-2130?
09:41:44 [trackbot]
ISSUE-2130 -- Basic Data Types section needs clarifications -- OPEN
09:41:44 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2130
09:42:43 [Zakim]
Zakim has left #svg
09:44:24 [ChrisL]
ChrisL has joined #svg
09:44:41 [ChrisL]
RIM states that they use SVG Tiny 1.2
09:44:43 [ChrisL]
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=211600037
09:45:10 [ChrisL]
RIM engineers are looking at supporting 3-D graphics, probably through adopting the Java specification for OpenGL ES (JSR 239). The company is also broadly adopting 2-D scalable vector graphics such as SVG Tiny 1.2. It first used SVG in version 4.6 for the Blackberry Bold phone.
09:45:10 [ChrisL]
"We are looking at doing fairly complete support for SVG in all the places an image needs support in a device," said Liam Quinn, who heads browser development at RIM.
09:46:34 [ChrisL]
issue-2130?
09:46:34 [trackbot]
ISSUE-2130 -- Basic Data Types section needs clarifications -- OPEN
09:46:34 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2130
09:47:31 [fat_tony]
CL: We had a related issue which was about xml:id and the XML Schema
09:47:45 [fat_tony]
... and we resolved to fix the schema
09:47:54 [fat_tony]
... which fixes the first part of the issue
09:48:00 [fat_tony]
... for the second one
09:48:07 [fat_tony]
... we are asked to supply an example
09:48:23 [fat_tony]
... this is related to XML namespacing
09:48:51 [fat_tony]
DS: He may simply not understand what QNames are
09:49:27 [fat_tony]
... I guess we could add a quick example
09:50:39 [ChrisL]
XML namespaces has two methods, one for elements (unprefixed ones use the default namespace) and one for attributes (where unprefixed ones do not).
09:51:10 [ChrisL]
Following the tag finding on qnames in attribute values, and common practice, qnames in attribute values also do not use default namespaces
09:51:11 [ChrisL]
http://www.w3.org/2001/tag/doc/qnameids.html
09:53:22 [ChrisL]
This wording needs to be clarified
09:53:25 [ChrisL]
"If the <QName> has a prefix, then the prefix is expanded into an IRI reference using the namespace declarations in effect where the name occurs, and the default namespace is not used for unprefixed names. "
09:53:42 [ChrisL]
ACTION: Chris to clarify QName expansion to tuples
09:53:43 [trackbot]
Created ACTION-2327 - Clarify QName expansion to tuples [on Chris Lilley - due 2008-10-30].
09:54:46 [ChrisL]
"If the <QName> has a prefix, then the prefix is expanded into a tuple of an IRI reference and a local name, using the namespace declarations in effect where the name occurs. Note that, as with unprefixed attributes, the default namespace is not used for unprefixed names. "
09:54:58 [fat_tony]
CL: Proposed sentence in IRC
09:55:56 [ChrisL]
The relevant part of the tag finding, that we follow, is "Specifications that use QNames to represent {URI, local-name} pairs MUST describe the algorithm that is used to map between them."
09:57:04 [jun]
jun has joined #svg
09:57:49 [fat_tony]
CL: So an example would be if you're animating an attribute name is stroke
09:58:06 [fat_tony]
... you'd be animating "stroke" and not "svg:stroke"
09:59:32 [fat_tony]
... [reads out rest of issue]
09:59:52 [fat_tony]
... so his third one is because in the schema we haven't defined anything as frame target
10:00:07 [fat_tony]
... do we want to patch up the schema to define something called "frame name"
10:00:21 [fat_tony]
DS: Do we define what a frame target is?
10:00:36 [fat_tony]
... we can add a definition
10:00:44 [fat_tony]
CL: Where is frame target used
10:01:07 [fat_tony]
ED: Linking, I think the <a> element
10:01:13 [ed]
http://dev.w3.org/SVG/profiles/1.2T/publish/linking.html#AElementTargetAttribute
10:01:47 [ChrisL]
http://www.w3.org/TR/SVGMobile12/linking.html#AElement
10:01:48 [fat_tony]
CL: [Reads part out in spec]
10:01:55 [ChrisL]
"<frame-target>"
10:01:55 [ChrisL]
Specifies the name of the frame, pane, or other relevant presentation context for display of the linked content. If this already exists, it is re-used, replacing the existing content. if it does not exist, it is created (the same as _blank, except that it now has a name). Note that frame-target must be an XML Name [XML11].
10:02:14 [ChrisL]
we could link XML Name to the types chapter
10:02:31 [ChrisL]
basically frame-target is of type XML Name. So there is no error in the spec
10:02:47 [fat_tony]
CL: The next one handler, string
10:02:58 [fat_tony]
... XML doesn't call string "strings"
10:03:09 [fat_tony]
ED: What does XML Events say?
10:03:18 [ChrisL]
for the next two, XML-NMTOKEN is a subset of string
10:03:22 [fat_tony]
... is it just an XML token?
10:04:05 [fat_tony]
CL: And we have a link to the types which say NMToken
10:04:49 [ChrisL]
NMTOKEN is correct, and links to http://www.w3.org/TR/SVGMobile12/types.html#DataTypeXML-NMTOKEN
10:05:00 [ChrisL]
'string' is too loose and should be corrected
10:05:16 [heycam]
heycam has joined #svg
10:05:50 [fat_tony]
CL: Which chapter is handler in?
10:05:55 [fat_tony]
ED: Scripting
10:06:54 [ChrisL]
we can edit the spec where it says string
10:07:12 [fat_tony]
ED: Do we just have XML-NMToken as a basic type?
10:07:14 [fat_tony]
CL: Yes
10:07:20 [fat_tony]
ED: We do us XML name
10:07:23 [fat_tony]
... on listener
10:07:26 [fat_tony]
... but not on handler
10:09:32 [fat_tony]
CL: I've corrected handler
10:09:38 [fat_tony]
... I don't see it on listener
10:10:02 [fat_tony]
ED: It's using XMLName, it should be using NMToken in that case
10:10:10 [fat_tony]
CL: So this is in the scripting chapter?
10:10:13 [fat_tony]
ED: Yes
10:12:55 [ed]
heycam: I have an up-to-date tools directory
10:13:35 [ed]
note that someone might have changed the example, we did discuss it
10:20:53 [fat_tony]
Topic: ISSUE-2139
10:20:56 [fat_tony]
ISSUE-2139?
10:20:57 [trackbot]
ISSUE-2139 -- Add note regarding eRR attribute and prefetch element -- RAISED
10:20:57 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2139
10:21:12 [fat_tony]
ED: A Emmons did send proposed text
10:21:41 [fat_tony]
... and Cyril responded to say if the text is added then he'll be fine with that
10:22:20 [fat_tony]
ACTION: Anthony to Add the text from the wording proposed by A Emmons to the specification regarding ISSUE2139
10:22:20 [trackbot]
Created ACTION-2328 - Add the text from the wording proposed by A Emmons to the specification regarding ISSUE2139 [on Anthony Grasso - due 2008-10-30].
10:23:23 [fat_tony]
Topic: ISSUE-2145
10:23:27 [fat_tony]
ISSUE-2145?
10:23:27 [trackbot]
ISSUE-2145 -- Clarify media timeline and document timeline -- RAISED
10:23:27 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2145
10:24:23 [fat_tony]
DS: He hasn't offered anything helpful regarding the issue
10:29:04 [fat_tony]
ED: Do we want to postpone this
10:29:13 [fat_tony]
DS: We will look at this one in a bit
10:54:48 [dino]
dino has joined #svg
11:12:24 [fat_tony]
fat_tony has joined #svg
11:14:34 [fat_tony_]
fat_tony_ has joined #svg
11:23:56 [heycam]
heycam has joined #svg
12:01:23 [fantasai]
fantasai has joined #svg
12:16:02 [ed]
png?
12:16:14 [fat_tony_]
fat_tony_ has joined #svg
12:16:37 [fat_tony]
scribe: Anthony
12:16:43 [fat_tony]
scribeNick: fat_tony
12:17:00 [fat_tony]
Topic: SVG IG Japan
12:18:33 [jun]
jun has joined #svg
12:18:56 [fat_tony]
JF: Just started the activity in Japan
12:18:58 [fat_tony]
... for SVG IG
12:18:59 [dino]
dino has joined #svg
12:19:05 [fat_tony]
.. created a mailing list
12:19:17 [fat_tony]
... had first f2f meeting on Friday
12:19:26 [fat_tony]
... the second is on 12th Nov
12:19:32 [fat_tony]
... and we invited Doug to talk to the group
12:21:02 [fat_tony]
... the group includes Takagi-san from KDDI and Takahashi-san fromm Indigo and Mori-san from Osaka City Uni
12:21:13 [fat_tony]
CL: Where is the mailing list?
12:21:26 [fat_tony]
JF: Yes it is in W3C
12:21:47 [fat_tony]
... there are several people from JIPDEC
12:21:48 [ChrisL]
http://lists.w3.org/Archives/Public/public-svg-ig-jp/
12:22:25 [fat_tony]
JF: JIPDEC is a Japanese standards body
12:22:37 [ChrisL]
JIPDEC - Japan Information Processing Development Corporation
12:22:38 [fat_tony]
... that is managing the standarisation of SVG in Japan
12:22:49 [ChrisL]
http://www.jipdec.or.jp/eng/
12:23:09 [fat_tony]
DS: JIPDEC sells copies of the JIS standard
12:23:13 [shepazu]
s/11th Nov/12th Nov/
12:23:53 [fat_tony]
JF: Keio W3C will have JPC meeting on the 6th November
12:24:20 [fat_tony]
... so we can expect more traffic on SVG IG JP
12:25:11 [fat_tony]
DS: If Kaz can translate the description on the public mailing list page in English to Japanese
12:25:37 [fat_tony]
ACTION: Doug to Coordinate on Kaz on JP IG list description
12:25:37 [trackbot]
Created ACTION-2329 - Coordinate on Kaz on JP IG list description [on Doug Schepers - due 2008-10-30].
12:25:44 [ChrisL]
list description is in english currently
12:25:45 [ChrisL]
http://lists.w3.org/Archives/Public/public-svg-ig-jp/
12:26:03 [fat_tony]
JF: Currently our main activity in SVG IG JP is to support the SVG JIS standardisation
12:26:23 [fat_tony]
... and coordinate with other people. Another activity is to promote the usage of SVG for
12:26:27 [fat_tony]
... web mapping in Japan
12:26:38 [fat_tony]
... we will working on a new module called SVG Map module
12:26:50 [fat_tony]
CL: This is related to the existing JIS standard?
12:27:12 [fat_tony]
JF: No this is a different module and and email to promote it has been sent out
12:27:17 [fat_tony]
... we will work on a complete module
12:27:24 [fat_tony]
... so we can make a complete proposal to SVG WG
12:27:36 [fat_tony]
... we also considering on gathering SVG map data in Japan
12:27:48 [fat_tony]
... and publish the map data on the SVG community site
12:27:56 [fat_tony]
... possibly on planet SVG
12:28:09 [fat_tony]
CL: Are there minutes of the F2F meeting?
12:28:26 [fat_tony]
JF: Yes minutes were scribed but they are in Japanese
12:28:34 [fat_tony]
... by Kaz
12:28:55 [fat_tony]
DS: I want to thank you for all your effort you have put into this
12:28:56 [ChrisL]
thats good. hope to see them on the mailing list
12:29:16 [fat_tony]
DS: The fact that you are the chair of the SVG IG is really good. I appreciate that
12:29:25 [fat_tony]
Topic: SVG JIS Standard
12:29:45 [fat_tony]
JF: On the same date we had the first SVG JIS committee meeting
12:30:21 [fat_tony]
... Hagino-san of W3C Keio is the manager
12:30:36 [fat_tony]
... and the goal is to create a JIS Standard for the SVG based format for mapping
12:30:51 [fat_tony]
... and that includes a complete translated specification of SVG Tiny 1.2
12:31:01 [fat_tony]
DS: When will they begin translation?
12:31:08 [fat_tony]
JF: As soon as PR is available
12:31:20 [fat_tony]
... in the first committee meeting we discussed the possible category of the JIS standard
12:31:29 [fat_tony]
... and also the structure of the standard has been discussed
12:31:39 [fat_tony]
... there are two possible categories, one is mapping
12:31:47 [fat_tony]
... and networking category
12:31:52 [fat_tony]
DS: Can it be in both?
12:31:58 [fat_tony]
JF: That is an important point
12:32:11 [fat_tony]
... as for the structure four possibilities was suggested
12:32:17 [fat_tony]
... the first is the one just for SVG
12:32:24 [fat_tony]
... and one for SVG map module
12:32:49 [fat_tony]
... the second is to have just one standard just for SVG map module and that will be different from the SVG Tiny 1.2 spec
12:33:11 [fat_tony]
... and the third possibility is to have a single JIS standard to have branch of map module
12:33:31 [fat_tony]
... and the last possibility is to have a single combined specification which has SVG map and SVG Tiny all in one
12:34:06 [fat_tony]
CL: The advantage of each
12:34:28 [fat_tony]
s/The advantage/There are advantages/
12:35:03 [fat_tony]
JF: There are some people who think that it is not useful out side of the use case of mapping
12:35:46 [fat_tony]
... we had the conclusion that there will be a map module and a network module
12:36:55 [fat_tony]
... in the last committee meeting they decided to have a separate standard for SVG Tiny and a separate for SVG Map module
12:37:20 [ChrisL]
Its my preference also, to have one standard which is SVGT1.2 in Japanese, and a second one which is SVG Mapping and could be submitted to W3C so we can have it as an W#C spec in English as well
12:37:23 [fat_tony]
... so we hope that we can bring the Map module to the working group
12:37:34 [fat_tony]
DS: I know Andreas will be interested in this module
12:37:44 [fat_tony]
... the other thing that KDDI is not a member of W3C
12:37:52 [ChrisL]
I would like to see the Japanese version on the W3C site as an official translation
12:37:54 [fat_tony]
... so they can't make a submission
12:38:11 [fat_tony]
JF: It will be a proposal from the IG
12:38:39 [fat_tony]
CL: We need to get patent statements from all of the authors
12:38:48 [fat_tony]
... agreeing to W3C patent policy
12:39:00 [fat_tony]
JF: People in SVG IG JP agree to W3C patent policy
12:39:57 [ChrisL]
http://www.svgopen.org/2004/papers/indigo/
12:40:13 [ChrisL]
Development of location based search engine service using goSVG
12:40:24 [ChrisL]
Yuzo Matsuzawa
12:40:24 [ChrisL]
Indigo Corporation
12:40:30 [fat_tony]
JF: The goal is to come up with SVG Map profile which might be based on SVG 2.0 Core
12:41:01 [fat_tony]
... or some other useful module like Transforms
12:42:32 [fat_tony]
... SVG JIS project will be two year
12:42:46 [fat_tony]
... it started this April and ended in Mar 2009
12:42:55 [fat_tony]
... that is the goal in the first year to do the translation
12:43:07 [fat_tony]
... of the whole specification
12:43:18 [fat_tony]
... we have to finish the translation around the end of next March
12:43:33 [fat_tony]
... in the second year the committee will take a formal process to publish the standard
12:43:54 [fat_tony]
... in order to achieve this the timing for SVG Tiny to achieve PR and Rec is important
12:44:04 [fat_tony]
... and will start the translation as soon as the PR spec is published
12:44:15 [fat_tony]
... so we hope this will happen in early Nov
12:44:31 [fat_tony]
DS: So you will start translating when it's in PR and not Rec correct?
12:44:35 [fat_tony]
JF: Yes
12:45:25 [ChrisL2]
ChrisL2 has joined #svg
12:45:25 [fat_tony]
DS: So as part of the translation I'm sure they will find typos
12:45:51 [fat_tony]
... I'd be surprised if reading the specification they will not be confused, will they be able to propose a question
12:45:58 [fat_tony]
... if the english is not clear
12:46:07 [fat_tony]
JF: The problem is the translation is out sourced
12:46:17 [fat_tony]
... but perhaps the SVG IG can review the translation
12:46:45 [fat_tony]
CL: If someone perhaps miss understand somethings
12:46:52 [fat_tony]
... then it would be nice for it to come back to us
12:47:03 [fat_tony]
DS: They have an investment on getting it correct
12:47:25 [fat_tony]
... if something is confusing to the translator they should know that they should communicate with the SVG WG
12:47:29 [ChrisL2]
its good in that case to ask the WG for clarification. Sometimes the English is not clear to a non native speaker. (Actually some of the spec is written by non-native speakers, too)
12:48:17 [fat_tony]
DS: Our plan is early next week we will do our call for transition
12:48:32 [fat_tony]
... it is possible as early as Wed
12:49:31 [fat_tony]
... we think we can go to PR on Nov 3rd as PR and we will to Rec on Dec 2nd
12:49:42 [fat_tony]
CL: When we go to Rec we will make a press release
12:50:02 [fat_tony]
... it would be nice to have Canon on the press release
12:51:05 [fat_tony]
DS: Just so you know RIM has announced that it is developing SVG Tiny 1.2
12:54:14 [ed]
scribe: Erik
12:54:18 [ed]
scribeNick: ed
12:54:34 [ed]
Topic: svg transformations module
12:56:14 [dino]
i just sent in comments on svg transformations. Did they make it to the list?
12:56:26 [dino]
shepazu, are you moderator?
12:56:47 [shepazu]
dino, just modded it
12:56:55 [shepazu]
dino: can you join us?
12:57:01 [dino]
shepazu, thankyou!
12:57:11 [dino]
yes, i'll come up if you promise to be nice
12:57:32 [ed]
DS: dino sent another message (I'm moderating this now, it got caught)
12:57:42 [ed]
http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0224.html
12:59:15 [ed]
AG: sent the proposal to the public wg list
12:59:26 [ed]
...tried to keep it as close as possible to the css proposal
12:59:59 [ed]
...the one in css uses z-order
13:00:14 [ed]
...I decided to leave that out for now and use the painters algorithm
13:00:22 [ed]
...it's an extension of the svg 2d transforms
13:00:44 [ed]
...it's extended to 3x4 matrix to give you the extra rotation capabilities
13:00:50 [ed]
...we think that's all that's necessary
13:01:06 [ed]
...obviously extending this means we need to extend the DOM interfaces
13:01:17 [ed]
DS: does this have impacts on declarative animations?
13:01:26 [ed]
AG: yes, we need to consider that use-case
13:01:38 [ed]
...and we need to add a section there to say how that should be handle
13:02:31 [ed]
...if you have a circle on top of a rectangle and you rotate both as a group you'll still see the circle because it's on top of the rect
13:02:40 [ed]
...rotate in the 3d sense
13:03:14 [ed]
present: Al gilman, CL, DS, AG, JF, dino
13:04:03 [ed]
DJ: the way css transformations work is that anything that has a transforms gets a css stacking context
13:04:11 [ed]
...which means it goes into the z-index system
13:05:09 [ed]
...z-index doesn't mean position, it's just like an offscreen buffer and the order you draw those
13:05:40 [jdaggett]
jdaggett has joined #svg
13:05:44 [ed]
...you can have something something with a z value that puts something close to the viewer, but have a z-index that puts it below some other elements
13:06:10 [ed]
...one question is how the svg transformations are supposed to be rendered
13:07:21 [ed]
CL: it's hard to do a rotation of two elements that rotate in a circle in z
13:09:28 [ed]
if you have two elements in differnt 3d coordinate systems each group is rendered in two offscreens, so you can't have one elements sometimes in front of and sometimes behind
13:09:46 [ed]
DJ: most systems in 3d don't allow you to do grouping
13:09:59 [ed]
CL: opengl doesn't allow that, but PHIGS does
13:10:24 [ed]
...opengl is immidiatemode, PHIGS is more like svg, it has a structure and a DOM, it has nesting, transformations
13:11:14 [ed]
...in PHIGS has the same concept of grouping and transformations as svg, but everything is in a 3d coordinate system
13:11:29 [ChrisL2]
s/in a/in the same/
13:12:24 [ed]
ALG: are you talking about real 3d rendering in svg? is there any use in x3d?
13:13:02 [ed]
CL: 3d rendering in 2d
13:13:35 [ed]
DJ: you can position things but it's like drawing a postcard in 3d space
13:14:03 [ed]
CL: 2.5d is 3x3 matrices
13:14:23 [ed]
AG: the problem is that it's bad for authoring, it's difficult to write the transformations and hard to animate
13:14:43 [ed]
DS: are we proposing 2.5d or 3d transforms?
13:15:10 [ed]
AG: localized 3d transforms
13:15:37 [ed]
...it's still sort of 2.5d because you don't have a single 3d coordinate system, you have localized 3d coordinate systems
13:15:57 [ed]
CL: the 3d transforms are still affine transforms?
13:16:28 [ed]
DJ: the proposal canon sent has non-affine transformations available
13:16:40 [ed]
...3d affine transforms
13:17:02 [ed]
...they have true perspective, so they're not 2d affine transforms
13:17:20 [ed]
CL: normally geometry are seen as structure
13:17:56 [ed]
...in svg, and colors and such are seen as styling, so properties vs attributes
13:18:07 [ed]
DS: but if it's going to be in css it should be properties
13:18:18 [ed]
CL: but then the transforms in svg should also be properties?
13:19:04 [ed]
AG: the reason for having them as properties is to keep it as close to css as possible
13:19:31 [ed]
ED: people have been asking for transforms to be in css for some time (even for svg use-cases)
13:20:21 [ed]
DS: can you still have the animated "starwars" effect?
13:20:29 [ed]
AG/DJ: yes
13:22:21 [ed]
CL: how do we move this forward?
13:22:35 [ed]
AG: what's the priority of transforms in css?
13:22:49 [ed]
DJ: it's not part of css until the group is rechartered
13:23:04 [ed]
...mozilla just implemented css transforms, but only the 2d parts
13:23:21 [ed]
DS: are you willing to work with the SVGWG to move this forward?
13:23:53 [ed]
DJ: currently css transforms can apply to svg root elements only, like a postcard
13:24:15 [ed]
DS: we need to figure out how SVG and CSS should work together wrt to transforms
13:25:01 [ed]
DJ: there are no units in svg in transform values, might be a problem for example
13:25:44 [ed]
AG: i'm happy to work with the css wg to move this
13:26:41 [ed]
DJ: mostly the proposals are the same
13:26:56 [ed]
...we now do a full 4x4 matrix
13:27:02 [ed]
...things you need to be aware of
13:27:06 [ed]
...hit testing
13:27:27 [ed]
AG: and how do you get boundingboxes?
13:27:35 [ChrisL2]
non-invertible matices. singularities
13:27:38 [ed]
DJ: we have it on the phones
13:27:54 [ed]
...what happens is that sometimes, with overflow hidden in css, you have to flatten the whole tree
13:28:01 [ed]
...sometimes it looks like 3d but it's really not
13:28:14 [ed]
...[draws on whiteboard]
13:28:59 [fantasai]
There were two concerns that came up when we discussed transforms in Beijing
13:29:08 [fantasai]
one was syntax: making the syntax match more closely CSS conventions
13:29:16 [fantasai]
the other was the default value of the property
13:29:21 [fantasai]
which can't be the same as the identity transform
13:29:32 [fantasai]
because transformation needs to trigger some side effects in CSS
13:29:38 [fantasai]
such as turning the element into a block formatting context
13:29:40 [ed]
DJ: clipping in 3d is difficult
13:29:43 [fantasai]
so it contains all its floating children ,etc
13:29:52 [ed]
...you can't preserve 3d and have clipping
13:30:08 [ChrisL2]
yes. so the initial value needs to be 'no transform applied' so you dont get a css stacking context, right?
13:30:17 [ed]
...the transforms spec isn't very big, but it's probably full of things that needs further discussion
13:30:35 [ed]
...perspective-transform ...??
13:31:03 [ed]
...read our proposal and ask for clarifications where needed
13:31:19 [ed]
...reason we haven't got much feedback is probably because not many have tried implementing it so far
13:31:52 [ed]
...css has a lot of edge cases that affect the 3d transforms
13:32:40 [ed]
CL: the initial value for transform needs to be 'none' not identity, because it sets up a stacking context
13:33:17 [shepazu]
shepazu has joined #svg
13:34:02 [ed]
DJ: it's nice to put the perspective on a parent div or svg:g, and then use it for the child elements
13:34:13 [ed]
AG: understand the need to the property
13:34:36 [ed]
DJ: preserve3d is something svg would need too probably
13:36:05 [ed]
AG: it would be nice to have DJ for another F2F for more discussion on this
13:36:30 [ed]
...we could achieve faster progress that way
13:36:53 [ed]
DJ: i'll join the svg mailinglist
13:38:02 [ed]
JF: it's important to work with the CSSWG on this
13:38:08 [ed]
...we don't want two specs on this
13:39:48 [ed]
RESOLUTION: we won't form a joint taskforce, we'll work with DJ and the CSS WG to ensure that 3d transforms can be used in both CSS, HTML and SVG
13:41:13 [dino]
dino has joined #svg
13:43:12 [ed]
Topic: next F2F meeting(s)
13:45:03 [ed]
JF: canon has an experimental implementation of the 3d transforms module in svg, and we can confirm that we can easily describe 3d-based UI:s by using this
13:45:41 [ed]
...maybe at the next F2F we can have a demo ready
13:47:20 [ChrisL2]
Foundations of Open Media Software (FOMS)
13:47:20 [ed]
AG: we can host the next F2F in sydney, we want to do it after the FOMS conference (http://www.foms-workshop.org/foms2009/pmwiki.php/Main/CFP)
13:47:21 [ChrisL2]
Developer Workshop
13:47:21 [ChrisL2]
Thursday 15 - Friday 16 January 2009
13:47:21 [ChrisL2]
Hobart (Tasmania), Australia
13:47:29 [ChrisL2]
http://www.foms-workshop.org/foms2009/pmwiki.php/Main/CFP
13:48:19 [ed]
AG: so Jan 19
13:49:04 [ed]
ED: i would prefer to have it a bit later
13:51:30 [ed]
CL: there's is an AC meeting in march
13:51:50 [ed]
ED: early february would be better
13:52:38 [ed]
DS: i'll be speaking at a conference in february, *checking when*
13:55:11 [ed]
DS: let's schedule the f2f for february 16-20
14:08:08 [fantasai]
Minutes from CSSWG meeting in Beijing: http://lists.w3.org/Archives/Member/w3c-css-wg/2007JulSep/0184.html
14:38:13 [ed]
ed has joined #svg
14:45:53 [ChrisL2]
Scribe: Chris
14:45:54 [jun]
jun has joined #svg
14:46:03 [ChrisL2]
scribenick: ChrisL2
14:46:17 [ChrisL2]
Topic: More Last Call Comments
14:46:35 [ed]
http://www.w3.org/Graphics/SVG/WG/track/products/11
14:46:56 [ChrisL2]
ED: We now have only 9 issues
14:47:36 [ChrisL2]
http://www.w3.org/Graphics/SVG/WG/track/products/11
14:49:07 [ChrisL2]
ISSUE-2153
14:49:07 [ChrisL2]
RNG link
14:49:07 [ChrisL2]
Link to RelaxNG Schema
14:49:47 [ChrisL2]
ISSUE-2153?
14:49:48 [trackbot]
ISSUE-2153 -- Link to RelaxNG Schema -- RAISED
14:49:48 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2153
14:50:35 [ChrisL2]
this can be closed, Doug has updated the spec to point to the actual correct RNG that we are all editing
14:50:52 [ChrisL2]
also the make scrip updates this master -> publish
14:51:27 [ChrisL2]
ISSUE-2145?
14:51:28 [trackbot]
ISSUE-2145 -- Clarify media timeline and document timeline -- RAISED
14:51:28 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2145
14:51:36 [ChrisL2]
ED: Prefer to have AE on this one
14:51:48 [ChrisL2]
sync behaviours not currently impleented in Opera
14:51:54 [ChrisL2]
postpone to tomorrow?
14:52:03 [ChrisL2]
DS: Perfer to do not if poss
14:52:12 [ChrisL2]
ED: Some suggested text in the comment
14:53:02 [ChrisL2]
(we discuss 'locked')
14:54:28 [ChrisL2]
CL: On this part "The specification should say what happens when a video/audio element points to a file or a set of streams containing multiple audio tracks (english and french, or AAC and AC3) or multiple video tracks.
14:54:28 [ChrisL2]
"
14:55:01 [ChrisL2]
the answer is that it depends on whatever fragment syntax is defined for that media type registration. Depends also on what the media fragents WG comes up with
14:55:14 [ChrisL2]
there are other technologies that relate to this eg MPEG-21
14:55:28 [ChrisL2]
its outside our spec. But clearly something that needs to be solved
14:55:56 [ChrisL2]
DS: on his second-;ast para
14:56:14 [ChrisL2]
ED: .... agree about media timeline rather than 'play time'
14:57:14 [ChrisL2]
CL: What does smil say about sync delay and the allowed amount of sync?
14:57:47 [ChrisL2]
ED: eg a strwaming video, it can be difficult to seek back. Thats an example where the media timeline cannot be controlled
14:58:00 [ChrisL2]
... not always possible to restart from time zero
14:58:13 [ChrisL2]
s/strw/str/
14:58:43 [ChrisL2]
DS: Media eleents are time containers. So locking one does not lock its parent
15:01:08 [ChrisL2]
CL: But if they are locked, and you pause the child, what happens to the parent. Thats what he is asking
15:04:57 [ChrisL2]
http://www.w3.org/TR/SMIL2/smil-timing.html#Timing-ControllingRuntimeSync
15:05:40 [ChrisL2]
DS; Lockimng is only in terms of timeline sync, so if you pause an element its timeline is frozen; when its playing its synced to the parent
15:06:39 [ChrisL2]
CL: I read there "Note that the semantics of syncBehavior do not describe or require a particular approach to maintaining sync; the approach will be implementation dependent. Possible means of resolving a sync conflict may include:"
15:09:25 [ChrisL2]
also under "Paused elements and the active duration"
15:09:36 [ChrisL2]
"In addition, when an element is paused, the accumulated synchronization offset will increase to reflect the altered sync relationship. See also The accumulated synchronization offset."
15:10:44 [ChrisL2]
http://www.w3.org/TR/SMIL2/smil-timing.html#Timing-PausedElementsAndActiveDur
15:10:56 [ChrisL2]
DS: So in the end its defined by SMIL there
15:14:13 [ChrisL2]
ED: So I can change playtime. will do that now
15:15:44 [ChrisL2]
ACTION: Doug respond on ISSUE-2145 citing these minutes and pointing to SMIL 2.1 to talk about elapsed time offset when paused
15:15:44 [trackbot]
Created ACTION-2330 - Respond on ISSUE-2145 citing these minutes and pointing to SMIL 2.1 to talk about elapsed time offset when paused [on Doug Schepers - due 2008-10-30].
15:30:46 [ChrisL2]
ISSUE-2107?
15:30:47 [trackbot]
ISSUE-2107 -- i18n comment 6: Direction and bidi-override attributes -- OPEN
15:30:47 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2107
15:31:25 [ChrisL2]
CL: We are almost done on that one
15:31:47 [ChrisL2]
... we had a native Hebrew speaker earlier today check our examples and tests
15:31:58 [ChrisL2]
... its added to the spec, tested and impleented
15:32:10 [ChrisL2]
... doug has an action to add an example to the spec
15:34:59 [ChrisL2]
DS: Want a step by step example and also a template for people to follow
15:44:03 [ChrisL2]
Still open until the examples are added
15:44:34 [ChrisL2]
Still open until the examples are added
15:47:07 [ChrisL]
ChrisL has joined #svg
15:47:31 [ChrisL]
ISSUE-2147?
15:47:32 [trackbot]
ISSUE-2147 -- Section on externally referenced documents confusing -- OPEN
15:47:32 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2147
15:48:25 [ChrisL]
ED: Cameron wrote about this on public list. 2 script elements with same UIR, execute twice not once so section is incorrect
15:50:37 [ChrisL]
DS: That section is badly writted
15:50:48 [ChrisL]
ED: AE did a small rewrite of some of it
15:51:02 [ChrisL]
DS: I sent an email with a more extensive rewrite
15:51:14 [ChrisL]
ED: There are multiple copy pasted sentences there
15:52:56 [shepazu]
http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/att-0161/externalRefs.html
15:53:32 [ChrisL]
14.1.6 Externally referenced documents
15:53:46 [ChrisL]
http://www.w3.org/TR/SVGMobile12/linking.html#externalReferences
15:55:12 [ed]
DS: my proposed text is the last one in the externalRefs.html file above
15:56:35 [ChrisL]
ED: Scripting chapter covers the script case, Cameron fixed it
15:58:50 [ed]
http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0216.html
15:59:01 [ed]
actually not yet
15:59:26 [ed]
http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0201.html
16:03:14 [ChrisL]
the questions on external media and external scripts are in fact completely independent of the section on primary and resource documents, which are only about svg
16:14:18 [ChrisL]
Topic: Testing
16:14:33 [ChrisL]
media-audio-206-t is passed in GPAC
16:15:24 [jun]
jun has left #svg
16:15:32 [ChrisL]
but animate-elem-226-t fails
16:15:42 [ChrisL]
rrsagent, make logs public
16:15:49 [ChrisL]
rrsagent, make minutes
16:15:49 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/10/23-svg-minutes.html ChrisL
18:04:59 [jdaggett]
jdaggett has joined #svg