07:25:14 Tav has joined #svg 08:01:39 nikos has joined #svg 08:12:14 shepazu has joined #svg 08:21:22 nikos has joined #svg 08:32:24 Chair: Cameron 08:32:33 Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda 08:33:33 Meeting: SVG WG London F2F 2014 08:34:09 scribeNick: krit 08:34:50 topic: Getting rid of uses of const enums in SVG DOM 08:35:04 ed: Ties in tinto disucssion yesterday 08:35:15 ed: would get rid of const enums from SVG DOM 08:35:22 ed: might fall out of SVG DOM removal 08:35:40 ed: I prefer replacing it by simple DOMStrings 08:35:55 ed: I am concerned about new units getting new values 08:36:02 ed: we did not expose these new values 08:36:26 ed: this causes complexity in implementation. which values are exposed, which aren't 08:36:52 ed: do we want do wait until we experimented with removing SVG DOM first? 08:37:01 heycam: would be interesting what is kept 08:37:57 heycam: SVGTransform has individual enums as does SVGPath 08:38:08 heycam: interested if they are used and useful 08:38:11 krit: no 08:38:34 ed: there are convertTo methods on SVGLength for instance 08:38:40 ed: same for SVGAngle and others 08:38:56 heycam: preseverveAspectRatio 08:39:14 konno has joined #svg 08:39:15 krit: filters have a lot of these enumeration 08:40:26 tkonno has joined #svg 08:40:37 heycam: we should keep SVGLength around every though we remove SVGAnimated objects 08:40:38 http://www.w3.org/TR/SVG/types.html#__svg__SVGLength__convertToSpecifiedUnits 08:40:46 krit: don’t think that there is 08:40:58 heycam: there are some conversions used in SVGLength 08:41:16 krit: point is, people just convert to px 08:41:31 heycam: If you are able to remove SVGLength all together then…. 08:41:54 krit: we should discuss enums in isolation from SVG DOM removal 08:41:56 heycam: yeah 08:42:08 ed: should we do it in addition? 08:42:16 heycam: in addition would be easy 08:42:23 heycam: we could have type() 08:42:33 heycam: and take then IDL enum type 08:43:01 ed: I added a unit turn to SVGAngle which is not exposed as an enum value in Blink 08:43:36 krit: for SVGLength alone we have a huge amount of new units 08:44:04 krit: which enumerations are you thinking about? In all IDL files or all of them? 08:44:09 ed: everywhere 08:44:16 ed: and use new unit types 08:44:42 ed: also, there is no way to know if an implementation is supporting certain units 08:45:28 heycam: could create a new SVGAngle object 08:45:36 heycam: and apply “7turns" 08:45:53 heycam: and look at the unit less value and look if it is 7 08:45:55 Tav has joined #svg 08:46:06 krit: for a short term it is reasonable 08:46:49 heycam: I wonder how many improvements should we do before knowing if we remove SVG DOM or not? 08:47:26 krit: Implementations removing SVG DOM now, obviously don’t need to care. The spec can still be ahead and change SVG DOM in case experiment fails 08:47:59 ed: we have the existing method take a number or string 08:48:38 ed: can you have multiple types on a property with WebIDL? 08:48:40 heycam: yes 08:49:03 http://dev.w3.org/SVG/proposals/improving-svg-dom/#enumerations 08:49:12 krit: sure you want a string and not a enum value in the sense of WebIDL 08:49:19 heycam: I think you do 08:49:41 krit: they are still basically string with special exception handling 08:49:48 ed: yes, that is what i want 08:50:01 heycam: still wonder if it is worth to do now 08:50:31 ed: I think it is ok to have it in parallel 08:50:52 heycam: if we need to keep the object around and have new stuff…. 08:51:03 heycam: .. in my proposal I had a hard cut 08:51:16 heycam: I suppose it makes sense if we need to keep SVG DOM 08:53:03 ed: I would still go ahead with both,… experimenting with removing SVG DOM and implement the new enum 08:53:33 krit: so you suppoty old enums and the new? where is the benefit for you? complexity stays? 08:54:17 ed: so I will probably remove the old const enums and replace it with new enums 08:54:36 krit: if you break the old one… do you think it is worth still having enums at all? will ppl move over? 08:54:55 ed: seeing where the experiment goes probably makes more sense 08:56:15 ed: ok, I’ll bring up the topic again 09:06:47 topic: Raw cubic bezier coordinate list accessors 09:08:08 birtles: proposal was to add a method to get the points of a path as an array of dicts 09:08:23 birtles: we talked about details in the past… open vs closed paths 09:08:30 ChrisL has joined #svg 09:08:32 birtles: tow motivations: simplicity 09:08:37 birtles: and performance 09:08:55 birtles: in many implementations there is a perf hit from switching from JS to native code 09:09:22 birtles: with Cameron’s DOM we get a bunch of dict objects as an array 09:09:35 birtles: performance is less significant 09:09:44 Tav: can you handle arc? 09:09:49 birtles: approximations 09:09:57 birtles: didn’t work out on details 09:10:03 Tav: how about markers 09:10:15 birtles: doesn’t take markers into account just path data 09:10:32 birtles: same data structure for setting and getting on path generation 09:11:14 heycam: are there perf improvements with using types instead of arrays? 09:11:16 birtles: no 09:11:57 birtles: I can still shim and implement it 09:12:10 heycam: do you have comparisons between my proposal and yours? 09:12:18 birtles: we can do that fairly easy 09:12:26 birtles: seems worth while investigating 09:12:33 oslego has joined #svg 09:12:36 birtles: question if we bother at all 09:12:44 heycam: think it is reasonable 09:13:08 heycam: think the normalization is nice 09:13:50 birtles: we also do not implement normalized path segments in Mozilla 09:13:55 ChrisL: why? 09:14:11 krit: heycam: difficult to keep live objects in synch 09:15:01 birtles: also, it is an array of arrays 09:15:30 birtles: because of subpaths 09:19:22 krit: I think for normalization you don’t care too much about precise results, but you want to have the same amount of segments with the same order 09:19:43 krit: that is where Opera Presto and WebKit behave totally different sometimes 09:20:44 shepazu: we should say how a basic shape transforms into a path 09:20:51 heycam: I didn’t do that yet 09:21:12 Tav: we had the discussion at least 09:21:13 Rossen_ has joined #svg 09:21:42 krit: didn’t you do that for dash array heycam ? 09:21:45 can somebody let me into the bldg please 09:21:51 heycam: yes, it would be a reason to support it 09:23:35 shepazu: do you have anything about animating shapes? 09:23:41 birtles: no don’t want to do that 09:24:18 s/no don’t want to do that/really do want to do that/ 09:25:49 shepazu: we are not going to make it perfect :) 09:26:02 shepazu: lets pick it up another time 09:27:13 http://tavmjong.free.fr/blog/?p=741 09:27:23 action birtles Try implementing path data array and get performance numbers 09:27:23 Created ACTION-3645 - try implementing path data array and get performance numbers [on Brian Birtles - due 2014-08-30]. 09:28:06 ISSUE: look into shape morphing 09:28:06 Created ISSUE-2461 - Look into shape morphing. Please complete additional details at . 09:28:28 ACTION: Make topic scripts capture actions and issues too. 09:28:28 Error finding 'Make'. You can review and register nicknames at . 09:28:31 ACTION: Cameron Make topic scripts capture actions and issues too. 09:28:32 Created ACTION-3646 - Make topic scripts capture actions and issues too. [on Cameron McCormack - due 2014-08-30]. 09:38:45 https://stackoverflow.com/questions/9489736/catmull-rom-curve-with-no-cusps-and-no-self-intersections/23980479#23980479 09:41:32 tkonno has joined #svg 09:42:43 ACTION: Cameron to add math for Catmull-Rom curves to the spec 09:42:43 Created ACTION-3647 - Add math for catmull-rom curves to the spec [on Cameron McCormack - due 2014-08-30]. 09:42:47 ACTION-3647: https://stackoverflow.com/questions/9489736/catmull-rom-curve-with-no-cusps-and-no-self-intersections/23980479#23980479 09:42:47 Notes added to ACTION-3647 Add math for catmull-rom curves to the spec. 09:49:19 ACTION-3640: This should be done for symbol, marker and foreignObject. 09:49:19 Notes added to ACTION-3640 Add |symbol { overflow: visible; }| to the ua style sheet and add authoring suggestion to say to design symbols around (0,0). 09:50:59 nikos has joined #svg 09:53:36 -- actions session -- 10:05:22 nikos has joined #svg 10:10:45 jwatt has joined #svg 10:44:25 ChrisL has joined #svg 10:45:29 tkonno_ has joined #svg 10:48:41 Rossen_ has joined #svg 10:51:14 nikos has joined #svg 10:54:32 jwatt has joined #svg 11:06:01 RRSAgent, make minutes 11:06:01 I have made the request to generate http://www.w3.org/2014/08/23-svg-minutes.html heycam 11:06:08 fg 11:09:45 bg 11:10:18 ^C^C^C 11:42:23 nikos_ has joined #svg 12:50:23 heycam has joined #svg 13:55:47 tkonno has joined #svg 14:00:06 heycam has joined #svg 14:09:48 issue-59? 14:09:48 Sorry, but issue-59 does not exist. 14:10:09 issue-58? 14:10:09 Sorry, but issue-58 does not exist. 14:11:59 nikos has joined #svg 14:13:44 tkonno has joined #svg 14:17:01 scribenick: cabanier 14:17:17 topic: Catmull-Rom 14:17:49 cam: I added a section on Catmull-rom to the spec 14:17:53 Rossen_ has joined #svg 14:18:45 heycam has joined #svg 14:18:57 s/cam/heycam 14:18:59 https://svgwg.org/svg2-draft/paths.html#PathDataCatmullRomCommand 14:19:23 ... syntax wise, I added just what Doug's polyfill said 14:19:28 ... you need 3 coordinates 14:21:07 ... the curves take a sequence of point and the path goes from the second control point to ??? 14:21:41 shepazu: in my implementation, the first point is the moveto and the last 2 points are the same 14:22:08 ... technically it needs an extra control point 14:22:50 (lots of discussion at the whiteboard) 14:24:28 shepazu: I suggest that we have 2 point 14:25:07 heycam: I think it should be a minimum of 1 point 14:25:18 shepazu: then it should be a line 14:25:59 ... I agree that it should only be 1 point 14:26:09 nikos_ has joined #svg 14:26:28 heycam: the spec at the moment, if the previous is a moveto... 14:26:47 ChrisL: I think there should be a minimum of 2. (draws on whiteboard) 14:27:51 ... you always need 4 points 14:28:10 ... you always go between 2nd and third point 14:28:21 ... you make up first and last by doing the tangent 14:28:31 ... you always start drawing from the first point 14:28:43 .... you can do a fictitious last point 14:28:58 shepazu: the point you start from is the last point from the previous 14:29:03 heycam: it's the current point 14:29:07 ChrisL: yes 14:29:17 ... currentpoint is inferred 14:29:27 ed: what would it look like if you do a circle 14:29:46 Tav: would 4 points make a circle? 14:29:53 shepazu: I don't think so? 14:30:04 Tav: how do I close the path? 14:30:26 ChrisL: closepath will be a straight line 14:30:38 ... to do it smoothly we need a different symbol 14:30:45 ... which is a new requirement 14:30:51 shepazu: I don't agree 14:31:00 ... that is not the point of this 14:31:30 ChrisL: suppose you draw a set of CR pieces, he wants a new command that does the continuity 14:32:56 q+ 14:33:30 shepazu: so, I understand what Tav is asking for but I'd rather not take on that requirement since it makes the model so complex 14:33:41 ... you can do it. we don't have it for beziers 14:33:54 ChrisL: I don't agree. you just get the data differently 14:34:12 shepazu: I would like to split it into 2 different issues 14:34:27 ... CR and the issue of soft closing 14:34:58 ... I can see a reasonable additional command that closes smoothly 14:35:20 ... for instance 'y' and possible reuse the catmull rom algorithm 14:35:50 ... we rejected tangient parameter to keep it simple 14:35:58 ... we just want point 14:36:23 RRSAgent: q+ 14:36:23 I'm logging. I don't understand 'q+', krit. Try /msg RRSAgent help 14:36:28 Tav: in order to make a closed path you might need to choose 14:36:31 Zakim, q+ 14:37:38 ... given a circle a, b,c,d you may want to consider point d to do a smooth close to point a 14:38:02 ... you might want to consider d to a, to draw a to b 14:38:22 shepazu: why do you want it to be a circle? 14:38:33 tav: I don't. it can be any shape 14:38:58 shepazu: rather than treat this a catmull-rom curve, let's call this a smooth closed path 14:39:21 ... and it would act differently if it was a bezier 14:39:27 ChrisL: not quite 14:39:36 q+ 14:39:55 shepazu: catmull rom is the only one where the previous point changes the next point 14:40:26 q+ 14:40:36 (more heated discussion) 14:41:41 heycam: if you have beziers it's not always possible to calculate the point 14:41:59 krit: why does inkscape need it? 14:42:04 Tav: it doesn't 14:42:19 krit: as an implementor, I don't need this and wouldn't implement 14:42:30 ChrisL: are you making an informed decision? 14:42:46 krit: can you do it today with bezier? 14:43:15 ChrisL: given an arbitrary sequence of points can you today make a smooth curve through them? 14:43:29 heycam: yes, we can use beziers. 14:43:39 ChrisL: and the group agreed to do it 14:43:50 krit: that doesn't really matter. 14:44:06 ChrisL: so you don't want new features in SVG? 14:44:09 The circle of Tav https://onedrive.live.com/redir?resid=DA0535041C44EB4D!26327&authkey=!AL_LeXmaTwrSbZc&v=3&ithint=photo%2cjpg 14:44:13 krit: I didn't say that? 14:44:33 ChrisL: are you opposed to new features 14:45:15 jwatt: are you against bezier curves? 14:46:25 Tav: it's about authors just doing smooth graphs 14:46:48 ... and I'm against it because it will be used incorrectly 14:47:02 ChrisL: people can do a lot of things wrong 14:47:30 krit: is catmull rom the best algorithm? 14:47:35 ... it's the most known 14:47:45 shepazu: and the easiest to do 14:48:15 ... but it's not trivial to do 14:48:37 krit: but you can do it with bezier unlike with line to approximate beziers 14:49:16 shepazu: I'd like to stay with the resolution that we'll implement this 14:49:32 ... everytime I mention this, people like it 14:49:43 ... authors have asked for this 14:50:02 ... what is the point of your objection? 14:50:30 ... if you have a better implementation, please put it forward 14:50:43 krit: I think we have primitives to do this. 14:51:03 shepazu: let's not waste f2f time on this 14:51:23 krit: there's no proposal. 14:51:38 ... we've discussed this many times already 14:52:03 shepazu: that is inaccurate. you're trying to knock us back 14:52:15 ChrisL: we have a formula and a couple of issues 14:52:27 heycam: I think we should talk about the issues 14:52:44 shepazu: the smooth close path is a separate issue 14:52:50 ChrisL: agreed 14:53:24 shepazu: I would be ok to do a smooth closed path command 14:54:16 Q= to propose solutions to the issues in 9.3.8 14:54:16 tav: inkscape has that problem, but I don't want to distract 14:54:26 q+ to propose solutions to the issues in 9.3.8 14:54:50 ... a smooth bezier to catmull-rom transition 14:55:20 ... you can get the first point from the handle 14:56:14 ChrisL: I propose that we'll just address the issues 14:56:28 ... should we add a tension parameter? 14:57:29 resolution: Catmull-Rom will not add a tension parameter and will stay with the standard 14:58:04 RESOLUTION: Catmull-Rom will not add a tension parameter and will stay with the standard parameters 14:58:40 ... should we allow less than three coordinate pairs? 14:58:59 heycam: if you're building up a path, you need them 14:59:15 http://schepers.cc/svg/path/dotty.svg 14:59:22 ChrisL: as long as we define what it is so we don't get degenerate behavior 15:00:25 ... one point is a straight line from the current point 15:00:38 ... two points will give you a smooth curve 15:03:47 RESOLUTION: the r command will take at mimum 1 coordinate pair that will draw a straight line 15:04:14 ChrisL: issue 8 is no longer a problem then 15:04:43 .... the moving without drawing anything was solved by the previous resolution 15:04:53 (for reference, issue 8 was: "Is it a problem that the command will move then pen from the current position to (x1, y1) without drawing anything? If so, should we made the first control point explicit in the command rather than implicitly taken from the current position? That would then mirror the behavior written above for how the current position is left at the second-last control point.") 15:04:56 heycam: I think it's more about having the implicit points 15:05:32 ChrisL: we now move what multiple r commands means 15:05:50 ... a single r with give you continuity 15:06:10 ... by having multiple ones, you will not get the continuity 15:06:55 shepazu: I don't really like that. it's a bit confusing 15:07:16 ChrisL: if it didn't have that behavior it would act as if it was one command 15:07:34 heycam: I think I prefer that each r is its own smooth curve 15:07:49 Tav: bezier to catmull rom needs a way to break it 15:08:09 ChrisL: can we agree that we don't get continuity 15:08:33 heycam: a new r command will not be continuous with the previous? 15:08:38 shepazu: I agree with that 15:09:26 RESOLUTION: multiple R commands will not have curve continuity between them 15:10:34 ChrisL: issue 9: Where should we link to for a definition of Catmull-Rom curves so that we don't have to redefine them here? 15:10:51 ... there's a wikipedia with the math 15:10:59 heycam: there were a couple of different options 15:11:21 http://en.wikipedia.org/wiki/Centripetal_Catmull%E2%80%93Rom_spline 15:11:25 ... mostly about the implicit begin and end points 15:11:43 Tav: they're mostly about how to avoid loops 15:12:29 ChrisL: I propose to use the Centripetal one from the wikipedia article 15:12:48 heycam: I think that's a good idea 15:13:09 ... I'm going to read up on it 15:14:19 ... do we want the formulation that doesn't introduce the loops and cusps? 15:14:47 https://stackoverflow.com/questions/9489736/catmull-rom-curve-with-no-cusps-and-no-self-intersections/23980479#23980479 15:14:49 RESOLUTION: catmull-rom will use the formula that doesn't introduce the loops and cusps 15:16:15 Tav: the wikipedia with the six votes is the one we want 15:16:42 s/wikipedia/stackoverflow/ 15:17:46 shepazu: can we also put in the spec on how to deform this to beziers? 15:18:14 heycam: we don't have to do that 15:19:37 ... informally, it might be good to have it 15:19:58 shepazu: can we call it 'p' instead of 'r'? 15:20:09 heycam: it doesn't really matter 15:20:11 ChrisL: sure 15:22:20 jwatt: I want more than one letter 15:22:33 ChrisL: people don't really care 15:22:55 heycam: people will just fiddle with it 15:23:07 RESOLUTION: the name of the Catmull-Rom command is 'p' reflecting 'points' 15:24:33 heycam: one final issue is that we should decide that we get the implicit points from the tangent 15:24:41 shepazu: wasn't there a good pdf? 15:24:51 ChrisL: yes, I will drop it in 15:24:52 http://www.cemyuksel.com/research/catmullrom_param/catmullrom.pdf 15:25:18 heycam: this does limit the set of curves that you can produce 15:25:46 shepazu: I would contend that you're not looking for precision but convenience 15:26:00 heycam: that's reasonable 15:27:16 ... so, at the start of the p command and the previous is a curve, how do you determine the preceding point? 15:27:53 ... if it's cubic or quadratic, since we have the control point, we will use that 15:28:27 ... if we don't, we continue the line and use the point from the same distance 15:28:51 q? 15:29:04 rrsagent, here 15:29:04 See http://www.w3.org/2014/08/23-svg-irc#T15-29-04 15:29:36 Zakim has joined #svg 15:32:36 cabanier: do you need to remember an extra point? 15:32:43 heycam: you have to do that anyway 15:34:22 ... to summarize: if you have a previous command other than 'p', the implicit first point is based on the tangent just preceding the curve 15:34:43 ... you always know the one coming in if it's a line or curve 15:36:31 shepazu: can you come back with a more concrete proposal? 15:36:57 heycam: I'll make an issue in the spec 15:56:59 nikos has joined #svg 16:02:31 ScribeNick: heycam 16:02:36 Topic: Parameterised SVG 16:02:51 jwatt: we have a need that I want to discuss 16:03:06 ... it stems from Firefox OS people who need performance, and keep memory usage down -- they use icon fonts 16:03:23 ... I'd like to move them away from icon fonts towards using SVG 16:03:51 ... I ran through some alternatives to make performance of SVG-in- enough for their needs 16:04:03 ... I think we can get close to that, but one thing they want is to be able to do what they do with icon fonts 16:04:15 ... the color font on the element they apply the font to, can be used to style the content of the icon 16:04:20 ... right now we have no mechanism to do that 16:04:26 ChrisL: not any style across that boundary 16:05:33 jwatt: they want to have a way to reference out of the SVG to get a computed value 16:05:36 ... or pass it in, either way 16:05:44 ... they want to do it with CSS selectors, so set a property on it 16:05:56 ... rather than like the params spec, where you have to add something to the query string or param elements 16:06:00 heycam: why? 16:06:12 jwatt: because that's going to be more convenient to theme things 16:07:03 shepazu: the way I've rethought parameters, in the context of CSS Variables -- 16:07:26 ... params consisted of two things. the way to specify how you pass the things into the file, the second was how to propagate those values and use them in the file 16:07:34 ... they're two separate problems 16:07:41 ... I think Variables are probably good enough for the second half 16:08:01 ... I'm proposing we're left with the problem of the behaviour of passing the values in, and/or having implicit behaviour 16:08:19 ... I don't care if parameters are explicitly declared, or if you can implicitly extract them from the context 16:08:21 ... both seem reasonable to me 16:08:30 krit: my question first is, does it need to be ? can it be