ED: next, allow referencing root external files with use
00:33:56 [ChrisL]
ISSUE-2238:
00:35:00 [heycam]
DH: with <use>, you get the same animation timeline, vs if you use image
00:35:14 [heycam]
CM: also with events you can distinguish which shadow tree elements was clicked, for example
00:38:07 [heycam]
DH: would this apply to other things that reference external elements, like mask?
00:38:16 [heycam]
ED: maybe wouldn't make sense there
00:38:30 [heycam]
CC: there is the animation element in 1.2T, is that relevant here?
00:38:49 [heycam]
ED: but that only references a whole document anyway
00:39:07 [heycam]
CL: in 1.2T we split it up into <image> for more static images, and <animation> for animated ones
00:39:20 [heycam]
... with <animation> you can use the SMIL timing attribtues on it, so you can control its timeline separately
00:39:32 [heycam]
... but you can't do that with animated SVG referenced from <image>
00:40:02 [heycam]
... the name animation is confusing though, compared to animate
00:40:15 [heycam]
... in the end though image was able to point to svg content
00:40:40 [heycam]
... so we may or may not want to keep <animation>, possibly renamed
00:45:13 [heycam]
RESOLUTION: We will relax referencing requirements to particular elements to allow dropping fragments to mean referencing root element, where it makes sense, such as with use, in SVG2.
00:46:30 [heycam]
ACTION: Cyril to investigate whether more than use would benefit from relaxing reference requirements so that "blah.svg" refers to the root element
00:46:31 [trackbot]
Created ACTION-3157 - Investigate whether more than use would benefit from relaxing reference requirements so that "blah.svg" refers to the root element [on Cyril Concolato - due 2011-11-04].
action: chris to reply to alex explaining how wide gamut colours and flourewscent/metallic printing are accomodated in SVG color
16:57:41 [trackbot]
Created ACTION-3159 - Reply to alex explaining how wide gamut colours and flourewscent/metallic printing are accomodated in SVG color [on Chris Lilley - due 2011-11-04].
CM: perhaps tav can write up a summary of inkscape's non-scaling features
17:58:14 [dholbert]
TB: sure
17:58:38 [dholbert]
action: tav to write up summary of inkscape's non-scaling features, as possible candidates for svg2
17:58:38 [trackbot]
Created ACTION-3161 - Write up summary of inkscape's non-scaling features, as possible candidates for svg2 [on Tavmjong Bah - due 2011-11-04].
18:00:12 [dholbert]
resolution: svg2 should include non-scaling features, aside from non-scaling stroke. (2 separate components: non-scaling part of the object, and non-scaling entire object)
CL: the start point of the dashing on basic shapes like circles
18:17:00 [dholbert]
CL: and on multi-segment paths, e.g. if you're partway through a dash at the end of one segment, do you start the next segment with just a partial dash
18:17:20 [dholbert]
resolution: svg2 shall specify stroke dashing more precisely
TB: Couple problems with trying to use patterns for this. one is, if you use a diagonal line, you'll often get misalignments
18:22:25 [dholbert]
TB: also, SVG is used for e.g. engravers, who want to be able to do one continuous stroke across a background.
18:22:35 [dholbert]
CL: same applies to plotters
18:23:41 [dholbert]
CM: not sure if this would have a predefined set of hatches, or let you define your own
18:24:39 [dholbert]
CC: could be useful for cartoons
18:25:21 [dholbert]
ED: though in that case you could probably just use a pattern
18:26:00 [ChrisL]
Hatching (hachure in French) is an artistic technique used to create tonal or shading effects by drawing (or painting or scribing) closely spaced parallel lines
VH: I've encountered the issue with patterns. the main convincing argument to me is TB/CL's points about one needing continuous lines for certain use-cases
18:27:05 [dholbert]
CM: It seems like something worth looking into
18:28:09 [dholbert]
resolution: svg2 should support hatching without the artifacts that patterns currently impose
CC: jasper proposed nonlinear transforms; that's what vertex shaders are about
18:52:02 [dholbert]
VH: you actually deform a texture; you're not deforming the geometry itself
18:52:21 [tbah]
Conference timed out, could you restart?
18:52:44 [Zakim]
-tbah.a
18:52:45 [Zakim]
Team_(svg)17:47Z has ended
18:52:45 [Zakim]
Attendees were +1.650.693.aaaa, tbah
18:52:52 [heycam]
Zakim, code?
18:52:52 [Zakim]
the conference code is hidden, heycam
18:52:57 [heycam]
Zakim, room for 3?
18:52:58 [Zakim]
ok, heycam; conference Team_(svg)18:52Z scheduled with code 26631 (CONF1) for 60 minutes until 1952Z
18:52:59 [heycam]
Zakim, code?
18:52:59 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam
18:53:06 [tbah]
Thanks
18:53:45 [Zakim]
Team_(svg)18:52Z has now started
18:53:52 [Zakim]
+tbah
18:53:54 [Zakim]
+tbah.a
18:55:34 [heycam]
Zakim, who is on the call?
18:55:34 [Zakim]
On the phone I see tbah, tbah.a
18:58:25 [dholbert]
CC: jasper wanted to separate the gradient map from the transformation map
18:58:40 [dholbert]
CC: the transformation map could be used for text warping or object warping
18:59:01 [dholbert]
CC: I think it's very similar to vertex shaders; you have an initial object, you give the end object, and you interpolate in between
18:59:26 [dholbert]
CM: If we have vertex shaders, do we need this?
18:59:40 [dholbert]
CL: Shaders are about transforming the rendered result; this is about transforming the geometry
19:00:55 [dholbert]
VH: For example, if you're transforming a curve into a curve, a vertex shader would transform it into small line segments - not actually transform the geometry
19:01:05 [dholbert]
s/transforming a curve/transforming a straight line/
19:02:18 [dholbert]
CM: we're already getting perspective transforms from CSS3 transforms, right?
19:02:30 [dholbert]
VH: yes, but that's transforming the rendered output, not the geometry
19:03:57 [dholbert]
VH: in SVG, with geometry transforms, we think about it transforming the bounding box. With a warp filter, you wouldn't get the bounding box from the resulting rendered output
19:04:23 [dholbert]
TB: How do you define these transforms?
19:04:29 [dholbert]
CM: That's an open question
19:04:37 [dholbert]
TB: mathematical equations?
19:04:45 [dholbert]
CC: or you provide a grid before/after
19:05:38 [dholbert]
CC: I'm concerned in terms of authoring, that you'd end up with lots of shaders, lots of GLSL - not really declarative.
19:06:26 [dholbert]
CC: it should be possible to specify a transformation without writing a shader
19:06:50 [dholbert]
CM: In some ways I'd like to be able to do fancy warping, but it seems like a really open-ended/big feature
19:07:27 [dholbert]
CL: mercator was one of the suggested transformations; if we were to make a fixed list of allowed transformations, someone's always going to want a different one
19:07:36 [dholbert]
CL: so it'd need to be customizable
19:08:00 [dholbert]
CL: so I have concerns over complexity & extensibility
TB: this is a good idea; you also need to be able to specify the center of rotation
19:25:11 [dholbert]
CL: We get this for free in the CSS transforms
19:25:32 [dholbert]
CM: hopefully all the CSS properties we support will have presentational attributes, too
19:25:33 [dholbert]
CL: yes
19:25:45 [shepazu]
shepazu has joined #svg
19:26:15 [dholbert]
CC: So in CSS, this is the "transform-origin" property?
19:26:33 [dholbert]
CL: yes. CSS defaults to rotating about the center, whereas SVG defaults to rotating about upper-left corner
19:27:11 [dholbert]
TB: how do you get the center of e.g. a rotating 5-pointed star, where the bounding box changes as it rotates?
19:27:25 [dholbert]
VH: the center of rotation would be chosen pre-transform
19:28:09 [dholbert]
resolution: we will ensure there is a way to specify rotations around particular points and shapes
19:29:11 [dholbert]
TB: Inkscape stores a transformation center; used for scaling, for skewing
19:29:18 [dholbert]
TB: not just for rotations
19:29:29 [dholbert]
VH: something similar in illustrator, too
19:31:02 [Zakim]
-tbah.a
19:31:06 [Zakim]
-tbah
19:31:07 [Zakim]
Team_(svg)18:52Z has ended
19:31:07 [Zakim]
Attendees were tbah
19:32:13 [thorton]
thorton has joined #svg
19:33:41 [thorton]
thorton has joined #svg
19:38:19 [plinss]
plinss has joined #svg
20:01:11 [cyril]
cyril has joined #svg
20:59:07 [jun]
jun has joined #svg
21:02:07 [jen]
jen has joined #svg
21:02:16 [cyril]
cyril has joined #svg
21:02:23 [ed]
scribeNick: ed
21:02:30 [ed]
topic: vector effects
21:02:45 [ed]
CL: geometry api?
21:02:54 [ed]
CM: vincent wanted to talk about that
21:03:03 [ed]
... maybe we can have that discussion later
21:03:05 [ChrisL]
action-1?
21:03:05 [trackbot]
ACTION-1 does not exist
21:03:10 [ChrisL]
action-100?
21:03:10 [trackbot]
ACTION-100 does not exist
21:03:29 [ed]
... we were discussing having better interfaces for points, paths, and combining and offsetting
21:03:46 [ed]
CL: the other one was stroke-below-fill
21:04:18 [ed]
... assuming this ends up as a vector-effect value
21:04:35 [ed]
DS: i suspect that CSS ppl are going to think it's like an underline
21:04:57 [ed]
CL: fill then stroke then markers
21:05:16 [ed]
DS: what if it's the middle thing?
21:05:22 [ed]
CL: markers, fill, then stroke?
21:05:39 [ed]
DS: it's not the full functionality, it's a shorthand
21:06:01 [ed]
CC: what if you wanted to have both non-scaling-stroke AND stroke-below-fill?
21:06:17 [ed]
... what's the philosophy behind the vector-effects property?
21:06:24 [ed]
CL: it's like a filter effect
21:07:27 [ed]
... I could do add combination value keyword
21:07:40 [ed]
CM: concerned about using vector-effect for this
21:08:05 [ed]
CL: most things in filter effects are called 'feSomething', and in vector effects 'veSomething'
21:08:43 [ed]
DS: is the property vector-effect appropriate and intuitive to what ppl would expect?
21:08:53 [ed]
... what if you wanted the fill on top of the stroke for text in html?
21:09:02 [ed]
... do we have the same mechanism for that?
21:09:19 [ed]
CM: so you want a slightly differnt way to express this, rihgt?
21:09:51 [ed]
... mapping the "i want stroke under the fill" to using "vector-effects" perhaps is not so intuitive
21:10:14 [ed]
... though having them separate might make it harder for linking it to vector-effects
21:11:05 [ed]
CM: we have existing stroke and fill, and that's input to the vector effects
21:11:18 [ed]
CL: plus the styling
21:12:14 [ChrisL]
stroke-order: above-fill (default) | below-fill
21:12:53 [ed]
CM: it's not the order that's below the fill
21:13:58 [ed]
DS: maybe we could have a poll to what's most intuitive?
21:14:21 [ed]
CM: but maybe we could resolve on separating the property out, not making it a vector-efffect shorthand
21:14:57 [ChrisL]
paint-order: fill-stroke-marker| stroke-fill-marker | and so on
21:16:29 [ed]
RESOLUTION: we will have a property that means stroke underneath fill vector-effect shorthand, but not using the vector-effect property
21:17:32 [ed]
CL: do we want to use vector-effects=non-scaling-stroke as is, or separate it out?
21:17:59 [ed]
DS: could be a threshold, scale up as much as it can go, but min value is 1
21:18:14 [ed]
CM: would like to see this as a separate property for non-scaling-stroke
21:18:38 [ed]
DS: helps discoverability
21:19:10 [ed]
ED: so vector-effects would only be the url() syntax?
21:19:30 [ed]
CM: if we don't come up with something else that we can use as shorthands
21:20:42 [ed]
ED: slight concern about backwards compat, since it's implemented as a vector-effect shorthand already
21:21:36 [ed]
... also non-scaling-stroke="yes|no"? seems a bit silly
21:22:11 [ed]
... and all other stroke properties are prefixed 'stroke-'
21:22:31 [ed]
DS: to me it's a vector-effect, underneath it's the same thing
21:22:49 [ed]
... doesn't need to be called vector effect...
21:26:09 [ed]
CM: it's not terrible in vector-effects, but i'd prefer it as a separate attribute
21:29:03 [ed]
... the painting order is a simple thing compared to the vector effects
21:29:50 [ed]
RESOLUTION: we will keep vector-effect=non-scaling-stroke as is
21:31:12 [plinss]
plinss has joined #svg
21:34:27 [stakagi]
stakagi has joined #svg
21:35:00 [stakagi]
Initially, I thought that ref (svg, x, y) made it satisfied for non-scaling-whole-objects.
21:35:17 [stakagi]
But, another fixed-size-shapes may be required.
21:35:26 [stakagi]
Differ from the ref(svg,x,y), for map usecase totally fixed-size-shape are required, such as line-width of vector effects. By ref(svg,x,y), shape size is fixed but initial size is not fixed according to ( SVG user agent viewport and viewBox))
21:35:27 [heycam]
stakagi, I think that's true, as long as the appropraite coordinate space is the root element
21:35:34 [ed]
CL: yes, we mentioned ref before, it's on the requirements list right?
21:35:58 [stakagi]
This matter is pointed by Alex
21:36:27 [ed]
CM: so you want to get around the outermost svg scaling and get a fixed pixel size for the scaling to screen
CM: i wrote this proposal to address adaptive stroke-dashing
22:10:38 [ed]
[CM draws on whiteboard]
22:11:40 [ed]
CM: to adjust the dashes to e.g get a dash at the start and the end of a path, and then space the rest out along the curve
22:11:58 [ed]
CL: another case is for rectangles, where you want the corners to have dashes
22:12:39 [ed]
CC: if you have percentages for stroke-dasharray / dashoffset maybe it would address some part of this
22:12:49 [ed]
CL: stroke-dasharray-adjust
22:13:29 [ed]
CM: either stretch the gaps, or stretch the dashes, or both
22:13:40 [ed]
CC: or compress
22:16:22 [ed]
CM: maybe what this proposes is too much control
22:16:30 [ed]
DS: yes, DWIM or auto might be better
22:23:20 [ed]
CC: i think having stretch and compress is enough
22:24:20 [ed]
... so compress, take an integer number, say you have 2.5 times the dashes, it would do 3 and the compress it to fit
22:24:53 [ed]
CL: in some cases you don't want to change the lenght of the dashes
22:25:16 [ed]
CC: if it's closed you keep the last gap, otherwise remove it
22:25:31 [ed]
CM: my proposal is a little bit different
22:26:57 [ed]
[general discussion and drawing on whiteboard]
22:28:23 [ed]
CC: so maybe it's more about keeping the last gap or not
22:29:02 [ed]
DS: which case are you optimizing for CM?
22:33:16 [ed]
CM: maybe we should get rid of compress, and just have stretch?
22:33:31 [ed]
CC: both are useful, if you end in the middle of a dashpattern
22:33:34 [ed]
...it's like a rounding
22:33:45 [ed]
CL: whichever one has the least change
22:34:11 [ed]
DS: people probably rather want dashes that are of equal size
22:34:23 [ed]
... and the rect corner thing
22:34:38 [ed]
CM: my proposal addresses that, bottom half of the page
22:35:01 [ed]
CM: i'm unconfortable with having 4 options
22:35:26 [ed]
CL: people that are pushing for this want more control
22:35:53 [ed]
DH: as long as there's good fallback behavior
22:36:02 [ed]
CM: you want auto to be something like round gaps
22:36:22 [ed]
CL: you want auto to do what is done currently, otherwise it would change current behaviour
22:37:09 [ed]
CC: are dashes fixed? if you increase length of path, you get more and more dashes and gaps, right?
22:37:50 [ed]
... if you animate it it will blip when it does the rounding to an integer number of dashes/gaps
22:38:07 [ed]
CM/CL: yes, that's unavoidable
22:40:12 [ed]
CC: maybe we can start with this proposal, even if it's too much control
22:41:57 [ed]
RESOLUTION: the proposal for stroke-dash-adjust pending modification for edge-cases (open path vs closed path, impossible compression of gaps, round vs ceil)
22:42:33 [ed]
ACTION: cameron to update the stroke-dash-adjust proposal to address the edge-cases mentioned in the above resolution
22:42:33 [trackbot]
Created ACTION-3163 - Update the stroke-dash-adjust proposal to address the edge-cases mentioned in the above resolution [on Cameron McCormack - due 2011-11-04].
22:53:35 [cyril]
s/round vs ceil)/round vs ceil) is accepted/
23:08:26 [cyril]
scribe: cyril
23:08:33 [cyril]
topic: SVG Params
23:09:31 [cyril]
CL: Sairus Patel was yet another person who raised the problem that colors are baked in, and Params could be a solution
23:09:49 [cyril]
DS: I thougt about this use case before
23:09:59 [cyril]
CM: I'm curious how the params would be set
23:10:06 [cyril]
... in the font URL or on the text element
23:10:27 [cyril]
ED: it would be nice to pass it on the whole font face
23:10:57 [cyril]
CC: what's the status of the spec right now? stable ?
23:11:19 [cyril]
DS: no, there are 2 models and I can't decide which one is the best
23:11:56 [cyril]
... I don't define what happens when the types are wrong, it's not strongly typed
23:12:59 [cyril]
CM: in the first you declare the params that the document is expected and you provide fallback
23:13:19 [cyril]
... in the second, you don't provide fallback but the use of the param has to provide fallback
23:14:42 [cyril]
DS: I think the one implemented by Adobe is the one in TR, with one level of indirection
CM: but I think this is the wrong solution to achieve that gradient effect
00:34:22 [heycam]
ED: the tubefy thing is what I've heard the most requests for
00:34:33 [heycam]
DS: the extruded text also interests me
00:35:02 [heycam]
... but I don't see people wanting to do this in production apps
00:35:13 [heycam]
... for 3D things they would use WebGL
00:36:25 [heycam]
CM: I love these effects, but I am worried about this not being practical enough for the complexity of a performant implementation
00:37:37 [heycam]
ED: the script library is very small
00:37:56 [heycam]
JY: have other people been using his script?
00:38:53 [heycam]
DS: that tubefy example is Israel Eisenberg redoing his gradient worm with replicate
00:39:45 [heycam]
DS: I think that is a good point, is anyone else doing stuff with it?
00:40:57 [heycam]
JY: if people use this script library, then it's a good hint to include the functionality, because you get the advantage of not needing DOM nodes in the native implementation
00:41:12 [heycam]
DS: two things would change my mind
00:41:21 [heycam]
... one, if we saw an uptake of people using the script library to solve the problems they have
00:41:56 [heycam]
... and two, if we saw more concrete examples of practical uses of the library
00:42:07 [heycam]
... using it to solve a problem
00:42:47 [heycam]
CC: we have browsers, and authoring tools in the group, and we haven't had any people crying out that they really want this
00:44:14 [heycam]
RESOLUTION: We will not include replicate in SVG2 unless accompanied by concrete use cases and demonstration of author/implementor interest.
00:45:48 [heycam]
DS: I would like to see a spec just to see if it can yield other solutions, to see what emerges from it
00:45:59 [heycam]
Topic: Turtle graphics
00:46:03 [heycam]
DS: there are two aspects of turtle graphics
00:46:10 [heycam]
... there's the replicating patterns, which is more ambitious
00:47:48 [heycam]
... and the other is Cameron's proposal, which does not include repetition
00:48:55 [heycam]
CM: I think we need to see some justification for extending my turtle graphics to the more general form
00:49:13 [heycam]
... since mine are grounded in particular use cases, for example animating angles between path segments, easily creating pie chart shapes, etc.
00:50:17 [heycam]
... general logo-like graphics, I'm not sure what the practical reason to include that
00:50:43 [heycam]
RESOLUTION: We will not include general turtle graphics in SVG2 without examples of practical reasons to do so.
00:55:09 [heycam]
Topic: Smooth curve through points
00:55:14 [heycam]
CM: this is just catmull-rom curves
00:55:20 [heycam]
... which we have already decided to include
00:55:35 [heycam]
RESOLUTION: We will include smooth path between points functionality in SVG2.