IRC log of svg on 2014-04-09

Timestamps are in UTC.

07:06:28 [RRSAgent]
RRSAgent has joined #svg
07:06:28 [RRSAgent]
logging to http://www.w3.org/2014/04/09-svg-irc
07:06:30 [trackbot]
RRSAgent, make logs public
07:06:30 [Zakim]
Zakim has joined #svg
07:06:32 [trackbot]
Zakim, this will be GA_SVGWG
07:06:32 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
07:06:33 [trackbot]
Meeting: SVG Working Group Teleconference
07:06:33 [trackbot]
Date: 09 April 2014
07:06:38 [heycam]
Chair: Cameron
07:06:52 [heycam]
Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Leipzig_2014/Agenda
07:10:30 [heycam]
Scribe: Cameron
07:10:32 [heycam]
ScribeNick: heycam
07:10:38 [heycam]
Topic: Automated filter regions
07:10:55 [krit]
https://www.w3.org/Graphics/fx/wiki/Filter_effects#Automated_Filter_Region_calculation
07:11:05 [heycam]
krit: I'm currently working on automated filter region calculation code
07:11:11 [heycam]
... I know blink did some work on that
07:11:19 [heycam]
... to minimize the effected area as much as possible
07:11:33 [heycam]
... I'd be happy if there would be some contributions on how this should work
07:11:52 [heycam]
... the main problem is if you do not have limits at the beginning, and you use primitives like feTurbulence, that don't have bounds
07:11:56 [heycam]
... or lighting effects
07:12:01 [heycam]
... this could affect the whole canvas
07:12:04 [heycam]
... which isn't necessarily what you want
07:12:11 [heycam]
... currently we have the 10% bounds around the objectBoundingBox
07:12:16 [heycam]
... getting rid of that for gaussian blur would be good
07:12:25 [heycam]
... you can calculate the boundaries automatically
07:12:31 [heycam]
... for displacement map, turbulence, etc., there's no bounds
07:12:34 [heycam]
... what should we do for them
07:12:59 [heycam]
... should we clip to the viewport -- possible, but a lot bigger than you need -- or take the old 10% filter margins?
07:13:24 [heycam]
heycam: did roc suggest getting rid of those attributes altogether?
07:13:34 [heycam]
krit: no, but he said if you don't specify them then the bounds should be calculated automatically
07:13:49 [heycam]
Tav: you can calculate the maximum displacement
07:13:53 [heycam]
krit: it could still be huge though
07:14:03 [heycam]
... and for turbulence, there's no hint about how big it should be
07:14:12 [heycam]
Tav: it's only useful to have turbulence as input for something else
07:14:17 [heycam]
... so you have to work backwards to work it out
07:14:27 [heycam]
heycam: you must be able to work it out
07:16:08 [heycam]
Tav: the filter is applied to the object. you have the object size.
07:16:15 [heycam]
krit: feTurbulence is not limited to the object size
07:16:43 [heycam]
cabanier: what about keeping the current behaviour but special casing blur, color matrix, etc.?
07:19:24 [heycam]
heycam: what about finding the maximum rectangle based only on the primitives that you can work it out for
07:19:42 [heycam]
... and then use the union of those rectangles for the remaining ones like turbulence
07:20:02 [Tav]
Tav has joined #svg
07:21:38 [heycam]
krit: the 10% fallback might be easier, since implementations already handle that, but it's not good for authors
07:23:53 [heycam]
heycam: what is more useful for authors if they use only an infinite extent filter primitive?
07:24:00 [heycam]
... I don't like the 10%
07:24:45 [stakagi]
stakagi has joined #svg
07:25:01 [heycam]
krit: who prefers viewport and who prefers the 10% limit?
07:25:07 [heycam]
pdr: viewport, though that will be slower
07:25:19 [heycam]
Tav: if you have a flood fill, that will now go everywhere
07:25:23 [heycam]
... could break content
07:25:35 [heycam]
krit: you can always specify x/y/width/height if you need to
07:25:41 [heycam]
ed: leaning towards 10% margin
07:26:10 [heycam]
pdr: how does CoreImage handle this? or other native APIs?
07:26:14 [heycam]
krit: don't know how CoreImage does it
07:26:19 [heycam]
cabanier: you have to set it up yourself right?
07:26:28 [heycam]
krit: you give the images as input, so you don't run into the infinite extent issue
07:26:39 [heycam]
cabanier: doesn't IE have all of these optimizations?
07:27:32 [heycam]
Tav: how does turbulence work, does the pattern shift?
07:27:35 [heycam]
krit: I think it would
07:29:39 [heycam]
davve: are users complaining about this?
07:29:49 [heycam]
krit: new users don't understand these 10% margins at all
07:29:57 [heycam]
ed: it's usually people using gaussian blur
07:30:56 [heycam]
heycam: would content break if we just said turbulence defaults to 0,0,100%,100% unless attributes are given on the primitive?
07:30:59 [heycam]
krit: I think it would
07:32:32 [heycam]
... should we defer this decision, or can we come to a conclusion?
07:32:42 [heycam]
... I'd be fine with using 10% margin for now, but at least for things that are unbounded
07:32:46 [heycam]
... and try to be smart for other cases
07:33:06 [heycam]
Tav: if there is a primitive you cannot figure out, you use the 10%
07:34:37 [heycam]
heycam: are you able to write down in the spec exactly when we have to use the 10% then?
07:34:38 [heycam]
krit: yes
07:35:19 [heycam]
... a lot of authoring tools in the past set the filter region to the whole viewport
07:35:24 [heycam]
ed: if you don't optimize it's going to be super slow
07:36:04 [heycam]
... I know I saw some diagram with lots of little cloud shapes, and each had a filter applied
07:36:10 [heycam]
... it was very slow
07:36:20 [heycam]
Tav: there is badly authored content out there
07:36:40 [heycam]
heycam: I think Omnifgraffle at one point was outputting large filter regions
07:40:07 [heycam]
RESOLUTION: For filter primitives that are unbounded, and the size cannot be computed automatically, the default filter region will be -10%,-10%,120%,120%
07:40:26 [heycam]
krit: next is the lighting filters
07:40:41 [heycam]
... in Blink/WebKit, they are treated as infinite extent
07:40:43 [heycam]
... but not in Gecko
07:42:34 [heycam]
[dirk shows an example]
07:43:19 [krit]
SVGFEPointLightElement-svgdom-y-prop.html
07:43:28 [heycam]
... in Firefox the output of the lighting primitive is limited to exactly the size of the input
07:43:41 [heycam]
Tav: I think that's wrong, and Blink/WebKit are right
07:44:09 [heycam]
Zakim, remind me in 8 hours to go home
07:44:09 [Zakim]
ok, heycam
07:46:10 [ed]
https://webkit.googlesource.com/WebKit/+/master/LayoutTests/svg/dynamic-updates/script-tests/SVGFEPointLightElement-dom-y-attr.js is what it generates
07:46:35 [krit]
http://trac.webkit.org/export/167007/trunk/LayoutTests/svg/dynamic-updates/SVGFEPointLightElement-svgdom-y-prop.html
07:49:17 [krit]
<svg:svg width="300" height="300"><svg:defs><svg:filter id="myFilter" filterUnits="userSpaceOnUse" x="0" y="0" width="200" height="200"><svg:feGaussianBlur in="SourceGraphic" stdDeviation="2" result="blur"></svg:feGaussianBlur><svg:feDiffuseLighting in="blur" surfaceScale="1" diffuseConstant="1" lighting-color="yellow"><svg:fePointLight x="100" y="180"
07:49:17 [krit]
z="30"></svg:fePointLight></svg:feDiffuseLighting></svg:filter></svg:defs><svg:circle width="200" height="200" cx="100" cy="60" r="50" filter="url(#myFilter)"></svg:circle></svg:svg>
07:51:02 [heycam]
heycam: I think it is just a bug in firefox
07:51:14 [heycam]
krit: and IE11 matches Blink etc.
07:51:17 [heycam]
... so I will leave the spec as is
08:00:10 [heycam]
Topic: animation of filter effects
08:00:19 [heycam]
krit: Brian wrote a good summary
08:00:24 [heycam]
... we got one reply
08:00:27 [heycam]
birtles: we talked about it a bit further in Web Animations
08:01:28 [birtles]
some discussion here: http://lists.w3.org/Archives/Public/public-fx/2014JanMar/0118.html
08:01:58 [birtles]
original discussion here: http://lists.w3.org/Archives/Public/public-fx/2014JanMar/0063.html
08:02:15 [stakagi_]
stakagi_ has joined #svg
08:03:10 [heycam]
... I'll summarise
08:03:16 [heycam]
... there's different ways of adding things together
08:03:46 [heycam]
... if you have two animations which are targetting the same element, and they're independent animations, and they're both applying a filter to the element, then visual result you expect is equivalent to building up a list
08:03:51 [heycam]
... suppose they're both applying a blur of radius 2
08:03:56 [heycam]
... the equivalent visual result is blur(2)blur(2)
08:04:00 [heycam]
... so you append onto the list
08:04:09 [heycam]
... but for SVG there's also cumulative animation
08:04:15 [heycam]
... where the same animation builds on its own result
08:04:23 [heycam]
... that should give you a different result after 2 iterations, blur(4)
08:04:29 [heycam]
... this comes up with transforms as well
08:04:34 [heycam]
... if you have skew(22)
08:04:40 [heycam]
... if you accumulate that three times, you should get skew(66)
08:04:52 [heycam]
... after three iterations
08:05:26 [heycam]
... but if you have three indepedent animations with skew(22) and they're additive, you use post-multiplication to get skew(22)skew(22)skew(22)
08:05:31 [heycam]
... so that's two different kinds of "addition"
08:05:40 [heycam]
... that's something we've realised in Web Animations, we know two different ways to add
08:05:49 [heycam]
... for most things they're identical, say for lengths
08:05:53 [heycam]
... but for some types they're different
08:05:58 [heycam]
... for filters that's an example where they're different
08:06:12 [heycam]
heycam: is it just when you have lists?
08:06:14 [heycam]
birtles: doesn't have to be
08:06:22 [heycam]
... for transform lists you don't have to build up the list, you can use post-multiplication
08:06:26 [heycam]
... the effect is the same there
08:06:40 [heycam]
heycam: do you have an exhaustive list?
08:06:46 [heycam]
birtles: so far it's just filters and transforms where this has come up
08:07:06 [heycam]
... another reason it's important to make the distinction, with cumulative animation, the list gets longer each time you repeat
08:07:29 [heycam]
... so it's advantageous to define the operation differently for filter lists
08:07:42 [heycam]
... it's basically a component-wise addition rather than an independent combination
08:07:55 [heycam]
... so we've defined this already in Web Animations
08:08:20 [heycam]
birtles: for any data type we define how to interpolate, how to compute distance, how to add, and how to accumulate
08:09:12 [heycam]
... you don't have to define all of these operations
08:09:21 [heycam]
... the definitions say if there's no cumulate addition operation for this type, use normal addition
08:09:31 [heycam]
... if that's not defined, it uses "non-additive" addition, i.e. just use the RHS
08:09:38 [heycam]
krit: this relies on Web Animations defining the types
08:10:14 [heycam]
... for filter effects, I don't want to have infinite lists
08:10:20 [heycam]
birtles: for filters we need to define how accumulation works
08:10:33 [heycam]
... and I think we need to define that in terms of matching up filter primitives, starting from the rhs, and adding the component values
08:11:11 [heycam]
krit: another problem is that a lot of the values that pass are not linear
08:11:14 [heycam]
... greyscale for example
08:11:21 [heycam]
... and just adding these numbers would give a non-linear behaviour
08:11:26 [heycam]
... for some of the filter functions it's not even computable
08:11:37 [heycam]
ChrisL: can the distance metric not linearise it?
08:12:39 [heycam]
birtles: it's up to the spec to define how to combine the numbers for the cumulative addition
08:12:52 [heycam]
krit: for some primitives I just don't know how to combine the numbers
08:13:03 [heycam]
Tav: if you apply a gaussian blur twice to something, it's not the same as doubling it
08:13:08 [heycam]
birtles: it's up to you to think for each one
08:13:19 [heycam]
... if you were to make this animation, and run it twice and build on the result, what's the expected result of that
08:13:26 [heycam]
... define the operation in those terms
08:13:38 [heycam]
... it's up to the spec author who introduces a new animatable type
08:13:54 [heycam]
krit: I'd rather not allow the addition then
08:13:57 [heycam]
birtles: I think we should work it out
08:14:04 [heycam]
... I think it's useful to have additive animations
08:14:18 [heycam]
... as long as you're defining that additive animation, you should define the cumulative one as well, so you don't get longer lists
08:14:26 [heycam]
krit: additive is one part
08:14:34 [heycam]
... if you have two blurs you add the two numbers
08:14:40 [heycam]
birtles: if they're independent animations you do append to the list
08:14:46 [heycam]
... you don't have the problem of the list building forever
08:14:55 [heycam]
krit: I think that's what I specify at the moment
08:15:01 [heycam]
... assume that all of the primitives are linear
08:15:13 [heycam]
... not sure how to figure it out
08:15:21 [heycam]
birtles: might work just to add for blur
08:15:40 [heycam]
birtles: if you're animating a blur from 0 to 2, and then you say run it again and build on your result, going 2-4 is what you're asking for
08:16:00 [heycam]
krit: I think that's what we do right now. if you animate stdDeviation on the SVG filter, you have linear accumulation
08:16:09 [heycam]
... therefore that's what you do at the moment with SMIL animations
08:16:18 [heycam]
... so for blur and drop-shadow maybe you can do the same
08:16:25 [heycam]
... so what about distance, for paced animations?
08:16:33 [heycam]
birtles: there are a bunch of definitions for different data types
08:16:48 [heycam]
... if there's no meaningful sense of distance for a datatype, don't define it
08:16:58 [heycam]
krit: I don't think distance makes sense for filters
08:17:37 [heycam]
birtles: in the short term we can say there is no distance function for filters
08:21:31 [heycam]
-- break --
08:26:36 [shepazu]
shepazu has joined #svg
08:37:55 [stakagi]
stakagi has joined #svg
08:40:45 [nikos]
nikos has joined #svg
08:41:43 [nikos]
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Advanced_Gradients
08:42:14 [heycam]
Topic: Advanced gradients beyond SVG 2
08:43:00 [ChrisL]
ChrisL has joined #svg
08:43:13 [heycam]
nikos: I wanted to have a high level discussion on the possibility of extending the advanced gradients in SVG after SVG 2
08:43:26 [heycam]
... it might seem premature to talk about that now, but the reason I bring it up is that Canon is willing to put some time towards this
08:43:35 [heycam]
... and we want to get feedback from the group if they're interested in in the future
08:43:39 [heycam]
... if it's a good way to spend our time
08:43:57 [heycam]
... we think there are two ways to extend the advanced gradients
08:44:05 [heycam]
... one is diffusion curves, which is something we're particularly interested in
08:44:12 [heycam]
... we gave a talk at SIGGRAPH last year about our research
08:44:21 [heycam]
... and I talked last year at Graphical Web about them in SVG
08:44:34 [heycam]
... the other thing is a stepping stone, or maybe complementary, is to extend the mesh gradients
08:44:39 [heycam]
... SVG 2 has the coons patch gradients
08:44:51 [heycam]
... but there are some issues with those, and there are some other representations we might want to look at
08:44:59 [nikos]
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Advanced_Gradients
08:45:07 [heycam]
... to start with diffusion curves, there are some examples on the wiki page
08:45:25 [heycam]
... I'm assuming everyone knows how they work
08:46:59 [heycam]
birtles: is the same as edge blends?
08:47:06 [heycam]
nikos: not totally sure
08:49:06 [heycam]
ChrisL: so diffusion curves, the curves are a boundary, and I was talking with some font designers getting interesting in coloured fonts
08:49:15 [heycam]
... they wanted the center curve of the shape to be what constrained the gradient
08:49:24 [heycam]
nikos: see the tube example on the wiki page
08:49:54 [heycam]
... see also the biharmonic model. both the inria people and we have a colour on the left and on the right, and you can also control the gradient along each curve
08:49:59 [heycam]
... that lets you get a smooth profile through the curve
08:50:11 [heycam]
... then you can conceptually assign one colour to the curve, and get a smooth gradient through the center
08:50:12 [ChrisL]
https://gist.github.com/mbostock/4163057
08:50:41 [heycam]
nikos: is that a linear gradient along the path?
08:50:42 [heycam]
ChrisL: ye
08:50:45 [heycam]
s/ye/yes/
08:51:07 [heycam]
nikos: if you were to do that with diffusion curves, you would have the outside paths, and assign green at the control points at one end and red to the points at the other end
08:51:51 [heycam]
ChrisL: I was talking to John Hudson and said font designers were worried that linear and radial gradients weren't sufficient
08:52:48 [heycam]
nikos: diffusion curves and gradient meshes make the same sort of images
08:52:55 [heycam]
... smooth transitions, and discontinuities
08:53:05 [ChrisL]
s/and said/and he said/
08:53:14 [heycam]
... the benefit of diffusion curves, and I think it fits well with SVG, is that it's a more compact representation
08:53:24 [heycam]
... the initial motivation was to mimic what artists draw
08:53:30 [heycam]
... outlines first, then fill between them with colours
08:53:52 [heycam]
... and it also lends itself well to animation
08:55:07 [heycam]
nikos: inria have contacted me, and they're interested in collaborating on diffusion curves for SVG or some other kind of mesh for SVG
08:55:16 [heycam]
... they'll be releasing a library soon that implements their method
08:55:20 [heycam]
... so will be interesting to see performance of that
08:55:41 [heycam]
ChrisL: the coons patches have the property of smoothness within a patch, and no continuity between patches
08:55:55 [heycam]
... is there a way to have a type of patch that you can specify a type of continuity between catches?
08:56:31 [heycam]
nikos: there are a few mesh formats that satisfy that
08:56:46 [heycam]
... inria's solver generates a triangle mesh that does have those properties, since it follows that biharmonic model with smooth transitions across boundaries
08:57:13 [heycam]
... illustrator's representation they show to the author have those properties, but they subdivide when exporting to patches
08:57:38 [heycam]
Tav: if you look at an output from Illustrator, you can see the lines
08:57:47 [heycam]
ChrisL: seems like an easier way than subdividing and bulking up the content
08:57:55 [heycam]
ChrisL: just have formulation of the patches that have the property you want
08:58:05 [heycam]
nikos: that's something the inria guys wanted to see in SVG
08:58:20 [heycam]
... it's more general, better for vectorisation of images too
08:58:25 [heycam]
... I think that could complement diffusion curves
08:58:39 [heycam]
... diffusion curves for simpler gradients, and meshes for great big areas
08:58:50 [heycam]
... I think we'd be interested in following both paths
08:58:56 [heycam]
ChrisL: I like the suggestion to rename the mesh gradient
08:59:01 [heycam]
... either rename it, or put an optional type on it
08:59:14 [heycam]
... since they'd have different content models etc.
08:59:57 [heycam]
Tav: I've thought about autosmoothing patches
09:00:09 [heycam]
ChrisL: not talking about hacking it in to the existing one, but adding a different type of patch that does have continuity
09:00:22 [heycam]
Tav: we know how illustrator does this, so we could just add that
09:00:36 [heycam]
... one good thing about coons patch meshes is that PDF, postscript, etc. already support them
09:00:55 [heycam]
ChrisL: to some extent, it ties us to that one type since we've called it "meshGradient"
09:01:30 [heycam]
nikos: I don't see a strong case for having an attribute that specifies the type, rather than having a different element
09:01:39 [heycam]
ChrisL: if we end up with multiple elements, and they take the same list of attributes, that's not a problem
09:01:49 [heycam]
... if we have one thing with type="", but that determines which attributes you use, that's messy
09:02:04 [heycam]
heycam: I agree
09:02:32 [heycam]
Tav: if we decide to have this smoothing, that's no longer a coon's mesh gradient
09:02:40 [heycam]
... so the suggestion to rename it to coonsMesh might not be appropriate
09:02:58 [heycam]
nikos: I think you would keep the coon's mesh as is, and if you had a different type you'd name it smoothMesh or whatever
09:03:08 [heycam]
Tav: I think you can add smoothing to coons patch
09:03:13 [heycam]
ChrisL: what's it called in PDF?
09:03:16 [heycam]
nikos: "gradient mesh"
09:03:42 [heycam]
... that's what it's called in illustrator
09:03:50 [heycam]
... in PDF there's coons patch, and tensor-product patch
09:03:59 [heycam]
... that doesn't give you full continuity
09:04:12 [heycam]
... what's recognised as "gradient meshes" is the full continuity
09:04:24 [heycam]
ChrisL: we did look earlier at tri-mesh and we abandonded that
09:04:49 [heycam]
... I suggested using Phong shading, since we already have that in filters
09:04:57 [heycam]
Tav: triangle meshes aren't easy to use for the artist
09:05:09 [heycam]
ChrisL: I had proposed using a scatter field of dots, and delauny triangulation
09:07:25 [heycam]
nikos: if the structure is not going to change, it's appropriate to call it "coons patch mesh gradient"
09:07:29 [heycam]
... it's still based on an array of coons patche
09:07:31 [heycam]
s/patche/patches/
09:08:35 [heycam]
nikos: I think it's safe to give the current SVG 2 representation a more specific name
09:08:39 [heycam]
Tav: not sure "coons" is the right name though
09:08:50 [heycam]
... doesn't that describe how you fill it to?
09:08:52 [heycam]
nikos: no
09:09:07 [heycam]
... the interpolation of the colours is what makes it a mesh gradient, but a coons patch mesh doesn't have to be filled in a particular way
09:09:49 [heycam]
... you could change some parameters of the blending, and it would still be accurate to call it an array of coons patch
09:09:55 [heycam]
... so calling it a coons patch mesh gradient would still be accurate
09:10:05 [heycam]
... the issue is that it might not exactly match what's in PDF for example
09:10:09 [heycam]
ChrisL: a subset of it would
09:10:23 [heycam]
heycam: "coons patch mesh gradient" is quite long as a name
09:11:30 [heycam]
ChrisL: cmesh? cpmesh?
09:19:11 [heycam]
heycam: I don't really like coonsMeshGradient but I can live with it
09:19:19 [heycam]
... feel like there might be a better name but can't think of one
09:22:45 [krit]
<coonsPatchMesh>
09:23:08 [heycam]
... might be ok to drop "Gradient" from the name, since it gets rendered directly (and also can be used as a paint)
09:23:49 [heycam]
... I like coonsPatchMesh more than coonsMeshGradient
09:24:50 [heycam]
... <cpatchGradient>?
09:24:56 [heycam]
Tav: we should add tensor products I think
09:24:59 [heycam]
... it's not any harder
09:25:15 [heycam]
... when you render the mesh, it's no hard to handle the tensor products
09:27:12 [heycam]
heycam: what about calling it patchGradient, and then the child elements indicate what kinds of patches are being used?
09:36:45 [heycam]
... what about: <meshGradient><meshRow><coonsPatch>
09:36:56 [heycam]
... and the <coonsPatch> can be used for both regular coons patches and tensor-product patches, if we add that
09:37:09 [heycam]
... any other non-coons patches we might add later would have a name different from <coonsPatch>
09:37:46 [heycam]
RESOLUTION: We will rename <meshPatch> to <coonsPatch>.
09:38:09 [heycam]
ChrisL: you were also concerned about working on this in parallel, and working in a community group
09:38:15 [heycam]
... would allow the inria guys to contribute
09:38:23 [heycam]
... another possibility is a taskforce
09:38:48 [heycam]
nikos: community groups you have to keep things on track, and keep people contributing
09:38:53 [heycam]
ChrisL: seems like a reasonable way forward
09:40:38 [heycam]
heycam: I don't have a good sense of how difficult this would be to implement
09:40:55 [heycam]
nikos: we would hope to implement it in webkit, and probably provide a reference implementation / library
09:41:14 [heycam]
nikos: could demo stuff ~ at the end of the year
09:41:31 [heycam]
ChrisL: the group is not going to say definitely no at this stage, and not definitely yes
09:41:36 [heycam]
... needs to be demonstrated and looked at
09:41:55 [heycam]
... so it's not a total waste of time
09:42:11 [heycam]
... I think with the existing stuff, people will want to get rid of the lines
09:43:43 [heycam]
... concern with the gradient meshes was that you need this solver to calculate the pixel values which people would be scared about speed
09:43:53 [heycam]
Tav: inkscape's rendering of mesh gradients is fast
09:43:58 [heycam]
cabanier: it's also easily GPU implemented
09:44:48 [heycam]
heycam: acceptable to say to put in some more effort so we can make a better judgement with more data?
09:44:51 [heycam]
nikos: yes I think so
09:44:58 [heycam]
ChrisL: having regular updates from the CG would be good too
09:47:11 [nikos]
http://patate.gforge.inria.fr/html/
09:50:36 [heycam]
RESOLUTION: SVG WG is happy for CG to be formed to begin looking into diffusion curves.
09:51:22 [nikos]
scribenick: nikos
09:51:35 [nikos]
Topic: Telcon time
09:51:55 [nikos]
heycam: all the daylight savings changes have been made now
09:52:01 [nikos]
... it would be good to make a time that Chris can call in
09:52:19 [nikos]
ChrisL: I'm available 6am to 8 or 9 pm
09:52:28 [nikos]
... 9pm finish
09:52:50 [nikos]
Tav: i have trouble before 9am
09:54:02 [heycam]
http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140409&p1=37&p2=152&p3=248&p4=224&p5=179
09:54:30 [nikos]
krit: Need to consider Rich as well
09:54:37 [nikos]
... he's something like 2 hours after Seattle
09:55:24 [heycam]
http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140409&p1=37&p2=152&p3=248&p4=224&p5=24&p6=179
09:58:38 [nikos]
heycam: 6am Europe seems like a good spread
09:59:02 [nikos]
... midnight in New York, 11pm in Austin
10:01:04 [nikos]
heycam: times that are possible but not present - 4pm paris, midnight Melbourne, 7am SFO
10:01:25 [nikos]
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=4&day=9&hour=14&min=0&sec=0&p1=37&p2=152&p3=248&p4=224&p5=24&p6=179
10:01:39 [nikos]
Ignore the selected day, just look at the time
10:03:23 [nikos]
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=4&day=9&hour=13&min=0&sec=0&p1=37&p2=152&p3=248&p4=224&p5=24&p6=179
10:07:24 [nikos]
RESOLUTION: new telcon is 3PM Thursday Euro time
10:38:17 [nikos]
nikos has joined #svg
10:52:21 [nikos_]
nikos_ has joined #svg
11:07:01 [nikos]
Topic: Variable-width stroke
11:07:26 [nikos]
Topic: 'vector-effect' non-scaling features update
11:07:32 [stakagi]
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/vector_effects_extension
11:07:52 [nikos]
stakagi: I had an action about non scaling object
11:08:14 [ChrisL]
action-3578?
11:08:14 [trackbot]
action-3578 -- Satoru Takagi to Add the new transform(ref) functionality to svg 2 -- due 2014-02-07 -- OPEN
11:08:14 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/actions/3578
11:08:32 [nikos]
... I prepared this wiki page
11:08:48 [nikos]
... it was also pointed out that the variation of the effect should be prepared
11:09:01 [birtles]
stakagi: At the Seattle F2F we decided that we should approach non-scaling effects not using transformRef but with vector-effect
11:09:06 [nikos]
... such as non scaling size and fixed position or non rotating objects, etc
11:09:32 [nikos]
... this wiki page shows an enhanced proposal for vector effects
11:10:00 [nikos]
... one effect is non scaling size, another is non rotating, and last is fixed position
11:10:26 [nikos]
... additional parameters is viewport, screen, device, number
11:10:40 [nikos]
... I prepared a web application that emulates this
11:10:43 [stakagi]
http://svg2.mbsrv.net/devinfo/devstd/non-scaling-objects-2/VectorEffectTest.html
11:12:33 [nikos]
stakagi: The demo is using the equivalent of the viewport keyword. The other options such as screen and so on are not part of the demo
11:12:45 [nikos]
... each effect is also described as a formula
11:12:55 [nikos]
... a transformation formula - see section 1.3
11:13:04 [stakagi]
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/vector_effects_extension#Transformation_Formula
11:13:22 [nikos]
stakagi: my question is may I add this to the SVG 2 specification?
11:13:33 [nikos]
ChrisL: I've had a look and it seems generally good to me
11:13:48 [nikos]
... I had one comment that non scaling by itself was a little odd. Suggested non-scaling-size
11:14:00 [nikos]
... I've had a play with the app and it seems self explanatory
11:14:32 [nikos]
... in general this seems to be the sort of stuff that the action covered
11:14:58 [nikos]
... can't remember the url
11:15:41 [nikos]
... is it like in svg 1.2 we had ref where you could transform relative to another element?
11:15:54 [nikos]
stakagi: yes, but bits in grey I may remove
11:16:08 [nikos]
heycam: what's the difference between screen and viewport?
11:17:25 [nikos]
birtles: I don't quite understand, but in the formula it's all split out
11:17:41 [nikos]
... we have get screen ctm in SVG already and that's what screen refers to
11:17:44 [nikos]
... viewport is a subset of that
11:18:17 [nikos]
ChrisL: viewport only goes one level up so if you have nested viewports...
11:18:49 [nikos]
birtles: if you have nested viewports, then viewport will give you the closest
11:18:54 [nikos]
... while screen always gives the outermost
11:19:09 [nikos]
... the third keyword device includes the transformations applied by the browser chrome and so on
11:19:13 [nikos]
... such as pinch zoom
11:19:19 [nikos]
... and device pixel ratio
11:19:41 [nikos]
ChrisL: it would be useful to put that in the explanation
11:19:52 [nikos]
ed: the equations have a division by the square root of the determinant of the ctm
11:19:59 [nikos]
... is it specified what happens when that is zero?
11:20:18 [nikos]
stakagi: when that happens nothing should be displayed
11:20:24 [nikos]
ed: does that need to be stated somwhere?
11:20:33 [nikos]
stakagi: I haven't written the spec text yet
11:21:37 [nikos]
heycam: what was number?
11:21:41 [nikos]
... goes this number of viewports up?
11:21:46 [nikos]
ChrisL: yes
11:22:27 [nikos]
.. we worked out the common cases were going one level up or all so there's keywords for that
11:22:45 [nikos]
heycam: don't know if there's features that let you reference things in the hierarchy
11:22:54 [nikos]
ChrisL: you mean by counting?
11:22:56 [nikos]
heycam: or by name
11:23:03 [nikos]
ChrisL: we have lots of things where you point to an id
11:23:13 [nikos]
... sometimes we restrict but in general terms its a uri
11:23:24 [nikos]
heycam: but they're generally things that are downwards
11:24:31 [nikos]
ChrisL: this is basically what we had before with the ref where you might want to reference other svgs and have them pan together for example
11:25:39 [nikos]
ChrisL: what we've done in the past is to use a uri reference for pointing to things in the same or in other documents
11:25:48 [nikos]
... and restrict to the same document if needed
11:26:30 [nikos]
heycam: if your containing document is a few levels up, where script would be restricted from accessing it, is it ok to get the ctm?
11:26:39 [nikos]
ChrisL: I was imagining it would always be on the same domain
11:27:36 [ChrisL]
reasonable to allow cross document but not cross domain. same restriction as with script
11:27:52 [nikos]
birtles: wonder how much number will be used
11:27:57 [nikos]
ChrisL: suspect it will be used the least
11:28:05 [nikos]
stakagi: I'm not fussed either way
11:28:39 [nikos]
heycam: is the use case of having the document you stop at being somewhere in the middle of the chain an important one?
11:28:47 [nikos]
stakagi: seems like it would be useful for tiles of maps, but it's hard to know
11:29:46 [nikos]
[Chris gives a use case example of a map where the size of symbols is fixed]
11:30:00 [nikos]
ChrisL: in some ways it's easier to track with an id
11:30:07 [nikos]
heycam: think numbers might be hard for an authoring perspective
11:30:19 [nikos]
... especially with an adaptive number of levels - you'd have to update the numbers
11:30:47 [nikos]
... if the use case is knowing where the top level of the map is then it's similar to screen
11:30:55 [nikos]
... it's near screen
11:31:04 [nikos]
ChrisL: you could put an id and point to it
11:31:12 [nikos]
... seems like an obvious place to put an id
11:31:20 [nikos]
... I do think we need to point to intermediate levels
11:31:37 [nikos]
... think numbers are going to be more trouble than they're worth though
11:32:02 [nikos]
... not hearing anyone arguing for numbers
11:32:17 [nikos]
birtles: could perhaps add it later once we understand the use case better
11:32:27 [nikos]
ChrisL: we're not taking away functionality, only syntax
11:32:34 [nikos]
... use cases aren't affected
11:32:50 [nikos]
... do people have any other issues?
11:32:57 [nikos]
heycam: still not convinced url is the ideal way to referene
11:33:02 [nikos]
ChrisL: I'd rather see url than an id ref
11:33:27 [nikos]
heycam: if you're in control of all these docs and you can put an identifier then you can say go to that
11:33:33 [nikos]
ChrisL: doesn't seem like the web architecture way to do it
11:33:37 [nikos]
... you'd point to a uri
11:34:26 [nikos]
heycam: let's say you've designed your mapping thing and it's embedded ( which is why we need more than screen)
11:34:42 [nikos]
... if you want that available in different contexts then you might need something other than url
11:35:06 [nikos]
ChrisL: you're right number would be useful there
11:35:26 [nikos]
heycam: I still don't like number though. You're not necessarily going to have the same number of steps all the time to get to where you want
11:35:44 [nikos]
ChrisL: so we need a way to point to somewhere higher up without knowing the name of the document that contains that
11:37:40 [nikos]
birtles: I don't see whats wrong with id
11:37:44 [nikos]
heycam: implies the same document
11:38:25 [nikos]
... I think something like id is needed, but not exactly id as in the proposal
11:38:47 [nikos]
... I wonder if in Thomas's use cases if he ever has other documents?
11:41:10 [nikos]
... I think maybe that feature may be ok but not sure of exact way to do the referring.
11:41:13 [nikos]
... could think about that later
11:41:17 [nikos]
ed: you mean start without it ?
11:41:38 [nikos]
heycam: is Takagi-san sure the feature is needed?
11:41:45 [nikos]
birtles: no I think he's happy for us to decide
11:41:52 [nikos]
heycam: if that's the case then I lean towards not adding for now
11:42:20 [nikos]
stakagi: I don't have a particular opinion, but in Seattle Chris and Doug proposed it
11:43:50 [nikos]
ChrisL: so if you do the multi pane mapping thing you have to always go to the top
11:43:56 [nikos]
... so you can only have one level
11:44:16 [nikos]
heycam: I meant drop url and id as well as number
11:44:33 [nikos]
ChrisL: it's really common to do multi pane things and have them transform together
11:45:13 [nikos]
... I understand you don't want to bake uri in so that components are reusable but I'd rather that than no uri at all
11:45:59 [nikos]
stakagi: I still want to look into the needs of the specific use cases and add what's needed after
11:46:16 [nikos]
... so I think it's ok to leave off the grey parts of the syntax until after the investigation
11:46:23 [nikos]
ChrisL: I'd rather have it in
11:46:57 [nikos]
... it's easier to define everything within the model and then remove things
11:47:33 [nikos]
... if we do it in terms of pointing at elements, then we say you point at the element and there's syntactic sugar for nearest and further
11:47:55 [nikos]
s/further/furthest
11:48:34 [nikos]
heycam: Brian was wondering if we could just use id and look at each document for that id
11:48:43 [nikos]
heycam: but I was a bit uncomfortable with that
11:48:49 [nikos]
... maybe a new attribute is needed
11:49:09 [nikos]
... if it's documents and not viewport establishing elements within documents then maybe the name attribute on iframe could be used
11:49:32 [nikos]
birtles: can we leave this as agree on the requirement but we don't know what the addressing mechanism should be ?
11:49:34 [nikos]
ChrisL: yes
11:49:43 [nikos]
nikos has joined #svg
11:50:20 [nikos]
heycam: I can see the use case for identifying a top level document somewhere in the chain which is the root you want to trasform things relative to
11:50:33 [nikos]
... but not sure about documents somewhere up the chain
11:51:01 [heycam]
s/documents/individual viewport establishing elements within documents/
11:51:43 [nikos]
birtles: Takagi-san was wondering about screen ctm and whether that should include the browser chrome trasnform
11:51:52 [nikos]
... spec not clear currently, wondering if anyone knows about that
11:52:07 [nikos]
heycam: I know there's a lot of confusion about window.devicePixelRatio and that's part of what Ted was going to investigate
11:52:36 [nikos]
krit: did someone check if screen ctm goes outside of svg root?
11:53:17 [nikos]
heycam: when an object is fixed position, what point on the object is fixed?
11:55:05 [nikos]
birtles: I don't quite understand but I think it's the 0,0 part of the shape
11:55:13 [nikos]
... but if you put a translation on it then it's the x,y of that translation
11:55:36 [nikos]
... specified under fixed position
11:55:44 [nikos]
... if it has a transform on it then it uses the tx,ty
11:58:06 [nikos]
stakagi: I think it would be better if there were separate attributes for that but don't have any ideas on what that would look like
11:58:17 [nikos]
heycam: I'm having trouble getting my head around what fixed-position actually means
12:00:05 [nikos]
... in the demo, if I zoom then the arrow remains centered on the magnifying glass thing
12:00:11 [nikos]
... what defines that that is the origin?
12:01:01 [nikos]
heycam: seems like one of the main use cases for fixed-position is location markers on the map where you want the icon to get bigger on zoom but position to stay fixed
12:01:28 [nikos]
... are all the combinations sensible?
12:01:49 [nikos]
I'm wondering if there's only a couple of combinations that you'd want to use and then there's a better name for each
12:02:50 [nikos]
ChrisL: with the transform attribute you can say rotate, scale, translate in any combination and these ones are basically the same choices but stopping them happening
12:03:08 [nikos]
... so if we allow the transforms in any order then should also allow them all to be switched off
12:03:17 [nikos]
heycam: guess there will always be some combinations that don't make sense
12:03:30 [nikos]
... can we use the names translate, rotate, scale?
12:03:36 [nikos]
... fixed-position is pretty descriptive
12:04:16 [nikos]
... compared to non-translation
12:04:55 [nikos]
... so we're deciding whether takagi-san will go ahead and add these to the property?
12:04:58 [nikos]
ChrisL: yes
12:04:59 [nikos]
ed: yes
12:05:17 [nikos]
heycam: have a feeling these will cover Thomas's use cases as well
12:05:27 [nikos]
ChrisL: once there's spec text he'll be able to see more easily
12:05:41 [nikos]
heycam: so we have a separate keyword for non-scaling stroke
12:05:51 [nikos]
... that's a bit different to others that say which bit of the transform isn't applied
12:06:20 [nikos]
nikos has joined #svg
12:06:32 [nikos]
heycam: maybe non scaling stroke should be taken out of the brackets
12:06:45 [nikos]
... since it's more canned
12:06:54 [nikos]
ChrisL: so you can't say non-scaling-stroke and non-rotation?
12:06:55 [nikos]
heycam: yes
12:07:03 [nikos]
ed: what if you had hatching that wasn't meant to be rotated?
12:07:15 [nikos]
heycam: that was one of Thomas's use cases
12:08:40 [nikos]
Tav: there's two independent things. Positioning something and then how it's transformed
12:08:51 [nikos]
birtles: it's actually non scaling stroke width that non-scaling-stroke refers to
12:09:24 [nikos]
heycam: ok I was confused.
12:09:42 [nikos]
... so we might have additional keywords like non scaling stroke to keep the pattern oriented for example
12:09:56 [nikos]
birtles: begs the question of whether it should be a separate property
12:09:59 [nikos]
Tav: makes sense
12:10:36 [nikos]
heycam: but we can discuss that sort of thing later
12:10:42 [nikos]
birtles: think it's worth splitting off now
12:11:06 [nikos]
... vector-effects makes more sense when referring to the stroke but less when referring to the transform
12:14:03 [nikos]
ed: would prefer if names didn't have 'non' at the beginning
12:14:08 [nikos]
heycam: is it ok to decide the name later?
12:14:28 [birtles]
property name suggestions so far: transform-constraint, transform-limit, transform-lock, untransform, fixed-transform non-transform etc.
12:14:41 [birtles]
keyword values: fixed-scale, fixed-rotation etc.
12:14:53 [birtles]
heycam: 'transform-context' ?
12:15:29 [birtles]
... since it specified not only the parts but also the point of reference
12:15:38 [birtles]
s/it specified/it specifies/
12:15:41 [nikos]
heycam: we do need to decide if Takagi-san should add it
12:16:00 [nikos]
ChrisL: he should
12:16:01 [nikos]
ed: yes
12:16:08 [nikos]
Tav: yes
12:17:08 [nikos]
RESOLUTION: Takagi-san to add vector effects extension proposal to SVG 2 specification
12:17:31 [nikos]
ACTION: Takagi-san to add vector effects extension proposal to SVG 2 specification
12:17:31 [trackbot]
Error finding 'Takagi-san'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.
12:17:47 [nikos]
nikos has joined #svg
12:18:06 [nikos]
ACTION: stakagi to add vector effects extension proposal to SVG 2 specification
12:18:06 [trackbot]
Created ACTION-3619 - Add vector effects extension proposal to svg 2 specification [on Satoru Takagi - due 2014-04-16].
13:14:38 [nikos]
nikos has joined #svg
13:16:25 [ChrisL]
scribenick#: cabanier
13:16:57 [ChrisL]
scribenick: ChrisL
13:19:20 [ChrisL]
Topic: Variable stroke width
13:19:24 [birtles]
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Variable_width_stroke#Syntax_proposal
13:19:51 [ChrisL]
birtles: some tweaks from last time
13:20:00 [ChrisL]
... also a polyfil, not finished
13:20:02 [birtles]
https://rawgithub.com/birtles/curvy/master/index.html
13:20:41 [ChrisL]
birtles: syntax proposal had consensus last time but people asked for a polyfil to test algos with
13:21:11 [ChrisL]
... does parsing and processing of values, does not draw the stroke yet
13:21:32 [ChrisL]
... most syntax implemented
13:22:07 [ChrisL]
heycam: can you explain the syntax
13:22:23 [ChrisL]
birtles: choice of algo, and some predefined test cases
13:22:30 [ChrisL]
... can write your own
13:22:42 [ChrisL]
... and permalink to sendto other people
13:23:26 [ChrisL]
birtles: three properties plus a shorthand. list of widths, can do asymmetric
13:23:47 [ChrisL]
... percentages are % of computed value of stroke width
13:24:04 [ChrisL]
... absolute distances, issue if they should allow relative
13:24:18 [ChrisL]
birtles: drawn segments can be adressed
13:24:31 [ChrisL]
krit: all absolute?
13:24:34 [ChrisL]
birtles: yes
13:24:51 [ChrisL]
ed: order of values, is it order in path?
13:25:09 [ChrisL]
birtles: yes, parallel arrays in ascending order elsse clamped like css gradients
13:25:18 [ChrisL]
s/elsse/else
13:25:57 [ChrisL]
krit: comma separated list
13:26:10 [ChrisL]
... are you sure, shorthand has list too
13:27:04 [ChrisL]
birtles: formal syntax not specced out yet
13:27:44 [ChrisL]
ChrisL: is it piecewise linear or what?
13:28:02 [ChrisL]
birtles: that is why there is a choice of algo in the polyfil, not decided yet
13:28:16 [ChrisL]
heycam: so you walk the path and interpolate
13:28:39 [ChrisL]
heycam: catmull-rom with warping would look good
13:29:28 [ChrisL]
birtles: only get gaps if you use the shorthand
13:29:41 [ChrisL]
zakim, go away
13:29:41 [Zakim]
I don't understand 'go away', ChrisL
13:30:46 [ChrisL]
birtles: have only looked at sytntax parsing and calculation, not done rendering
13:31:03 [ChrisL]
birtles: negatives not allowed
13:31:24 [ChrisL]
heycam: catmull-rom can overshoot into negative
13:31:33 [ChrisL]
ChrisL: just clamp to zero if so
13:32:10 [ChrisL]
birtles: can have negative positions for strokes, probably unduly complex
13:33:20 [ChrisL]
ChrisL: need extra points at ends to get flaring
13:33:37 [ChrisL]
birtles: like stroke-offset, maybe a separate property? open issue
13:34:06 [ChrisL]
birtles: repeat is if you have less data than needed. maintain final value or repeat pattern
13:34:59 [ChrisL]
birtles: (goes through examples in proposal)
13:35:39 [ChrisL]
birtles: want to have a width at start of every segment. eg path in response to direct input with touch/pressure/tilt
13:35:50 [ChrisL]
... align each with segment on the path
13:36:09 [ChrisL]
... else editing is complex with two arrayts in sync
13:36:28 [ChrisL]
heycam: what if you use the longhand and no positions?
13:36:39 [ChrisL]
birtles: equally distributed
13:37:22 [ChrisL]
ChrisL: ok so you can have one width per segment but not forced to
13:37:26 [ChrisL]
birtles: yes
13:37:42 [ChrisL]
ed: how does this work with dash arrays and line caps
13:37:54 [ChrisL]
heycam: cap is as small as the point it is at
13:38:10 [ChrisL]
... trapezoid for square caps?
13:38:19 [ChrisL]
cabanier: yes, like in Illustrator
13:38:36 [ChrisL]
heycam: so stroke warpingf is after dashing and capping
13:38:44 [ChrisL]
krit: horribly complex
13:38:59 [ChrisL]
s/ingf/ing
13:39:38 [ChrisL]
birtles: there was an action to write a polyfuil but it wasn't done so this is a start
13:40:02 [ChrisL]
... important question is relative vs. absolute
13:40:28 [ChrisL]
Tav: how to do segments that cross?
13:40:39 [ChrisL]
... trap off the part
13:40:50 [ChrisL]
ed: zero length segments?
13:40:51 [ChrisL]
bb
13:41:02 [ChrisL]
Tav: not a problem
13:41:23 [ChrisL]
birtles: can have two widths at same position, gives sudden drop
13:41:46 [ChrisL]
birtles: its value then position, to align with css gradients
13:42:21 [ChrisL]
birtles: to get a smooth repeat it needs to come back to first value
13:42:44 [ChrisL]
Tav: corners?
13:42:53 [ChrisL]
birtles: needs to be worked out
13:43:08 [ChrisL]
... not clear if computational complexity makes it too slow
13:43:31 [ChrisL]
heycam: markers that have size relative to stroke width?
13:43:39 [ChrisL]
birtles: at the point where the marker is
13:43:57 [ChrisL]
ed: mitre joins can just out a long way, how to handle
13:44:01 [ChrisL]
birtles: hmmm
13:44:48 [ChrisL]
birtles: should be able to animate positions and values, perhaps not shorthand
13:45:00 [ChrisL]
heycam: expand out shorthand on each keyframe
13:45:11 [ChrisL]
heycam: so lets decide on relative vs absolute
13:45:41 [ChrisL]
Tav: prefer absolute
13:45:58 [ChrisL]
ChrisL: is it an either or, or would we want both?
13:46:08 [ChrisL]
heycam: not hard to convert from one to the other
13:46:24 [ChrisL]
birtles: relative and absolute differ if the path is extended
13:46:42 [ChrisL]
ed: like uppercase/lowercase for rel/abs in path
13:47:41 [ChrisL]
birtles: markers should be relative distances
13:48:05 [ChrisL]
heycam: another difference is that didnt have sepaate properties for positions and markers
13:48:34 [ChrisL]
... single property letts you have multiple markers at same place though you could just repeat the position
13:48:54 [ChrisL]
... for repeating, easier to think of relative, copy the values
13:49:48 [ChrisL]
birtles: instead of a property for repeat mode, separate property that specifies a pattern as a mode swidth
13:50:04 [ChrisL]
Tav: as you widen stroke does the pattern widen?
13:50:07 [ChrisL]
birtles: no
13:50:38 [ChrisL]
birtles: not sure how to make it line up with markers
13:51:09 [ChrisL]
birtles: implementability comments
13:51:19 [ChrisL]
Tav: implemented, popular feature
13:51:57 [ChrisL]
krit: will be a performance hit
13:52:02 [ChrisL]
cabanier: fairly simple
13:52:32 [ChrisL]
Tav: we have dash array, works fine. converts path to a fill, puts dash onit, ends up on stroke
13:52:57 [ChrisL]
heycam: like the feature
13:53:06 [ChrisL]
birtles: will continie to work on syntax
13:53:21 [ChrisL]
krit: that is detail, important thing is rendering
13:53:49 [ChrisL]
birtles: ok, work out bugs with the polyfil
13:54:01 [ChrisL]
ed: very sharp corners, linejoins etc
13:54:24 [ChrisL]
krit: need path planarization to do this
13:54:42 [ChrisL]
cabanier: just draw all path segments, amke sure turn same way, then fill
13:54:57 [ChrisL]
... so no need for planarization
13:55:03 [ChrisL]
... no unions
13:55:14 [ChrisL]
s/amke/make
13:55:33 [ChrisL]
heycam: width=0 widths=list, is that ok
13:55:36 [ChrisL]
birtles: yes
13:56:07 [ChrisL]
birtles: next step is to do an implemnetation
13:56:47 [ChrisL]
krit: interop needs a defined algo
13:56:57 [ChrisL]
... kinda the same is not a goal
13:57:11 [ChrisL]
heycam: ok with seg values?
13:57:14 [ChrisL]
Tav: yes
13:57:20 [ChrisL]
krit: yes
13:57:29 [ChrisL]
... each moveto is one segment
13:57:54 [ChrisL]
birtles: sense is to count the drawing segments
13:58:19 [ChrisL]
Tav: (draws) how to specify a gap
13:58:53 [ChrisL]
birtles: yes, 2 segments
13:59:01 [ChrisL]
TabAtkins: 2,5,3,5
13:59:16 [ChrisL]
s/TabAtkins/Tav
13:59:28 [ChrisL]
birtles: (draw)
13:59:37 [ChrisL]
Tav: so it knows to skip
14:00:17 [ChrisL]
Tav: its haow we did in inkscape, per segment basis
14:01:08 [ChrisL]
ed: generated path can vary by impls. so does not match what author intended
14:01:26 [ChrisL]
... seg might not match due to internal normalization
14:01:42 [ChrisL]
heycam: no, its bassed on path as specced not after normalization
14:02:02 [ChrisL]
cabanier: unless you specify normalization
14:02:11 [ChrisL]
krit: and you don't want to
14:02:25 [ChrisL]
krit: result can be a path object
14:03:02 [ChrisL]
cabanier: would be cool. would need an acessor on path
14:03:26 [ChrisL]
krit: would help canvas too
14:04:29 [ChrisL]
heycam: with abs positions how can you do segment based patterns? (draws things with calc())
14:05:25 [ChrisL]
if doing a pattern on first segment, its a mode to opt into
14:05:41 [ChrisL]
birtles: seprsate property for segment based patterns
14:06:07 [ChrisL]
birtles: not for VWS, just for markers
14:06:21 [ChrisL]
... authoring hard with different modes
14:06:49 [ChrisL]
birtles: 2 issues in wiki
14:07:30 [ChrisL]
a) negative positions (as with css gradients) b) repeating patterns with vws, can start pattern part way through
14:07:42 [ChrisL]
ed: couldbe useful
14:07:50 [ChrisL]
cabanier: not sure how
14:08:12 [ChrisL]
birtles: set position as -10 +10 then starts half way through
14:08:51 [ChrisL]
... or a flag for that like stroke-dash-offset
14:09:22 [ChrisL]
heycam: prefer negative offset
14:10:13 [ChrisL]
birtles: need values greater than 100% so if you can at one end should at other (negative) too
14:11:04 [ChrisL]
heycam: can you animate length ofpath ... hmm dasharray so it works, animate d attr
14:11:22 [ChrisL]
birtles: ok so issue 2 solved, do allow negative
14:11:48 [ChrisL]
birtles: stroke widths lining up per seg without repeating them
14:12:04 [ChrisL]
... empty list is the initial
14:12:18 [ChrisL]
heycam: needs a keyword for that
14:12:42 [ChrisL]
... for one per seg
14:13:03 [ChrisL]
... keyword plus vale, or list of pairs
14:13:08 [ChrisL]
birtles: yes
14:13:15 [ChrisL]
s/vale/value
14:13:55 [ChrisL]
heycam: reflect value?
14:14:08 [ChrisL]
birtles: yes
14:14:15 [ChrisL]
heycam: add to spec
14:14:53 [ChrisL]
birtles: next step, finish impl to render
14:15:12 [ChrisL]
heycam: if you want linear, for sawtooth
14:15:32 [ChrisL]
Tav: inkscape has bezier or spiro as interpolators
14:16:10 [ChrisL]
... and linear, two types of bezier
14:17:06 [ChrisL]
heycam: (worries about double plurals)
14:17:57 [ChrisL]
ChrisL: its not replacing stroke-width, it is modulasting it
14:18:06 [ChrisL]
Tav: yes, easy to sanimate width
14:18:34 [ChrisL]
krit: interesting to implement in canvas
14:18:45 [ChrisL]
birtles: prefer to see to get another path
14:19:15 [ChrisL]
krit: cost is calculation not rendering
14:21:08 [ChrisL]
ChrisL: (tangent on CR interpolator for linear gradients)
14:22:50 [ChrisL]
(people making spirographs in the air and giggling slightly)
14:23:36 [ChrisL]
heycam: squashing repetitions on a circle
14:23:48 [ChrisL]
Tav: multiple of four only
14:24:47 [ChrisL]
... no, four thirds segments
14:25:50 [ChrisL]
birtles: do need to specify equivalent path for all basic shapes
14:25:58 [ChrisL]
(we have already)
14:26:06 [ChrisL]
ed: ooh you could do stars
14:27:04 [ChrisL]
birtles: hoping for help on the rendering part
14:27:20 [ChrisL]
heycam: have lost an example that would have helped
14:27:59 [ChrisL]
birtles: wait to solve issues before adding to spec
14:28:06 [ChrisL]
heycam: add by end of june
14:28:09 [ChrisL]
birtles: ok
14:29:05 [ChrisL]
Topic: svg integration
14:29:28 [nikos]
scribenick: nikos
14:30:06 [nikos]
heycam: SVG in OT spec needs to define or reference the referencing modes (to turn of script or other features that don't make sense)
14:30:20 [nikos]
... also it has some things like UA style sheet that it defines to make contextFill and contextStroke work by default
14:30:28 [nikos]
... and describes mapping of colour palette to css variables
14:30:37 [nikos]
... question is - where do each of those things get defined?
14:30:40 [nikos]
... in the OT spec itself?
14:30:45 [nikos]
... or in one of our specs that we control?
14:31:01 [nikos]
ChrisL: anything that might include a list of elements or definition of list of elements I'd prefer we control
14:31:12 [nikos]
... don't have a strong opinion about UA style sheets
14:31:31 [nikos]
heycam: one part about UA style sheet is where it forced display:none on text
14:31:51 [nikos]
ChrisL: if we add another element that's like text but does different things then technically it would still be allowed and that would be bad
14:32:02 [nikos]
... so I don't like to see lists of our elements in other specs
14:32:11 [nikos]
heycam: my feeling before was that some parts should eb defined in the SVG integration spec
14:32:18 [nikos]
... given it's already trying to define referencing modes
14:32:24 [nikos]
... integration spec never published as a WD
14:32:35 [nikos]
ChrisL: it's been around for a while and not moving forward
14:32:38 [nikos]
... so we need to get it published
14:32:44 [nikos]
heycam: I thought it would be ok to publish a FPWD
14:32:55 [nikos]
... so OT spec can reference an un-dated url of the spec
14:33:00 [nikos]
... so it will get updated as we make changes
14:33:11 [nikos]
... and sort out details of referencing modes that might still need defining in the near future
14:33:37 [nikos]
... but importantly because their spec is solidifying soon (this week or next week) then we will have reference to the TR page
14:33:48 [nikos]
ChrisL: if we have a short name without a date they can link and always get the latest version
14:33:56 [nikos]
... much better than referring to an editors draft or a dated version
14:34:15 [nikos]
heycam: OT spec doesn't publish regularly so will be difficult to revise in future
14:35:04 [nikos]
ChrisL: we should learn lessons from the past and keep control of our stuff that's referenced
14:35:12 [nikos]
cabanier: didn't they want another secure mode?
14:35:39 [nikos]
ChrisL: we could use secure animated + a couple of lines that stop text being displayed
14:35:46 [nikos]
... our we could make a new mode that incorporates all that
14:35:55 [nikos]
... all the text to date has pointed to secure animated mode
14:36:28 [nikos]
krit: the issue I have with the spec is that it does not solve the issues of security (which it should solve)
14:36:37 [nikos]
... it has weird text saying what you should and shouldn't do
14:36:42 [nikos]
... but not what you can and cannot fetch
14:36:46 [nikos]
... and that's the most important part of the spec
14:36:52 [nikos]
... don't expect this to be fixed soon
14:37:09 [nikos]
... so I don't want it published as FPWD without fixing this issue
14:37:16 [nikos]
... no issue with having additional modes for SVG in OT
14:37:30 [nikos]
... I would like the doc to go forward
14:37:35 [nikos]
... would like it to have a higher priority
14:37:40 [nikos]
... but most important issue should be fixed
14:38:00 [nikos]
... the issue is you can't just say script isn't allowed
14:38:13 [nikos]
... especially for images, doesn't what you can fetch
14:38:32 [nikos]
... in the introduction it says something about cross origin but no further details
14:38:41 [nikos]
ChrisL: thought secure animated mode disallowed referencing other resources
14:38:49 [nikos]
heycam: but you can use data urls
14:39:03 [nikos]
krit: spec doesn't specify what it really means
14:39:16 [nikos]
ChrisL: don't understand why you don't want it published?
14:39:19 [nikos]
krit: it's not marked as an issue
14:39:22 [nikos]
... it should be
14:39:44 [nikos]
... and someone should add parts that you need to reference from OT fonts
14:39:59 [nikos]
... we resolved that Cameron and myself were added to editors list, but haven't had time to work on it
14:40:14 [nikos]
ChrisL: What I'm asking for is that we have editors that are present and clearly mark the issues
14:40:18 [nikos]
... and go to FPWD
14:40:27 [nikos]
... not trying to blow off fixing that
14:40:42 [nikos]
... but for FPWD the normal thing to point out known issues and get review
14:40:47 [nikos]
krit: that would be ok for me
14:40:58 [nikos]
heycam: if you can list the issues that should be pointed out, I can add them to the draft
14:41:15 [nikos]
krit: Doug points out a lot of things in the introduction. All of them should be issues
14:41:35 [nikos]
ChrisL: normally issues should be displayed prominently
14:42:33 [nikos]
... I agree with the points you're raising
14:42:40 [nikos]
... HTML5 has some good stuff that we can point to for definitions
14:43:39 [nikos]
heycam: I agree that for things like fetching there's a lot of work to go into the SVG 2 spec for the right hooks
14:44:16 [nikos]
krit: I have a new document that has text that can be copied into the integration spec
14:44:53 [nikos]
... in the meantime we can link to my document for things like fetching strategies
14:45:27 [nikos]
heycam: so can you provide me with the list of issues?
14:45:29 [nikos]
krit: yes
14:45:38 [nikos]
heycam: when is next committee draft being done?
14:45:41 [nikos]
ChrisL: think that ship has sailed
14:45:51 [nikos]
... had to put it in their own document
14:45:57 [nikos]
... but Vlad is waiting for a reference to switch to
14:46:04 [nikos]
... so we do have a few months
14:46:35 [Tavmjong]
Tavmjong has joined #svg
14:47:07 [nikos]
heycam: let's work on it tomorrow
14:47:14 [nikos]
... then maybe publish at next telcon
14:47:35 [nikos]
ChrisL: a fresh resolution to publish would be good
14:47:56 [nikos]
heycam: would people be happy to publish the document as is plus the list of issues from Dirk?
14:47:58 [nikos]
ChrisL: yes
14:48:24 [nikos]
RESOLUTION: Publish FPWD of SVG integration once list of issues is included
14:49:06 [heycam]
Scribe: Cameron
14:49:12 [heycam]
ScribeNick: heycam
14:49:38 [heycam]
Topic: Text issues
14:49:53 [heycam]
Tav: I have 46 text issues
14:50:45 [heycam]
... first one, foreignObject
14:51:22 [heycam]
... it says in text from SVG 1.1 "if more complex layout is required [ ... ] such as XHTML in foreignObject, the exact semantics are not completely defined at this time"
14:51:25 [heycam]
ChrisL: we take out the mention of XHTML
14:51:27 [heycam]
... and just say HTML
14:51:35 [heycam]
... and if you're using XML serialization fine
14:51:53 [heycam]
heycam: we should define exactly how HTML in foreignObject works
14:52:04 [heycam]
ChrisL: we need to say that the very common thing, HTML, is defined
14:52:13 [heycam]
... and say that it establishes an outermost continaing block context
14:52:19 [heycam]
ed: I think that's in SVG Integration
14:52:46 [heycam]
ChrisL: I'd like for it to say that foreignObject can have all sorts of stuff, but one thing is html, and here's how it works with the CSS box model
14:53:13 [heycam]
Tav: next, issue 8
14:53:17 [ChrisL]
establishes an outermost containing block
14:53:21 [heycam]
... we talked about using height and width for providing a wrapping context
14:53:34 [heycam]
... I think that causes problems, in that our origin is not the upper left corner, it's the text baseline for horizontal text
14:53:39 [heycam]
... which if you just have a width is not a problem
14:53:42 [heycam]
... same thing if you have a height
14:53:52 [heycam]
... the origin is the center of the kanji glyph for example
14:53:56 [heycam]
... as soon as you say width and height it's a problem
14:54:24 [heycam]
... I think for the purpose of text in a rectangle, we should use shape-inside for that, rather than mess around with width/height and define how you shift down
14:54:33 [heycam]
... it also makes it hard to do the SVG 1.1 text position fallback
14:56:35 [heycam]
[explains how to use tspans with x/y to do fallback]
14:57:10 [heycam]
heycam: so the presence of width="" controls whether x/y on <text> are ignored
14:57:16 [heycam]
... is that a problem?
14:57:17 [heycam]
Tav: no
14:59:58 [heycam]
heycam: I think x/y/width/height should be the rectangle into which to lay out the text
15:00:18 [heycam]
Tav: but then the y value on the <text> doesn't match the non-rectangular-layout position of the first line of text
15:00:33 [heycam]
... makes the fallback harder to write, you have to shift the lines down to fit into the box
15:00:43 [heycam]
... I think instead you should use shape-inside to define the rectangle to lay text into
15:00:58 [heycam]
heycam: what happens if you put width and height then?
15:01:09 [heycam]
... you should use the one appropriate for the writing-mode on the <text>?
15:01:12 [heycam]
Tav: yes
15:01:41 [heycam]
... next, issue 16
15:01:54 [heycam]
... shapes define an inset rectangle, which I thought might be interesting
15:02:06 [heycam]
... this has to do with syntax, being able to define something inside a different shape
15:04:30 [heycam]
... inset-rect
15:04:41 [heycam]
heycam: not sure how different this would be from padding?
15:04:53 [heycam]
Tav: should we allow elements inside other elements, and use the geometry of those elements
15:05:02 [heycam]
... for connectors it would be useful to have a point defined in terms of the bounding box of the object
15:05:15 [heycam]
... should you be able to define a text box in terms of an outer element
15:11:48 [heycam]
Tav: next thing is issue 22
15:11:52 [heycam]
... there are a number of issues here
15:12:04 [heycam]
... I assume we want to reference CSS writing modes
15:12:07 [heycam]
... they do things a bit differently
15:12:11 [heycam]
... from what SVG 1.1 has done
15:12:21 [heycam]
... if I copy them directly, I don't know if it will break content
15:12:40 [heycam]
heycam: I would say it wouldn't break content
15:12:57 [heycam]
Tav: there is direction, unicode-bidi and writing-mode
15:14:02 [heycam]
ChrisL: at one point we thought that unicode-bidi and writing-mode was all we needed, but we were told direction was needed
15:14:16 [heycam]
Tav: there are values like lr-tb, ... in SVG 1.1
15:14:27 [heycam]
... and horizontal-tb, etc. in css3-writing-modes
15:14:33 [heycam]
ChrisL: the SVG 1.1 ones are copied from XSL
15:14:43 [heycam]
Tav: we should just move to the CSS values?
15:15:07 [heycam]
heycam: yes
15:15:42 [heycam]
Tav: writing-mode also misses the mongolian direction
15:15:46 [heycam]
... in SVG 1.1
15:15:57 [heycam]
... next, issue 28
15:16:08 [heycam]
... glyph-orientation-vertical, etc.
15:16:33 [heycam]
... it has additional values upright and inline in css3-text
15:18:17 [heycam]
heycam: seems to be not in the latest draft of css3-text
15:18:27 [heycam]
... if it's not there, we shouldn't have it
15:19:04 [heycam]
Tav: next, issue 30
15:19:17 [heycam]
... we use "current text position" over 100 times in the Text chapter
15:19:24 [heycam]
... and I don't think that's a CSS layout term
15:19:34 [heycam]
... I think that needs to be purged somehow
15:19:40 [heycam]
ChrisL: is there an alternative term to use?
15:25:26 [heycam]
heycam: I reckon you won't need that term, since you'll be deferring to CSS box layout
15:25:31 [heycam]
Tav: next, issue 35
15:25:40 [heycam]
... baseline-shift is still in css3-line
15:25:44 [heycam]
... useful for super/subscripts
15:25:46 [heycam]
... Inkscape uses it for
15:25:56 [heycam]
... vertical-align is a shorthand for baseline-shift etc.
15:27:42 [heycam]
heycam: [talks about how that spec is not being worked on, but might soon by Alan]
15:27:58 [heycam]
Tav: in general, CSS has more features on text than we've ever had
15:28:09 [heycam]
... text-indent hanging-punctuation
15:28:16 [heycam]
... do we pull all those things in?
15:29:16 [heycam]
heycam: I think for text/inline stuff yes assume it works
15:29:22 [heycam]
Tav: next, issue 42
15:29:40 [heycam]
... text-overflow:clip
15:29:48 [heycam]
... it's already possible to do clipping with clip path, this is only clipping if the text overflow
15:29:52 [heycam]
... convenient shorthand
15:30:03 [heycam]
... in issue 41 it's argued this property is useless
15:30:19 [heycam]
... it would be useful if you move the mouse to the ellipses and show the remaining text
15:31:31 [heycam]
... do we agree we should have text-overflow?
15:31:38 [heycam]
heycam: what does text-overflow apply to? block or inline elements?
15:32:16 [heycam]
ed: makes sense to keep clip
15:32:25 [heycam]
ed: applies to block container
15:34:23 [heycam]
heycam: I think the hover to show the overflow should be done in the document
15:35:24 [heycam]
text { text-overflow: ellipsis; overflow: hidden; } text:hover { overflow: visible; }
15:35:42 [heycam]
Tav: next, issue 45
15:35:48 [heycam]
... I assume we're linking to css3-fonts
15:35:53 [heycam]
... font-variant has been completely reworked
15:35:54 [heycam]
ChrisL: yes
15:37:02 [heycam]
Tav: next, issue 46
15:37:07 [heycam]
... css3-text-decoration
15:37:16 [heycam]
... it's a bit different from what SVG has done in the past
15:37:18 [heycam]
... you can set the colour on the underline
15:37:51 [heycam]
... I assume we want to preserve the text-decoration like it's shown in the figure
15:38:05 [heycam]
... you can have the stroke and fill different on underline, but at the same time allow text-decoration-color to set the colour
15:38:09 [heycam]
... would that remove the stroke?
15:38:15 [heycam]
ChrisL: they don't really distinguish between fill and stroke
15:38:23 [heycam]
... they tend to talk about "the" colour of the text
15:41:27 [heycam]
heycam: maybe make text-decoration-color affect only the fill of the decoration
15:41:33 [heycam]
... not sure how to deal with currentColor being the initial value
15:43:25 [heycam]
Tav: we should define how/whether text-decoration on text on a patch works
15:43:30 [heycam]
ed: that's been undefined for a while
15:43:38 [heycam]
... some people use textPath for multi-line text
15:43:43 [heycam]
... and would expect underlines to work there
15:44:10 [Zakim]
heycam, you asked to be reminded at this time to go home
15:44:19 [heycam]
Zakim, thanks
15:44:19 [Zakim]
you are very welcome, heycam
15:44:49 [heycam]
RESOLUTION: text-decoration doesn't paint on a <textPath>
15:45:37 [heycam]
-- end --
15:45:42 [heycam]
RRSAgent, make minutes
15:45:42 [RRSAgent]
I have made the request to generate http://www.w3.org/2014/04/09-svg-minutes.html heycam
15:46:18 [heycam]
Present: Cameron, Rik, Dirk, Tav, Satoru, Brian, Erik, Chris, Nikos
15:46:23 [heycam]
RRSAgent, make minutes
15:46:23 [RRSAgent]
I have made the request to generate http://www.w3.org/2014/04/09-svg-minutes.html heycam
15:46:56 [ChrisL]
http://www.w3.org/community/groups/proposed/#svgadvgrad
16:29:06 [shepazu]
shepazu has joined #svg
17:45:26 [thorton]
thorton has joined #svg
18:08:29 [Zakim]
Zakim has left #svg
19:36:26 [Tavmjong]
Tavmjong has joined #svg