07:17:55 RRSAgent has joined #svg 07:17:55 logging to http://www.w3.org/2008/10/23-svg-irc 07:17:57 RRSAgent, make logs public 07:17:57 Zakim has joined #svg 07:17:59 Zakim, this will be GA_SVGWG 07:17:59 ok, trackbot; I see GA_SVGWG()2:30AM scheduled to start 48 minutes ago 07:18:00 Meeting: SVG Working Group Teleconference 07:18:00 Date: 23 October 2008 07:18:29 heycam has left #svg 07:25:08 jun has joined #svg 07:35:29 Topic: LC comments 07:36:10 http://lists.w3.org/Archives/Member/member-svg-editors/2008Oct/0322.html 07:36:24 ori has joined #svg 07:37:22 Chair: Erik 07:37:28 scribe: anthony 07:37:58 http://www.w3.org/Graphics/SVG/WG/track/products/11 07:38:20 Topic: ISSUE-2085 07:38:29 ISSUE-2085? 07:38:29 ISSUE-2085 -- Spec unclear where focus should initially go when a document is loaded -- OPEN 07:38:29 http://www.w3.org/Graphics/SVG/WG/track/issues/2085 07:38:39 ED: Issue raised by Ikivo 07:38:49 ...NH has an action to propose new wording 07:39:18 DS: Perhaps we should make a proposal to him 07:40:07 fat_tony has joined #svg 07:40:23 scribeNick: fat_tony 07:40:24 http://dev.w3.org/SVG/profiles/1.2T/publish/interact.html#navigationbehaviour 07:40:47 ED: The thing he is complaining about is the steps for how focus navigation 07:41:05 s/navigation/navigation behaves/ 07:41:44 ED: You can interpreter this in a few ways 07:41:52 ... that's not necessarily a bad thing 07:42:02 DS: Do we talk about document focus vs UA focus 07:42:25 ACTION: Doug to Propose wording for document focus vs user agent focus that addresses ISSUE-2085 07:42:25 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 Topic: ISSUE-2094 07:42:56 ISSUE-2094? 07:42:56 ISSUE-2094 -- accessing rules for traitAccess -- OPEN 07:42:56 http://www.w3.org/Graphics/SVG/WG/track/issues/2094 07:43:02 ED: We have two open actions there 07:43:04 ... one is on me 07:43:09 ... the other on A Emmons 07:43:27 ... and A Emmons had the action to respond to the commenter 07:43:34 DS: Who was this for? 07:43:37 ED: Julien R 07:44:19 ... I'll just check the public mailing list 07:44:26 AG: Did you make the change? 07:44:43 ED: No he's just asking for an answer 07:44:51 ... it's not clear that he wants anything changed 07:45:14 DS: What's the justification for the ones we chose not to change? 07:45:25 ED: I really hoped A Emmons would take care of this 07:45:34 ... he seemed to have a good grasp on it 07:45:55 AG: Can we ping him at lunchtime? 07:46:01 DS: We can always send him an email 07:48:27 Topic: ISSUE-2107 07:48:32 ISSUE-2107? 07:48:32 ISSUE-2107 -- i18n comment 6: Direction and bidi-override attributes -- RAISED 07:48:32 http://www.w3.org/Graphics/SVG/WG/track/issues/2107 07:48:51 ED: Is this done? 07:48:58 DS: We really need Chris here for this 07:49:10 ... and the next one 2110 07:49:21 ... these are both internationalisation issues 07:51:08 present: Ori Idan, Fons Kuijk, Jun Fujisawa, Doug Schepers, Erik Dahlstrom, Anthony Grasso 07:51:36 OI: Bidi direction is important to the I18N 07:51:44 ... I think there are issues with RtoL 07:51:59 DS: We do not cover vertical text in Tiny 07:52:07 ... but we do in full 07:53:27 s/RtoL/Right-to-Left and Tob-to-Bottom/ 07:53:51 AG: The wording in the specification allows for support for Top-to-Bottom text 07:53:55 ... but doesn't mandate it 07:54:24 DS: Tiny is just subset of features in full 07:54:34 s/Tiny/Tiny 1.1/ 07:55:10 ED: We do have tests for Right-to-Left and Top-to-Bottom 07:55:14 ... but they are simple tests 07:55:18 ... we don't test all the tricky cases 07:56:04 ... so with the issue here I do agree with it 07:56:13 ... the last comment I believe is a miss understanding 07:56:19 OI: [Reads Issue] 07:56:32 ED: There is nothing preventing you from doing that 07:56:42 ... [Explains feature] 07:56:58 OI: Is inherited like CSS? 07:57:00 ED: Yes it is 07:57:08 OI: If it is inherited like CSS that is ok 07:57:16 ED: We took the direction property from CSS 07:57:20 ... so it should be the same 07:57:36 OI: The default is Left-to-Right 07:57:45 DS: Would it be worth noting that in the spec 07:58:49 OI: Could say that the property of RtL is inherited from the top block 07:58:56 ... then it will be inherited to the terms inside it 07:58:58 ... that's in CSS 07:59:03 ... what is it in your terms 07:59:09 ED: TextContent 07:59:21 DS: I think this is just an authoring note 07:59:27 s/TextContent/text content element is the term for it/ 07:59:28 ... if you put direction in the root of the document 07:59:36 ... it will apply only to text elements 07:59:55 ... it could confuse people because it's not like "text-direction" 07:59:58 dbaron has joined #svg 08:00:12 ED: It does map to the CSS property 08:00:15 dino has joined #svg 08:00:25 OI: You should note that it only applies to text blocks 08:00:55 ... if I have a text block with direction RtL and a nested text block is also RtL 08:01:07 DS: And of course override-able 08:01:14 ED: That's one of his requests 08:01:17 ... to have examples 08:01:29 ... I think it would be useful to have the inheriting thing explained 08:02:14 OI: So people know that there is inheritance? 08:02:23 ... may not be necessary 08:02:33 DS: More so for authors rather than implementers 08:02:46 ... I think I'm going to put in a note 08:03:11 ... because it's not really clear that direction applies to text 08:03:20 OI: The direction property only applies to text 08:03:35 ... not to graphics 08:04:32 ED: Another comment he makes here in this issue 08:05:16 ... that we say in the spec that authors are discouraged from using direction and unicode-bidi 08:05:41 DS: [Reads out issue] 08:06:04 ... so what this sentence means for people using western languages don't mess with this 08:06:14 OI: Do you understand the issue if you place a dot after it 08:06:30 ... the unicode algorithm doesn't know about the dot if it's LtR or RtL 08:06:55 ... That's a problem with 'weak directionality' 08:07:03 ... they don't have a directionality 08:17:44 ed has joined #svg 08:26:50 ED: Just need to clean up the wording on this issue and make an example or two 08:27:01 OI: I can review the wording now if you want 08:27:18 ED: So in this issue there was not suggested text (wording) 08:27:32 ... there's no concrete proposal on this issue 08:27:59 OI: I can review this issue, propose wording and make an example 08:28:08 ED: If you can make an example sure, that'd be great 08:28:55 ed has joined #svg 08:29:47 ... so he's example for the example of using RtL on the top and unicode-bidi embed 08:31:33 DS: Did we decide about the in most cases? 08:31:43 ED: Ori said he's happy to review any text proposal we have 08:31:52 ... if you can propose some new wording that would be great 08:32:19 OI: I'm not on the mailing list but I will send you an email 08:32:26 ... Here's a small HTML example 08:32:40 ... [shows example] 08:39:30 ori has joined #svg 08:39:32 ACTION: Doug to Propose wording and examples for ISSUE-2017 08:39:32 Created ACTION-2325 - Propose wording and examples for ISSUE-2017 [on Doug Schepers - due 2008-10-30]. 08:40:08 s/ISSUE-2017/ISSUE-2107/ 08:40:30 Topic: ISSUE-2110 08:40:34 ISSUE-2110? 08:40:34 ISSUE-2110 -- i18n comment 8: Text rendering order -- RAISED 08:40:34 http://www.w3.org/Graphics/SVG/WG/track/issues/2110 08:41:04 OI: I think this is very similar 08:41:11 ... oh wait, this is different 08:41:40 ... that would be great if the direction of RtL that right glyph would be rendered first 08:41:44 ... I think it would be nice 08:41:48 ... but it is not a must 08:42:01 ... that the right most glyph would be rendered first 08:42:20 ... would be good from slow implementations so you can read the glyphs as they're being rendered 08:42:29 ED: I'm not sure that the sentence is saying that 08:42:36 OI: That's how I read it 08:42:51 ... [reads sentence out] 08:43:05 DS: So when it says rendering, I don't think the rendering would be slow 08:43:15 ... if they're overlapping then the order matters 08:43:32 OI: If they're not overlapping and the rendering order is not fast enough 08:43:37 ... then you'll notice it 08:43:55 ... do you think there'll be any slow implementation? 08:44:18 ... do you think there'll be a slow application in a hand held device with a slow processor 08:44:39 ... it only matters if this is a slow rendering device 08:44:51 DS: Honestly I'd be very surprised 08:45:03 ... because the text is processed as a block 08:45:16 ... and put in order for placing on the canvas 08:47:20 ED: I mean rendering part of text content block would be very strange 08:47:48 OI: If the user agent that does the rendering to a canvas is it possible 08:48:29 ... there is actually know mean for the rendering order of blocks 08:48:47 DS: Individual characters in the block may over lap due to kerning 08:49:14 http://lists.w3.org/Archives/Public/www-svg/2008Oct/0117.html 08:49:18 ED: Chris has suggested new wording there 08:49:28 http://lists.w3.org/Archives/Public/www-svg/2008Oct/0179.html 08:49:34 DS: Here is my reply 08:52:01 ... if the glyphs are reordered in the byte stream what happens? 08:52:07 OI: Why would that happen? 08:52:45 DS: Richard says it could; for example South East Asian characters 08:53:13 ... we need Richard for this 08:53:19 ED: We may need some tests 08:54:05 OI: We need a Hebreu for this 08:54:09 ... or Arabic 08:54:17 ... and for South East Asian languages 08:54:38 ... maybe Richard can supply us an example today 08:55:01 DS: There is nothing stopping us for making examples today 08:56:08 ... but it needs to be done in two days 08:56:18 ED: How is this handled in HTML again? 08:56:24 ... is this already addressed 08:56:29 OI: Yes, it works fine 08:56:38 ... I'm not sure about the rendering order 08:56:48 ... in HTML it doesn't matter 08:56:52 DS: Yes you can 08:56:59 ... because of CSS 08:57:05 ... they are adding Opacity in CSS 08:57:14 ... so they will run into the same issues 08:57:27 ... with letter spacing 08:57:36 ... so HTML and CSS has the same problem 08:58:09 ED: For consistency we use the same algorithm 08:58:28 OI: For consistency can we say it's defined in HTML 08:58:36 DS: Probably not 09:02:03 OI: The issue is the running order just as Richard sent in ISSUE-2110 09:02:14 ED: I mentioned reasons for reordering 09:02:21 ... so I agree to that one 09:02:27 ... the one that Chris sent 09:03:26 OI: The reason we need to discuss rendering order is for when we have overlap 09:03:29 ... I agree with Chris 09:04:19 ED: So essentially this is rendering the first character you'd read 09:04:29 dbaron has joined #svg 09:04:36 OI: I agree with Chris 09:04:41 ... not to sure about what Doug is saying 09:04:52 ... we need a clarification from Richard 09:05:12 ED: Does this address the whole issue 09:06:00 ACTION: Erik to Add the proposed wording for ISSUE-2110 09:06:01 Created ACTION-2326 - Add the proposed wording for ISSUE-2110 [on Erik Dahlström - due 2008-10-30]. 09:41:40 Topic: ISSUE-2130 09:41:44 ISSUE-2130? 09:41:44 ISSUE-2130 -- Basic Data Types section needs clarifications -- OPEN 09:41:44 http://www.w3.org/Graphics/SVG/WG/track/issues/2130 09:42:43 Zakim has left #svg 09:44:24 ChrisL has joined #svg 09:44:41 RIM states that they use SVG Tiny 1.2 09:44:43 http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=211600037 09:45:10 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 "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 issue-2130? 09:46:34 ISSUE-2130 -- Basic Data Types section needs clarifications -- OPEN 09:46:34 http://www.w3.org/Graphics/SVG/WG/track/issues/2130 09:47:31 CL: We had a related issue which was about xml:id and the XML Schema 09:47:45 ... and we resolved to fix the schema 09:47:54 ... which fixes the first part of the issue 09:48:00 ... for the second one 09:48:07 ... we are asked to supply an example 09:48:23 ... this is related to XML namespacing 09:48:51 DS: He may simply not understand what QNames are 09:49:27 ... I guess we could add a quick example 09:50:39 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 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 http://www.w3.org/2001/tag/doc/qnameids.html 09:53:22 This wording needs to be clarified 09:53:25 "If the 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 ACTION: Chris to clarify QName expansion to tuples 09:53:43 Created ACTION-2327 - Clarify QName expansion to tuples [on Chris Lilley - due 2008-10-30]. 09:54:46 "If the 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 CL: Proposed sentence in IRC 09:55:56 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 has joined #svg 09:57:49 CL: So an example would be if you're animating an attribute name is stroke 09:58:06 ... you'd be animating "stroke" and not "svg:stroke" 09:59:32 ... [reads out rest of issue] 09:59:52 ... so his third one is because in the schema we haven't defined anything as frame target 10:00:07 ... do we want to patch up the schema to define something called "frame name" 10:00:21 DS: Do we define what a frame target is? 10:00:36 ... we can add a definition 10:00:44 CL: Where is frame target used 10:01:07 ED: Linking, I think the element 10:01:13 http://dev.w3.org/SVG/profiles/1.2T/publish/linking.html#AElementTargetAttribute 10:01:47 http://www.w3.org/TR/SVGMobile12/linking.html#AElement 10:01:48 CL: [Reads part out in spec] 10:01:55 "" 10:01:55 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 we could link XML Name to the types chapter 10:02:31 basically frame-target is of type XML Name. So there is no error in the spec 10:02:47 CL: The next one handler, string 10:02:58 ... XML doesn't call string "strings" 10:03:09 ED: What does XML Events say? 10:03:18 for the next two, XML-NMTOKEN is a subset of string 10:03:22 ... is it just an XML token? 10:04:05 CL: And we have a link to the types which say NMToken 10:04:49 NMTOKEN is correct, and links to http://www.w3.org/TR/SVGMobile12/types.html#DataTypeXML-NMTOKEN 10:05:00 'string' is too loose and should be corrected 10:05:16 heycam has joined #svg 10:05:50 CL: Which chapter is handler in? 10:05:55 ED: Scripting 10:06:54 we can edit the spec where it says string 10:07:12 ED: Do we just have XML-NMToken as a basic type? 10:07:14 CL: Yes 10:07:20 ED: We do us XML name 10:07:23 ... on listener 10:07:26 ... but not on handler 10:09:32 CL: I've corrected handler 10:09:38 ... I don't see it on listener 10:10:02 ED: It's using XMLName, it should be using NMToken in that case 10:10:10 CL: So this is in the scripting chapter? 10:10:13 ED: Yes 10:12:55 heycam: I have an up-to-date tools directory 10:13:35 note that someone might have changed the example, we did discuss it 10:20:53 Topic: ISSUE-2139 10:20:56 ISSUE-2139? 10:20:57 ISSUE-2139 -- Add note regarding eRR attribute and prefetch element -- RAISED 10:20:57 http://www.w3.org/Graphics/SVG/WG/track/issues/2139 10:21:12 ED: A Emmons did send proposed text 10:21:41 ... and Cyril responded to say if the text is added then he'll be fine with that 10:22:20 ACTION: Anthony to Add the text from the wording proposed by A Emmons to the specification regarding ISSUE2139 10:22:20 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 Topic: ISSUE-2145 10:23:27 ISSUE-2145? 10:23:27 ISSUE-2145 -- Clarify media timeline and document timeline -- RAISED 10:23:27 http://www.w3.org/Graphics/SVG/WG/track/issues/2145 10:24:23 DS: He hasn't offered anything helpful regarding the issue 10:29:04 ED: Do we want to postpone this 10:29:13 DS: We will look at this one in a bit 10:54:48 dino has joined #svg 11:12:24 fat_tony has joined #svg 11:14:34 fat_tony_ has joined #svg 11:23:56 heycam has joined #svg 12:01:23 fantasai has joined #svg 12:16:02 png? 12:16:14 fat_tony_ has joined #svg 12:16:37 scribe: Anthony 12:16:43 scribeNick: fat_tony 12:17:00 Topic: SVG IG Japan 12:18:33 jun has joined #svg 12:18:56 JF: Just started the activity in Japan 12:18:58 ... for SVG IG 12:18:59 dino has joined #svg 12:19:05 .. created a mailing list 12:19:17 ... had first f2f meeting on Friday 12:19:26 ... the second is on 12th Nov 12:19:32 ... and we invited Doug to talk to the group 12:21:02 ... the group includes Takagi-san from KDDI and Takahashi-san fromm Indigo and Mori-san from Osaka City Uni 12:21:13 CL: Where is the mailing list? 12:21:26 JF: Yes it is in W3C 12:21:47 ... there are several people from JIPDEC 12:21:48 http://lists.w3.org/Archives/Public/public-svg-ig-jp/ 12:22:25 JF: JIPDEC is a Japanese standards body 12:22:37 JIPDEC - Japan Information Processing Development Corporation 12:22:38 ... that is managing the standarisation of SVG in Japan 12:22:49 http://www.jipdec.or.jp/eng/ 12:23:09 DS: JIPDEC sells copies of the JIS standard 12:23:13 s/11th Nov/12th Nov/ 12:23:53 JF: Keio W3C will have JPC meeting on the 6th November 12:24:20 ... so we can expect more traffic on SVG IG JP 12:25:11 DS: If Kaz can translate the description on the public mailing list page in English to Japanese 12:25:37 ACTION: Doug to Coordinate on Kaz on JP IG list description 12:25:37 Created ACTION-2329 - Coordinate on Kaz on JP IG list description [on Doug Schepers - due 2008-10-30]. 12:25:44 list description is in english currently 12:25:45 http://lists.w3.org/Archives/Public/public-svg-ig-jp/ 12:26:03 JF: Currently our main activity in SVG IG JP is to support the SVG JIS standardisation 12:26:23 ... and coordinate with other people. Another activity is to promote the usage of SVG for 12:26:27 ... web mapping in Japan 12:26:38 ... we will working on a new module called SVG Map module 12:26:50 CL: This is related to the existing JIS standard? 12:27:12 JF: No this is a different module and and email to promote it has been sent out 12:27:17 ... we will work on a complete module 12:27:24 ... so we can make a complete proposal to SVG WG 12:27:36 ... we also considering on gathering SVG map data in Japan 12:27:48 ... and publish the map data on the SVG community site 12:27:56 ... possibly on planet SVG 12:28:09 CL: Are there minutes of the F2F meeting? 12:28:26 JF: Yes minutes were scribed but they are in Japanese 12:28:34 ... by Kaz 12:28:55 DS: I want to thank you for all your effort you have put into this 12:28:56 thats good. hope to see them on the mailing list 12:29:16 DS: The fact that you are the chair of the SVG IG is really good. I appreciate that 12:29:25 Topic: SVG JIS Standard 12:29:45 JF: On the same date we had the first SVG JIS committee meeting 12:30:21 ... Hagino-san of W3C Keio is the manager 12:30:36 ... and the goal is to create a JIS Standard for the SVG based format for mapping 12:30:51 ... and that includes a complete translated specification of SVG Tiny 1.2 12:31:01 DS: When will they begin translation? 12:31:08 JF: As soon as PR is available 12:31:20 ... in the first committee meeting we discussed the possible category of the JIS standard 12:31:29 ... and also the structure of the standard has been discussed 12:31:39 ... there are two possible categories, one is mapping 12:31:47 ... and networking category 12:31:52 DS: Can it be in both? 12:31:58 JF: That is an important point 12:32:11 ... as for the structure four possibilities was suggested 12:32:17 ... the first is the one just for SVG 12:32:24 ... and one for SVG map module 12:32:49 ... 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 ... and the third possibility is to have a single JIS standard to have branch of map module 12:33:31 ... and the last possibility is to have a single combined specification which has SVG map and SVG Tiny all in one 12:34:06 CL: The advantage of each 12:34:28 s/The advantage/There are advantages/ 12:35:03 JF: There are some people who think that it is not useful out side of the use case of mapping 12:35:46 ... we had the conclusion that there will be a map module and a network module 12:36:55 ... 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 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 ... so we hope that we can bring the Map module to the working group 12:37:34 DS: I know Andreas will be interested in this module 12:37:44 ... the other thing that KDDI is not a member of W3C 12:37:52 I would like to see the Japanese version on the W3C site as an official translation 12:37:54 ... so they can't make a submission 12:38:11 JF: It will be a proposal from the IG 12:38:39 CL: We need to get patent statements from all of the authors 12:38:48 ... agreeing to W3C patent policy 12:39:00 JF: People in SVG IG JP agree to W3C patent policy 12:39:57 http://www.svgopen.org/2004/papers/indigo/ 12:40:13 Development of location based search engine service using goSVG 12:40:24 Yuzo Matsuzawa 12:40:24 Indigo Corporation 12:40:30 JF: The goal is to come up with SVG Map profile which might be based on SVG 2.0 Core 12:41:01 ... or some other useful module like Transforms 12:42:32 ... SVG JIS project will be two year 12:42:46 ... it started this April and ended in Mar 2009 12:42:55 ... that is the goal in the first year to do the translation 12:43:07 ... of the whole specification 12:43:18 ... we have to finish the translation around the end of next March 12:43:33 ... in the second year the committee will take a formal process to publish the standard 12:43:54 ... in order to achieve this the timing for SVG Tiny to achieve PR and Rec is important 12:44:04