06:31:41 RRSAgent has joined #svg 06:31:41 logging to http://www.w3.org/2009/06/01-svg-irc 06:31:42 RRSAgent, make logs public 06:31:44 Zakim, this will be GA_SVGWG 06:31:45 ok, trackbot; I see GA_SVGWG()2:30AM scheduled to start now 06:31:45 Meeting: SVG Working Group Teleconference 06:31:46 Date: 01 June 2009 06:32:45 GA_SVGWG()2:30AM has now started 06:32:52 +??P0 06:32:59 Zakim, ?? is me 06:32:59 +ed; got it 06:33:06 +Shepazu 06:34:09 +??P2 06:34:12 +??P1 06:34:15 Zakim, ??P1 is me 06:34:15 +heycam; got it 06:34:15 Zakim, ??P2 is me 06:34:16 +anthony; got it 06:37:01 -heycam 06:37:05 ChrisL has joined #svg 06:38:07 +ChrisL 06:38:47 zakim, who is here? 06:38:47 On the phone I see ed, Shepazu, anthony, ChrisL 06:38:48 On IRC I see ChrisL, RRSAgent, heycam, ed, anthony, shepazu, karl, jwatt, Zakim, ed_work, trackbot 06:42:05 +??P3 06:42:09 Zakim, ??P3 is me 06:42:09 +heycam; got it 06:43:08 Chair: Cameron 06:43:28 scribeNick: ed 06:43:31 scribe: Erik 06:43:55 Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0177.html 06:44:16 Topic: Experiment on alternate SVG path syntax for better EXI compression 06:44:37 CM: haven't yet had time to read the PDF 06:45:24 CL: i have, if you make the markup more verbose EXI is able to compress it better 06:45:49 ...no studies of whether gzip or EXI is more efficient 06:46:33 ...but we have talked about adding path syntax in next major svg version 06:46:53 ...for animating, for xslt:ing etc 06:47:47 -heycam 06:48:18 +??P3 06:48:20 Zakim, ??P3 is me 06:48:20 +heycam; got it 06:48:20 DS: another possible advantage would be for connecting things in layout 06:48:39 yup, can put an id on individual path commands 06:49:13 DS: also for markers, we could have richer ways of addressing individual path segments 06:49:34 CL: ...??... event listeners 06:50:24 AG: using that method you get good EXI compression 06:50:37 DS: CL has a point in that the study isn't complete 06:50:48 ...or maybe EXI is done? 06:51:00 ...can you do both EXI and gzip at the same time? 06:51:08 CL: yes, but it's like gzipping a jpeg file 06:51:11 also, once the schema is expanded to allow event listeners, etc the exi compression will be less efficient 06:52:05 DS: we could go for two syntaxes, one for compression 06:52:20 AG: would like to think of the same syntax for transforms as well 06:52:46 ...you could reuse the transforms, without using a group 06:53:45 DS: just wondering if people would then ask for a z-index attribute on a path segment 06:54:25 ...would be useful if the study could look at existing svg content, e.g from wikipedia 06:54:47 ...could write a script to convert into EXI syntax 06:55:11 ...what are the statistics, what files have been tested? 06:55:18 CL: not given in the study 06:55:51 -heycam 06:55:56 DS: we should ask them for statistics, and references to what files have been tested, and also how it compares to gzip 06:56:26 ...and that people can put id attributes on child elements, how does that affect performance/compression? 06:57:09 CL: id is the least of their worries, if you put presentation attributes everywhere that might mean it's less efficient, we should ask about that too 06:57:48 DS: stroke could be meaningful, for individual path segments 06:58:09 heycam has joined #svg 06:58:19 +??P3 06:58:24 Zakim, ??P3 is me 06:58:25 +heycam; got it 06:58:25 CL: inheritance of properties... 06:59:09 DS: we should ask these questions, and ask what the consequences of our changes would be 06:59:53 ...nurbs would be nice to have too 07:00:19 CL: yeah, but in new element in that case 07:00:33 yes, though not added to path - better to be its own element so they can be tweened etc 07:00:33 AG: would like to restrict z-index to group elements 07:01:11 DS: at the f2f we should talk about the consequences of breaking up the path syntax would be 07:01:24 ...and what it wiold mean to change the fill on one segment 07:01:37 CL: might change the fill of markers on that segment possibly 07:02:08 CM: would this help with calligraphic strokes? variable strokewidth... 07:02:50 CL: the idea of having a width gradient, an element that has a number of width stops, and you apply that to a path 07:03:38 DS: another aspect, ppl don't always want the strokewidth to be the same on both sides 07:04:17 ...0, 20, 10; 0 blah... sequences where one would be the inner and one would be the outer strokewidth 07:04:48 CL: you want a right stop and a left stop 07:05:40 DS: or do percentages of the pathlength, say at 70% along the path it's 20px wide 07:06:49 CL: two modes, one relative to the overall strokewidth, and one would be absolute 07:06:56 its like objectboundingbox except the dimensions are different, the rectangle is the length of the path times the width 07:07:09 width can be absolute or relative 9to the stroke width) 07:07:21 CM: seems like a topic for the f2f 07:07:22 s/9/(/ 07:07:46 ACTION: CL to write up proposal for variable stroke-width on paths 07:07:47 Created ACTION-2583 - Write up proposal for variable stroke-width on paths [on Chris Lilley - due 2009-06-08]. 07:08:36 Topic: Native support for Drag & Drop in SVG 07:08:39 http://lists.w3.org/Archives/Public/www-svg/2009May/0053.html 07:08:58 CM: featurerequest for simpler way of doing drag&drop 07:09:36 DS: there's a drag&drop element attribute being defined in the webapps wg, and also in html5 07:09:55 ...a more robust way of doing it might be to extend the layout syntax 07:11:15 ...if you just have drag & drop elements, you'd need scripts to drive it 07:11:37 ...it would be possible to use smil only 07:12:30 CM: i wouldn't like drag&dropiping if it just added a transform or something 07:12:44 ...also deals with data flavours 07:13:03 ...maybe that was more of the issue, than the actual moving of the graphic 07:13:25 ...that part (data side) is being handled by html/webapps...would like that to be the same 07:13:47 DS: chaals and I were editing this in the webapps wg 07:14:22 ...there might be cases where you want to paste the rasterized version of the graphic, the title of the graphic...what you are grabbing is complex 07:14:48 ...do you drag just one element, what about sizes etc 07:15:13 ...and what if you drop it into another document (or somewhere which doesn't support svg) 07:15:28 ...it's a different issue from moving things around though 07:16:09 ...I started working on the connector element (SVG Integration?) 07:18:56 ACTION: CL to mail patrick ion about smooth curves with points on path and CC the svg-wg list 07:18:56 Created ACTION-2584 - Mail patrick ion about smooth curves with points on path and CC the svg-wg list [on Chris Lilley - due 2009-06-08]. 07:20:12 ACTION: Cameron to reply to the drag&drop email 07:20:12 Created ACTION-2585 - Reply to the drag&drop email [on Cameron McCormack - due 2009-06-08]. 07:20:55 DS: ppl might want to do math while dragging, the size of the thing increases or something....might be nice to have declarative way of doing that 07:21:59 ACTION: DS to write up scenarios for drag&drop and how it should work declaratively etc 07:21:59 Created ACTION-2586 - Write up scenarios for drag&drop and how it should work declaratively etc [on Doug Schepers - due 2009-06-08]. 07:23:21 ACTION: CL to respond to the EXI mail, in http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0177.html 07:23:22 Created ACTION-2587 - Respond to the EXI mail, in http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0177.html [on Chris Lilley - due 2009-06-08]. 07:24:25 Topic: ISSUE-2267: Consider removing SVGEvent 07:24:36 ISSUE-2267? 07:24:36 ISSUE-2267 -- Consider removing SVGEvent -- RAISED 07:24:36 http://www.w3.org/Graphics/SVG/WG/track/issues/2267 07:25:15 CM: can we drop the SVGEvent interface? 07:25:30 ...it extends Event, but doens't add anything on it 07:25:58 CL: we added it so that we could extend it if we needed it I think 07:26:27 CM: there's no real need for having the interface 07:26:54 ED: it's not used in the spec? 07:27:15 CM: well, it's used but is no different from Event 07:27:56 DS: how would this affect UA:s? 07:28:05 CL: not exposed really 07:28:29 CM: we don't distinguish between Event and SVGEvent 07:29:18 ACTION: Cameron to remove the SVGEvent interface in SVG 1.1F2 07:29:18 Created ACTION-2588 - Remove the SVGEvent interface in SVG 1.1F2 [on Cameron McCormack - due 2009-06-08]. 07:29:36 Topic: Plans for SVG 1.1 test suite, missing test coverage 07:29:54 CL: the long list of tests there should be autogenerated? 07:30:36 ...some of the tests are ok, but some can't be tested unless you have a UA that supports some extension feature 07:31:00 CM: semiautomated was the thought 07:31:09 ...we can look at this at the f2f 07:31:20 ...I'd like to decide which are testable and to make tests for them 07:31:28 ...and split them among ourselves 07:31:59 ...seems like a good idea to republish the testsuite at the same time as the 1.1F2 07:32:22 ...we may be gated on the testsuite 07:34:19 yes, but if the testing takes too long we should release the spec anyway, as its valuable to have a spec with errata rolled in 07:34:43 Topic: Multiple 07:34:48 CL: responded to that 07:35:15 ...the whole point is to display a missing glyph, 07:35:21 ...it's undefined in CSS 07:36:05 ...you can pick the missingglyph from another source 07:36:54 CM: do we say about glyph selection? 07:37:08 CL: we do what CSS says 07:37:14 http://www.w3.org/TR/CSS21/fonts.html#algorithm 07:37:19 CM: should we have it in our spec though? 07:37:35 CL: yeah, we use the fontselection algorithm, from css 07:37:59 CM: does it mean it can pick a font you didn't list in font-family? 07:38:11 CL: yes 07:39:02 ...by default it uses a special unicode font which shows the codepoint 07:39:15 ...answer should be yes, we know, it's not a problem 07:39:40 CM: if that's what we require, then I guess it wouldn't be good to diverge from that 07:39:56 ...in the CSS3 font matching algorithm, has it been updated? 07:40:08 CL: not sure, will check 07:40:15 6. If a particular character cannot be displayed using any font, the user agent should indicate by some means that a character is not being displayed, either by displaying a symbolic representation of the missing glyph or using the ‘missing character’ glyph from another font. 07:40:35 its step 6 in http://dev.w3.org/csswg/css3-fonts/#font-matching 07:40:48 CL: the basis is the same though 07:41:04 ...allows missingglyph from any font 07:41:28 ACTION: cameron to respond to http://www.w3.org/Bugs/Public/show_bug.cgi?id=4930 07:41:28 Created ACTION-2589 - Respond to http://www.w3.org/Bugs/Public/show_bug.cgi?id=4930 [on Cameron McCormack - due 2009-06-08]. 07:42:14 Topic: google i/o 07:42:58 DS: talked to brad neuberg, who's working on the shim 07:43:06 ...making good progress 07:43:23 ...release hopefully ready by svg open 07:43:37 AG: shim? 07:44:09 DS: shim is like a plugin, but isn't really, it's a script library that enables functionality 07:44:32 ...this one uses flash to render SVG, and it should work with existing code 07:44:50 ...like a svg virtual machine 07:45:58 ...IE users are slow to upgrade 07:46:35 ...even if IE supported SVG in the next version it would take years before ppl could use it 07:47:28 ...the shim also gives consistent results across browsers (ED: though that does require plugins are enabled) 07:47:51 ...gives consistent look&feel 07:48:47 ...talked about the params spec with google guys 07:49:29 ...the shim can be rolled out much faster than a browser, and it's opensource 07:49:50 ...could help svg specs move along faster too 07:51:41 CL: could help ppl with the ASV issue, helps SVG 07:52:05 ...slightly worrying that the shim might decide the featureset 07:52:53 DS: well it has a short releasecycle, and it's opensource 07:53:03 CL: svg tiny 1.2 stuff? 07:54:32 DS: I suspect textwrapping in svg would be one thing 07:54:50 ...zooming is one thing which would help some UAs like firefox 07:56:04 CL: risk of slowing down browser implementations 07:56:45 ...it's good as a move from ASV still, and for adding features 07:58:06 DS: also connected with the google wave guys 07:58:15 ...interested in dom 3 events, the key events stuff 07:58:28 ...to get it folded it into webkit / chrome 08:01:05 Topic: F2F 08:01:20 DS: please send me your travel info 08:02:23 ...AG you'll be dialing in? 08:02:29 AG: yep 08:03:34 -ChrisL 08:03:35 -ed 08:03:36 -anthony 08:03:42 -heycam 08:03:48 -Shepazu 08:03:49 GA_SVGWG()2:30AM has ended 08:03:50 Attendees were ed, Shepazu, heycam, anthony, ChrisL 08:03:52 Zakim, bye 08:03:52 Zakim has left #svg 08:03:58 rrs-agent, make minutes 08:04:04 RRSAgent, make minutes 08:04:04 I have made the request to generate http://www.w3.org/2009/06/01-svg-minutes.html ed 08:48:07 heycam has joined #svg 09:51:23 heycam has joined #svg