22:10:58 <RRSAgent> RRSAgent has joined #svg
22:10:58 <RRSAgent> logging to http://www.w3.org/2009/02/18-svg-irc
22:11:00 <trackbot> RRSAgent, make logs public
22:11:00 <Zakim> Zakim has joined #svg
22:11:02 <trackbot> Zakim, this will be GA_SVGWG
22:11:02 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
22:11:03 <trackbot> Meeting: SVG Working Group Teleconference
22:11:03 <trackbot> Date: 18 February 2009
22:11:14 <ChrisL> zakim, remind us in 9 hours to go home
22:11:14 <Zakim> ok, ChrisL
22:11:27 <ChrisL> rrsagent, this meeting spans midnight
22:12:37 <ChrisL> Meeting: Annual Barbeque Outing
22:13:10 <ChrisL> Chair: wooden item for sitting upon
22:13:52 <shepazu> ChrisL, new phone number is 02 9976 8721
22:14:20 <ChrisL> thanks!
22:14:27 <ChrisL> 02?
22:14:39 <shepazu> sorry, +612
22:14:45 <ChrisL> gotcha
22:14:45 <anthony> not 02
22:14:51 <ed__> new room, new countrycode
22:15:29 <ChrisL> was the old troom not to your liking? insufficient sea views, perhaps?
22:15:44 <shepazu> the new room is *much* further away
22:22:15 <heycam> Scribe: Cameron
22:22:19 <heycam> ScribeNick: heycam
22:23:15 <heycam> Topic: SVG 3D transforms
22:23:22 <heycam> ED: anthony you were saying it's mostly done, ready for publication?
22:23:29 <heycam> AG: the changes we talked about on tuesday i've started folding in
22:24:03 <heycam> AG: i was going to add a bit more wording on how to handle the order of rendering and maybe put in the backface-visibility
22:24:10 <heycam> CM: don't think we agreed to backface-visibilty yet
22:24:18 <heycam> ED: don't need to put everything in yte
22:24:21 <heycam> s/yte/yet/
22:24:27 <heycam> AG: the other thing is layeredGroup
22:24:54 <heycam> AG: that can probably wait as well, can put in a comment that mention backface-visibility and layeredGroup as possible things to be added later
22:24:58 <ChrisL> Dean's comments on Steve Zilles' objection http://lists.w3.org/Archives/Member/w3c-css-wg/2009JanMar/0104.html
22:25:07 <heycam> DS: also put in the spec that we're seeking to converge with CSS on a single solution
22:25:22 <heycam> AG: need to update the use cases document with a few points we made the other day
22:25:28 <heycam> AG: openvg requirement
22:25:57 <heycam> AG: and the general plan to have alignment between our's and CSS'
22:26:05 <heycam> DS: they don't have a use cases and requirements document
22:30:38 <heycam> AG: i've put together all my thoughts from tuesday and i'll draft up an email to send it to our list for review
22:30:40 <heycam> DS: so it seems like you took a lot of stuff from theirs
22:30:41 <heycam> AG: yes
22:31:28 <heycam> ... we had an earlier proposal but we wanted to align more closely with theirs
22:31:43 <heycam> ... so that implementors and users could have consistent functionality
22:32:15 <heycam> CM: you'll have that draft mail ready for when?
22:32:25 <heycam> AG: could be today
22:33:10 <heycam> DS: any objections to publishing svg 3d transforms?
22:33:19 <heycam> JW: no objections, but haven't got a good understanding of the module yet
22:40:09 <ChrisL> We need to be sure that the CSS transform stuff fits with SVG transforms, when both are applied. Dean mentioned this in his email
22:41:42 <heycam> RESOLUTION: We'll publish what we have currently for the SVG 3D Transforms module
22:43:15 <heycam> ACTION: Anthony to prepare SVG 3D Transforms for publication
22:43:15 <trackbot> Created ACTION-2474 - Prepare SVG 3D Transforms for publication [on Anthony Grasso - due 2009-02-25].
22:43:24 <heycam> ACTION: Doug to prepare SVG 3D Transforms for publication
22:43:24 <trackbot> Created ACTION-2475 - Prepare SVG 3D Transforms for publication [on Doug Schepers - due 2009-02-25].
22:43:40 <heycam> RRSAgent, pointer?
22:43:40 <RRSAgent> See http://www.w3.org/2009/02/18-svg-irc#T22-43-40
22:44:48 <heycam> Topic: Vector effects
22:44:58 <ChrisL> http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.html
22:45:07 <ChrisL> http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffects.html
22:45:29 <heycam> ED: starting with the primer
22:45:56 <heycam> CL: i've started to explain in general terms about rendering order and combining stuff, how to make compound shapes
22:46:11 <heycam> CL: there's a useful diagram with text-with-stroke
22:46:20 <heycam> CL: where it looks ugly with the stroking on top, and nice with stroking behind
22:46:46 <heycam> CL: then i summarise what vector effects can do
22:47:04 <heycam> ... the basic idea is that in 1.1 and 1.2T, the default rendering order is fill then stroke then markers
22:47:11 <heycam> ... always in that order, and exactly one stroke, etc.
22:47:19 <heycam> ... the idea is to have a property on any shape that lets you modify that
22:47:34 <heycam> ... so you can stroke/fill in different orders, multiple strokes, modify the shape of the stroke, convert the stroke to a path and then stroke it, etc.
22:47:56 <heycam> ... one particular use case, which came from andreas neumann, for cartography is to have pieces of geometry and stitch them together
22:48:05 <heycam> ... e.g. the border between france and belgium, you want to just render that border once
22:48:23 <heycam> ... then i go through in the same order as the language spec giving a one or two sentence explanation of each primitive and a picture
22:48:32 <heycam> ... so the first one is veStrokePath
22:48:46 <heycam> ... i put a thick stroke on it and turn it into a path and then stroke it
22:49:09 <heycam> DS: chris did you change the image for the previous example?
22:49:13 <heycam> CL: yes i've done a bit of tidying up
22:49:29 <heycam> JW: when you say the stroke is converted to a path, you mean the edges of the stroke become a path and then those edges are stroked themselves
22:49:31 <heycam> CL: right
22:49:45 <heycam> ... veStroke is a command to draw a stroke, but you can have multiple ones of them
22:49:55 <heycam> ... in the example there are three of them
22:50:00 <heycam> ... veReverse changes the orientation of a path
22:50:08 <heycam> ... probably only useful in combination with something else, e.g. markers
22:50:27 <heycam> ... any markers that are asymmetric and oriented automatically are flipped
22:50:33 <heycam> ED: this could be useful for motion path as well?
22:50:35 <heycam> CL: yes it could
22:50:42 <heycam> DS: this would have effects on fill
22:50:44 <heycam> CL: yes it would
22:51:04 <heycam> DS: fill-rule="evenOdd"
22:51:26 <heycam> CL: next one is veUnion
22:51:36 <heycam> ... merges two shapes together
22:52:23 <heycam> ... two drawings for that, two random shapes unioned
22:52:41 <heycam> ... the other example is having a thick stroke, converted that to a stroke, then unioned them
22:52:45 <heycam> ... so that's like an outset effect
22:53:22 <heycam> DS: is that unioning the colours too?
22:53:25 <heycam> CL: no it's just the shape
22:53:59 <heycam> CM: do you think it's worth having an explicit veOffset primitive?
22:54:00 <heycam> CL: maybe
22:54:12 <heycam> ... i wonder whether inset/outset should be added
22:54:44 <heycam> ... next is veIntersect, which does intersection
22:54:48 <heycam> ... subtraction of shapes
22:55:27 <heycam> ... hopefully that example makes it obvious what veIntersect is useful for
22:55:33 <heycam> DS: would the fill-rule properties have an effect here too?
22:55:35 <heycam> CL: yes they would
22:56:45 <heycam> DS: one thing with fill-rule i've wanted is a third value that can fill all the interior of shapes
22:56:52 <heycam> CL: if they were separate shapes you could do that with a union
22:57:02 <heycam> DS: so basically take the outline, and fill everything inside (and still have strokes etc.)
22:57:36 <heycam> CL: next one down is a veExclude
22:58:58 <heycam> CL: you can do an "inside stroke" effect with it, i'll add an example for it
22:59:19 <heycam> ... next are examples that are originally from peter sorotokin
22:59:47 <heycam> ... let's move on to the language spec
23:00:23 <heycam> DS: when reading in the language spec it talks about the default rendering order, i'd put a visual example of what is meant by that
23:00:50 <ChrisL> http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffects.html
23:01:09 <heycam> CL: this is much more littered with ednotes
23:01:15 <heycam> ... first is the vectorEffect element
23:01:22 <heycam> ... you can use it like you use a filter
23:01:26 <heycam> ... putting it in a <defs>
23:01:35 <heycam> ... but also you can use it as a drawing primitive directly
23:01:43 <heycam> ... so if you do want to hide it you need to put it into <defs>
23:01:54 <heycam> ... it should be possible to do both
23:02:13 <heycam> ED: you could put display:none on it and reference it from somewhere else
23:02:40 <heycam> CL: there's a couple of attribute definitions
23:02:49 <heycam> ... 'clipout', which doesn't have any examples
23:02:55 <heycam> ... i need to look at that a bit more
23:03:01 <heycam> ... most of this has been taken from the original 1.2 chapter
23:03:06 <heycam> ... i've tried to tidy it up
23:03:26 <heycam> ... as doug says, the default vector effect is there in this section
23:04:08 <heycam> AG: i'll send in some comments about wording
23:04:44 <heycam> CL: so this is an advantage compared to filter primitives, we say what happens when you have a "null" one
23:04:50 <heycam> ... which is that there's no rendering
23:04:54 <heycam> ... next section, there's a big ednote
23:05:15 <heycam> ... so not all of these attributes are available on *all* vector effect primtiives
23:05:20 <heycam> ... so i will redo this section
23:05:36 <heycam> ... the definitions of these common attributes need to be here, but they're not all used on all primitives
23:05:52 <heycam> ... i was looking in the filters chapter, there was the same kind of thing, e.g. x/y/width/height are used on lots of primtiives
23:05:57 <heycam> ... i'll do that same editing here
23:06:15 <heycam> DS: it might help people conceptualize this if you point out that the way this works is a bit like filters
23:06:23 <heycam> ... it's like a graph of primitives
23:06:32 <heycam> ... and it's similar in its syntax and way of defining effects
23:06:54 <heycam> ED: some of the vector effects will be more expensive than others
23:07:09 <heycam> DS: it'd be good to point out which ones are more expensive than others (for both vector effects and filter effects)
23:07:23 <heycam> ED: there is some wording like that in the filters spec, but it's not really on everything
23:08:07 <heycam> ED: would you like to see two classes of conforming UAs?
23:08:11 <heycam> CL: i think it's more guidance for authors
23:08:12 <heycam> DS: yes
23:08:28 <heycam> CL: e.g. telling them that they shouldn't set the filter region to the whole canvas
23:08:42 <heycam> ... the other ednote in this section is whether the attributes are animatable or not
23:08:52 <heycam> ... some of them i made guesses, since it didn't say so in the 1.2 draft
23:09:12 <heycam> CM: in the filters spec are in and in2 animatable?
23:09:18 <heycam> ED: yes
23:09:29 <ChrisL> so they should be animatable here also
23:09:34 <heycam> ED: result is also animatable in the filters spec
23:09:59 <heycam> CL: what's the diff between transform and transformPath?
23:10:04 <heycam> s/CL/CM/
23:10:08 <heycam> CL: it's not immediately clear
23:10:26 <heycam> ... one of them, transform, it basically pops you into a different coordiante space, does the operation, and then reverses the transformation
23:10:36 <heycam> ... whereas transformPath, oddly named, just does a transform
23:10:54 <heycam> ... so if you go up to the primer again, and look at the second diagram, with three hearts
23:11:04 <heycam> ... the pink heart with the skewed blue stroke, that would be an example of transformPath
23:11:07 <heycam> ... we can rename these two attributes
23:11:14 <heycam> ... the idea is that most of the outputs of these primitives are paths
23:11:20 <heycam> ... so all it's done is transform it
23:11:54 <heycam> ... if you transformed it into something that's three times as wide, it would end up being thin
23:12:16 <heycam> ... if transform it, stroke, then inverse transform it, the stroke ends up not being uniformly thick
23:13:13 <heycam> ... next is veStrokePath
23:13:21 <heycam> ... it takes the stroke and turns it into a path, basically
23:13:29 <heycam> ... if you don't give it any params, it takes what the stroke would've been
23:13:39 <heycam> ... but you can provide attributes on the element to give it different stroking
23:13:52 <heycam> ... there are the usual things you can put on strokes, e.g. stroke-dasharray, stroke-width, et.c
23:14:03 <heycam> ... in the original spec, these were defined with a bit of RNG
23:14:12 <heycam> ... so far these are all the same as the correspondingly named property
23:14:17 <heycam> ... do we need to allow the word inherit?
23:14:26 <heycam> ... where you'd inherit from, the parent, wouldn't have useful values
23:14:39 <heycam> CM: so these are attributes and not properties?
23:14:48 <heycam> CL: if they're properties, then you can style them
23:15:00 <heycam> ... but the disadvantage is that you'd have properties with same names but different sets of values
23:15:10 <heycam> ... then you'd need to rename them to something else
23:15:33 <heycam> ... the value of using a stylesheet isn't that high, imo
23:15:49 <heycam> ED: if you use the same attribute names, it could be a bit tricky with parsing and mapping them to properties
23:15:53 <heycam> ED: maybe we should rename the attributes?
23:16:05 <heycam> CL: we could prefix them all with "ve" e.g.
23:16:23 <heycam> CM: they're like the font attributes
23:16:38 <heycam> CL: it puts a bit of work on the implementor, but i think it makes it more understandable for the author
23:16:51 <heycam> CL: as it is now, they're the same (except for perhaps removing "inherit")
23:17:10 <heycam> ... stroke-opacity was missing from the original spec, so i've added it here
23:17:33 <heycam> ED: so veStrokePath produces an outline, how would opacity affect the outline?
23:17:39 <heycam> CL: all of these attributes are controlling the stroke, then you're converting that to a path
23:17:47 <heycam> ... there's a veStroke as well, which has all the same attributes on it
23:17:58 <heycam> ... the properties are the ones pertaining to the stroke
23:18:20 <heycam> ... e.g. if you had stroke-dasharray, each dash gets converted to subpaths
23:18:28 <heycam> s/subpaths/a subpath/
23:18:42 <heycam> ED: if you have stroke-opacity:0.5, what effect would it have?
23:18:49 <heycam> CL: it'd be the same as setting stroke-opacity:0.5 normally
23:18:59 <heycam> ED: so it has no effect on the path, just how it's rendering?
23:19:20 <heycam> CL: next is veSetback
23:19:27 <heycam> ... it has a single attribute, a list of four lengths
23:19:34 <heycam> ... i need to draw a diagram for this
23:19:47 <heycam> ... imagine an arc with arrowheads
23:19:53 <heycam> ... then you put a really thick stroke on the line
23:20:09 <heycam> ... so parts of the line stroke come out past the arrowhead
23:20:23 <heycam> ... so it puts it sets the path back
23:20:39 <heycam> DS: so that's similar to the offset on paths
23:21:22 <heycam> JW: why can't you set the origin of the maker to match the end of the stroke?
23:21:35 <heycam> DS: they have to give numeric values, they can't say "put it at the end of the stroke"
23:21:49 <heycam> ... they have to judge themselves what the right offset is
23:22:19 <heycam> [doug draws]
23:27:12 <heycam> JW: with setback you need to keep a track of the marker dimensions
23:27:25 <heycam> ... perhaps easier is to say that the stroke is masked out by the marker, haven't thought that through though
23:27:42 <heycam> CL: so you'd convert the stroke to a path, and convert the marker to a path, then use the union/exclusion operations
23:28:20 <heycam> CM: there should be some simple thing to say "automatically draw the path up to the right point of the back of the marker"
23:29:02 <heycam> CM: maybe markers should have two origin points (the front and the back of the arrowhead)
23:31:52 <heycam> DS: i'd suggest marking veSetback as needing examination for use cases
23:36:00 <heycam> CL: veAffine is next
23:36:09 <heycam> ... it just moves the path, applies a transform to the path
23:36:24 <heycam> ... veReverse, the diagram in the primer explains that
23:36:34 <heycam> ... next, veJoin, don't have an example of that
23:36:39 <heycam> ... it takes two paths and concatenates them
23:36:48 <heycam> ... with an attribute that says whether to insert a lineto to join them
23:36:55 <heycam> ED: with veAffine, would that apply 3d transforms?
23:37:07 <heycam> CL: maybe veTransform would a better name than veAffine then
23:38:43 <heycam> CM: maybe a third option for 'connect' to make the start point of the second path be the same as the end point of the first path
23:38:48 <heycam> ... not sure of the use cases though
23:39:40 <heycam> CL: next three 
23:41:34 <heycam> CM: the algorithms for some of these things might not be well known
23:41:40 <heycam> CL: inkscape implements them, mostly
23:41:59 <heycam> ... i'm wondering if these child elements should be in alphabetical order
23:43:21 <heycam> CL: veFill is how you do your basic fill
23:43:24 <heycam> ... it has the usual fill properties
23:43:36 <heycam> ... in theory you could do multiple fills
23:44:25 <heycam> ... the examples use these values "currentStrokeOpacity" etc., but they're not valid values yet
23:45:43 <heycam> ... particularly useful here would be to allow markers to be painted with whatever the current stroke paint is
23:46:22 <heycam> DS: if you have a marker with stroke green fill lime, and i want to change it to cornflowerblue/blue
23:46:27 <heycam> CL: you want to do computations on the colour values?
23:46:33 <heycam> DS: not necessarily
23:47:06 <heycam> ... we could say that in the marker, give it keyword values
23:47:13 <heycam> ... i often have different colours for the fill and the stroke
23:48:04 <heycam> CM: is there a marker-opacity?
23:48:14 <heycam> ED: no, but you can put opacity on the contents of the marker itself
23:48:57 <heycam> ISSUE: We need to define the order of rendering for markers on a path
23:48:57 <trackbot> Created ISSUE-2229 - We need to define the order of rendering for markers on a path ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2229/edit .
23:49:42 <heycam> CM: there's a question there, is fill-rule needed on veFill?
23:50:07 <heycam> CM: might be good to just include them all
23:50:26 <heycam> CL: a question for marker
23:50:32 <heycam> ...  there is a marker shorthand
23:50:43 <heycam> ... when we made attribute questions, we decided not to have attributes for shorthands
23:50:52 <heycam> ... because attributes are unordered
23:51:10 <heycam> ... if you said marker="blah" marker-start="foo" you wouldn't know which one wins
23:51:22 <heycam> ... otoh people often do says marker:blah and put the same marker on everything
23:52:30 <heycam> ED: in our implementation, you wouldn't look at the values until you need the cascaded values
23:52:33 <heycam> ... so it shouldn't be a problem
23:52:58 <heycam> CL: otherwise currently you have to repeat those three marker-* attributes
23:53:05 <heycam> ... however some implementations allow you to do that
23:53:13 <heycam> ... those implementations are inconsistent on which ones win
23:53:24 <heycam> CM: same for @font i guess
23:53:32 <heycam> ED: they're the only shorthands we have, i think
23:54:23 <heycam> CL: veMarkerPath, this lets you convert a marker to the union of marker contents
23:54:39 <heycam> CM: what happens to the styling of the shapes within the marker?
23:54:54 <heycam> CL: the output it is a path
23:55:32 <heycam> s/it //
23:55:40 <heycam> ... most of these elements produce another path, some of them draw something
23:55:46 <heycam> ... you'd need to use them in combination, often
23:56:04 <heycam> ... vePath and vePathRef are interesting
23:56:11 <heycam> ... vePath is a parent, with any number of vePathRef children
23:56:18 <heycam> ... this is how you take 20 different paths and combine them all
23:56:28 <heycam> ... in some cases you need to reverse them as well
23:56:59 <heycam> CM: so you would define boundary paths, them reference them here
23:57:22 <heycam> DS: as an aside, in firefox if you set stroke-opacity it doesn't do anything do the marker
23:57:27 <heycam> ... setting fill-opacity doesn't do anything
23:57:30 <heycam> ... setting opacity it does
23:58:25 <heycam> CL: next is the vector-effect property
23:58:33 <heycam> ... we've already used part of this in 1.2T, the non-scaling-stroke thing
23:58:52 <heycam> CM: would you imagine introducing new keywords for more canned vector effects?
23:59:09 <heycam> CL: so you can also specify "default", which is the plain vector effect
23:59:15 <heycam> ED: in tiny the initial value is "none", rather than "default"
23:59:17 <ed__> http://www.w3.org/TR/SVGMobile12/painting.html#NonScalingStroke
00:00:18 <heycam> CL: so we'll keep the value "none" and explain it means the default vector effect
00:01:03 <heycam> ... next issue is that we have the default vector effect; what happens in 1.2T that doesn't implement markers?
00:01:21 <heycam> ... can you use veMarker when you don't support markers?
00:01:23 <heycam> ... is it a no-op
00:01:34 <heycam> CM: is it likely that there will be implementations that do full vector effects but not markers?
00:01:36 <heycam> CL: probably
00:02:05 <heycam> CM: easiest would be to say that veMarker is a no-op, imo
00:02:31 <heycam> CL: we could have language in there that says "if the host language supports marker, then..."
00:04:38 <heycam> ... note here the definition of non-scaling-stroke
00:07:58 <heycam> ED: ref(host) should be ref(svg)
00:08:21 <heycam> CL: back to the examples in the primer
00:09:10 <heycam> ... the second example is a fill pattern that doesn't scale
00:09:45 <heycam> ... the third example is bogus, stroke-width-adjust doesn't appear anywhere else in the spec
00:10:17 <heycam> ED: if you use stroke-width="nn%"
00:10:29 <heycam> ... then just say that percentages there are resolved against the stroke-width on the original path
00:10:41 <heycam> CM: i guess that's similar to font-size percentage resolution
00:10:53 <heycam> CL: next is the example that was at the top of the document
00:11:07 <heycam> ... next is the example making markers take the colour of the strke
00:11:10 <heycam> s/strke/stroke/
00:11:49 <heycam> DS: this satisfies a longstanding problem with markers
00:12:12 <heycam> ... could you change the opacity of the marker, or stroke-dasharray of the marker?
00:12:29 <heycam> CL: markers can be arbitrarily complex
00:12:32 <heycam> ... and markers can have markers
00:13:22 <heycam> ... there's an example in the test suite where markers have markers
00:14:19 <heycam> ... two more examples, one is the same as the preceding but a bit different
00:14:46 <heycam> ... converts the fill/stroke/marker to a single path, and then paints it
00:14:53 <heycam> ... you can see the example of this when using a gradient, e.g.
00:15:04 <heycam> ... the last example shows vePath
00:15:29 <heycam> ED: it'd be good to see an example of a map, to see if it's actually more compact
00:15:34 <heycam> ... there's a lot of syntax with the vePath stuff
00:15:51 <heycam> CL: with a large number of points in the paths, it'd be a win
00:16:20 <heycam> ... the other thing here is that if you export the same thing multiple times, especially with paths reversed, you can sometimes get paths that don't fit together exactly
00:16:55 <ChrisL> what was the nuber again?
00:17:27 <heycam> +61 2 9976 8721
00:18:25 <ChrisL> i got a receptionist
00:18:33 <heycam> ok let me check
00:18:41 <heycam> hmm
00:18:45 <heycam> try again?  the number should be right
00:21:37 <heycam> CM: what would happen with events?
00:21:45 <heycam> CL: you should be able to put event handles on these things that are drawn
00:23:19 <heycam> ... same with symbol/use, what happens there?
00:23:26 <heycam> ED: there's the SVGElementInstance tree objects
00:24:16 <heycam> JW: why are we using xlink:href on these?
00:24:31 <heycam> CL: because that's what we use everywhere
00:24:39 <heycam> JW: how about dropping the xlink prefix here?
00:24:51 <heycam> CL: if you want to suggest dropping xlink prefix everywhere, that'd be more reasonable
00:24:58 <heycam> CL: but not just on the one
00:25:28 <heycam> DS: for text, i think we should special case it to say that the stroke is by default behind the fill
00:25:41 <heycam> CM: have a canned stroke-behind vector effect?
00:26:20 <ChrisL> someone mentioned putting ve ona  group?
00:26:21 <heycam> ... so you could put vector-effect property on a group
00:26:29 <heycam> CL: not sure that's supported currently
00:27:06 <heycam> DS: we might like to say that the stroke is behind all of the text glyphs
00:29:47 <heycam> "Each property may also have a specified value of 'inherit', which means that, for a given element, the property takes the same computed value as the property for the element's parent."
00:33:19 <heycam> DS: it'd be useful to have an interface to get resulting path geometry from vector effects
00:35:36 <heycam> DS: i couldn't figure out how to do variable stroke width
00:35:45 <heycam> CL: i don't think you could with this, it might be possible to add it
00:35:54 <heycam> DS: could be that we do it with some other mechanism than vector effects
00:36:09 <heycam> CM: just add a new stroke property
00:36:32 <shepazu> http://www.inkscape.org/screenshots/gallery/inkscape-0.45-patternalongpath.png
00:36:33 <heycam> CL: you could have something like a gradient definition
00:36:41 <heycam> CL: to define the varying stroke width
00:36:49 <heycam> CM: might be simpler to just have lists of numbers in properties
00:37:20 <heycam> CL: the face one could be done with that gradient-like definition
00:37:35 <heycam> CL: the snake one looks complex
00:38:22 <heycam> CM: a brush element that can be referenced?
00:38:57 <heycam> DS: there was an example of someone using an SVG font to make custom shapes, and then place the shapes along a path (with textPath)
00:39:15 <ChrisL> object-on-a-path
00:40:50 <heycam> CM: when will we publish this?
00:40:58 <heycam> CL: i'd like to get these comments discussed today addressed
00:41:07 <heycam> ED: it'd be nice to have some thought go in to the DOM aspects of htis
00:41:11 <heycam> s/htis/this/
00:41:19 <heycam> ... there's nothing so far, but maybe there should be something
00:42:26 <heycam> Topic: CSS transitions
00:42:47 <ed__> http://dev.w3.org/csswg/css3-transitions
00:44:30 <heycam> ED: i didn't find what happens when there's a mismatch between the number of transition-property and transition-duration properties
00:44:59 <heycam> Topic: Back to vector effects for a minute
00:45:23 <heycam> DS: alex adam asked what's the use case for union, intersect and include
00:45:33 <heycam> ... he says, isn't that something that an authoring tool should do?
00:45:48 <heycam> ... to me, the use case is that these things might change dynamically, they might be animated
00:45:58 <heycam> ... or you're just constructing paths at run time
00:46:29 <heycam> ... to me, that's the use case, but we should talk about the explicitly, and talk with the inkscape community to see if this is something that they want
00:46:36 <heycam> CL: i'd like to have a draft out before libre graphics, and talk to those guys there
00:47:33 <heycam> JW: it's a fair question, anyway
00:47:50 <heycam> ED: perhaps different conformance classes, maybe for authoring tools
00:48:22 <heycam> AG: the vector-effects property doesn't mention styling, but it has visual effects, should it go in CSS?
00:48:25 <heycam> ED: it's a css property
00:48:26 <heycam> AG: ok
00:49:06 <heycam> Topic: CSS transitions
00:49:20 <heycam> ED: so i couldn't find what happens when there is a mismatch
00:49:46 <heycam> ... there's a table at the end that says animatable properties
00:49:52 <heycam> ... why define in that spec which properties are animatable?
00:50:04 <heycam> CM: maybe as an initial definition of which ones are animatable
00:50:17 <heycam> ED: it misses out some SVG properties
00:50:35 <heycam> ... also he leaves out a bunch of the ones that are keyword values
00:50:44 <heycam> CM: in SVG all properties are animatable
00:51:45 <heycam> ED: in 1.2T we have two properties that aren't animatable
00:52:37 <heycam> ED: for the svg properties, it should just point to the svg spec to determine whether it is animatable
00:53:19 <heycam> DS: maybe they just want a single place to list which properties are animatable, but maybe a tutorial is better for that
00:53:41 <heycam> ED: for the css props that svg imports, i haven't checked the table to see if there are any mismatches in animatability
00:54:28 <heycam> ED: this spec is quite simple, so my question would be is it useful to have this spec if css animations is also there?
00:54:43 <heycam> ED: what's the point of making this spec simple if it doesn't address the use cases that css animations does?
00:54:53 <heycam> DS: iirc, the transitions were meant to be really simple
00:55:16 <heycam> ... there was some disagreement, that bert saw the use cases for transitions but not for animations (iirc)
00:55:31 <heycam> ED: i would prefer that transitions becomes as simple as possible
00:56:26 <heycam> ... i'm a bit worried about the animation of svg properties, and if the animation here will be different from the interpolation we use here and in smil
00:56:31 <heycam> ... it's not that well defined what happens
00:57:27 <heycam> ... you could say that it's overly complex to have cubic-bezier(), because it does specify a bunch of canned timing functions already
00:57:35 <heycam> ... are those canned ones the ones that cover most use cases?
00:57:58 <heycam> ... i suspect most people will use the canned ones
00:58:52 <heycam> CM: how is the effect applied?  override style sheet?  or somewhere in the computation of computed value?
00:59:15 <heycam> JW: i think it's basically the override style sheet
00:59:40 <heycam> ... there is a property you can specify on elements to disable animation
00:59:47 <heycam> ... that's in css animations
01:02:03 <heycam> ... not clear on that
01:02:47 <heycam> CM: animations doesn't really build on top of transitions
01:02:55 <heycam> DS: it builds on the idea, but not the syntax or behaviour
01:04:46 <heycam> ED: does it define "<time>" as the value of transition-delay?
01:04:51 <heycam> ... it doesn't link to where that grammar is defined
01:05:01 <heycam> ... in CSS 2.1, there was one for aural style sheets
01:05:10 <heycam> ... which allows you to specify a time with either "s" or "ms" suffixes
01:05:20 <heycam> ... so it would be a bit different from the clock values used in SVG/SMIL
01:05:28 <heycam> ... not sure if that's the correct definition intended, though
01:05:33 <heycam> ... it should be linked to the correct place
01:05:50 <heycam> ... the same applies for all the ones that can specify multiple values
01:06:03 <heycam> ... what happens if the number of animated transition properties is not the same as the number of transition-delays, etc.
01:06:26 <heycam> ... also not sure why it says why it says it applies to block-level and inline-level elements.  so it doesn't work on svg elements?
01:06:49 <heycam> ... why not just say any elements?
01:08:53 <heycam> ... if you have 20 properties that you want to animate, you'd need to put them one after another in the properties
01:09:01 <heycam> ... and have a long string of numbers in transition-duration, e.g.
01:09:08 <heycam> ... it does make it more compact, but it's also hard to read
01:09:44 <heycam> CM: also you really want to add new transitions rather than replace those properties, if you have multiple style rules that match an element and which specify transitions
01:10:35 <heycam> CM: so how does this work in combination with SVG animations?
01:10:41 <heycam> ED: in svg you have an override style sheet for the animated properties
01:10:44 <heycam> ED: which would win?
01:11:03 <heycam> CM: they should define exactly how transitions are applied
01:11:27 <heycam> ED: if transitions start before svg animations start, you might get a different underlying value for svg animations
01:11:59 <heycam> JW: they say you take a snapshot of the underlying values
01:12:54 <heycam> ... they don't define what happens if you've got the delay, when that snapshot happens
01:13:06 <heycam> ... after or before the delay?
01:13:52 <heycam> CM: CSS Transitions doesn't mention anything about snapshots
01:13:57 <heycam> DS: it should say what happens with script changing values
01:14:49 <heycam> DS: though it says that animations builds on transitions, it doesn't say what happens when they conflict
01:15:37 <heycam> DS: i've thought it would be useful to say that the property being animated in smil affects the dom
01:15:44 <heycam> ED: you could use getPresentationBlah()
01:17:18 <heycam> DS: sometimes you might want to change the actual Attr node values
01:21:09 <heycam> CM: how are transitions triggered?
01:22:40 <heycam> ... it's not clearly defined
01:23:46 <heycam> JW: we should split up our comments into things that concern them (e.g. underdefined things) and things which concern us, because of integration with svg animations
01:24:12 <heycam> ... the integration with svg comments should come early
01:24:27 <heycam> ED: they have TransitionEvents
01:24:49 <heycam> ... in SVG we have TimeEvents, from SMIL
01:24:56 <heycam> ... why not use those instead of introducing new ones?
01:25:25 <heycam> CM: they have propertyName and elapsedTime properties on TransitionEvent object
01:25:33 <heycam> s/object/interface/
01:26:02 <heycam> ED: on TimeEvent we only use detail, which is the repeat count
01:26:31 <heycam> CM: these get dispatched to the target of the transition/animation, and ours are dispatched to the animation element
01:26:59 <heycam> ED: when are the transition events raised?  if you had one that was very short, so it does begin, and the duration is very short, so you never paint the end value
01:27:09 <heycam> ED: is it possible to not have the end event in some situations like that?
01:27:43 <heycam> CM: there's no begin
01:27:47 <heycam> ED: ok that doesn't matter then
01:28:23 <heycam> ED: still you might have a transition that lasts very short, would you still get the event
01:29:01 <heycam> CM: they have "Context Info: propertyName ", shouldn't that include elapsedTime too?
01:30:03 <heycam> CM: what's the purpose of having a transition on properties like 'visibility'?
01:30:10 <heycam> JW: you get the delay
01:30:15 <heycam> CM: but apart from that it seems useless
01:30:28 <heycam> CM: it doesn't define how interpolation of gradients work
01:31:13 <heycam> CM: I don't think you can interpolate gradients from transitions in SVG
01:31:34 <heycam> CM: since the values are url()
01:32:33 <heycam> CM: i *guess* you could generate data URLs containing <linearGradient> with appropriate <stop> values inside?  but that doesn't sounds like what they mean
01:34:58 <heycam> CM: why is interpolation of scaleZ defined in the css 2d animations spec?
01:35:55 <heycam> CM: they can interpolate matrix transforms by decomposing them first and then interpolating the decomposed transform items
01:36:02 <heycam> CM: but we don't have animateTransform type="matrix"
01:36:14 <heycam> http://dev.w3.org/csswg/css3-2d-transforms/#animation
02:51:12 <heycam> JW: for the animation of colour, it says to take each rgb component and animate them individually
02:51:35 <heycam> ... but that's not always useful
02:51:39 <heycam> CM: svg has color-interpolation to control this
02:52:05 <heycam> JW: if you're going to break things up into components, and someone specifies an hsl() colour it shouldn't be interpolated in rgb space
02:52:26 <heycam> ED: also you might have percentages in one and integers in another
02:54:22 <heycam> Topic: CSS Animations
02:54:56 <ed__> http://dev.w3.org/csswg/css3-animations
03:14:10 <ed___> ed___ has joined #svg
03:14:58 <ed__> ed__ has joined #svg
03:16:07 <ed___> ed___ has joined #svg
03:17:49 <ed__> ed__ has joined #svg
03:18:27 <ed__> ed__ has joined #svg
03:18:34 <ed__> ed__ has joined #svg
03:19:14 <ed__> ed__ has joined #svg
03:20:18 <jwatt> scribenick: jwatt
03:20:19 <ed___> ed___ has joined #svg
03:21:23 <ed__> ed__ has joined #svg
03:22:02 <ed___> ed___ has joined #svg
03:22:16 <jwatt> CM: it says "In the case of multiple animations specifying behavior for the same property, the animation defined last will override the previously defined animations."
03:24:05 <ed__> ed__ has joined #svg
03:26:03 <jwatt> ... that's different from SMIL Animation which says that the most recently begun animation takes priority
03:26:33 <jwatt> CM: [tests]
03:26:48 <ed__> JW: what if all of them are begun at the same time?
03:26:54 <ed__> CM: then it's document order IIRC
03:29:17 <jwatt> JW: isn't this referring to the order of the names specified in the ‘animation-name’ property?
03:29:33 <heycam> http://mcc.id.au/temp/2009/animorder.svg
03:30:20 <jwatt> CM: that's probably what it means, that makes more sense
03:30:35 <jwatt> JW: or hopefully that's what it means
03:31:04 <jwatt> JW: the order of keyframe at rules shouldn't matter I think
03:31:30 <jwatt> CM: it does say the animation "defined last" which sounds more like the at rule declaration order though
03:33:52 <jwatt> JW: so what would the CSS spec have to say to be more compatible?
03:34:12 <jwatt> CM: the animation that most recently began applying would be the one that started last
03:34:28 <jwatt> CM: the document order doesn't really matter I guess
03:36:18 <jwatt> CM: they talk about the "intrinsic style"
03:36:31 <jwatt> ED: they need to define the term
03:37:49 <jwatt> CM: it's not clear whether the 'animation-timing' properties are used in the @rule or outside
03:38:56 <ed__> ED: same as for css-transitions the "applies to: block and inlinelevel elements" should probably be just elements, unless there's a good reason for disallowing svg elements to have animations on its properties
03:40:20 <jwatt> JW: I think the ‘animation-name’ property is the only one that doesn't go in an @rule
03:41:10 <jwatt> CM: the animation shorthand property allows you to combine ‘animation-name’ and others though
03:42:09 <ed__> [[Properties that are unable to be animated are ignored in these rules, with the exception of animation-timing-function', the behavior of which is described below.]]
03:42:48 <jwatt> ED: it doesn't say who decides whether something cannot be animated...spec? implementation? ...?
03:43:12 <jwatt> s/spec/spec? which
03:43:16 <jwatt> s/spec/spec? which/
03:43:36 <jwatt> ED: the grammar for the keyframes doesn't define whitespace 
03:44:04 <jwatt> DS: they're generally pretty good with their syntax, but yes, that needs defined
03:44:14 <jwatt> CM: another thing about grammar
03:44:44 <jwatt> ... the grammar says ident, but the examples use strings with quotes around them
03:45:25 <jwatt> ...not sure why it restricts to visual media - might have oral properties where it would be useful
03:45:42 <ed__> s/oral/aural/
03:46:14 <jwatt> ...the events are defined to be cancellable, but it doesn't say what it means to cancel them
03:46:41 <jwatt> ...the definitions of the constants - someone has claimed 7 already?
03:47:27 <heycam> const unsigned short COLOR_PROFILE_RULE = 7
03:47:29 <jwatt> ...yes, SVG does
03:47:40 <heycam> that's on SVGCSSRule in SVG (so technically not on CSSRule)
03:48:45 <jwatt> CM: that's been there since 1.0 (since 2001)
03:49:33 <jwatt> ... but I bet the SVG WG at the time may well have not have told the CSS group
03:55:04 <jwatt> CM: so to potential SMIL Animation - CSS Animation integration problems
03:56:17 <jwatt> ...if CSS animations are meant to be done using the override stylesheets, then since that's how it works in SVG, how will the final value be resolved?
03:57:47 <jwatt> ... I think that's the main one
03:58:40 <jwatt> JW: should we adopt the  ‘animation-timing-function’ property keywords
03:58:56 <jwatt> DS: sounds like a good idea
03:59:07 <jwatt> CM: keysplines="ease"
03:59:13 <jwatt> JW: yeah
04:00:48 <jwatt> DS: we should put together our individual reviews and send them in
04:01:13 <jwatt> ...we want to coordinate with them so that we have compatible syntax
04:01:53 <jwatt> ED: it would be good to see their use cases and requirements document
04:03:17 <jwatt> ...I'd be curious to see a list of use cases that it meets that isn't met by SMIL Animation
04:03:34 <ed__> s/Animation/Timesheets/
04:10:16 <heycam> heycam has joined #svg
04:12:55 <heycam> Topic: Filters
04:12:59 <heycam> Scribe: Cameron
04:13:01 <heycam> ScribeNick: heycam
04:13:27 <heycam> ED: ISSUE-2181
04:13:32 <heycam> ISSUE-2181?
04:13:32 <trackbot> ISSUE-2181 -- Look at Solutions for 'filter' Property Conflict with IE Filters -- OPEN
04:13:32 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2181
04:14:05 <heycam> JW: so in old versions of IE they'll get unhappy?
04:14:25 <heycam> ED: the problem is that some scripts do if (elt.style.filter) to sniff for IE
04:15:26 <heycam> CM: some browsers make the svgElement.style.filter value "falseish"
04:15:31 <heycam> ED: opera doesn't
04:15:42 <ed__> (yet anyway)
04:16:33 <heycam> ED: it seems that maciej was favouring changing the name of the accessor
04:16:49 <heycam> ED: so e.g. svgElement.style.svgFilter
04:17:13 <heycam> JW: i don't think the spec should acknowledge the problem, just ignore it
04:17:38 <heycam> JW: you could put an informative note
04:18:36 <heycam> ED: there's no css spec that say the CSS properties that SVG adds are on CSSStyleDeclaration (or whatever the relevant interface)
04:18:48 <heycam> s/CSSStyleDeclaration/CSS2Properties/
04:19:53 <ed__> http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSS2Properties
04:20:22 <heycam> http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSS2Properties
04:21:00 <heycam> dashed property names map to camel case attribute names there
04:23:54 <ed__> JW: i think browsers can handle this case, and be smart about detecting it "looking for IE"
04:24:10 <ed__> ...no need for dirty hack like changing the name to e.g svgFilter
04:24:27 <ed__> ...but i'm fine with adding an informative note in the cssom spec about this
04:24:30 <heycam> ACTION: Erik to talk to Anne about handling SVG properties in CSS OM, and adding the informative note about 'filter'
04:24:31 <trackbot> Created ACTION-2476 - Talk to Anne about handling SVG properties in CSS OM, and adding the informative note about 'filter' [on Erik Dahlström - due 2009-02-26].
04:24:52 <heycam> ISSUE-2071?
04:24:52 <trackbot> ISSUE-2071 -- potential security hole involving pointer-events, filters, foreignObject, cross-origin IFRAMEs, and elementFromPoint -- OPEN
04:24:52 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2071
04:43:14 <heycam> CM: I think we need to think about pointer-events with non-shapes and non-<image> elements and define that better
04:53:33 <heycam> https://developer.mozilla.org/en/DOM/document.elementFromPoint
05:16:01 <ed__> ACTION: DS to Propose a solution for ISSUE-2071, referring to external resources and how that affects security ("tainting" an svg) and how that might apply to methods like elementFromPoint
05:16:01 <trackbot> Created ACTION-2477 - Propose a solution for ISSUE-2071, referring to external resources and how that affects security (\"tainting\" an svg) and how that might apply to methods like elementFromPoint [on Doug Schepers - due 2009-02-26].
05:24:42 <heycam> [various unminuted discussion]
05:26:42 <heycam> ED: naming convention for module test cases
05:26:47 <heycam> ED: i don't know what to call them
05:27:43 <heycam> CM: don't want to conflict with SVG 1.1 test case names
05:28:34 <heycam> AG: I think just put "-m" suffix on each test
05:28:39 <heycam> AG: ("m" for module)
05:32:00 <heycam> DS: i say "filters-<conformancestatementid>-<fourdigitnumber>.svg"
05:35:23 <heycam> JW: can we use something other than CVS for the tests?
05:59:56 <heycam> heycam has joined #svg
06:02:24 <heycam> Topic: Layout
06:02:58 <heycam> http://dev.w3.org/SVG/modules/layout/publish/SVGLayoutReqs.html
06:05:53 <heycam> heycam has joined #svg
06:09:42 <ed__> ED: I'd like some generic way of saying "50%+10px" or similar, for attributes that currently take e.g length values 
06:10:30 <ed__> ... and also some way of defining what those percentages are relative to
06:11:58 <ed__> ... it would then be possible to remove the filterMarginUnits and mx,my etc attributes in the filters module 
06:16:30 <ed__> DS: [talks about params-proposal]
06:17:06 <ed__> CM: arbitrary arithmetic in attributes?
06:17:35 <ed__> DS: maybe verbose, but may let people solve problems
06:17:44 <ed__> CM: would like to see canned ones
06:18:02 <ed__> DS: it would be useful i think
06:19:58 <ed__> CM: would you only like addition or other operations also?
06:20:07 <ed__> ED: might be others that could be useful as well
06:21:04 <ed__> DS: [lays out a tree structure using menthos wrappers]
06:21:48 <ed__> ...[talks about positional relationships and semantics]
06:23:48 <ed__> CM: paddings and margins are things we should support yes
06:24:40 <ed__> DS: would like for the a way of expressing semantics for the content
06:25:11 <ed__> CM: right, but inferring it from the expressions/layout might not be the right way, perhaps aria though
06:25:54 <ed__> ...i don't think it'd be a requirement that an expressionbased layout would infer semantics
06:28:24 <ed__> CM: ok, first one: <length> + <length>
06:28:41 <ed__> JW: right, so 20em + 1px (or minus)
06:29:04 <ed__> CM: next is arbitrary arithmetic expressions of lengths
06:29:18 <ed__> ...is that useful?
06:29:36 <ed__> ...you could do multiplications with additions
06:30:06 <ed__> JW: would like to see use-cases for that
06:30:36 <ed__> ED: we might consider having functions, sin, cos etc...
06:31:41 <ed__> CM: next category, being able to specify to refer to the lenght of a different element
06:31:54 <ed__> s/specify to//
06:32:58 <ed__> s/next category/next level/
06:33:36 <ed__> JW: i don't think that's a level continuing from the others, but a new category
06:34:03 <ed__> CM: cycles are a problem in such a model
06:34:59 <ed__> JW: tracking values is a larger engineering problem
06:35:25 <ed__> CM: well, svg already has alot of things that needs to be tracked, for updates etc
06:36:31 <ed__> DS: if this layout scheme became popular then it might get used outside of svg
06:36:51 <ed__> JW: say I change a length that depends on a lenght, that depends on a length
06:36:55 <ed__> ...not trivial
06:37:04 <ed__> CM: not terribly complex
06:37:11 <heycam> heycam has joined #svg
06:38:05 <ed__> JW: you'd need to keep a table of dependencies, concerned that it might not be efficient
06:39:24 <ed__> CM: having one-way assignment of lengths depending on other lengths is good for simple cases, but not for more complex ones
06:39:46 <ed__> DS: right, for things like the available screenspace for example
06:39:58 <ed__> CM: [draws on whiteboard]
06:40:52 <ed__> ...doing gridbag layout isn't very convinient with this style of writing the constraints
06:41:31 <heycam> heycam has joined #svg
06:44:40 <ed__> ...we'd like probably to have some form of containers for constraining the layout
06:46:13 <ed__> JW: so why couldn't CSS do this?
06:46:27 <ed__> ED: because it's only concerned with the box model?
06:46:40 <ed__> JW: right, perhaps it should look outside that
06:47:45 <ed__> ...if we define our tags then do we expect people to use those to do layout? (outside of svg)
06:48:27 <ed__> DS: doesn't always apply, some things can't be done that way... different layout, let's not jump to conclusions yet
06:48:49 <ed__> JW: i'd not like to see every spec define its own custom markup for layout
06:49:05 <ed__> ...but let's work out the requirements first
06:50:31 <ed__> DS: [draws a springs and struts layout system]
06:51:26 <ed__> ...it's a simple model
06:52:36 <ed__> CM: if a spring spans across a parent-child boundary then it becomes difficult to solve
06:54:23 <ed__> AG: in that particular model, find me the optimal layout of this
06:54:29 <ed__> ...and you want to fit that to some region
06:54:46 <ed__> CM: that's probably a step up, that's harder to solve
07:11:15 <Zakim> ChrisL, you asked to be reminded at this time to go home
07:13:41 <ed__> ...[long discussion on collision detection and layout]
07:14:36 <shepazu> [discussion about springs-and-struts and other models]
07:15:44 <shepazu> I propose an "intersection" event
07:18:12 <heycam> heycam has joined #svg
07:21:07 <shepazu> ... which would give the objects that intersected, and their vectors
07:22:11 <jwatt> JW: I think in the general case getting precise vectors would be hard
07:22:52 <jwatt> ... not sure how easily an acceptable approximation could be obtained
07:22:59 <jwatt> ... in the general case
07:23:46 <jwatt> ... and you want to be able to get the outline of the group to get the boundary
07:24:12 <jwatt> ... the union of all descendants 
07:25:45 <jwatt> ... which if you're doing collision detection over a large number of objects with many descendant graphic elements - every animation sample - you'd think it would hurt
07:37:49 <ed__> CM: so we're agreed that R3 Support fallback to non-layout capable user agents should be reworded to add "where worthwhile"
07:39:36 <ed__> ...R4
07:39:55 <ed__> ...so people often find fonts are different in different viewers, and you want to adapt to it
07:40:14 <ed__> JW: should mention language there
07:41:03 <ed__> CM: next R5
07:43:43 <Zakim> Zakim has left #svg
07:51:28 <ed__> JW: might want some examples with R6 for the color depth and its effects on layout
07:54:07 <ed__> CM: might make R7 a bit more generic, to cover more cases
08:00:43 <ed__> JW: on a barchart scaling the bars buit not the gaps would require layout of some sort
08:02:52 <heycam> heycam has joined #svg
10:09:57 <ed__> ed__ has joined #svg
10:53:32 <heycam> heycam has joined #svg
10:53:39 <heycam> RRSAgent, make minutes
10:53:40 <RRSAgent> I have made the request to generate http://www.w3.org/2009/02/18-svg-minutes.html heycam
10:56:10 <shepazu> shepazu has joined #svg
10:57:51 <heycam> can't believe how much email backlog i'm building up over these few days
11:19:04 <heycam> heycam has joined #svg
11:23:23 <heycam> hey anthony, you don't Lost too do you?
11:23:29 <heycam> if you do could you bring it tomorrow as well?
12:27:18 <jwatt> jwatt has joined #svg
12:27:33 <jwatt> ugh
12:27:37 <jwatt> http://benzilla.galbraiths.org/2009/02/18/bespin-and-canvas-part-2/