IRC log of svg on 2011-12-22
Timestamps are in UTC.
- 20:12:16 [RRSAgent]
- RRSAgent has joined #svg
- 20:12:16 [RRSAgent]
- logging to http://www.w3.org/2011/12/22-svg-irc
- 20:12:18 [trackbot]
- RRSAgent, make logs public
- 20:12:18 [Zakim]
- Zakim has joined #svg
- 20:12:20 [trackbot]
- Zakim, this will be GA_SVGWG
- 20:12:20 [Zakim]
- ok, trackbot, I see GA_SVGWG(SVG1)3:00PM already started
- 20:12:21 [trackbot]
- Meeting: SVG Working Group Teleconference
- 20:12:21 [trackbot]
- Date: 22 December 2011
- 20:12:26 [cyril]
- yes, don't tell me I woke up early for nothing :)
- 20:13:50 [Zakim]
- +??P2
- 20:13:54 [heycam]
- Zakim, ??P2 is me
- 20:13:54 [Zakim]
- +heycam; got it
- 20:14:00 [Zakim]
- +[IPcaller]
- 20:14:01 [heycam]
- Zakim, who is on the call?
- 20:14:01 [Zakim]
- + +33.9.53.77.aabb
- 20:14:03 [Zakim]
- On the phone I see +61.2.980.5.aaaa, heycam, +33.9.53.77.aabb, [IPcaller]
- 20:14:15 [ed]
- Zakim, [IP is me
- 20:14:15 [Zakim]
- +ed; got it
- 20:14:49 [heycam]
- Chair: Cameron
- 20:15:17 [heycam]
- Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2011OctDec/0109.html
- 20:15:23 [cyril]
- zakim, +61 is me
- 20:15:23 [Zakim]
- +cyril; got it
- 20:15:46 [ed]
- scribeNick: ed
- 20:16:10 [ed]
- Topic: mesh gradients
- 20:16:18 [Tav]
- http://tavmjong.free.fr/SVG/MESH/Mesh_Boundaries.html
- 20:16:40 [ed]
- TB: i've been looking at cyril's comments on the problems with mesh gradients
- 20:17:06 [ed]
- ... as can be seen in the examples in the link above, there are discontinuity in the gradient
- 20:17:35 [ed]
- ... scroll down, and you can see the same problem for linear gradients too
- 20:18:25 [ed]
- ... look at where the red line breaks
- 20:18:38 [cyril]
- mach banding effect I think
- 20:18:59 [ed]
- TB: probably the brain is geared towards finding discontinuities
- 20:19:18 [ed]
- CM: where there's a bend in the line, it looks brigther
- 20:19:30 [cyril]
- http://en.wikipedia.org/wiki/Mach_banding
- 20:19:47 [ed]
- CC: not sure it's this exactly, but it's related
- 20:20:10 [ed]
- TB: with mesh gradients you have the control points along the sides, that not only control the shape but also the spread
- 20:20:50 [ed]
- ... next figure shows the same discontinuities as for the linear gradients but with mesh gradients
- 20:21:43 [ed]
- ... i've moved the control points in the figure with the purple curve, giving a smoother look
- 20:22:26 [ed]
- ... if you change the controlpoints you change two things at once, both shape and color
- 20:22:52 [ed]
- ... the mesh in this case is still a rectangle
- 20:23:08 [ed]
- CC: would be nice to show the controlpoints in the example, for understanding it better
- 20:23:15 [ed]
- TB: will add that
- 20:23:58 [ed]
- ... now in "Understanding Coons Patches"
- 20:24:35 [ed]
- ... shows controlpoints, and what you get
- 20:25:11 [ed]
- ... if you move controlpoints further you get discontinuities
- 20:25:23 [ed]
- ... you can never have a derivative of 0 at the edge of a patch
- 20:25:42 [ed]
- CC: what if you put the controlpoint in horizontal?
- 20:25:47 [ed]
- TB: can't do that
- 20:25:53 [ed]
- ... they're in colorspace
- 20:26:11 [ed]
- ... 1/3 of the way up and 1/3 of the way down
- 20:26:37 [ed]
- ... it's not a controlpoint for the mesh, it's for the color
- 20:26:59 [ed]
- CM: are you illustrating the rate of the change?
- 20:27:10 [ed]
- TB: something like that yes
- 20:28:05 [ed]
- CM: so the color moves quicker at the start of the curve
- 20:28:21 [ed]
- TB: i've plotted what happens when you move the controlpoints
- 20:28:36 [ed]
- CC: are you using the same controlpoints for the upper and lower parts of the curve
- 20:28:40 [ed]
- TB: yes
- 20:29:10 [Zakim]
- -heycam
- 20:29:23 [ed]
- CC: you use linear interpolation since you have two colors, you'd have bilinear if you had one color in each corner
- 20:29:49 [ed]
- TB: just illustrating that it's possible to reduce the effect
- 20:29:57 [Zakim]
- +??P2
- 20:30:03 [heycam]
- Zakim, ??P2 is me
- 20:30:03 [Zakim]
- +heycam; got it
- 20:30:28 [ed]
- ... once you move the controlpoint outside the mesh it overlaps itself
- 20:30:38 [ed]
- ... if you introduce a tensor
- 20:30:53 [ed]
- ... you could change the the way the colors inside the mesh are distributed
- 20:31:03 [ed]
- ... doesn't affect the edges
- 20:31:55 [ed]
- ... i've looked at the cairo code and it exploits this to compute the gradient, divides the patch from top to bottom using the tensor points so that you have a series of bezier curves taht are no wider than a pixel
- 20:32:03 [ed]
- ... and then it draws each bezier curve in turn
- 20:33:00 [ed]
- CC: illustrator doesn't use coons patches
- 20:33:14 [ed]
- ... probably tensor product patches with tensor derivatives
- 20:33:22 [ed]
- ... with bicubic interpolation
- 20:33:39 [ed]
- TB: what they show in illustration...
- 20:33:51 [ed]
- ... is shown as one patch but is actually many patches
- 20:34:05 [ed]
- ... the boundaries don't correspond to the object, but to the edges to the mesh
- 20:34:53 [ed]
- ... some examples have rough shapes that can't be described by a simple bezier
- 20:35:29 [ed]
- CM: clipping is another trick
- 20:35:56 [ed]
- TB: when we discussed it previously there was a request to use the mesh as a clip or by itself
- 20:36:11 [ed]
- CC: but then tehre would be a problem with the stroke
- 20:36:24 [ed]
- ... not sure if we decided to do it as a paintserver or not
- 20:36:41 [ed]
- TB: anyway, that's the state atm
- 20:37:07 [ed]
- CM: does messing with the controlpoints help for eliminating the disconts?
- 20:37:14 [ed]
- TB: a bit
- 20:37:40 [ed]
- ... by adding extra patches it's possible to smooth it out
- 20:38:18 [ed]
- CC: i've experimented with corel draw, looks like they do something very similar to illustrator
- 20:39:07 [ed]
- CM: could the subdivision of patches be useful to define in the document?
- 20:39:43 [ed]
- ... could we describe this simply, and would we want to enable that by an attribute for example?
- 20:40:01 [ed]
- CC: i think they're approximating, not sure there's a single way to do this
- 20:40:09 [ed]
- ... depends on quality etc
- 20:40:23 [ed]
- TB: leaning towards letting the author handle it
- 20:41:45 [ed]
- ... if you have a regular gradient you owuld not use meshes, or they would subdivide
- 20:42:21 [ed]
- ... i'm going to read the paper cyril linked to again
- 20:42:31 [ed]
- CC: let's discuss this at the F2F
- 20:43:11 [ed]
- ... coons patches are fine and you can do good things with them, but there are limitations, and authoring tools solve them atm, but we may want to introduce something like that in the future
- 20:43:39 [ed]
- TB: we might want to smooth out linear gradients too
- 20:44:01 [ed]
- ... using catmull-rom curves
- 20:45:22 [Zakim]
- -heycam
- 20:46:12 [Zakim]
- +??P2
- 20:46:15 [heycam]
- Zakim, ??P2 is me
- 20:46:15 [Zakim]
- +heycam; got it
- 20:46:21 [Tav]
- zakim, +33 is me
- 20:46:21 [Zakim]
- +Tav; got it
- 20:47:05 [ed]
- topic: SVG2 requirements
- 20:47:07 [cyril]
- http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Free_audio.2Fvideo_codec_requirements
- 20:47:19 [cyril]
- http://mpeg.chiariglione.org/meetings/geneva11-1/geneva_press.htm
- 20:47:35 [ed]
- CC: this is from MPEG
- 20:48:00 [ed]
- ... one track for MPEG1, since patents are phasing out
- 20:48:22 [ed]
- ... other option is AVC standard but with a baseline where patent holders agree to make it free
- 20:48:28 [ed]
- ... that's not yet decided
- 20:48:42 [ed]
- ... there are big interests, political and economical
- 20:49:10 [ed]
- CM: what's your sense of these two possible ways forward?
- 20:49:26 [ed]
- CC: first option is clear in terms of patent conflicts
- 20:49:39 [ed]
- ... if there were other patents they would have been claimed before
- 20:49:49 [ed]
- ... thing is it won't be good quality
- 20:50:10 [ed]
- ... building on mpeg1 is unclear, due to patents
- 20:50:35 [ed]
- ... other option H264 / AVC one, it would be compatible with most exisitng codecs
- 20:50:46 [ed]
- ... but it's a big question for the stakeholders
- 20:51:05 [ed]
- TB: what does google support in their browser?
- 20:51:15 [ed]
- CC: on pc it's different from on android
- 20:51:30 [ed]
- ...think they're talking about dropping 264 on pc, and android
- 20:51:41 [ed]
- TB: what's the fallback?
- 20:51:44 [ed]
- CC: webm
- 20:51:52 [ed]
- ... but the licensing isn't clear either
- 20:52:26 [ed]
- ... mpeg issued a call for patents covering webm, and got responses (3 digits)
- 20:52:43 [ed]
- CM: the responses will be published yes?
- 20:52:53 [ed]
- CC: i think so, next year maybe
- 20:54:18 [ed]
- CM: in terms of requirements i don't think we should be reuqiring codecs at this point
- 20:54:25 [cyril]
- http://www.webm-ccl.org/
- 20:54:29 [ed]
- ... it's something that should be done for the whole web platform
- 20:55:39 [ed]
- CC: apple and microsoft are missing from the webm licensing members list
- 20:58:20 [cyril]
- RRSAgent, pointer
- 20:58:20 [RRSAgent]
- See http://www.w3.org/2011/12/22-svg-irc#T20-58-20
- 20:59:30 [cyril]
- SVG WG supports the goal, including for the whole web platform, but it does not seem feasible at the moment
- 20:59:57 [ed]
- RESOLUTION: SVG WG supports the goal, including for the whole web platform, but it does not seem feasible at the moment
- 21:00:11 [heycam]
- http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Tooltip_element
- 21:00:19 [ed]
- CM: next tooltip elements
- 21:00:34 [ed]
- ... this has come up before
- 21:00:49 [ed]
- ... i've never really been satisfied with the tooltips in tiny so far
- 21:01:08 [ed]
- ... not clear to me what's a good solution
- 21:01:39 [Zakim]
- -heycam
- 21:02:13 [ed]
- ... he wants a way to generate tooltips
- 21:02:19 [Zakim]
- +[IPcaller]
- 21:02:21 [heycam]
- Zakim, [ is me
- 21:02:22 [Zakim]
- +heycam; got it
- 21:02:38 [ed]
- TB: doesn't browsers differ today with what's displayed as a tooltip, <title> or xlink:title
- 21:03:03 [ed]
- CM: yes I think you're right TB
- 21:03:32 [ed]
- ... html is a bit different because it has a title attribute
- 21:04:05 [ed]
- ... i think our title element has a broader meaning than @title in html
- 21:04:41 [ed]
- ... people are used to what it does in html
- 21:04:58 [ed]
- ... i think we should look into the issue for svg2
- 21:05:37 [ed]
- ... agree with DOH that using metadata with role isn't the right way to do this
- 21:05:44 [ed]
- CC: maybe a should req?
- 21:06:52 [Tav]
- http://tavmjong.free.fr/SVG/PROGRESSBAR/SteamEngineProgressBar_StandAlone.svg
- 21:06:56 [heycam]
- SVG 1.1 also says "Alternate presentations are possible, both visual and aural, which display the ‘desc’ and ‘title’ elements but do not display ‘path’ elements or other graphics elements. This is readily achieved by using a different (perhaps user) style sheet."
- 21:07:26 [Zakim]
- -Tav
- 21:08:13 [Zakim]
- +Tav
- 21:09:15 [Zakim]
- -Tav
- 21:09:45 [Zakim]
- +Tav
- 21:10:21 [ed]
- CM: the document has both <title> and <desc> duplicating the content
- 21:10:52 [ed]
- ED: don't think any of the browser display <desc> as a tooltip
- 21:11:49 [ed]
- CM: think we can improve on the requirements for tooltips, to align with html implementation
- 21:12:05 [ed]
- ... so that they're shown under the same circumstances
- 21:12:31 [ed]
- ... we can investigate more when we look into the issue
- 21:13:04 [ed]
- RESOLUTION: SVG2 will have stronger requirements for when to display tooltips
- 21:13:18 [heycam]
- http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Hit-testing_on_image_alpha
- 21:13:44 [ed]
- CM: this was discussed in an FXTF meeting IIRC
- 21:13:58 [ed]
- ... perhaps more generic, with images and fill
- 21:15:42 [ed]
- ED: probably the proposal from zynga, with masks for mouse events
- 21:16:03 [ed]
- CC: we could discuss this with alex at the F2F
- 21:17:00 [ed]
- ACTION: ED to summarize the discussions about hittesting with alpha from the FX list
- 21:17:00 [trackbot]
- Created ACTION-3190 - Summarize the discussions about hittesting with alpha from the FX list [on Erik Dahlström - due 2011-12-29].
- 21:17:25 [heycam]
- http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Anchor_events_.28anchorActivated.2C_anchorTargeted.29
- 21:17:58 [ed]
- CM: doug is requesting an event for when the link changes
- 21:18:12 [ed]
- ... html already has the hashchanged events
- 21:18:24 [ed]
- CC: this should be part of the harmonization with html, right?
- 21:18:41 [ed]
- CM: not sure if we said before if we decided on document level events and such
- 21:19:34 [ed]
- ... think we should consider all the documentwide events
- 21:20:27 [ed]
- ... in html, and make them apply to svg
- 21:20:42 [ed]
- ... where it makes sense
- 21:22:14 [cyril]
- "SVG 2 will have HTML document wide events (including hashchange) apply to SVG documents when they make sense"
- 21:23:17 [ed]
- RESOLUTION: SVG 2 will consider adding HTML document wide events (including hashchange) in SVG documents where they make sense
- 21:23:35 [heycam]
- http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_adding_drag_and_drop_functionality
- 21:24:15 [ed]
- CM: DND in html5 is dragsources and dragtargets, and getting things from other applications
- 21:24:24 [ed]
- ...not with moving elements around
- 21:24:54 [ed]
- ... we should try to get the html5 dnd functionality
- 21:25:22 [ed]
- ... not sure about the dnd for moving things in the document
- 21:25:59 [ed]
- ... probably better to focus on improving the DOM apis for getting the mouse cursor in the variious cooridnate systems, to ease moving things around that way
- 21:27:29 [ed]
- ED: aligning with html5 on this sounds good to me
- 21:27:37 [heycam]
- http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dnd
- 21:28:22 [ed]
- ... and improving the DOM apis too
- 21:29:39 [ed]
- ACTION: CM to investigate how html5 drag&drop could be used in svg
- 21:29:39 [trackbot]
- Sorry, amibiguous username (more than one match) - CM
- 21:29:39 [trackbot]
- Try using a different identifier, such as family name or username (eg. charles, cmccorma)
- 21:29:49 [ed]
- ACTION: heycam to investigate how html5 drag&drop could be used in svg
- 21:29:50 [trackbot]
- Created ACTION-3191 - Investigate how html5 drag&drop could be used in svg [on Cameron McCormack - due 2011-12-29].
- 21:30:26 [ed]
- ACTION: heycam to investigate what document wide events would make sense to apply to svg documents too
- 21:30:27 [trackbot]
- Created ACTION-3192 - Investigate what document wide events would make sense to apply to svg documents too [on Cameron McCormack - due 2011-12-29].
- 21:31:24 [ed]
- RESOLUTION: SVG2 may require drag&drop functionality, and we'll investigate html5's functionality for that
- 21:32:36 [Zakim]
- -ed
- 21:32:38 [Zakim]
- -heycam
- 21:32:42 [Zakim]
- -cyril
- 21:32:45 [Zakim]
- -Tav
- 21:32:46 [Zakim]
- GA_SVGWG(SVG1)3:00PM has ended
- 21:32:48 [Zakim]
- Attendees were +61.2.980.5.aaaa, heycam, [IPcaller], +33.9.53.77.aabb, ed, cyril, Tav
- 21:32:58 [ed]
- Zakim, end telcon
- 21:32:58 [Zakim]
- I don't understand 'end telcon', ed
- 21:33:06 [ed]
- trackbot, end telcon
- 21:33:06 [trackbot]
- Zakim, list attendees
- 21:33:06 [Zakim]
- sorry, trackbot, I don't know what conference this is
- 21:33:07 [trackbot]
- RRSAgent, please draft minutes
- 21:33:07 [RRSAgent]
- I have made the request to generate http://www.w3.org/2011/12/22-svg-minutes.html trackbot
- 21:33:08 [trackbot]
- RRSAgent, bye
- 21:33:08 [RRSAgent]
- I see 4 open action items saved in http://www.w3.org/2011/12/22-svg-actions.rdf :
- 21:33:08 [RRSAgent]
- ACTION: ED to summarize the discussions about hittesting with alpha from the FX list [1]
- 21:33:08 [RRSAgent]
- recorded in http://www.w3.org/2011/12/22-svg-irc#T21-17-00
- 21:33:08 [RRSAgent]
- ACTION: CM to investigate how html5 drag&drop could be used in svg [2]
- 21:33:08 [RRSAgent]
- recorded in http://www.w3.org/2011/12/22-svg-irc#T21-29-39
- 21:33:08 [RRSAgent]
- ACTION: heycam to investigate how html5 drag&drop could be used in svg [3]
- 21:33:08 [RRSAgent]
- recorded in http://www.w3.org/2011/12/22-svg-irc#T21-29-49
- 21:33:08 [RRSAgent]
- ACTION: heycam to investigate what document wide events would make sense to apply to svg documents too [4]
- 21:33:08 [RRSAgent]
- recorded in http://www.w3.org/2011/12/22-svg-irc#T21-30-26