IRC log of svg on 2009-06-01

Timestamps are in UTC.

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