01:27:53 RRSAgent has joined #svg 01:27:53 logging to http://www.w3.org/2013/11/15-svg-irc 01:27:57 Zakim has joined #svg 01:28:07 Zakim, call Huangshan 01:28:07 sorry, heycam, I don't know what conference this is 01:28:15 Zakim, room for 4? 01:28:16 ok, heycam; conference Team_(svg)01:28Z scheduled with code 26631 (CONF1) for 60 minutes until 0228Z 01:28:19 Zakim, call Huangshan 01:28:19 ok, heycam; the call is being made 01:28:20 Team_(svg)01:28Z has now started 01:28:21 +Huangshan 01:28:22 nikos has joined #svg 01:29:31 kk 01:29:57 It's a good thing we just switched to unlimited minutes, from 600. 01:30:02 nikos1 has joined #svg 01:30:19 scribe: nikos 01:30:23 scribe: nikos1 01:30:28 My cell plan. 01:30:39 scribenick: nikos 01:30:42 +TabAtkins 01:30:43 -TabAtkins 01:30:43 +TabAtkins 01:30:45 jun has joined #svg 01:31:01 myakura has joined #svg 01:31:05 Topic: Path rotation and new circluar/elliptical arc commands 01:31:23 heycam: one of the requirements we had for svg 2 was for a path command to set current rotation 01:31:30 ... subsequent commands are then relative to that rotation 01:31:41 ... the reason for allowing was to avoid having to do trig 01:31:57 ... if you want to animate the path - e.g. rotate one section 01:32:11 ... I wanted that in conjunction with a simpler arc command 01:32:25 ... so you could do circular or elliptical arc from current position by a certain number of degrees 01:32:34 ... I've given that letter 'b' for bearing 01:32:49 ... the capital 'B' takes the angle in degrees 01:33:01 https://svgwg.org/svg2-draft/paths.html#PathDataBearingCommands 01:33:36 ... the idea is that when you have a bearing that is not zero, that effects only relative path commands after that 01:33:59 ... so 'h' would go that distance in the direction of the bearing 01:34:09 heycam: initial rotation is zero 01:34:41 TabAtkins: tradition for angles is to make them zero degrees pointing upwards - especially with bearing 01:35:37 TabAtkins: you need a capital B, but typically the way angles are done is that zero degrees points upwards 01:35:54 ... it doesn't matter a lot, not sure it makes a difference here 01:36:06 heycam: it makes a difference which path commands you use to go straight forward 01:36:14 TabAtkins: the notion of straight forward doesn't have a meaning here 01:36:57 heycam: if we want 'h' to mean head forward 01:37:06 ... then it makes sense for zero degrees to mean in the positive x axis 01:37:30 krit: we use always x axis for rotation 01:37:35 ... but bearing is usually looking north 01:37:42 ... e.g. negative y axis 01:37:55 heycam: unless we want the initial bearing value to be non zero 01:37:57 \me 'v' is Veer left, or Venestre ? 01:38:15 ... then we couldn't have zero degrees meaning upwards 01:38:21 ... and lower case 'h' to mean go to the right 01:38:47 krit: can this be combined with cubic and quadratic curves? 01:38:51 heycam: I've defined it so that it does 01:38:57 ... all points are rotated around the origin 01:39:06 ... for straight line segments and quadratics and cubics 01:39:13 ... the point gets rotated 01:39:23 krit: it's changing the co-ordinate space 01:40:50 heycam: you can't build up a path in Direct2D and apply a transform half way through 01:41:07 ... I've described in the respective sections what it means to have the transform applied 01:41:43 heycam: if you look at the cubic bezier command section for example, I added a paragraph detailing how the control points are transformed 01:41:53 cyril: what are the consequences on animate motion? 01:42:05 heycam: it's the same as if you have two line segments 01:42:19 ... where we might have to think about it is with the methods that give a path segment that is a particular length 01:43:06 heycam: I think it makes sense for the default to be zero, and that to be in the positive x axis 01:43:22 cyril: do you think it should be normalised? 01:43:27 heycam: good question, I guess it should 01:43:42 cyril: what about path morphing? Should have no effect right? 01:43:51 ... you normalise first then you apply 01:43:56 ... by morphing I mean path animation 01:44:07 ... so do you require a 'b' to match up with a 'b'? 01:44:11 heycam: I think so 01:44:18 ... you want to animate the 'b' 01:44:37 heycam: the other part of the discussion I wanted is 01:44:46 ... the best way to get a bearing relative elliptical arc 01:44:50 ... haven't added this to the spec yet 01:45:11 ... the last thing we came up with in Switzerland was to add the two arc commands that canvas has 01:45:18 ... maybe with long names since we're running out of letters 01:45:24 ... we can still do that 01:45:58 ... but I don't think the canvas arcs are good for doing an arc from the current position in a given direction 01:46:08 ... I wrote up a couple of options for doing that in a text file 01:46:24 TabAtkins: we also wanted to add in one of the arc commands from paper.js 01:46:34 ... where you give two points that are on the arc 01:46:43 ... three points in total 01:46:46 http://pastebin.com/se55bMW3 01:47:10 ... the 'i' command does a circular arc in the given direction for a certain number of degrees 01:47:43 i 01:47:44 = circular arc with the given radius, beginning in the current bearing 01:47:44 direction, drawing degrees of the circle, defaults to going clockwise 01:47:44 e

01:47:44 = elliptical arc with the given radii, beginning in the current bearing direction, 01:47:45 as if you were already around the ellipse, going to , 01:47:45 defaults to going clockwise 01:48:07 heycam: I was thinking of having two commands. One for circular, one for elliptical 01:48:30 ... the circular arc (i) goes fowards from the current position in the current direction with a radius and a certain number of degrees 01:48:44 ... the elliptical version takes the x and y radius 01:48:51 ... you also have to specify the start angle 01:49:12 ... might not be so useful but included for completeness 01:49:19 TabAtkins: the i command makes it easier to do corners for example 01:49:30 ... h, i 90 degrees 4 times 01:49:42 heycam: the current bearing never changes unless you give a 'b' command 01:50:06 ... so you'd do "h i 90 degrees b 0 (zero degrees off previous arc command) h " and so on 01:50:30 cyril: with 'e', why do you need a start angle? 01:50:39 heycam: you need to know where around the elliptical arc you are 01:50:45 cam draws on whitebaord 01:50:55 TabAtkins: basically because ellipses aren't radially symmetric 01:51:26 heycam: the angle is the angle around the arc, not the initial bearing 01:51:52 shepazu: if you're making a pie chart, is the initial angle always going to be 90 degrees? 01:51:58 TabAtkins: this command isn't great for making a pie chart 01:52:01 heycam: it's good for pie charts 01:52:09 ... maybe not as good as the canvas one with the center point 01:52:19 ... you can move the the center point, then bear in whatever direction 01:53:27 ... "m 100,100 b -90 h 40 b 90 i 20 0 b 90 h 40 " 01:53:30 ... then some more 01:53:40 cyril: why do you need the 'b 90' ? 01:54:14 heycam: you turn 90 degrees at the end of the upwards line 01:54:26 shepazu: I like the idea of being able to do angles in svg finally 01:55:09 Hmm, bearings help a little bit with pie charts, but only if you're drawing all the segments in one go. 01:55:24 heycam: one thing with these two circular elliptical and bearing path commands is that there is no natural absolute version of these commands 01:55:41 ... you could make it so that with the abs version you don't do the rotation of the bearing 01:55:46 ... but it's unlikely you would use it 01:55:49 You need the Canvas arc command to do pie segments separately in an easy way. 01:56:07 SO MANY ARCS NECESSARY 01:56:09 shepazu: this introduces angles into SVG 01:56:20 ... I'm wondering is this a pattern we are going to duplicate? 01:56:26 ... are there other places we could use angles? 01:56:34 ... is this a suitable precedent to follow? 01:56:45 wonsuk has joined #svg 01:57:06 TabAtkins: does the star element use angles? 01:57:12 shepazu: it doesn't 01:57:23 heycam: I was wondering whether zero degrees should be positive x? 01:57:32 TabAtkins: I can't find a decent way to make proper bearing angles easy to use 01:57:40 ... so I think we go with the current proposal 01:57:46 heycam: I like how 'h' can be thought of as move ahead 01:58:30 ... if anyone have any better ideas for bearing relative arc commands let me know 01:58:48 ... otherwise I'll add lower case 'i's and 'e's 01:59:01 TabAtkins: not bothered about absolute commands 01:59:51 heycam: 'b' and lowercase 'i' and 'e' break pattern of last value of command is the ending co-ordinate 02:00:00 ... don't think that's a problem 02:00:25 I honestly didn't even realize that was a pattern. 02:00:42 heycam: question of what to do with the SVG dom? 02:00:49 ... new path seg interface derivatives? 02:00:55 ... probably no 02:01:08 birtles: would you even add this feature to the old svg ? 02:01:10 heycam: ideally not 02:01:24 heycam: just like with transforms we do have to define what happens if you use them 02:01:33 ... can do the same thing as transforms 02:01:55 ... should markers be painted at the b? 02:02:00 heycam: I think no 02:02:03 TabAtkins: agree 02:02:12 cyril: no, they don't introduce a segment 02:03:11 cyril: a colleague of mine edited some path commands, where should I put it? 02:03:17 heycam: mail it? 02:03:39 Topic: SuperPath commands 02:03:43 cyril: a colleague of mine edited some path commands, where should I put it? 02:03:46 heycam: mail it? 02:06:25 cyril: the idea is to have 'p' for referring to a path 02:07:02 http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDec/0055.html 02:07:42 cyril: we are proposing two commands, with absolute and relative 02:07:54 ... the piece command takes a url fragment 02:08:13 ... draws a sub path from the current point using the commands from the referenced fragment 02:08:34 ... r draws the referenced path backwards 02:09:11 krit: so the path needs to be in the same document 02:09:25 ... the syntax is not clear about that 02:09:28 cyril: iri is defined 02:09:41 krit: iri is defined to be url and then iri 02:09:50 cyril: but if the url is not there then it is a fragment to the current document 02:09:56 ... don't think we want to allow the url 02:10:13 heycam: I would like to use ids for reference in current document, not iri 02:10:46 cyril: so in the syntax the '#' would be removed 02:10:54 cyril: can you have spaces in ids? 02:11:07 birtles: I don't like ids, but we can come back to that 02:11:21 krit: how do you differ between the different command without '#' 02:11:26 ... could be the pr command for example 02:11:40 ... having # would be a delimiter you could detect 02:12:48 krit: we aren't strict about spaces or comments 02:13:20 ... I think you want to make it clear that it's a reference 02:13:32 heycam: I think it's only a problem if we have the repeated parameter thing 02:13:55 thorton has joined #svg 02:14:26 cyril: the difficulty here is how you draw a reverse path 02:14:35 ... usually you have the ending point and then the following points 02:15:02 ... if you reverse a quadratic bezier the first point isn't given in the command 02:15:22 ... have added some notes in the text 02:15:46 ... see annotation 5 02:16:11 cyril draws on the board 02:18:40 shepazu: someone told me (maybe David Dailey) that he heard feedback that the super path thing turns out not to be the solution for mapping that they thought it would be 02:18:55 ... because when you normalise paths the differences aren't significant 02:19:03 ... could you communicate with David Dailey about this? 02:19:15 krit: the proposal doesn't say how to deal with dash-array especially with shared paths 02:19:18 cyril: I know 02:19:32 krit: many implementations can't do it at the moment 02:19:44 krit: I'd like it added as 'at risk' from the beginning 02:19:54 ... I don't think it will be implemented in the next version of browsers 02:20:33 heycam: I think all features will be assessed when going to CR 02:20:45 shepazu: it gives a lack of confidence marking as at risk initially 02:21:22 ... implementers won't even look at it if it's marked as 'at risk' 02:21:31 ... we can always mark it at last call 02:21:42 heycam: especially since it's in the list of requirements 02:22:00 cabanier: Flash was never able to fix stroking on edge lists 02:22:03 ... it always looked bad 02:22:25 ... what happens with end caps, etc? 02:22:42 cyril: the model we had in mind was to copy all the paths as if they were specified there 02:22:51 heycam: this doesn't address shared edges 02:23:39 cyril: this isn't trying to address the problem of having touching objects 02:23:47 ... it's for maths 02:24:04 ... you just say you have a common path between two objects 02:24:32 shepazu: if I have two states on a map that are adjacent 02:24:44 ... in that case, this proposal says they have a shared line 02:24:55 ... and it's referenced in the syntax 02:24:56 s/it's for maths/it's for maps/ 02:26:22 heycam: this does give you information about which pixels are completely covered 02:26:33 ... the underlying graphics libraries aren't going to give us the facility to make use of that 02:26:43 shepazu: That might be the essence of what David Dailey was alluding to 02:27:22 cyril: we're not changing how the rendering is working 02:27:31 ... it's just for syntax 02:27:41 krit: the idea of super paths was to have shared edges 02:27:48 cyril: that's not what I was thinking 02:28:15 ... it's adding semantics to the document so that path data can be re-used 02:28:28 .. with animations applied, etc 02:28:37 krit: I don't think this is the real requirement of super paths 02:28:47 shepazu: I'd like to point out another thing that troubles me 02:28:59 ... that is, for me it's common when I'm using a map that I 02:29:05 ... might pull out a particular shape 02:29:15 ... e.g. pull out Germany from a map of Europe 02:29:26 ... if I do that now it's got it's own shape 02:29:36 ... with this I have to follow the reference 02:29:44 ... we already have an API for that 02:30:00 cyril: I was thinking we could import the points into the normalised version 02:30:30 shepazu: the authoring experience is made more complicated with references 02:31:02 heycam: in your example you are referencing p1 02:31:23 ... if case of commands was different what would be the effect? 02:32:09 cyril: if the path you are referencing uses relative commands then those commands are relative to the last point before the referenced path 02:32:16 ... and if the path uses absolute commands then they're absolute 02:32:34 heycam: does that mean, if you had a mix of absolute and relative, that segment sizes would be different for the same re-used path? 02:32:36 cyril: yes 02:32:54 cyril gives example 02:33:08 thorton has joined #svg 02:33:22 cyril: we kept small 'p' and small 'r' because all existing commands had two versions 02:33:25 ... but they're useless 02:34:04 krit: 'r' is reserved 02:34:08 cyril: call it 'x' 02:34:40 heycam: could you enumerate the problems? 02:35:00 cyril: I heard it's not solving all the problems 02:36:01 cyril: I'd like to add it to the spec for further discussion 02:36:03 heycam: I'm ok with that 02:36:41 ACTION: cyril to add piece commands to SVG 2 specification 02:36:41 Created ACTION-3546 - Add piece commands to svg 2 specification [on Cyril Concolato - due 2013-11-22]. 02:41:02 mgylling has joined #svg 02:58:43 mgylling has joined #svg 03:03:10 kurosawa has joined #svg 03:07:01 scribenick: someone else 03:07:05 Zakim, who is on the call? 03:07:05 On the phone I see Huangshan, TabAtkins 03:08:30 -Huangshan 03:08:50 >_< 03:09:11 Zakim, call Huangshan 03:09:11 ok, heycam; the call is being made 03:09:14 -TabAtkins 03:09:14 +TabAtkins 03:09:15 +Huangshan 03:10:12 Scribe: Cameron 03:10:15 ScribeNick: heycam 03:10:18 Topic: Filter effects 03:10:26 http://dev.w3.org/fxtf/filters/ 03:10:37 http://dev.w3.org/fxtf/filters/#issues-index 03:10:38 I lied, I can't hear anything but an occasional burst of voice. 03:11:18 cyril has joined #svg 03:11:25 krit: first issue is xlink attributes 03:11:30 ... we have it on most elements 03:11:33 ... which did we decide to remo e 03:11:34 Note that that #issues-index section is auto-generated by Bikeshed. Yet another reason to switch! 03:12:42 heycam: we should remove all except xlink:href 03:12:48 ... then do the thing we planned to do with introducing href 03:12:57 krit: can we agree on removing those other attributes? 03:13:00 cabanier: yes 03:13:16 s/remo e/remove/ 03:13:48 RESOLUTION: Remove all xlink attributes apart from xlink:href from Filters. 03:14:14 krit: next issue is something I'd like to discuss at the next F2F 03:14:16 ... then, issue 3 03:14:44 ... the text is saying that xlink:href="" is an IRI to something within the current SVG document fragment 03:14:51 ... this limits filters to only the current document 03:14:59 ... I think Filter is the only thing restricted like this 03:15:02 ed: gradients does this too 03:15:10 ... only for inheriting definitions of gradients 03:15:12 isn't it the 10th time we resolve on removing xlink:href ? 03:15:41 krit: does Firefox implement this? 03:15:45 birtles: I think it may 03:15:52 krit: for WebKit and Blink I'm pretty sure we don't 03:16:14 krit: do we want to deprecate it? 03:16:19 ed: cleaner just to remove it? 03:16:43 heycam: I don't see it as very useful for 03:16:53 ed: it's of very limited use 03:17:43 heycam: I've never liked this inheriting pattern 03:17:49 krit: Inkscape uses it for gradients 03:17:57 ... it doesn't for filters 03:18:30 ed: I wanted to lift the restriction at some point, but the feature isn't that useful 03:18:42 ed: and we decided to keep it limited, since we want to remove it 03:19:10 krit: I won't implement it in WebKit and Blink 03:19:38 heycam: it's probably all right for us to remove it then 03:19:56 RESOLUTION: Remove from Filter Effects. 03:21:23 krit: issue 4, discuss at next F2F 03:21:28 ... issue 5 is difficult to discuss without Chris 03:22:05 it's about this in the spec: 03:22:08 Unless otherwise stated, all image filters operate on premultiplied RGBA samples. Some filters like , and work more naturally on non-premultiplied data. For the time of the filter operation, all color values must temporarily be transformed to the required color multiplication of the current filter unless stated differently on the particular filter primitive. 03:22:18 krit: I think the last part doesn't matter, since none of the primitives have special handling 03:22:27 ... they all require one of the colour spaces 03:22:37 ... the input must be in premultipled or non-premultiplied 03:22:45 ... I think the last sentence is confusing 03:23:19 ... I just want to remove the "unless ..." 03:25:12 ... the issue is incorrect, it's nothing to do with color space 03:26:17 cabanier: [asking about sepia] 03:26:20 krit: that would be a separate issue 03:26:44 krit: next issue 6 03:26:50 ... "Why is SourceGraphic drawn into a fixed linear RGB?" 03:27:07 ... SourceGraphic takes the parent object, why do you need to draw it into a temporary buffer in linearRGB? 03:27:14 ... why can't you change it to something different? 03:27:23 ... would like to get some input from Chris 03:27:32 ... Issue 7 03:27:47 ... the FillPaint and StrokePaint allow you to reference the fill/stroke of the element you're filtering 03:27:56 ... and use these fill or paint servers as generated input images 03:28:07 ... the question is, it's not really defined how you actually use them 03:28:22 ... you can have FillPaint referencing a paint server, like a pattern, and that can be userSpaceOnUse or objectBoundingBOx 03:28:31 ... the objectBoundingBox of what? the element that is filtered? 03:28:43 heycam: I'd say the bounding box of the thing it's targeting 03:28:46 krit: that would make sense 03:28:53 ... but the spec doesn't say 03:29:20 ... if the paint server is drawn using objectBoundingBox, then it should use the boundign box of the element being filtered 03:29:49 ed: the alternative would be the filter region 03:30:17 RESOLUTION: FillPaint/StrokePaint objectBoundingBox should be relative to the bbox of the filtered element. 03:30:30 krit: issue 8 03:30:36 ... which coordinate space for userSpaceOnUse? 03:30:48 ... if you have a paint server with userSpaceOnUse, which user space to use? 03:31:17 ... the filter can be in an SVG element that has a different viewport from the filtered element 03:31:37 heycam: I think again it only makes sense to use the filtered element's user space 03:31:39 ed: I agree 03:31:54 RESOLUTION: FillPaint/StrokePaint userSpaceOnUse should use the coordinate space of the the filtered element. 03:31:58 krit: skip issue 9 03:32:07 ... issue 10, we discussed this multiple times before 03:32:11 ... we have different subregions 03:32:33 ... should the input of the filter prmitive be clipped, the output clipped, both? or not at all? 03:32:41 ... the spec really says you should clip the output 03:32:45 ... implementations are inconsistent 03:33:07 ... you can't test what they implement, since it's hard to figure it out; it doesn't matter in most cases 03:33:12 ... would be good if we define which we use 03:33:15 ... just pick one 03:33:22 ed: if it doesn't make a big difference, why do we need to define it? 03:33:42 krit: it does make a difference, but it's hard to test -- it depends on the particular filter operator 03:34:24 heycam: what was the outcome of the previous discussion? 03:34:32 krit: we talked about clipping both 03:34:35 ... but that is the most limiting 03:34:41 ... do we want to change this? or keep it as it is? 03:35:11 heycam: I say just keep our previous decision 03:35:17 shepazu has joined #svg 03:35:17 ed: alternative is to add some control over it 03:35:21 krit: don't think that's necessary 03:35:34 RESOLUTION: Filter primitives will clip both input and output. 03:35:42 krit: issue 11 03:35:54 ... should we add all remaining blend modes from Compositing? 03:36:07 ... feBlend has certain blend modes 03:36:11 ... Compositing has more 03:36:13 ... do we backport them? 03:36:30 heycam: I think so 03:36:32 ed: yes 03:36:50 krit: I'd like to have a wiki page with all features that aren't in Filters but we might want to deal with in the next level 03:37:07 ... I'd like to defer these to the next level 03:38:38 krit: there was also a request to backport all the Compositing modes from that spec to feComposite 03:38:54 ... but we removed compositing from CSS 03:39:04 nikos: the extended porter-duff isn't in level 1, deferred to level 2 03:39:12 cabanier: but it is in there for canvas 03:39:20 ... you can do all the porter duff with the current keywords 03:39:41 ... so I think you should just close this issue 03:39:52 shepazu: whenever I talk to developers/designers, who really want compositing 03:39:59 ... what was the rationale for deferring this? 03:40:05 krit: they really want blending, rather than porter duff 03:40:16 shepazu: what was the rationale for not putting it into this level? 03:40:31 cabanier: it was impossible to implement in the way that you expect it 03:40:33 ... we're working on it 03:40:41 ... I think the browsers are all upgrading their compositors 03:40:49 ... we still get pushback because it's much more complex than it first seems 03:41:11 ... but we're slowly moving towards getting it working 03:41:16 nikos: and the blend modes have been implemented 03:41:46 shepazu: what's the timeframe for porter duff? 03:41:59 cabanier: we'll start working on the level 2 spec as soon as this one goes out 03:42:08 cabanier: for blink, it'll probably be 1 year out 03:43:22 cabanier: it's not technical issues, but it's convincing people 03:43:25