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