01:16:15 jet has joined #svg 01:44:42 thorton has joined #svg 02:41:50 glenn has joined #svg 03:18:54 glenn has joined #svg 05:10:53 Tav has joined #svg 06:27:15 birtles has joined #svg 06:32:03 konno has joined #svg 06:32:25 cabanier has joined #svg 06:35:26 Tav has joined #svg 06:36:29 trackbot, start telcon 06:36:31 RRSAgent, make logs public 06:36:31 Zakim has joined #svg 06:36:33 Chair: Cameron 06:36:33 Zakim, this will be GA_SVGWG 06:36:33 I do not see a conference matching that name scheduled within the next hour, trackbot 06:36:34 Meeting: SVG Working Group Teleconference 06:36:35 Date: 19 September 2012 06:36:46 Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Agenda 06:39:02 stakagi has joined #svg 06:39:06 Cyril has joined #svg 06:39:14 TabAtkins has joined #svg 06:39:57 nikos has joined #svg 06:40:03 scribenick: nikos 06:40:38 Topic: radialGradient @fr 06:41:02 ed: I have a couple of questions about the spec 06:41:15 ... 1: is fr allowed to be negative? 06:41:19 ... I think the thread decided no 06:41:29 2: should the focal point be constrained to be in the circle? 06:41:35 ... do we want to be fully compatible with canvas or not? 06:41:44 TabAtkins: I think Canvas behaviour is bad 06:41:51 ... whatever we do here I'd like to do it there too 06:42:10 cabanier: in Canvas you get a cone if drawing outside 06:42:35 TabAtkins: that behaviour doesn't make sense - there's a discontinuity in the behaviour for no good reason 06:43:24 heycam: would you ever want that effect? 06:43:27 TabAtkins: I don't think so 06:43:49 andreas has joined #svg 06:44:12 cabanier: all implementations come from PDF 06:44:38 cabanier: I think you should match what most people do 06:44:52 ... you should do it in CSS as well 06:45:10 TabAtkins: it' 06:45:17 ... s not good behaviour 06:46:04 cabanier: so how would you define radial gradients? 06:46:11 TabAtkins: I think the last colour should extend outside the plane 06:46:24 ... or restrict them to clamp 06:46:33 cabanier: I think SVG should match Canvas 06:46:38 heycam: we do clamp right? 06:46:41 ed: yes 06:47:00 TabAtkins: radial gradients are too complex for CSS 06:47:08 ... so what is ill defined about the clamping right now? 06:47:18 s/radial gradients/mesh gradients/ 06:48:01 TabAtkins: I don't think authors want it to extend, so I think it's better that we clamp 06:48:21 ed: a secondary issue - what happens if the radius cuts through the circle 06:48:51 TabAtkins: project out where the focal point would be. The definition should be in terms of the focal point and the fill shape 06:49:11 ... which behaviour do we want? turn it into a cone or clamp? 06:49:31 s/radius cuts through the circle/focal circle radius cuts through the other circle/ 06:49:40 cabanier: I think it should match what everybody else is doing 06:50:33 ed: even if we wanted to have canvas behaviour we have to keep old behaviour when it's exactly on the circle 06:50:38 ... so we don't break old content 06:51:42 http://jaspervdg.wordpress.com/2012/09/03/specifying-radial-gradients/ 06:54:37 heycam: I'm leaning towards allowing it outside the circle 06:56:05 TabAtkins: I'm not a fan of the cone effect 06:56:13 cabanier: I agree, but I think consistency is important 06:56:52 heycam: what happens when you put the focal point on the edge in Canvas? 06:57:12 cabanier: they don't have repeat so it's not a problem 06:57:35 ed: I think I agree that consistency with Canvas is important 06:58:45 Resolution: SVG radial gradients will align with Canvas for behaviour where the focal point is outside the circle 06:59:06 ed: for the case where it's exactly on the circle we are going to keep the old clamping behaviour for backwards compatibility? 06:59:21 ... when the focal point is exactly on the circle 06:59:38 Tav: what colour space do you do the averaging in ? 06:59:48 TabAtkins: CSS takes the easy answer and converts to sRGBA 07:00:09 Tav: optically you would want to use linear 07:00:42 cabanier: the gradient doesn't interpolate linearly 07:00:59 TabAtkins: the averaging should be in the same colour space as the rest 07:01:48 ... I think to get correct colours you average in the same colour space as you interpolate 07:03:37 TabAtkins__ has joined #svg 07:03:42 http://dev.w3.org/csswg/css3-images/#find-the-average-color-of-a-gradient 07:05:02 Action: Tav to specify radial gradient behaviour when the focal point is outside the circle 07:05:02 Created ACTION-3374 - Specify radial gradient behaviour when the focal point is outside the circle [on Tavmjong Bah - due 2012-09-26]. 07:05:16 Topic: Mesh Gradients 07:05:36 http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_artists.svg#36_0 07:06:56 Tav: The basic issue with the gradients right now is how to handle non-smooth transitions between boundaries 07:06:58 ... they cause banding 07:07:12 ... that point of the transition looks brighter 07:07:26 ... Adobe and Corel draw handle this by doing smoothing that's hidden from the user 07:07:34 ... it gets exported as 8x8 patches in the PDF 07:07:42 ... we could do what they do, but that would end with lots of patches 07:07:46 ... or we try some kind of smoothing 07:08:09 ... either automatic smoothing or we allow a more complex syntax that allows colours to be set at points on the handles or tensor points 07:08:20 heycam: is it like specifying easing? 07:09:07 Cyril: if you have two patches next to each other and you specify the colour derivatives at the shared points, then you have a continuous derivative and no banding 07:09:15 Tav drawing on board 07:09:37 Tav: If you have two patches, you want to smooth the join 07:10:16 ... what I did is use auto smoothing by looking at the slope and use that to construct a curve 07:10:31 Cyril: the problem with that is the rendering of patches is not isolated 07:12:23 Tav: You could define colours at the control points and add tensor points 07:12:35 Cyril: generally that's not what people do, the colour is separate from the geometry 07:13:01 shepazu: If you're trying to do patches you are probably trying to match them to a geometric shape - in most uses 07:13:41 Cyril drawing on board 07:14:26 Cyril: typically a coon's patch is something where you start with a unit square, with parameters u and v. You have a colour aspect where you have 4 colours on the corners, you have a bilinear interpolation inside 07:14:47 ... then you have a transformation, from u &v you get x & y on one side and a colour value on the other side 07:15:51 ... what you are proposing is the difference between coon's patches and tensor patches 07:15:57 ... there is also a ferguson patch 07:16:11 ... from simplest to more complex - coons, tensor and then ferguson 07:16:27 victor has joined #svg 07:16:41 ... what you are proposing is something like what PDF does with tensor patches but in the colour dimension and not the geometric dimensions 07:18:38 Tav: in 1 dimension, you interpolate the colours using a bezier 07:19:00 Cyril: I don't think that is a simple transition to 2 dimensions 07:20:08 Cyril: I would need to think about it 07:20:31 Tav: I am always proposing to have the extra points at 1/3rd and 2/3rd 07:20:47 TabAtkins__: I'm ok as long as there's an automatic way to do the interpolation 07:21:18 heycam: Are you describing extra things the author has to specify? 07:21:30 Tav: yes. Or if it's not specified you get the linear interpolation 07:21:58 heycam: I would like a boolean that enables a way for us to specify the method of smoothing 07:22:12 shepazu: I'd like to see this proposal in terms of a syntax 07:22:20 Tav: for auto smoothing it would simply be a flag 07:22:47 Cyril_ has joined #svg 07:22:55 Tav: I have a proposal syntax 07:23:19 ... I think we really need the tensor points as they allow you to draw how the colours spread inside and helps to remove some of the banding effects 07:23:40 ... 07:24:08 Cyril_ has joined #svg 07:24:22 ... when defining tensor points, you could replace that with an array of rows by columns with a colour array as well 07:25:27 Tav: one mesh consists of 16 points. These points could be described in an array of points. 07:26:08 shepazu: I don't know if that's simpler 07:26:18 Cyril__ has joined #svg 07:26:52 Tav: The points and handles defining the patch map into the array 07:27:46 Tav: if you are going to add the tensor points inside the patch, you cannot define them using the path syntax 07:28:54 Tav: slide 33 has an example syntax 07:34:10 shepazu: I'd like to see real world examples of how this is used and how many patches are needed 07:34:13 Cyril: it's heavily used 07:35:02 ... requires many many patches to make an image 07:35:07 shepazu: is this a good use for SVG? 07:35:26 TabAtkins__: it's a very good use for an SVG viewer 07:38:23 shepazu: is this something you could see being added CSS? 07:38:36 rrsagent, pointer? 07:38:36 See http://www.w3.org/2012/09/19-svg-irc#T07-38-36 07:38:46 TabAtkins__: no. 07:39:20 TabAtkins has joined #svg 07:40:23 shepazu: what we want is output that is consistent with the author's view in illustrator and inkscape 07:40:45 heycam: I'd like to avoid having the subdivision in the SVG 07:41:05 s/output/browser output/ 07:42:21 shepazu: This is unique and attention grabbing which are good criteria for inclusion in SVG 07:42:52 TabAtkins: is this a paint server or just geometry? 07:43:08 Tav: we decided if it's in the defs section it's a paint server, if it's not then it's geometry 07:43:16 ... you need to be able to clip if it's a paint server 07:44:36 Resolution: SVG mesh gradients should have a method for enabling smoothing and smoothing should be default behaviour 07:44:58 s/This is unique and attention grabbing which are good criteria for inclusion in SVG/This seems like something that 1) can't be done elsewhere in the web platform 2) couldn't be done in CSS (needs markup) and 3) will meet the real-world needs of authors, which are good criteria for inclusion in SVG 2/ 07:45:22 Action: Rik to find out what method Adobe uses for smoothing mesh gradients and report to group 07:45:22 Created ACTION-3375 - Find out what method Adobe uses for smoothing mesh gradients and report to group [on Rik Cabanier - due 2012-09-26]. 07:46:08 cabanier: if the patches are not hand editable then why not just make them really compact 07:46:34 shepazu: even if they're not hand editable they still need to be animatable 07:47:36 ed: One of my main concerns is a lot of details are missing from the spec at the moment 07:47:39 Tav: they will be added 07:48:07 ed: I'd like references to the algorithms used - they should be in the spec 07:48:21 Cyril: I'm not sure all the algorithms are royalty free 07:48:39 ... at least one has a patent 07:49:05 ... I think we won't be mandating a specific algorithm 07:49:17 TabAtkins: that's right, you require a certain output 07:49:33 ... it just has to be black box compatible 07:50:59 ed: My other point is about hand authoring - it doesn't seem to be really possible 07:51:26 ... if we were to have a simplified syntax that wouldn't give the same accuracy but gives something that could be manipulated would be useful 07:52:21 s/that wouldn't give/that (perhaps) wouldn't provide 07:52:48 shepazu: so it's common for people to use multiple meshes to create an object 07:52:51 ... what's the bounding box? 07:53:05 TabAtkins: if it's geometry then the bounding box is the edges 07:53:18 cabanier: they fold over themselves 07:53:34 TabAtkins: that would be as if any path folds over itself 07:54:02 shepazu: this is different to SVG in some ways - normally in SVG you have a shape which is the geometry and it might be affected by properties 07:54:11 ... then you fill it with some other thing that doesn't have geometery/size 07:54:31 cabanier: well we resolved that now radial gradients will have a boundary 07:54:38 shepazu: but you can't use getBBox on it 07:55:04 heycam: I think doug is saying it can be a mesh object as well as a paint server 07:55:22 shepazu: under what circumstances would you use it as a paint server? 07:55:32 andreas has joined #svg 07:55:54 ... I don't think it is the primary purpose 07:56:52 shepazu: we have talked several times about integrating canvas and svg and having a similar path model 07:57:00 ... now we are introducing a new element where you can't do that path stuff 07:57:09 ... for the pepper, I might want to just get the outline 07:57:12 Cyril: you can 07:58:08 cabanier: what about when it folds over itself? 07:58:15 ... the outline may not be the outermost path 07:58:44 heycam: if we had this method on circles, etc then it should work on the patch geometry as well 07:59:09 Cyril: if a patch overlaps itself the path would also, that's fine 08:00:31 shepazu: if I had line art and I want to colour it using mesh gradients how would I do that? 08:01:13 TabAtkins: you would use a paint server to contain the colour, the patches wouldn't match the geometry 08:01:22 jet has joined #svg 08:01:24 ... effectively, you would need to trace over the line art 08:01:41 shepazu: I think this has path like characteristics so it should have path like powers 08:02:52 Tav: I talked to the NVidia guy about HW acceleration and he said no problem. 08:02:55 Cyril: it's very simple 08:04:42 victor has left #svg 08:06:14 Cyril: When we selected Coon's patches, we also considered triangle patches. 08:06:23 ... the more I read about vectorisation, the more I see this being used 08:07:13 ... I am suggesting we add the triangular representation for meshes to SVG 08:07:36 heycam: is it wasteful to do the triangles using bezier paths? 08:07:43 Cyril: I would have to investigate but I suspect so 08:07:56 shepazu: Cyril, could you come up with a concrete proposal that shows syntax and outputs 08:08:34 Action: Cyril to write up a proposal for a triangular representation for gradient meshes 08:08:34 Created ACTION-3376 - Write up a proposal for a triangular representation for gradient meshes [on Cyril Concolato - due 2012-09-26]. 08:09:16 Topic: GetSVGDocument deprecation/removal 08:09:31 Topic: SVGDocument interface (alias to Document?) 08:09:49 ed: this is a bout merging all the interfaces of SVGDocument onto document 08:09:55 ... this is the direction HTML is going 08:10:26 ... we would want a minimal representation for backwards compatibility 08:10:43 shepazu: what is the syntax in HTML5 08:10:49 http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#document 08:10:59 TabAtkins: HTMLDocument is an alias for document 08:11:49 heycam: if you create a document, the type is defined by the root element, it can't change mid-life so whatever functionality for SVGDocument and HTMLDocument should be available on all documents 08:12:47 shepazu: in HTML, when you try to get forms and there are no forms, would the result be different in SVG compared to a HTML doc that has no forms 08:12:59 heycam: document.forms would be a HTML collection object with length zero 08:13:29 heycam: HTML collection is named HTML collection but it's really just a collection of any element 08:13:42 shepazu: what difference would this make to authors? 08:14:59 heycam: the difference will be additional properties 08:15:55 shepazu: we can remove details from our specification and refer to HTML5 08:16:30 ... I'm in favour of this, we can special case things as we find them 08:16:51 TabAtkins: i.e. SVG links are returned as well as HTML links 08:17:47 heycam: we need to discuss the alias 08:18:03 ... firstly in the IDL it becomes a partial interface for document 08:18:33 ... the aliasing of the interface, presumably HTML does that for HTMLDocument 08:19:30 TabAtkins: it just aliases to document. We would use the same line in SVG 08:19:40 "For historical reasons, Window objects must also have a writable, configurable, non-enumerable property named HTMLDocument whose value is the Document interface object." 08:19:55 heycam: we will do the same thing 08:20:14 Resolution: SVGDocument will be an alias for document 08:20:29 Action: ed make SVGDocument into an alias for document 08:20:30 Created ACTION-3377 - Make SVGDocument into an alias for document [on Erik Dahlström - due 2012-09-26]. 08:20:54 Topic: XLink deprecation 08:21:05 heycam: We might have already decided on this 08:21:23 ... whether all attributes become href or whether some become source and some become href 08:21:37 TabAtkins: I think they should be whatever they all are right now 08:21:43 ... we shouldn't change it, just drop the xlink prefix 08:22:19 ... I think we should align script 08:22:47 heycam: there are quite a number of elements that have xlink:href 08:23:02 shepazu: the idea was that we use xlink:href for any external resource 08:23:10 ... I don't mind if you can use href or src 08:23:35 ... we are going to have to xlink:href and href so we might as well allow src too 08:23:48 https://svgwg.org/svg2-draft/attindex.html 08:23:56 list of things that use xlink:href 08:24:43 a - makes sense 08:25:00 alt-glyph is a reference to an element so should be href 08:25:09 animate elements - makes sense 08:25:21 color-profile - being removed 08:25:42 cursor - represents an external image so could be src, but cursor is probably not similar to anything in HTML so can be left as href 08:26:14 image - should allow src 08:26:37 TabAtkins: the ones I'm concerned about are image and script 08:28:25 shepazu: with image, it behaves differently in SVG than in HTML, so they don't have to align 08:28:32 TabAtkins: script is the one I feel really strongly about 08:30:05 ... I might want script to accept 3 attributes, if there are not strong objections 08:30:22 shepazu: we resolved that href overrides xlink:href 08:30:37 ... but there's more to it - i.e. how it is represented in the DOM 08:30:41 http://www.w3.org/Graphics/SVG/WG/wiki/Href 08:31:11 heycam: I like allowing src for script 08:31:39 shepazu: users expect src 08:31:44 s/users/authors 08:31:57 heycam: I propose that src overrides everything 08:32:10 TabAtkins: I'd put src between href and xlink:href 08:32:17 heycam: I'd like to encourage src 08:32:19 shepazu: me too 08:34:40 heycam: set always sets 'src' and 'get' gets the attribute that exists with the highest precedence. 08:34:59 shepazu: this makes me reconsider image, why are we doing src in some things and not src in others? 08:35:13 ... we could align on src but say there's a couple of quirks with SVG image. 08:35:40 ... so anywhere that HTML has a general kind of element that uses src instead of href, SVG will also allow src and it will be the default 08:36:12 heycam: feImage should remain href because it can point to trees 08:36:34 TabAtkins: I'd like to stay doing what we currently do unless aligning with HTML 08:37:08 heycam: all the remaining elements in the list are href 08:37:48 ... one final issue - on image the href DOM property is an animated string 08:38:35 Zakim has left #svg 08:39:10 ... we should make .src be a DOM string that just reflects the base value, not the animated value 08:45:00 TabAtkins: There's 3 things 08:45:09 ... firstly the xlink:href gain a plain href 08:45:18 ... secondly, script and image gain a src attribute 08:45:48 thirdly, when getting from any, you get the highest precedence (src -> href -> xlink:href), when setting you set the highest that is available 08:46:46 Resolution: We will allow href on all elements that have xlink:href and allow src on image and script. With details as in the minutes. 08:47:07 Action: Cameron to add href on all elements with xlink:href and add src to image and script 08:47:07 Created ACTION-3378 - Add href on all elements with xlink:href and add src to image and script [on Cameron McCormack - due 2012-09-26]. 08:56:13 andreas has joined #svg 09:27:42 scribeNick: Cyril 09:27:51 Topic: Cameron's stuff 09:28:21 heycam: we have previously described ways of determining whether pointer-events were within the stroke region or the fill region or hte marker 09:28:36 ... we settled on a method to tell you which region was hit 09:28:40 ... I have done that 09:28:43 ... it's in the spec 09:28:52 http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSep/0194.html 09:28:55 https://svgwg.org/svg2-draft/types.html#InterfaceSVGGeometryElement 09:29:12 ... I took upon myself to add a new interface 09:29:22 ... on elements that can be filled and stroke 09:29:28 ... there are 2 methods: 09:29:32 isPointInFill 09:29:35 isPointInStroke 09:29:50 ... initially it is taking a Point object in user space 09:30:26 ... because often you will have a mouse event and you want to take the coordintes of hte mouseevent and translate them into the user space 09:31:04 ... that's a separate thing that's handy to do 09:31:16 ... oh, I forgot to make that change 09:31:34 ... SVGPoint should have a constructor that takes an element and a mouse event 09:31:47 ... if the element is not provided, it is assumed to be the target of the event 09:32:12 ... I had the conversion integrated but this is cleaner this way 09:32:22 ... I also worked on markers 09:32:37 ... there is a separate interface 09:32:46 https://svgwg.org/svg2-draft/painting.html#InterfaceSVGMarkableElement 09:33:16 ... it's implemented on elements that can have markers on 09:33:36 ... rahter than having a method is point in markers, which doesn't tell you whjich marker is used 09:33:40 ... it uses a marker index 09:34:03 ... this covers the automatic marker and the children marker 09:34:29 scribenick: cabanier 09:34:51 scribeNick: Cyril 09:35:03 ... in the same order as the rendering order 09:35:25 first the automatic ones and then the positioned ones 09:35:43 ... SVGMarkerList gives you a list of marker instances 09:35:49 https://svgwg.org/svg2-draft/painting.html#InterfaceSVGMarkerInstance 09:36:02 ... giving you the marker, its position ... 09:37:18 ... as a length along the path 09:37:24 ... the actual point that it's at and the angle 09:37:40 andreas: can you get the segment it's on? 09:37:49 heycam: there is a method for that in PathSegment 09:38:07 ... in fact angle and point are not strictly needed, but they are convenient 09:38:24 rik; can you change hte marker that you get? 09:38:35 heycam: yes, you can change the definition 09:38:59 andreas: sometimes you want to highlight hte marker that is selected 09:39:19 heycam: that would be difficult for the automatic markers, because you can't change just one 09:39:27 (the method for getting the segment is SVGPathElement.getPathSegAtLength) 09:39:28 ... you probably need to use child markers 09:40:31 tab: I agree 09:41:17 heycam: the marker has now two new attributes: position and reference 09:41:40 ... the SVGMarkerList does not let you add new markers 09:41:48 ... it's only access to the computed list of all markers 09:41:56 ... it might be a bit tricky to change that 09:42:08 ... if this was useful for adding/removing makers 09:42:31 ... we could have markers and childMarkers 09:43:03 brian: I noticed that the PathSegList throws an exception 09:43:12 ... it is not consistent 09:43:37 heycam: if you use the squared brackets you will not get exceptions 09:44:13 brian: on marker list the getter is defined to return null if the index is out of range 09:44:30 ... but other interfaces SVGPathSegList it is defined to throw an Index Size Error 09:44:41 ... so we need to make them consistent 09:45:07 ... one detail of that is that if you use square brackets syntax, you won't get an exception regardless of the index and range 09:45:20 ... that's due to the behavior defined in WebIDL 09:45:47 heycam: you could use path.markers[n] 09:46:18 ... if you use that even if me make the method throw an exception this won't 09:46:26 ... but I'll add the exception to the method 09:46:57 ACTION: heycam to make SVGMarkerList item method return an exception when the index is out of range 09:46:57 Created ACTION-3379 - Make SVGMarkerList item method return an exception when the index is out of range [on Cameron McCormack - due 2012-09-26]. 09:47:21 ACTION: heycam to make the SVGPoint changes to take a mouse event in the constructor 09:47:21 Created ACTION-3380 - Make the SVGPoint changes to take a mouse event in the constructor [on Cameron McCormack - due 2012-09-26]. 09:47:58 Topic: Hatchings 09:48:48 http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_artists.svg#15_0 09:49:17 tav: this is a fairly common technical drawing in maps 09:49:33 ... but you can use patterns but there are anomalies at boundarys 09:49:54 ... but there is also a problem for plotters, because the pen goes up and down at each boundary 09:50:01 ... open source plotters use SVG for that 09:50:11 ... I'd like to have some feedback on a new syntax 09:50:33 ... you specify an angle, origin, pitch and width 09:50:54 ... if you want multiple fills you want to use multiple elements 09:51:16 tab: you are using the line element and it should probably a path element 09:51:30 tav: yes you could specify a pattern that gets extruded (slide 18) 09:51:58 heycam: dasharray is pitch: gap and width and gap ... 09:52:59 tav: by using the path syntax you can have more complicated hatchings 09:53:39 tab: would you do a line to if start and end don't match 09:53:41 tav: yes 09:54:03 tab: you determine how large the tile is by using the bounding box 09:54:23 cyril: how is it different from a pattern 09:54:54 tab: when you tile patterns you should paint each tile separately 09:55:10 ... and that's not what you want for engravers for instance 09:55:45 cyril: what makes this behavior not possible with pattern? 09:56:26 (heycam drawing) 09:57:56 cyril: I don't understand why we need to introduce a new element just to change the rendering algorithm 09:58:42 doug: this makes it simpler to define a pattern that has overlaps with other pattern elements 09:59:45 ... because it overlaps with itself 10:00:08 (doug drawing example of the zig-zag pattern) 10:00:33 brian: in some cases, when you have cross hatching 10:00:40 tab: I like the syntax on the second slide 10:00:53 ... I don't like the more compact representation using the dash syntax 10:01:45 brian: this would make it more easy to detect the situations andreas showed us yesterday when you want to rotate the cross-hatching so that the lines don't end up parallel with the edges of the shape 10:01:48 doug: it would easier to animate this kind of pattern 10:02:09 (andreas showing point hatching) 10:03:54 tab: I like the idea, this is good! 10:04:10 doug: especially given the parameters that control the pattern repetition 10:05:04 brian: cross-hatching? 10:05:14 tav: easily done with multiple fills 10:05:28 cyril: what about nested hatchings? 10:06:02 tab: no, this just accepts paths 10:06:22 ... what happens if you put more complex strokes? 10:06:36 ... filling a stroke with a gradient or an image 10:06:50 ... does it repeat on a per tile basis or more 10:06:59 ... what is the gradientUnit 10:07:08 tav: I haven't thought about it 10:07:43 brian: how important is it to specify colors? 10:07:51 ... couldn't you do it on the referencing? 10:09:00 ... if you want a gradient, you could do it in a mask 10:09:33 tab: maybe we need to change line to hatchline so that its stroke property takes only a color and not a paint server 10:09:49 heycam: I'm nto sure it's impossible to have it work for gradients 10:10:14 ... but I can see that so that markers don't go on there 10:10:24 tab: and also filling would be a non-sense 10:10:34 heycam: but it could be made consistent for the model 10:11:48 ... I would still be fine with path and line instead of hatchpath and hatchline 10:12:05 brian: clip-path has restrictions 10:12:14 ... already 10:12:28 heycam: it is analogous to clip-path 10:12:34 rik: yes, it's the opposite 10:12:46 (that is, children of the clipPath element) 10:12:58 tab: if we say that some attributes are ignored, I would be fine with it 10:13:22 tav: offset tells you where you start with the pitch 10:14:12 tab: you could use the x,y attributes to encode the offset 10:14:57 brian: how do multiple fills work? 10:15:08 tab: we have to work that out yet 10:15:58 heycam: at some points, we want to allow multiple fills and multiple strokes without vector effect 10:16:20 tab: that is copy what CSS has done with background and that's the wrong way 10:16:30 ... having a compound fill would be better 10:16:42 rik: I agree 10:17:07 brian: you could bundle a cross-patch with a background for instance 10:17:19 s/cross-patch/cross-hatch/ 10:18:19 RESOLUTION: SVG 2 will have a modified version Tav's hatch proposal 10:18:54 ACTION: Tav to work out the details of the modifications of the initial proposal 10:18:54 Created ACTION-3381 - Work out the details of the modifications of the initial proposal [on Tavmjong Bah - due 2012-09-26]. 10:19:33 ACTION: Tab to think about a compound paint server proposal 10:19:33 Created ACTION-3382 - Think about a compound paint server proposal [on Tab Atkins Jr. - due 2012-09-26]. 10:23:23 (andreas showing a marker centroid example) 10:24:13 ScribeNick: TabAtkins 10:24:33 andreas: [shows a mapping example where patterns are placed at the centroid of the various geometric objects] 10:24:49 TabAtkins: You could do that maybe as a marker positioned at the centroid? 10:25:06 shepazu: If we exposed that kind of thing, you'd want an explicit DOM API on returning the centroid as well. 10:25:13 ScribeNick: Cyril 10:25:38 doug: centroid is actually not trivial to calculate 10:26:06 heycam: we could make the hatching large enough so that it does not repeat 10:26:18 ... actually you can use a pattern for that 10:26:52 doug: do we add a keyword for centroid 10:28:55 http://mathforum.org/library/drmath/view/57665.html 10:28:59 http://www.georeference.org/doc/transform_centroids.htm 10:29:53 (discussion on the centroid properties) 10:32:18 lunch!! 10:42:19 Centroid: http://user.gs.rmit.edu.au/rod/files/publications/MSIA_Centroid.pdf 11:16:02 andreas has joined #svg 11:43:27 TabAtkins has joined #svg 11:44:23 stakagi has joined #svg 11:45:06 Cyril has joined #svg 11:46:25 nikos has joined #svg 11:48:16 TabAtkins has joined #svg 11:54:32 cabanier has left #svg 11:54:47 cabanier has joined #svg 11:56:00 http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_artists.svg#19_0 11:56:03 http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_artists.svg#19_0 11:56:12 ScribeNick: heycam 11:56:16 Topic: extrapolated line join 11:56:26 http://tavmjong.free.fr/SVG/LINEJOIN/index.html 11:56:42 Tav: we talked about this last time 11:56:50 … the question at that point was "what about the math" 11:56:53 … so I've provided it here 11:56:57 … it's straightforward 11:57:09 … you're looking at the curvature at the end of the path where the two segments join 11:57:33 … using that to draw circles, and you shrink or expand circles to the edges of the path, and extrapolate from there 11:58:14 TabAtkins: it's just expanding the circle so that it matches the edge of the path, rather than the center of the path 11:58:41 Tav: you can have a straight line, and then displace that by half a stroke width 11:58:50 … because sometimes these lines aren't going to intersect 11:58:55 … you might also want to apply a miter limit 11:59:20 TabAtkins: seems reasonable, thanks for working out the math 11:59:32 Cyril: the curvature doesn't take into account the stroke, just the path? 11:59:34 TabAtkins: correct 11:59:37 Tav: it's going to be the same thing 12:00:15 Cyril: is this implemented somewhere? 12:00:27 TabAtkins: Inkscape has something similar but not quite the same 12:00:34 … the person implementing it just mirrored the path to get the curvature 12:00:37 … which I don't think you want to do 12:00:44 s/TabTakins/Tav/ 12:00:50 s/TabAtkins/Tav/ 12:02:13 cabanier: if they become a line, you miter them? 12:02:26 Tav: there are cases where the circles won't intersect, or if they're both lines 12:02:55 … then you fall back to miter 12:03:35 heycam: would you want to apply miter-limit to this join, and also to the fallback to a miter-limited miter? 12:03:44 TabAtkins: no, if the extrapolation doesn't work you fall back to bevel 12:03:55 … but yes apply miter-limit to extrapolated join 12:06:20 RESOLUTION: We will add extrapolated line joins to SVG 2, using Tav's proposal. 12:06:29 ACTION: Tav to add extrapolated line joins to the spec. 12:06:30 Created ACTION-3383 - Add extrapolated line joins to the spec. [on Tavmjong Bah - due 2012-09-26]. 12:07:12 Topic: GetSVGDocument interface 12:08:00 heycam: [explains what GetSVGDocument] 12:08:06 s/]/does]/ 12:08:13 ed: getSVGDocument doesn't work on embed 12:08:17 s/getSVGDocument/contentDocument/ 12:10:33 http://lists.w3.org/Archives/Public/www-svg/2012Aug/0095.html 12:11:31 heycam: from my testing there it looks like it is consistently not implemented on embed, yes 12:11:46 TabAtkins: I'm fine with keeping it in, for legacy purposes 12:12:00 … would be good to amend the spec to say that it returns the same as contentDocument for legacy purposes 12:13:00 from the spec: "This interface is deprecated and may be dropped from future versions of the SVG specification. Authors are suggested to use the contentDocument attribute on the EmbeddingElement interface to obtain a referenced SVG document, if that interface is available." 12:13:28 RESOLUTION: Keep GetSVGDocument in SVG 2. 12:14:19 Topic: spaces/commas in SVG view specification 12:14:51 heycam: just wanted to confirm what our decision was 12:15:43 ed: we decided to allow commas and spaces in viewBox and preserveAspectRatio parts of the view specification 12:15:45 heycam: ok 12:16:58 Topic: HTML integration 12:17:09 TabAtkins: I've started to push on getting html elements directly in svg 12:17:12 … but not the other way around 12:17:26 s/viewBox and preserveAspectRatio parts of the view specification/viewBox and preserveAspectRatio attributes, and to only allow comma separation in the view specification (for fragments) 12:17:28 …but I will do that just for the resource-like elements (like clipPath) 12:20:36 [for view fragments, heycam has an action to check if spaces would work after unescaping url fragments, and then allow spaces in there if that works] 12:21:06 Topic: SVG DOM improvements 12:21:32 heycam: I've added some constructors to SVG type interfaces 12:21:39 … for example https://svgwg.org/svg2-draft/types.html#InterfaceSVGLength 12:22:08 … three constructors there 12:22:12 … one initializes it to 0 12:22:32 … another takes the separate value and unit types 12:22:35 … and another takes a string 12:22:48 TabAtkins: the direction for CSS OM values api, is a constructor named "px" 12:24:02 el.style.width = CSS.px(5) 12:24:43 TabAtkins: then the length object has attributes for converting into various units 12:24:54 birtles: we had a proposal like that already 12:25:20 TabAtkins: this part of the CSS OM proposal is uncontroversial 12:25:53 heycam: how do SVGLength and CSSLengthComponentValue relate then? 12:25:58 TabAtkins: don't care, but they should behave the same 12:27:41 TabAtkins: you could also have CSS.length("20px") 12:28:29 heycam: would we use CSS.px() objects in place of SVGLength? 12:30:01 TabAtkins: you could make SVGAnimatedLength inherit from CSSLengthComponentValue 12:30:09 … and then add your baseVal animVal on there 12:30:32 ACTION: Tab to write up how SVG types should work with CSS OM objects 12:30:33 Created ACTION-3384 - Write up how SVG types should work with CSS OM objects [on Tab Atkins Jr. - due 2012-09-26]. 12:31:12 Topic: rendering-mode: animate 12:31:33 shepazu: there are various rendering modes like geometricPrecision 12:32:20 … when you try to snap to pixels, this affects the rendering 12:32:24 … they're optional anyway, it's a hint 12:32:41 … one of the cases we talked about is when you're animating 12:33:01 … if you use crispEdges for text animation, it'll be jerky 12:33:27 … I'm proposing a hint "animate" so that the user agent know that this is going to be animated 12:33:32 TabAtkins: so it can switch to a low cost rendering mode? 12:33:34 cabanier: it's higher cost 12:33:43 shepazu: you should switch to a mode that gives the best visual effect for being animated 12:34:15 ed: if you render a rectangle slowly across the screen you'll see the snapping happening 12:34:20 … or the blurring if you use the normal one 12:34:27 cabanier: how would you solve it? draw half pixels? 12:34:41 heycam: how is it different from geometricPrecision? 12:34:58 shepazu: an author won't know that the way to make text look good when you're animating is "geometricPrecision" 12:35:09 … but if you have a mode called "animate", the author will know 12:35:32 … you could say in the spec "if you're animating, use geometricPrecision", but it will be hard for authors to discover 12:36:08 … I don't feel too strongly about it, just thought it would be easier to use 12:38:49 birtles: I think most UAs already detect if something is being animated and optimize it 12:39:14 Cyril: I think the difference is geometricPrecision, some heuristic could not detect what the user would prefer 12:39:21 … the browser can detect it's going to be animated 12:39:41 shepazu: maybe we should add in for crispEdges that browsers may wish to disregard this when animating text 12:39:58 ed: I think it depends on the device 12:40:39 heycam: we could add a note for "auto" to say that text shouldn't be pixel snapped when it is being animated 12:41:37 hand 12:41:46 RESOLUTION: {shape,text}-rendering should say that "auto" means that pixel snapping shouldn't be done when animating 12:42:13 Zakim has joined #svg 12:42:37 hand 12:42:48 hand- 12:42:50 Gotta hand it to Zakim, he's pretty weird 12:42:58 On the other hand 12:42:58 ACTION: Doug to add notes to {shape,text}-rendering auto to mention not doing pixel snapping when animating 12:42:58 Created ACTION-3385 - Add notes to {shape,text}-rendering auto to mention not doing pixel snapping when animating [on Doug Schepers - due 2012-09-26]. 12:42:59 -hand 12:43:04 q- 12:43:14 q- 12:44:05 Topic: SVG documentation 12:44:31 shepazu: for W3C's documentation, I'd like to automatically extract element/attribute/property names and values from the spec 12:44:39 … if you could also send me tutorials you'd like to see 12:49:11 Topic: CSS Variables and Params 12:49:19 shepazu: params should use the variable mechanism for substituting values 12:49:31 … for text content, we need something to render it into the DOM, possibly 12:49:40 TabAtkins: make it accept a var() function in addition to a url() 12:50:47 shepazu: I'll work with Tab on this 12:50:52 Topic: rounded corners 12:51:05 shepazu: [draws a star with rounded corners] 12:51:20 … [but only on the outer points] 12:51:54 shepazu: my proposal is that you bisect the angle, the center point of the circle is the point on that line in which a circle of that radius will fit 12:52:02 … you specify a radius 12:52:26 TabAtkins: this is like a custom line join? 12:52:41 shepazu: yes, basically 12:52:47 … a comma separated list that repeats like dash array 12:52:56 … you give a list of radii, and it applies them in sequence when a corner is encountered 12:53:58 TabAtkins: this is the arcTo from canvas 12:55:50 heycam: is this like a line join? 12:55:54 shepazu: but this should affect the fill 12:57:16 glenn has joined #svg 12:57:31 shepazu: with my proposal, you would say r="5", with Tab's proposal you'd have to change each edge in the path data 14:06:41 stakagi has joined #svg 14:07:08 TabAtkins has joined #svg 14:10:03 birtles has joined #svg 14:18:36 nikos has joined #svg 14:18:45 ChrisL has joined #svg 14:19:07 rrsagent, here 14:19:07 See http://www.w3.org/2012/09/19-svg-irc#T14-19-07 14:19:22 heycam: is this only straight line segments? 14:19:29 shepazu: no any segments 14:19:59 TabAtkins: you want to preserve curve continuity when you come into the arc 14:20:42 shepazu: Tab's counterproposal is better than what you can do in path today 14:20:46 TabAtkins: yes because you have to do trig 14:21:09 shepazu: this proposal could also apply to rect, polyline, polygon, star, connector 14:21:20 glenn has joined #svg 14:21:21 … on a connector, you might want it to go through an intermediate point (with an orthogonal connector) 14:21:30 … but with a rounded corner there 14:22:03 … this proposal reduces the amount that you have to type 14:22:12 … even on a , it's easy then to style it differently 14:22:17 … rather than tweaking the path data 14:22:26 TabAtkins: sounds good to me 14:22:56 … the math shouldn't be hard to describe 14:23:02 shepazu: I also want there to be a way to pull this out 14:23:12 … toPathData() on a shape 14:24:06 glenn has joined #svg 14:24:20 … I'm not sure I want to see it on path, but on all other polygon-like elements 14:24:23 krit has joined #svg 14:24:24 … on straight lines it's really easy 14:24:36 … but there could be some odd beziers that would have a bad effect with this 14:24:44 … so for paths leave it to arcTo, but r on other elements 14:25:14 … this property wouldn't give you control of x and y, just a single radius 14:25:29 … I'd like to see the difficulties it would introduce to path, because I'd like to see it there 14:25:47 TabAtkins: there will be some cases that will be difficult to translate into paths, and some that will look weird 14:28:27 shepazu: I don't mind about the edge cases 14:28:42 shepazu: sometimes it will add to the fill and sometimes it will remove from the fill 14:29:23 heycam: it always goes on the smaller angle? (<180 degrees?) 14:29:24 shepazu: yes 14:30:01 shepazu: the property would be dasharray-like, a sequence of radii 14:30:12 glenn has joined #svg 14:31:09 TabAtkins: if the r argument on a rect applied in the same order as border-radius that would be good 14:31:28 heycam: what about applying this to ? 14:31:34 shepazu: rx ry should win 14:31:56 shepazu: if it's not possible to fit the circle between the segments, then it gets skipped 14:32:06 TabAtkins: is this an attribute or a property? 14:32:08 shepazu: property 14:34:51 also a presentation attribute 14:34:53 TabAtkins: just call the property "r" 14:35:22 @tab all properties are also presentation attributes, in svg 14:35:52 ed: I want to allow the same thing that border-radius could do on rect 14:35:56 … different x/y radii 14:37:02 @ed but then you need to specify how to align the major and minor axes of the ellipses. circular radii are much easier for rounding arbitrary shapes 14:37:51 shepazu: ellipses would be hard 14:37:55 ChrisL, yes, I meant to make a specialcase 14:37:56 TabAtkins: and you'd have to worry about rotation 14:37:58 shepazu: let's not do radii 14:38:07 s/radii/different x and radii/ 14:38:11 *x and y 14:39:27 shepazu: the only element it wouldn't be allowed on is ellipse 14:40:03 Why not on a per element basis in general 14:40:23 circle, rect, ellipse doesn't make sense for me with a new r 14:40:41 rect does, since you can have different things at different corners 14:40:46 circle and ellipse I don't think it's needed 14:41:07 heycam: Isn't rx and ry enough on rect? 14:41:28 krit: they set the same radii on all vertices 14:41:33 @krit only one value for the whole rect, though 14:41:45 ok 14:42:46 although we could extend rx and ry on rect to allow (1..4) values 14:43:07 that's also an option, but if we allow this new property on polygon, polyline, etc. I think it makes sense to use it on rect too 14:43:28 birtles: when do you want to set different radii on different points? 14:43:38 TabAtkins: for the star example, you want radius, no radius, radius, no radius, ... 14:43:57 as noted earlier, rect differs by allowing elliptical arc (already). only circluar arc on plyline, polygon and path though 14:44:42 elliptical arcs make less sense (at least, they're harder) on non 90-degree angles 14:44:44 so, i thnk it does not make sense on rect and instead, the existing rx and ry should be extended to take a list 14:44:44 i.e. not rect 14:45:25 ChrisL, we're proposing both 14:45:25 TabAtkins: we can extend rx/ry attributes too 14:45:25 while adding the new r property on path, polygon, polyline and star 14:45:37 ok 14:47:26 RESOLUTION: We add Doug's r="" proposal for rounded corners for shape-y elements, and pending the math, for paths too. 14:48:07 RESOLUTION: We also allow rx/ry to extend to multiple values on rect. 14:48:26 ACTION: Doug to add the r="" proposal to SVG 2. 14:48:26 Created ACTION-3386 - Add the r="" proposal to SVG 2. [on Doug Schepers - due 2012-09-26]. 14:49:07 i can take the rx ry extending action 14:50:00 ACTION: Chris to extend rx/ry on rect to allow lists of values. 14:50:00 Created ACTION-3387 - Extend rx/ry on rect to allow lists of values. [on Chris Lilley - due 2012-09-26]. 14:50:23 there might be some complications with the DOM there, they're SVGAnimatedLengths now -- would they become SVGAnimatedLengthLists? not sure. 14:50:52 yes I suspect so 14:51:01 do people depend on that in code? 14:51:16 it's possible 14:51:20 since we're making them properties we'd need to probably change the DOM somehow anyway 14:51:23 less likely than x/y/width/height but certainly possible 14:51:34 so that could be a script breaking change 14:51:51 could be 14:51:55 it should be thought about ): 14:52:03 s/):/:)/ 14:53:10 Topic: JSON serialization 14:53:12 http://www.w3.org/Graphics/SVG/WG/wiki/Path_toJSON 14:53:46 TabAtkins: the one change I made to your page was removing the ability to do multiple segments with the one command letter 14:54:37 cabanier: you could make x/y/etc. into an array 14:55:27 shepazu: you could have p[0].x, p[0].y, p[1].x, p[1].y 14:55:33 TabAtkins: what does that buy you? 14:55:47 Zakim has left #svg 14:55:58 what? ZAKIM!!! 14:56:07 cabanier: it would help you iterate over them 14:56:13 Zakim has joined #svg 14:56:22 TabAtkins: you would never want to do that 14:56:38 shepazu: you also changed sweepFlag to clockwise 14:56:41 TabAtkins: yes 14:57:25 birtles: what's wrong with an array of points in each command? 14:57:29 TabAtkins: it's a bit harder to work with 14:57:49 … for a MoveTo, for example, instead of blah.x you have to do blah.p[0].x 14:57:57 couldn't it also mean that the number of input elements is unpredictable? 14:58:17 birtles: if you take this and turn it back into a string, it's easier if it's an array 14:58:39 birtles: there was one library I was using... 14:59:05 s/p\[0\].x/p\[0\]/ 15:00:28 … it uses points 15:00:33 … but I can see that could be cumbersome 15:00:46 heycam: if you have a fixed number of points per command (<= 4) which we do, then I think not use an array is better 15:01:48 shepazu: one downside to this is that it doesn't map to the existing path command letters 15:01:49 paper.js also has a Path API you could look at http://paperjs.org/reference/ 15:02:36 shepazu: this current proposal it's more verbose but clearer 15:02:45 cabanier: it doesn't use more memory really 15:02:57 ed: will we have path commands that take arbitrary parameter lists? 15:03:10 TabAtkins: you can't, because you can't do the automatic segment repetition that the existing commands do 15:04:19 TabAtkins: the catmull-rom command takes a list of points though 15:04:30 shepazu: yes I wanted to have a new "p" start a separate catmull-rom curve 15:11:23 ACTION: Tab to investigate paper.js' arcThrough 15:11:23 Created ACTION-3388 - Investigate paper.js' arcThrough [on Tab Atkins Jr. - due 2012-09-26]. 15:15:12 *krit: we're looking at the paper.js stuff * 15:23:12 Topic: JSON serialization of SVG 15:24:38 shepazu: there are some reasons to want a standardised JSON serialisation of markup in general, including SVG 15:24:43 … this is something that some script libraries do anyway 15:25:09 … it would be good to have a unified way for them to use JSON serializations of SVG 15:25:15 … rather than each have an ad hoc one 15:25:23 … another thing is it would be useful for postMessage 15:25:28 … this is more general than SVG really 15:25:36 … it wants to be able to serialise any given markup 15:25:48 … this is not recommended for browsers to implement 15:26:08 s/implemented/render/ 15:26:34 TabAtkins: we would attach a toJSON to Element, and a fromJSON to Document 15:28:05 -- end -- 15:28:12 RRSAgent, make minutes 15:28:12 I have made the request to generate http://www.w3.org/2012/09/19-svg-minutes.html heycam 15:28:38 Present: Erik, Cameron, Nikos, Doug, Tab, Rik, Cyril, Takagi-san, Tav, Konno-san, Brian 15:28:41 RRSAgent, make minutes 15:28:41 I have made the request to generate http://www.w3.org/2012/09/19-svg-minutes.html heycam 15:28:59 http://www.w3.org/Graphics/SVG/WG/track/issues/2050 15:31:47 stakagi: for the JSON path syntax, the names should align with the proposal for expanded path segment elements 15:31:51 RRSAgent: make minutes 15:31:51 I have made the request to generate http://www.w3.org/2012/09/19-svg-minutes.html heycam 15:51:10 jet has joined #svg 16:56:18 Zakim has left #svg 17:09:08 konno_ has joined #svg