20:27:05 RRSAgent has joined #svg 20:27:05 logging to http://www.w3.org/2013/05/09-svg-irc 20:27:07 RRSAgent, make logs public 20:27:07 Zakim has joined #svg 20:27:09 Zakim, this will be GA_SVGWG 20:27:09 ok, trackbot; I see GA_SVGWG(SVG1)4:30PM scheduled to start in 3 minutes 20:27:10 Meeting: SVG Working Group Teleconference 20:27:10 Date: 09 May 2013 20:27:29 GA_SVGWG(SVG1)4:30PM has now started 20:27:36 + +1.425.373.aaaa 20:28:53 +[IPcaller] 20:29:02 Zakim, [ is me 20:29:02 +birtles; got it 20:29:40 +[IPcaller] 20:29:41 Zakim, Zakim [ is me 20:29:41 I don't understand 'Zakim [ is me', heycam 20:29:52 Zakim, [ is me 20:29:52 +heycam; got it 20:30:09 Zakim, who is on the call? 20:30:09 On the phone I see +1.425.373.aaaa, birtles, heycam 20:32:28 + +61.2.980.5.aabb 20:32:42 Zakim, +61.2 is me 20:32:42 +nikos; got it 20:32:50 +Doug_Schepers 20:33:37 Chair: Cameron 20:33:39 scribenick: nikos 20:33:45 Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0100.html 20:34:10 Topic: textLength tests 20:34:28 +cabanier 20:34:31 Thomas_Smailus: the plan is to take the existing test (from 1.1) and tweak it to bring it up to speed and deploy 20:34:41 ... looks like it will be one of the first tests for SVG 2 20:34:47 ... might take me a couple of weeks 20:35:02 heycam: we still don't have the test harness that CSS WG uses set up yet 20:35:09 ... so tests will just sit in the repository for the moment 20:35:27 heycam: we did agree on a template 20:35:30 ... it's on the wiki 20:35:42 ... the format is a bit different from the 1.1 tests 20:36:09 Thomas_Smailus: textLength was a feature that has tests but no one implemented 20:36:15 heycam: I'd try Opera, but don't know 20:36:41 Thomas_Smailus: there was something about if at least one browser supports then it's supported? 20:36:57 heycam: if we have two implementations we normally keep a feature when looking to remove 20:37:25 Topic: Variable Width Stroke 20:37:41 heycam: Brian could you summarise? 20:37:55 birtles: I posted to the list a particular use case I have 20:38:25 ... which is related to manipulating a path when you want to bind the width to points on the path 20:38:34 ... one example is a drawing application where the path is built from touch events 20:38:48 I am having trouble phoning in... says 26631 is restricted. 20:39:05 ... another example is a shape and you want to set the width of the stroke at particular points and it sticks to the points when you resize the shape 20:39:21 heycam has changed the topic to: http://lists.w3.org/Archives/Public/public-svg-wg/2013JanMar/0064.html 20:39:44 heycam has changed the topic to: http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0100.html 20:41:04 birtles: for my two examples, it's useful to attach the stroke width to points in the path -details in the mail 20:41:24 ... Rik replied with another use case which is where you want to reuse a particular stroke width profile 20:41:33 ... on paths which have different number of points to widths 20:41:39 + +33.9.53.77.aacc 20:41:44 ... his example is an illustrator tutorial 20:41:57 zakim, aacc is me 20:41:57 +Tav; got it 20:42:23 nikos: that was always the use case I imagined when talking about variable stroke width 20:42:31 Thomas_Smailus: it would mimic writing with fountain pen right? 20:42:37 birtles: yes 20:42:57 cabanier: it's a poor mans version of that - it's simple to implement but doesn't mimic the pen exactly 20:43:26 birtles: the application I'm involved in is a variable on that theme, where if you push harder it gets thicker 20:43:53 cabanier: pressing harder need not match up to a point though 20:44:11 birtles: that's a detail, even if you bind stroke widths to points, you can have more widths than points 20:44:41 ... so to summarise, we have two use cases, one where it's desirable to attach stroke widths to points, and one where you use percentages along the path 20:44:55 ... in inkscape they are kind of tied to points, but you have offsets from the points 20:45:08 ... I think we need to come up with a proposal to cover both approaches 20:45:18 ... I'd like to make sure we don't make it difficult for applications like I describe 20:45:26 s/describe/described 20:45:37 ... it would be unfortunate for my application if we only had percentages 20:46:03 cabanier: I don't think it would be that hard 20:46:47 ... it feels like we are going to do the same thing twice 20:46:56 ... and it depends how we apply the curve to the variable stroke width 20:47:02 ... I'm not sure you can add points to Catmull-Rom 20:47:17 ... beziers might be overkill 20:47:25 ... what does InkScape do? 20:47:35 Tav: there are 4 different types of interpolation 20:47:48 ... cubic bezier, cubic bezier johan, linear, and spiral interpolator 20:48:24 ... spiral path is complicated, it uses parts of spirals, hard to explain quickly 20:48:33 ... font forge has an implementation 20:48:43 ... it gives nice smooth paths but can go crazy sometimes 20:49:14 heycam: Brian, what do you think we should do initially? 20:49:22 cabanier: we definitely don't want straight line interpolation 20:49:29 shepazu: what do you mean by straight line interpolation? 20:49:33 heycam: I mean just linear 20:49:36 s/Brian,/Brian, Rik,/ 20:50:00 shepazu: I experimented a lot in the past on how to do variable stroke width 20:50:04 ... the syntax is the hard part 20:50:24 ... tying it to particular nodes is extremely unintuitive, percentages is probably more intuitive 20:50:37 Tav: when editing in InkScape, I think you want to tie it to the nodes somewhat 20:50:45 cabanier: do you really think about the nodes when editing? 20:51:00 Tav: suppose you want to modify the existing curve and you want the changes to follow that 20:51:04 shepazu: percentages would do that 20:51:18 cabanier: you can just calculate where the percentages are, and adjust those 20:51:43 ... you have all the information in the application so you can recalculate the percentages 20:51:50 shepazu: thats an authoring tool implementation detail 20:52:12 ... suppose you have a percentage, in one mode of your tool, if you change the length of the path the percentages stay the same 20:52:23 ... stroke width changes remain at the same percentages 20:52:33 ... in another mode when you make the path longer, the percentages change 20:52:50 ... I'm trying to avoid tying it to modes 20:52:59 Tav: try live path effects on InkScape 20:53:20 ... it's not tied exactly, if you drag a width point along, it moves to the next node 20:53:35 shepazu: Here's another possibility; we could allow units 20:53:46 ... if we had a property that had a list of links at which it changes 20:54:06 ... we could have units and allow em, percentages, pixels 20:54:31 birtles: I think that's good 20:54:53 shepazu: we have two scenarios 20:54:57 ... fixed positions of the width node 20:55:02 ... and variable positions of the width node 20:55:16 ... and both these are supported by using different units 20:56:05 shepazu: by pixels I mean unit less device co-ordinate 20:56:12 s/co-ordinate/co-ordinates 20:56:53 shepazu: I have to give a caveat - I have never tried this, it's my intuition 20:57:16 ... I have a third option, if we say widths are tied to percentages or pixels 20:57:27 ... there could be a third thing where we have a keyword or something where we tie it to particular nodes 20:57:34 birtles: that was my suggestion originally 20:57:55 s/that was my suggestion originally/I thought that was what you were suggesting/ 20:58:21 shepazu: we have different kinds of segments, and they have a differing number of nodes, and the nodes may not be on the line 20:58:24 ... e.g. a bezier 20:58:52 ... if we are talking Catmul-Rom, I can see a lot of value in attaching to the nodes 20:59:17 cabanier: the control points of the bezier are not useful for attaching widths to 20:59:29 shepazu: so we have a third option - put it at a node on the path 20:59:42 ... so for beziers control points would not be included 21:00:01 ... I don't know how much complexity that would include, but I think those three options will provide real flexibility 21:00:20 heycam: when Brian was talking about the nodes, I thought he was talking about the endpoint of each segment 21:00:23 ... perhaps with an offset 21:00:42 shepazu: I think that gets very complex syntactically 21:00:53 Tav: that's what InkScape does 21:00:59 cabanier: an author would never think like that 21:01:19 shepazu: and for hand editing it seems unintuitive 21:01:34 birtles: I suggested an example on the list, where you are resizing a box 21:01:41 cabanier: do you need to know that in the markup? 21:03:02 heycam: boxes are simple, I'd be interested to know if it applies to other more complex shapes? 21:03:45 nikos: the box is a simple example but it shoes that it can get complicated to keep stroke width profiles attached to segments without Brians idea of attaching widths to indexes 21:04:04 birtles: perhaps we need to consider different syntax proposals on the list 21:04:24 Tav: it would be interesting to look at what we are trying to do and craft syntaxes for them 21:05:04 shepazu: do we agree that we would want to have different stroke widths for inner and outer stroke? 21:05:13 cabanier: no 21:05:41 .. we discussed in Sydney 21:05:57 shepazu: I think that will frustrate people, I think they would want asymmetry more 21:06:11 birtles: would you be able to show some examples? 21:06:31 ... I think we discussed it may be nice to have but for SVG 2 we could add later 21:07:29 shepazu: Let's say we have a property, it lets you do pixels or percentages and it's a list 21:07:53 ... we say that's good enough for version 1 - symmetrical stroke width 21:08:20 ... it makes it harder to do the syntax later on if we want to add asymmetrical stroke widthds 21:09:00 birtles: when we make proposals perhaps we can include ways we could extend 21:09:20 cabanier: I think there's a lot of complexity with asymmetrical variable stroke 21:09:27 heycam: I don't think it would be too complex unless they overlap 21:10:05 birtles: once you have asymmetrical strokes, does it suggest you want negative widths? 21:11:07 shepazu: what is the proposed syntax? 21:11:28 ... for asymmetrical strokes, you have a stroke width and you want the stroke width to be applied at ... 21:11:46 ... you have three values for asymmetrical and two for symmetrical 21:11:54 ... width along the path, and how wide you want it at that point 21:12:01 ... 100% is 100% of the overall stroke width? 21:12:37 ... e.g. stroke width = 15, 100% at 10 pixels means 100% at 10 pixels, and you could say 120% or whatever 21:12:45 ... and that modifies the stroke width at that point 21:13:34 Tav: InkScape does absolute length. I don't see an advantage to using percentages 21:13:57 cabanier: You can reuse profiles 21:14:49 shepazu: I was thinking the width would be specified as a length for each point, but I like the idea of it being a percentage of the stroke width 21:15:16 ... one of the things we were talking about was the interpolation 21:15:26 ... how would we control that, would it also be a list? 21:15:47 ... e.g. at some point it's one type of interpolation and at another use another type 21:15:57 Tav: you could always put nodes close together if you want sharp edges 21:16:06 shepazu: so we'd have a third property? 21:16:38 ... stroke width, variable stroke width, and the third is the variable stroke width interpolation - it's a keyword to select the interpolation 21:17:19 cabanier: You can use Catmull-Rom as it does not need extra control points 21:18:06 shepazu: let's say we might have asymmetrical stroke width and I go from 0 - 100% and I want it nicely curved - shaped like a C 21:18:25 ... somewhere along the curve we would want it to be a certain width 21:18:37 ... are we talking about widths being defined along the normals? or is it always flat 21:18:46 cabanier: what do you mean by normals? 21:19:03 shepazu: if you draw a line that is the tangent 21:19:11 cabanier: yes it should be the nomral 21:19:14 s/nomral/normal 21:19:42 Tav: there's something else to think about - how do we handle end caps and line joins? 21:20:06 ... this is where the arc line join in InkScape comes from 21:20:13 cabanier: Whats the deal with line joins? 21:20:29 ... you would still cap it out - it would just be modified by the width 21:20:45 Tav: what does it mean to have a bevelled cap, or a square cap? 21:20:59 .. if your lines aren't coming in parallel anymore 21:21:10 ... comes up in asymmetrical and symmetrical cases 21:21:32 Tav: suppose you specify the end of your path to be 2 pixels wide and away from the end it's 10 pixels wide 21:21:51 heycam: so at the point where the semicircle connects to the path, the path isn't continuous anymore 21:22:00 ... for a normal stroke they would be going in parallel 21:22:40 cabanier: let me try in illustrator 21:23:28 ... it seems like it's capping with respect to the angles of the edges of the stroke 21:24:00 birtles: I wonder what all the different topics are we need to follow up on 21:24:08 ... first would be syntax - I'm happy to start discussion on the list 21:24:22 ... other issues we can also follow up on the list 21:24:37 ... just want to clarify - Doug you were talking about different interpolation modes 21:24:41 ... is that something we want or not ? 21:25:02 shepazu: personally I feel we should have different modes - but perhaps only two at first - Catmull-Rom and straight 21:25:31 birtles: I wasn't sure if Tav and Rik were agreeing with that 21:25:57 nikos: I'd like to see some examples 21:26:13 Thomas_Smailus: yeh without seeing some graphical use cases I'm not sure how it would look 21:26:43 heycam: If we have curves, they at least degenerate nicely into straight lines 21:27:04 ... that's not to say it might not be nice to have syntax to specify sharp changes 21:27:26 birtles: Doug do you want to produce some pictures and start a new thread? 21:27:48 ... if we decide it's complex, we can only allow one to start with 21:27:56 shepazu: I think it's a minor use case to have anything other than a smooth interpolation 21:28:21 ... so I'd be comfortable with only having a single interpolation now and later introduce an interpolation property if we see the need 21:28:30 ... it should be a simple change to the syntax 21:29:02 heycam: I wonder if you had control over the interpolation, whether it would be per segment or overall 21:29:22 shepazu: I think for calligraphic writing you would want to control per segment 21:30:14 ... would be great for fonts 21:30:31 ... you could use weights 21:31:07 Tav: I've experimented with fonts and it was quite difficult 21:31:37 nikos: it seems like for calligraphy, tuning the variable stroke widths would be so complex that you might as well just use complex paths to start with 21:32:40 heycam: Brian do you want to gather up the proposals on the wiki page? 21:33:10 birtles: there's still a lot that's changing so for now I'll send some stuff to the list with a straw-man proposal 21:36:48 -Tav 21:37:35 - +1.425.373.aaaa 21:37:43 -cabanier 21:37:48 -Doug_Schepers 21:37:49 -heycam 21:37:51 -nikos 21:37:51 GA_SVGWG(SVG1)4:30PM has ended 21:37:51 Attendees were +1.425.373.aaaa, [IPcaller], birtles, heycam, +61.2.980.5.aabb, nikos, Doug_Schepers, cabanier, +33.9.53.77.aacc, Tav 21:37:59 RRSAgent, make minutes 21:37:59 I have made the request to generate http://www.w3.org/2013/05/09-svg-minutes.html nikos 22:37:06 glenn has joined #svg 23:05:51 birtles has joined #svg 23:37:28 Zakim has left #svg 23:58:59 glenn has joined #svg