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
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]
20:13:54 [heycam]
Zakim, ??P2 is me
20:13:54 [Zakim]
+heycam; got it
20:14:00 [Zakim]
20:14:01 [heycam]
Zakim, who is on the call?
20:14:01 [Zakim]
+ +
20:14:03 [Zakim]
On the phone I see +61.2.980.5.aaaa, heycam, +, [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]
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]
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]
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]
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]
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]
20:46:12 [Zakim]
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]
20:47:19 [cyril]
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]
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]
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]
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]
21:02:13 [ed]
... he wants a way to generate tooltips
21:02:19 [Zakim]
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]
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]
21:08:13 [Zakim]
21:09:15 [Zakim]
21:09:45 [Zakim]
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]
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]
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]
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]
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]
21:32:38 [Zakim]
21:32:42 [Zakim]
21:32:45 [Zakim]
21:32:46 [Zakim]
GA_SVGWG(SVG1)3:00PM has ended
21:32:48 [Zakim]
Attendees were +61.2.980.5.aaaa, heycam, [IPcaller], +, 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 trackbot
21:33:08 [trackbot]
RRSAgent, bye
21:33:08 [RRSAgent]
I see 4 open action items saved in :
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
21:33:08 [RRSAgent]
ACTION: CM to investigate how html5 drag&drop could be used in svg [2]
21:33:08 [RRSAgent]
recorded in
21:33:08 [RRSAgent]
ACTION: heycam to investigate how html5 drag&drop could be used in svg [3]
21:33:08 [RRSAgent]
recorded in
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