See also: IRC log
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
cyril: my colleague has been
working on this superpath prototype
... the idea is that in many graphics, you need to share paths or pieces of paths among bigger paths
... for example you need to share them if you have regions in a map, share them sometimes in direct order, sometimes in reverse order
... so the idea is to reuse a piece of a path in another path
... benefits in reducing file size, but also more semantically correct content. not duplicating information when not needed.
... viewers could do better antialiasing on that path, it's only present once
... it could be rendered seamless
... last time we talked about it, I exposed the fact that we wanted to have a path with an ID attribute, then another path referencing that initial path
... after some investigation we realised that it's very hard to extract a piece of a path and make it a separate path alone
... because what command would you put at the front
... the geometry of the path often depends on the point before or the point after
... so we changed our idea here ab it
... nikos suggested instead of having the reusable path a separate path, define it while using it in the first place
... so you have the full context
... you have the previous point if you want to reuse it in reverse order, or the next point if you are reusing in direct order
Tav: that's clear, but not sure if it's necessary
cyril: you can see some examples
on this page
... don't pay much attention to the syntax yet
... my colleague is happy to change the syntax, it's just a prototype
<cyril> d="M 90,190 220,90 330,150 (p1|L330,150 280,230 L330,310 280,400)L120,375 z"
cyril: this is an example of
syntax; the path you will be reusing is between parens
... the ID is the thing after the open paren, and it ends with the bar
... when you want to reuse it
<cyril> d="M 500,385 390,460 280,400!p1|L450,50 565,81 z"
cyril: that's a reverse use
... and I think the prototype uses # for forward use
cyril: there's a more complex example with a map
cyril: this is a region of france
with three subregions
... the blue path for the sea
... as I said, the syntax is probably not the best
... but the big change is the path is defined inline
... when it's first used
... to have the full context
... what is preserved is the geometry
... what he does is any path used is converted to a path that has relative commands, so it's easier to reverse
... then the reversed relative commands are applied
... the next step for us is to fix the syntax, then have it run on many examples
... JC is writing a program to analyse existing content and replace duplicated paths with this
... when the content has been authored and the paths don't exactly match, e.g. with slightly different floating point values
Tav: in inkscape you can output
in relative or absolute
... I want to talk about auto closing a path
... with a rounded segment
... so you'd leave out the first point, then put the first point in the path
nikos: it wasn't to do with smooth curve final segments was it?
Tav: it helps with positioning the marker
heycam: so that's a mid marker
Tav: and makes the orientation expected
cyril: what does the group think of defining the reusable path name in the path data?
krit: how do we handle compatibility?
cyril: for the path that defines
the reusable path, it you could skip the ID then it could
... the path that reuses it you couldn't really do anything
Tav: now you define a country, as one path, and a region in that would be the path that you share?
cyril: the country would be a
single path element, but the d attribute would be divided into
many subpaths, each having an ID for example
... then you define a region with an external border with the country, when you define the path data for that region you reuse the subpath defines in the country border
Tav: I find that conceptually more complicated than defining each subpath separately
nikos: you could define all the
subpaths in defs
... and then you only need to reference it because you want to fill it
cyril: if you don't care that the path segment between the previous point and the first point of the reused path, then doing what you suggest is good
ed: can you get a continuous curve with reused subpaths?
ed: it's a similar problem to the
... also wondering with this proposed syntax, is it possible to have nested reusable subpaths?
cyril: I haven't tested that, I
guess the prototype doesn't accept that
... but in theory it could work
... one of the difficult things in the current impl is that the path is converted to relative, and if the path you are defining is at the end of a big path, and the big path uses another path, you need to resolve that one first
... there's a possibiltiy you need to process the whole file before doing anything
... there's also the possibility of doing loops
Tav: don't we have some rules for dealing with that already
ed: yes for ID cycles
cyril: so that would need to be specified
heycam: bit uneasy about defining
the names in the path data
... seems odd
birtles: if I add the get-path-data-as-floats API, how would this work?
cyril: it would return the
... animation is also an open issue
... I don't know how it can be implemented in browsers
... polyfilling is easy
heycam: we wouldn't do the seamless rendering first, that would need lots of graphics library rewriting
cyril: I don't think I need a
resolution or an action, but if anyone is willing to
... e.g. prototype in inkscape
Tav: I'd like to but have enough other prototypes to work on for now
<scribe> ACTION: jean-claude to further develop the protoype including with animation support [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action01]
<trackbot> Created ACTION-3734 - Further develop the protoype including with animation support [on Jean-Claude Moissinac - due 2015-02-19].
jet: I wanted to talk to the
group about some implementation experience that I've had
... recently and in the past
... at Mozilla we recently implemented a flash player in JS
... and just deployed it in nightly Firefox builds
... previously I worked at Adobe on the flash player
... before that at Macromedia on the flash authoring tool
... at Macromedia, Adobe was building their LiveMotion authoring tool
... I wanted to share with the group some of why flash got the ubiquity it did and Adobe's SVG didn't
... it wasn't so much that the technology was better, but that we did things at Macromedia so that it would defeat SVG at the time
... I think there's an opportunity to get past that after all this years
... and move interactive animations on the web in a way that SVG could not at the time
... the things that made it get over that hump at the time, weren't the things you'd expect
... Adobe's authoring tool was good, had a reputation for quality software, plugin worked in many places
... but when we would evanglize Flash over SVG, we'd demo with the worst browsers with SVG, and the best browser with Flash
... one company in particular the Flash developers went to at the time was Disney
... experts in animation, decided to use Flash on the front page of their site
... at the time, if you wanted to use animation you'd use GIF89, and there wasn't really anything else
... this is the era of 9600 baud modems and 386 computers
... today, the hardware is better, but similar network issues
... the things that made Flash successful was bug compatibility across browsers, and performance characteristics that were consistent across browsers
... for example Flash had retained mode API, binary file format
... small, fast, compiled
... after a while, the workflow would be that you'd take the authoring file format, .fla (which is a zip with xml resources, not quite svg)
... what I'm getting at is that SVG is an excellent authoring format, but a poor runtime format
... not because of XML vs binary is better or worse, but that we're unable to offer the consistent runtime/rendering experience because of what the format offers
... an example: coons patches, flash doesn't support that; nor gradient meshes
... but you can build a gradient mesh in the authoring tool and it spits out a bitmap under the covers
... there are things like that which make SVG very expressive, but which on a phone rendering a coons patch for your logo is less practical
... so what I'd like to get from the SVG group to see if there's an appetite to fix that
... is there a way for the implementors here to think about using SVG in a way that we can start with a subset that is normative for a runtime implementation
... not enough that we'd say you have to implement a coons patch for SVG, but that you could render a subset of SVG and have bug compatibility if possible
krit: it sounds a bit like the Basic SVG Profile
jet: SVG is one facet of it
... vector art and animation, and interactivity
... the part that made Flash also be ubiquitous is that its OM was very contained and strict
... you wouldn't expect that the HTML hosting your Flash file could mess with the Flash OM
... so maybe a basic profile of SVG?
... today, we implemented flash in /canvas
... something similar to the React Canvas
... implementing flash in JS/canvas
... SVG is so rich and powerful that I think it's better suited as an authoring format than a runtime one
... if we could design a subset that is a subset that has clear DOM semantics
... that the runtime can then make decisions about rasterising etc.
... that's the spiel, don't have concrete ideas
heycam: are you coming from the perspective of trying to implement Flash in SVG, and the performance wasn't there?
jet: not all performance, but
also different rendering model
... we also have an ad use case
... flash can bundle things up in a package neatly
ChrisL: sounds like you're asking
for a package format
... which travels in one unit
... or can play without being unpacked
jet: yes, that's one way. maybe
it is a zip container.
... there are things that made flash as a tagged binary file format, in the order of use
... you know before you use an element that you would've pushed it through the network
... the packaged file fromat like jar files, you have to get the whole blob before you can start
cyril: the work I presented
yesterday uses mp4 container rather than zip
... which can be used for streaming
... to come back to the earlier statement, I agree that design of Flash was very different
... authoring format, and publication format
... SVG is completely different in that the authoring format is the publication format
... so the tradeoffs are different
... performance and compact model is not the same
... that's a benefit but also a problem for optimisation
... looking at converting cartoons to SVG, there are thousands of ways of doing it
... so it's hard to optimise
... there are so many ways to do the same thing
jet: for an authoring format,
... flash was an authoring tool before it was a runtime format
... the compile-to-runtime was an artifact of having to send things over slow networks
... the answer I get to asking people why they're still writing flash, games/ads/etc., is both (a) these issues and (b) tooling
... so this is a problem we could solve, if we agree that we can start with a subset today that is available across all implementations
Rossen: I heard you mention a few
times offering a subset
... and also guaranteeing interop
... I think we can all agree on how to spec a subset
... I don't know about guaranteeing interop
... it's what we all try to do
... but how do you guarantee it?
jet: I think that opens us up to the same disadvantages
Rossen: here's one way to
... if this is something that we expose a number of APIs to the web platform, that you can implement SVG as one library, and that library is circulated and used
... that's the only way I can see that it's interoperable always
... going back for a second, you're mentioning a subset
... do you have an idea?
jet: I say subset just so it
would be surmountable problem
... if we say basic shapes are required and then pixel perfect requirements
... because that's a simple problem
ChrisL: last meeting we tried to
decide "is a geometry coordinate at the top/left of a pixel, or
middle of a pixel"
... and we couldn't agree, because different graphics libraries are different
... one reason Flash was successul was that there was one implementation (that mattered)
... and that the implementation is basically the spec
jet: so we implemented Flash
... that it was possible is somethign taht got me thinking
... if we can render it today, why couldn't we all do the same thing? why can we not do it for a format other than swf?
... firefox is going to pre-ship with the JS flash implementation, but it's not feasible to make all cartoon authors have to ship this library
... couldn't we polyfill a format other than flash, perhaps a subset of svg?
... I'd like to build on things already in the web platform
cyril: there is history to that. SVG Tiny 1.2 was that; an attempt to make a subset of SVG that was more efficient for mobile devices
krit: we could do that right now with specifications that exist. you could use web components to make your own vector format, if you have the right primitives
cyril: I doubt you'd have good performance there though
Rossen: I'm still thinking you're
talking about two different things here
... one is packaging, plus maybe additional step of standardising extension API where a platform piece can be delivered or hosted on CDNs and have lifetimes/updates and implementations will download them periodically
... so that they become part of the native packaged platform
... the other reason I have Flash installed on my machine is that I like to watch video
krit: content protection
jet: we're solving the video
problems another way, I think we'll get there
... the use cases are the ones I'd like to cover are ads, 2D games
... the people who makes those games/ads in Flash, is that SVG implementations are fragile
... can we make it so that it's less fragile across implementaitons, by saying that there's a subset that has to be normative across the board
Rossen: I think everything that
we publish is normative
... in order to get interop you either have to converge on a single implementation, or just pray
cyril: if you subset SVG, in some
sense you don't have 10 ways to do the same thing
... you can optimise that
cyril: how do you frame based animation in SVG?
Rossen: what is it today?
cyril: you can use display,
... Brian just exposed yesterday all the challenges if you want to optimise your animation
... there are several ways, will-change, transfromZ
Rossen: let's go back to
... from the SVG spec, tell me what is exposed is ambiguous and can be implemented in many ways
... if we're saying we're going to converge on one single technology that covers the entire web platform, I don't think this is the right forum
... I'd still like to figure out the problem for SVG
ChrisL: I'd like to see detail on what they find is fragile
roc: do people demand exact
rasterisation consistency on all targets? or are they more
concerned about performance consistency?
... or other things?
jet: it was consistency across targets
roc: rasterisation consistency?
jet: that, performance, ...
... we built a Flash renderer in JS, could this be a SVG renderer
Rossen: what does versioning look
like in this case?
... I think we are falling down to some basic software engineering problems where the answer is either scaling down to one implementation, or you pray
... there's always a first to market, and others following
... are you going to hold everything back so that nobody jumps the gun and releases a feature?
... I think we build new features so that you have graceful progression
... and that comes back to the single implementation
roc: are you implicitly saying that you find that canvas has sufficient rastiersation consistency to satisfy these people, and that builindg something on canvas would help these people?
cyril: I can't speak for Google, talking to the people who work on swiffy, they said exactly that. they started with SVG, and moved to canvas
roc: they're finding canvas more
... you could have authoring tools produce canvas and JS
... and compile down to that level
... if you do that I think everyone gets what they want
jet: there's something amiss there, then you have to implement the playback engine
roc: you can customise that
engine right down to exactly what the ad needs
... you won't need most of the features that Shumway has
... I don't know how small we can make that, but I think for a lot of ads we can make it pretty small
jet: is that something we could standardise?
roc: we wouldn't need to, which
is why it'd be a great solution
... in standards, we could look at making canvas rendering consistent
... as canvas is more focused than svg is
cyril: what's the scalability of canvas?
ChrisL: well it's immediate mode
roc: that's a problem that
canvas-using apps already have
... there's a couple of pieces to solving that
... we have consensus on solving that; there's an event that first when canvas needs to be re-rendered
... and an application listens for that event and rerender
... and we need a way for the app to size the backing store to device pixels
... which is a renderedWidth/Height property on the canvas
jet: then maybe all we have missing is the packaging side
roc: you might be able to design
your ad such that --- well you have image assets etc.
... there have been several proposals for zip-like but streamable bundles
... (you can make zip streamable if you format it correctly iirc)
... I'm not sure why they didn't go anyway
... maybe the use cases weren't compelling enough?
... some people were trying to do it as a performance thing in a single HTTP transaction
... but then SPDY came along
... so for speeding up website loading that solved it
... but for this problem of content traversing multiple networks was not really thought of as a use case
... technically it's not a mysterious problem
cyril: you should look at the SVG streaming spec; it's still a draft, but it might help you
heycam: marcos will know about packaging
roc: if we could re-use this new app packaging format that might be a solution
cyril: my recollection is that it wasn't streamable
jet ^ (packaging)
Tav: people were asking for a
different type of miter
... instead of clipping at a certain point, when you reach the limit, you get a uniform clipping
ChrisL: the existing one is discontinuous
krit: in canvas, what do we do
... do we do the second one?
Tav: the guy from nvidia (not
neil) said that half graphics engines do it one way, half do
... the lower one is existing behaviour in some engines?
roc: we just use the underlying
... so I'm sure it would be different on different platforms
krit: I think different platforms do align
Tav the proposal is to have a fourth (well, we have 'arcs')
Tav so if you're already doing something to implement arcs (i.e. not solely relying on existing libraries), then implementing this proposal is trivial
ChrisL: a new value would be good
Tav: I've played with the cairo
line join code
... and doing this is trivial
krit: does it work cross platform? cairo uses CoreGraphics on OS X.
roc: so the image rasteriser, not the other backends
<roc> cyril: in what way is http://w3ctag.github.io/packaging-on-the-web/#streamable-package-format not streamable?
<roc> shepazu: can you hear us?
ed: the proposal is?
krit: a new value that has this behaviour
Rossen: are you proposing an interpolation function that goes between these things?
<cyril> roc: it depends on the definition of streamable. My definition includes timing/synchronization. This packaging format is progressively processable, not streamable. Not seekable for instance.
Tav: no just clip the miter rather than fall back to the other point
<roc> cyril: OK. When Jet was talking about the Flash format being streamable, for the purposes of ad delivery, I think he meant "progressively processable"
<cyril> roc: there are use cases for adaptive streaming of ads as well
ChrisL: so you're using a line
cap which never triggers miter-limit
... the numerical value for miter-limit wouldn't affect it?
Tav: it would
ChrisL: you're looking for a line-join keyword?
<cyril> roc: mp4 being ubiquitous in all browser, I think it's a candidate that shouldn't be dropped without investigation
<roc> cyril: maybe, but I think you can't have adaptive streaming and a single inviolable package.
<cyril> cyril: still controlled/timed delivery of big packages is interesting too
<cyril> roc: still controlled/timed delivery of big packages is interesting too
RESOLUTION: We will add line-join:miter-clip in SVG 2.
<scribe> ACTION: Tav to add line-join:miter-clip to SVG 2. [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action02]
<trackbot> Created ACTION-3735 - Add line-join:miter-clip to svg 2. [on Tavmjong Bah - due 2015-02-19].
-- 15 min break --
Tav: there are problems when you
have a curved segment at the begin/end of a path
... in that in order to close the path you have to have a 0-length z
... that causes problems with how markers are rendered
... there are inconsistencies with how browsers handle them
... if you paste that link in 2 different browsers, compare the rendering, you'll see that they're inconsistent
... due to rounding errors, if you use relative path segments by the time you get to the end your last point may not match up with the first point
... would be nice to have a way that specifies they should match up
... some possible solutions on how to do that
... one possibility is new commands
... the Z command is essentially an L command, where the point is the first point
... so you could extend that, but I don't think it's good to extend Z_a or whatever
... you could use a non-numerical parameter
... which means "use the first point"
... you could use a Z to indicate that you should replace a missing point with the first point in the path
... so either the second or third solution would be a way of doing it
heycam: would you accept this special symbol anywhere in the path?
Tav: maybe but it wouldn't be as useful
heycam: makes me wonder if you would want to go back to any point, not just the first point
Tav: it reminds me of a different problem, if 2 points are on top of each other, say a handle is on top of the start, how is direction determined for markers?
heycam: I think we covered the marker direction issue a couple of weeks ago
cyril: the whole problem comes from rounding errors, right?
nikos: even ignoring precision
issues, having a Z command that closes a bezier is useful
... you could expand the meaning of Z to mean "close a path and create a segment if it needs to"
heycam: that's the third option
nikos: what if in an arc command you omitted the flag values and put a z there
heycam: I think just make that invalid
RESOLUTION: We will allow a Z to fill in any final coordinate pairs missing from the previous command.
<scribe> ACTION: Tav to add the new Z behaviour. [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action03]
<trackbot> Created ACTION-3736 - Add the new z behaviour. [on Tavmjong Bah - due 2015-02-20].
Tav: inkscape originally drew
ellipses/circles with paths
... some people noticed they could no longer put text along a circle
... because it's a common thing to do, it was proposed that we allow text on shapes
... in inkscape this is easy to do, because at the time we disply we've already converted the shape to a path
... the major issues have already been solved, such as the start point on a circle, because we had to define that using markers
heycam: and dashing
Tav: there are a couple of
... if you put text on a circle it might make sense to use a negative startOffset
... how do you put text on the other side
... we could have a flag to say which way the text goes
heycam: sounds fine
... what about the flag?
ChrisL: what would the names be? inside/outside? left/right?
ChrisL: as long as you have a good definition
... mapping people use "true left" of a river, left when moving downstream
Tav: how about negative startOffset?
heycam: negative startOffset is already allowed, but we probably don't define what happens with closed subpaths
RESOLUTION: We will allow <textPath> to reference shapes and a flag to say which side of the path the text is put.
<scribe> ACTION: Tav to update textPath for text on a shape. [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action04]
<trackbot> Created ACTION-3737 - Update textpath for text on a shape. [on Tavmjong Bah - due 2015-02-20].
Tav: this is an issue I came across
Tav: Opera Presto and Inkscape you see no red boxes
ChrisL: and red is bad right?
Tav: it means x/y/width/height are being interpreted when the spec says they shouldn't be
cyril: Firefox/Chrome behave the same
<ChrisL> IE11 is correct
Tav: Batik does it wrong, and
probably everyone assumed Batik does it right
... so I don't think following those attributes is useful
... I think the spec should be followed in this case
roc: I suspect those attributes
got cloned onto the <svg> and they're being interpreted
... so maybe we should add them for consistency with referencing <svg>?
ChrisL: is it fully defined what
it means, if we removed that rule from the spec?
... given that nested <svg>s already allow this
Rossen: I don't want to change
ChrisL: the reason I changed was that we added x/y to <svg>, and now referencing it is different from referencing <symbol>
roc: if the issue is what I think it is, I think it would be easy to fix. but consistency between <svg> and <symbol> would be good.
krit: does <symbol> have viewBox?
krit: then I'm starting to agree with roc
<shepazu> +1 to roc's proposal... we should do the same for <marker>, etc.
ed: if you have width/height on the <use> it will override the ones on the cloned tree
Rossen: and that makes sense
roc: this is not an argument for making symbol behave differently though
Tav: it's only used by a <use> element
ed: I think you'll still get the
same behaviour if you default width/height on <symbol> to
... so if we did that I'd be fine with it
krit: what happens now that x/y are properties?
Rossen: what is the main use case here that would be broken if we don't do this?
Tav: if someone has incorrectly
... some browsers have ignored it, others have not
Rossen: what would be the
expected behaviour or use that comes out from tooling?
... what would be more natual for tooling to output for this?
... when you're using <use>, I would expect tooling would probably define x/y/width/height on the <use>
heycam: so I agree that x/y on
<symbol> is not useful
... but the argument would be consistency with referencing <svg>
krit: it's an edge case, I don't think content would be relying on this behaviour
Rossen: what would be the most
natural thing from the author's point of view?
... in either case the code change would be straightfowrard
... I want to know what the effect for users would be
krit: <symbol width height>
and <use x y> without width/height, that would be useful
to avoid duplicating width/height all the time
... I think there is an argument to simplify the code
... by treating these the same
... the user could live with specifying width/height on <use>
dmitry: it looks more to be a bug
in the spec rather than the browsers
... as an author, I would expect x/y/width/height to be available on <symbol>
... it's not a big deal
ChrisL: the underlying model when
this was designed is that <use> positions a new thing,
and that referenced thing has its centre of its coord system
would pin it
... it does mean sometimes you need to display all four quadrants
... and there are some issues with clipping
... some people would rather specify the middle rather than 0,0
Tav: well we now have refX/refY on symbol, to match marker
Rossen: what would users want/say
roc: I don't think users are
necessarily going to use this
... do we change the spec to make things things more consistent
<pdr__> cyril asked me to confirm that swiffy has indeed switched to canvas
ed: send a mail to www-svg asking for feedback, wait two weeks, decide then?
Rossen: sounds reasonable
<scribe> ACTION: Tav to mail www-svg about the symbol x/y/width/height issue and report back in two weeks [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action05]
<trackbot> Created ACTION-3738 - Mail www-svg about the symbol x/y/width/height issue and report back in two weeks [on Tavmjong Bah - due 2015-02-20].
<ed> scribeNick: ed
heycam: this is the chapter for x,y,cx,cy and so on properties
<ChrisL> botie, tell cyril he was mean to zakim
<botie> ChrisL: excuse me?
heycam: issue 1: need to check the initial values for all of them
krit: r has different initial
values for gradients and circle
... propose to make it 'auto'
... to make it work out the correct value depending on element
heycam: is this done with UA styles?
TabAtkins: auto is more for when
auto is going to affect the results
... if you're just doing based on the element you should use UA styleaheets
krit: next issue, rx and ry
should use zero as initial value
... something that's not there is fx and fy
... on radial gradient
... the descirption is complicated, by default uses values from cx and cy...
... we could set them to auto and make them do the same thing
heycam: it's a strange feature
krit: it doesn't define specialcasing for fx,fy
heycam: we did decide to make fx and fy properties, right?
heycam: did we only do this because we did the other gradient attributes?
krit: I think so
heycam: we should focus on the
... don't do this for the gradient elements, even with cx, cy on gradients
ChrisL: but you can put presentation attributes on any element
ed: can't we just make them presentation attributes on particular elements?
heycam: if it's easier since presentation attributes work on any element (?)
krit: in webkit we didn't turn cx cy to properties on radialgradient
heycam: i'd prefer not making them presattrs in this case
RESOLUTION: don't make the layout properties into presentation attributes on the gradient elements
heycam: issue 2, what to do about x and y on text elements?
Tav: we also have them on tspan right?
... the issue is that they're list of values
... either we could allow list of values in the property, but only use the first value
... or the attribute has some special processing
... one option is to not make x y presentation attributes on any of the text elements
krit: I like that, or
alternatively make xy presattr on text, but map them to other
... don't quite like the second idea though
heycam: we already decided that
the x,y lists are bad due to font issues
... so don't think we should allow the second one
krit: another way might be to
apply the xy property to text elements, but also apply the
positoning fromthe xy attributes also
... that would allow positioning from css
heycam: that'd be a little bit
... but might be the best solution
Tav: so discourage use of the x,y,dx,dy?
heycam: I think we should try it out
krit: ok, so spec that and await feedback from implementations?
RESOLUTION: add a new keyword value to the x and y properties that means use-the-list-of-lengths in the attributes, and set that with the UA stylesheet
<scribe> ACTION: krit to add a new keyword value to the x and y properties that means use-the-list-of-lengths in the attributes, and set that with the UA stylesheet and add a note to say that it's still an open issue [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action06]
<trackbot> Created ACTION-3739 - Add a new keyword value to the x and y properties that means use-the-list-of-lengths in the attributes, and set that with the ua stylesheet and add a note to say that it's still an open issue [on Dirk Schulze - due 2015-02-20].
heycam: next chapter,
... issue 2, are there any more up-to-date defs for sizing? (i haven't checked)
... prob needs some closer review by somebody
... someone should take an action to look at this?
<scribe> ACTION: krit to review the svg2 coordinate chapter [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action07]
<trackbot> Created ACTION-3740 - Review the svg2 coordinate chapter [on Dirk Schulze - due 2015-02-20].
heycam: issue 9, about pAR
heycam: do ppl use 'defer' or can we drop it?
ChrisL: is this somehting new?
heycam: I think it's from the original 1.0 spec
krit: don't think webkit implements this
heycam: we have some tests for
defer, but doesn't mean that ppl are using it
... would be happy to try removing it
ed: I'm fine with removing it
heycam: firefox at least supports parsing it
Tav: inkscape doesn't support it
krit: webkit parses it but ignores it
ed: so does that imply that we should allow it but say in the spec that it must be ignored?
heycam: would prefer just to remove it (don't think there's much content using it)
krit: think we should parse it but ignore it
heycam: I'd prefer removing it
RESOLUTION: make defer do nothing (and investigate removing it later)
<scribe> ACTION: krit to make defer be ignored in pAR [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action08]
<trackbot> Created ACTION-3741 - Make defer be ignored in par [on Dirk Schulze - due 2015-02-20].
heycam: next, issue 15
heycam: in the bbox section
... bbox of text with the widht/height set on it
... should it be the box that it's laid out in, or the union of the glyph cells?
Tav: the text would just be the content area, can be reduced due to padding/margin
krit: we should handle it like normal block elements in html
heycam: so what should getBbox return?
Tav: there are different bboxes in css
<text x=10 y=10 width=100>A</text>
heycam: sometimes you have content that can't wrap
Rossen: inline elements don't
have width in css
... this is closer to block
... the blockrelated properties is what should apply to svg here
heycam: we don't need to make
getbbox does like getboundingclientrect
... if we ignore the width feature
... we might return the size of A
Rossen: with the width today if you specify it
<shepazu> (SVG also has different bboxes... geometric bbox, decorated bbox, etc.)
Rossen: you can say it's the bbox or that it's the union of the two, or just the text inside
Tav: depends on how much text you put in
heycam: it's a run of
... we can do pre-formatted text
... we can union the bboxes
... i think we shouldn't return the rect area defined by width/height for text
Tav: if you've wrapped text, some
text sticks out further than the others, you should make that
affect the bbox
... you'd have to look at all the lines to figure out the exact bbox
nikos: if we say width(height is always returned from getbbox you could just check the attribute
Rossen: the information for size
of each line is available internally
... you might want each line separately
ed: multiline text is new in svg2, do we want to allow fetching the size of each line?
krit: cssom defines that getclientrects maps to getbbox (?)
roc: maybe think of it as
... the intrinsic preferred width
heycam: problem is tht dx dy influences the bbox
krit: we could disable them for the case of having width/height
heycam: the options
... 1) look just a the glyphs, take bbox of each and then union the bboxes
... 2) if you have width attribute then bbox has that exact width and height be multiple of lineheight
... 3) union of option 1 and 2
TabAtkins: option 2 is closest to what css is doing today
Rossen: what do we do for negative margin on inline boxes?
TabAtkins: doesn't count
Rossen: not sure it translates well to svg
(draws on whiteboard)
Rossen: think that we want two ways, if you want getclientrects (the content) you get only the text - you can do union, intersection or whatever you want
heycam: if we want options we have a param for getBBox that we can use
Rossen: so list of text content boxes, or the parent box that's the union essentially
heycam: we can always add a way to get the other one
Rossen: right, because we don't have any way to get the lineboxes
heycam: the only downside is that
it's inconsistent with non-areabased text
... where we're using css to layout the text
... but shrinkwrapping the text
Rossen: that's fine though, the bbox is defined by the text content in that case
Tav: think we should not consider
dx, dy and rotate in the textarea case
... for the bbox
heycam: I think the block level element in css should provide the bbox (positioned)
Rossen: when width is auto one of
the three possible ways to size the box
... one is dependency on parent, in percentage
... other is that it's fixed
... third is that it's attached to the text content
-- break for lunch --
<nikos> scribe: Nikos
<scribe> scribenick: nikos
heycam: we discussed over
... when you call getBBox on a text element that has % or px or specified width then bounding box is the specified width
... and height is the height of the CSS box that gets created
... and if you leave off the width, then you take the union of all the bounding boxes for the text
... to handle cases where things are positioned
... if you don't have positions then it's like the other two cases where you're looking at the box and returning the bounding box anyway
... think that makes it a consistent model
... probably don't need to describe in terms of those three things
Tav: looks like a good solution to me
RESOLUTION: for text bounding boxes with specified width, % or px, then the bounding box is the specified width with height being the height of CSS box that is created - otherwise bounding box is union of all child text bounding boxes
<scribe> ACTION: heycam to spec behaviour of getBBox on text [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action09]
<trackbot> Created ACTION-3742 - Spec behaviour of getbbox on text [on Cameron McCormack - due 2015-02-20].
heycam: bogdan suggested we
gather up open issues on this page - we might not have a chance
to resolve them all this meeting
... so I summarised which I thought were substantive issues that need discussing
ed: back to text, if you have
text element without width or height and you have white space
property set to pre wrap
... you have some return characters to specify text as multiple lines
... you get three lines of text
... behaviour of bounding box should be as auto
heycam: this list is based just
on the red issues that are noted in the spec
... may be a few more things in tracker
<scribe> ... new ones may also pop up as we continue reviewing the existing text
UNKNOWN_SPEAKER: Erik and I have
reviewed some chapters
... neither of us are through the whole spec yet
... so probably later chapters need a closer look than the earlier ones
... bearing that in mind, this wiki lists the substantive issues that are noted in the spec
cyril: some chapters start at issue number > 1?
heycam: we've already discussed
some and some don't need discussing
... we may or may not get through this list
... how would you like to prioritise?
BogdanBrinza: normally for us we take a first pass at the list and find highest priority items
Rossen: hope we're in agreement
we want to ship the spec?
... so we can tackle a couple of ways
... we can look at the spec as a whole - if we agree we want to close all issues and ship the spec
... then move to a modular way of advancing svg
... then first pass should be to decide the must unstable and non core things
... that we can live without
... and make those modules right now
... that will reduce the amount of work we need to do as a group to discuss issues
... so as a first pass lets find big areas we can remove
... then from remaining we can assess what is in most dire need of group discussion time
heycam: I like the idea of creating modules immediately for things we're removing
cyril: maybe not the case for all chapters - but some seem to be very close to modules
Rossen: is your list an extraction of this table?
heycam: has some correlation
probably but this is just my judgement of the issues
... and which are not editorial
BogdanBrinza: think we agree on chapters that have most issues
Rossen: do we think we can go through the first step and move things to modules?
krit: I'm in favour of that - do you have features that you want to move
Tav: Think we'd spend more time arguing over which stuff to move than how to solve the issues
BogdanBrinza: Chapters 15, mesh gradients has a lot of issues
heycam: don't think we should be
looking at the chapter level - but at features
... if we look at my list of open issues - do you agree that if we've solved open issues for a feature should it stay?
Rossen: not sure - if we can move something to the next level why spend time talking about it?
heycam: sounds like you have ideas about features you don't want to see in the spec - even though there are no open issues
Rossen: I wouldn't oppose a stable feature staying
BogdanBrinza: generally not about features we want in the spec - but everyone wants to see a stable spec
heycam: do you think stability is not solely determined by open issues?
BogdanBrinza: I'd say that's the most important thing - but severity matters too
heycam: I was going to suggest
looking at features that correspond to open issues
... so if we've resolved issues on a feature it can stay
Rossen: do we consider features
... or just enough stuff there so we think it's complete but not sure
... are we going to find issues when we review?
... ok lets go through each issue then
heycam: let's finish co-ords chapter then we can talk about features in other chapters
<scribe> ACTION: heycam to make stable issue identifiers in the spec [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action10]
<trackbot> Created ACTION-3743 - Make stable issue identifiers in the spec [on Cameron McCormack - due 2015-02-20].
issue 17, co-ords chapter
heycam: issue 17, co-ords
... should fill correspond to the main area of that element?
... so fill:false should exclude that rectangular region?
<ed> for ACTION-3743 make sure that the template has fields for assigned actions, wg discussion and resolution
heycam: if it's not an svg
element you can't call getBBox, but you can call it on the
... so iframe or canvas should contribute to the bbox
Rossen: if it's not exposed how
can you get the bbox?
... should define getBBox on these elements
krit: if you put HTML in an svg document, how does CSS box model contribute to the bounding box computations - it's a general problem
Rossen: we define getBBox on foriegnObejct? Behaviour should be the same
krit: but on fo you have a whole html doc
heycam: fo and iframe and canvas just return the rectangle - but issue is whether fill dictionary parameter controls whether that contained element contributes or not
Tav: To me fill:false is not a
... as a control
heycam: sounds like we agree on that
RESOLUTION: The fill dictionary parameter doesn't affect bounding box of iframe, canvas, etc
<scribe> ACTION: heycam to update spec for fill dictionary parameter when called on iframe, canvas, etc [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action11]
<trackbot> Created ACTION-3744 - Update spec for fill dictionary parameter when called on iframe, canvas, etc [on Cameron McCormack - due 2015-02-20].
heycam: proposing to remove svg:transform’ attribute
krit: already done
ChrisL: where is it being moved to ?
heycam: no one uses it
ChrisL: mapping people use
... my understanding is we changed behaviour for this to match what implementations do
krit: the removed text was mostly pointless
cyril: it's not the same as the transform attribute - same name but in a different namespace
heycam: if you think it's being
used by people it can stay
... just worried wording is outdated
ChrisL: this was standardised through JIS
krit: I'll put it in integration spec
ChrisL: that's ok - just don't want it removed
AlexD: isn't this what Takagi-san is using for tiling?
cyril: don't think it should be
in integration spec - should be module on it's own
... I see integration spec as between svg, html, css
ChrisL: it's larger - how css uses things
Tav: I'd like to see it moved before it's taken out
krit: I'm doing it right
... into a new module right/
ChrisL: section above it as well?
heycam: there was going to be a mapping spec?
ChrisL: yes but mapping spec by
itself wasn't useful
... by itself
... so dispersed these features into svg 2 spec
Tav: that's why it's good having annotations describing why things are moved
RESOLUTION: svg:transform attribute will be moved to a new module
heycam: let's look at remaining
issues in terms of the features they encompass
... all path issues are for Catmull-Rom
Rossen: who is implementing it?
Tav: it's Doug's baby
Rossen: can we have a Catmull-Rom module?
ChrisL: tricky because it's in the path element
shane: we did that in CSS
ChrisL: was going to bring that up as a bad example
shepazu: there's a not great way
- which would still be good enough
... supersede description in new spec
... good way is define what path commands look like
... and say future specs may define new path commands
ChrisL: agree, not sure how much work it is making it properly extensible
shane: could put all stuff in path extension spec
ChrisL: so in core svg 2 path syntax is the same as svg 1.1?
heycam: we have bearing and
... that's an example of a feature that is complete in the spec, but people have reservations about it being in core svg 2
Tav: it's not something I care too much about having - but feel it will be ignored once it's in another spec
Rossen: that's how css
... survival of the fittest - good features progress faster
... I think it's a good way to do things
TabAtkins: don't be afraid of modules
heycam: Doing things in modules is the right thing- but I'm concerned if we move features to modules then svg 2 won't be much different to svg 1.1
ChrisL: that's a problem because we've then spent 10 years producing a spec that doesn't have new features
Rossen: if you have 5 other specs in the pipeline then you have a good story
ChrisL: we've already gone from
modules to one monolithic spec
... now we're going back
Tav: how much work to fix Catmull Rom?
heycam: need to add math to the
... issues could be summarily decided
Rossen: this is a good example of
a feature that could move imo
... it's a good feature
... some designers have questioned it's use
Tav: there's a good use when connecting points in a graph
heycam: I would have to do investigation of the math
Tav: it's pretty simple
Rossen: if it was such a hot feature I'd expect Adobe, InkScape, etc to be pushing it
krit: Adobe already stated we don't care
heycam: so if you want a sense of it staying in svg 2 or being split ... ?
krit: not necessary for svg 2
Rossen: can we resolve to move it to it's own module
heycam: as long as we create a
new spec immediately
... don't want to lose the work we have done
ed: do you have same concern about bearing?
Rossen: I haven't read the bearing stuff
heycam: I'll be less excited about shipping svg 2 with all the features removed
shane: I think we'll fairly
readily be able to find features that have no issues or trivial
and those that have substantive issues
... why not appoint champion or owner for features with substantive issues
... if issues aren't resolved by wg within a certain time frame we move it out
Rossen: features without issues
shouldn't necessarily remain part of the core
... if features have expensive implementation cost then they should maybe moved out
heycam: we could mark them at risk
Jet: is there a list of at risk
... that's probably the first step
heycam: table in your wiki page isn't at feature granularity, which is what we need to discuss
Rossen: it's easy to decide on some - basic types for example
krit: svg 1.1 isn't going to disappear - it can still be referenced
stakagi: not using transform at
the moment - it is ok to remove it from this level
... you can put me as editor of the svg:transform spec
heycam: Catmull-Rom - what are we
... put with superpath as svg path level 1?
shane: it's a really nice target
... doesn't mean it won't be published at the same time as svg 2
heycam: let's publish first draft of these things when we publish CR of svg 2
RESOLUTION: Will create SVG path module
heycam: should svg 2 path only be
what is supported by 1.1?
... so move all new things (e.g. bearing) into the module?
shane: there is work involved in moving stuff - if a feature has no issues then leave it
heycam: I'm ok either way
Rossen: i'm ok with either too
heycam: minimum work is leave it where it is
all: let's do that
<scribe> ACTION: heycam to move Catmull-Rom to SVG path module [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action12]
<trackbot> Created ACTION-3745 - Move catmull-rom to svg path module [on Cameron McCormack - due 2015-02-20].
heycam: Editors will be Cam, Doug, and Cyril
TabAtkins: do we want to use CSS
naming where everything that builds off SVG 2 is next
... then we'd start at 2
all: that's confusing, let's
heycam: next bunch of issues are
to do with text
... either shape text or rectangular ref text
Rossen: are your issues in an order?
heycam: just numeric
Rossen: can we do things with only 1 issue?
heycam: Let's do animate.html, Issue 2
birtles: basically new features
we'll defer to a separate spec
... then there's one or two edits I should make with regards to correctness
... not sure about allowing animatemotion to use a basic shape
... not sure if we want to include those slight improvements
... or defer everything
Rossen: what would it look like after your change?
ed: we resolved to allow basic shapes for text on path
birtles: so for consistency we
should leave it
... major features will be deferred
... I can take care of the issues that are there
... and get rid of references to features which we'll put in a different module
heycam: can we discuss attributeType="auto"?
ed: I came across issue with SMIL
elements and attributeType
... default is auto which means check if it's a property first
... if so that's what your'e animated, otherwise attribute
... since we made x and y properties
... it's a problem on text element
... which takes a list of values
... I'm wondering if we should try to be smarter here selecting the right thing
heycam: why wouldn't that content
... auto means when both property and presentation attribute, choose the property right?
ed: if we make x a property,
we'll try to animate x as a css property
... and that might not give the same result as previously
heycam: outcome of previous
discussion was that it would work
... property is the primary thing that determines the value
ed: if you have a list of values
(e.g. "10 20 30") it's not valid for the property, so animation
will stop working when it used to work
... one suggestion is to make auto pick the xml version if it's a text element
... that will preserve old behaviour
... and pick css property for any other element
Rossen: and when number of values is one?
AlexD: I don't like behaviour of attribute depending on what it's parent is
birtles: you have to look up parent or target anywhere when animating
AlexD: but not when binding
birtles: yes you need to look to see if there's an attribute of that name that can be animated
AlexD: seems like strange
behaviour to me
... choose one or the other and whatever it breaks it breaks
Rossen: doesn't sound like much will break
ed: expect most would use one value
birtles: I think there'd be some
... you see people moving characters around like that
Rossen: I'd be more concerned about tools and tool makers
birtles: that suggests keep backwards compat
AlexD: don't know if there's any tool that generates this
birtles: I was hoping to deprecate attributeType altogether
ChrisL: attributeType was introduced to disambiguate a name class between width and height attributes and properties
<birtles> Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1062106
ChrisL: so most of the time you
didn't need to specify it
... in some was we have more of a clash now
... we've promoted lots of things that were attribtues into properties
... so I don't think it serves much purpose at the moment
... think people tended to guess as to which value to set
... and it usually didn't matter
... so you'd probably find uses - but removing attributeType would probably render just the same
birtles: but how do we make text case work?
Rossen: state it's deprecated
birtles: if we get rid of attributeType how do you animate x attribute on text element?
Rossen: so what are options we
... option a) remove attributeType altogether because pretty much all properties are attributes and only x is problematic
... we'll deprecate multiple x/y value animate for text
... as a consequence
ed: do we want to consider deprecating having multiple x/y values on text element
cyril: it's heavily used isn't it ?
krit: yes but not for animation
<scribe> ACTION: ed to add use counter for multiple x/y values on text element [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action13]
<trackbot> Created ACTION-3746 - Add use counter for multiple x/y values on text element [on Erik Dahlström - due 2015-02-20].
Rossen: let's wait for more data then
ed: don't think we need to make both decisions at the same time
Rossen: option b) get rid of
attributeType and in this case have a fall back mechanism for
the property that gives a list of values
... e.g. we can take last or first valid attribute from the list
... and animate with that
... which will again break animation, but not as badly (maybe)
... in one case you have no animations at all - second you have animations of one frame
... not perfect, but less invasive
... option c) get rid of attributeType and add special handling for x on text
... make it context aware
... is there another option where we extend the attributeType to specify instead of doing context aware
heycam: it already has values to select attribute or property
ed: we could make auto on text elements, pick xml as the default
Rossen: option d) attributeType
for animate inside of text is always xml - there is no
... would reduce options in future
cyril: detect number of values?
Rossen: that would be hacky
birtles: I think we could drop
attributeType and leave a note in the spec with the context
aware behaviour as an open issue
... see what data we get on the use counter
... if there's not sufficient usage of multiple values for x we drop, otherwise we do context aware
Rossen: what about if we deprecate it now and see who fights for it?
birtles: I know there's a lot of opposition to multiple values for x anyway
ed: difference between static text with multiple values and animated multiple values - there will be a lot less animated
cyril: removing attributeType is ok - but the consequence in option a is not acceptable
birtles: the consequence only applies to animation
cyril: ahh ok
birtles: there is a work around
for jittering text
... using dx/dy
RESOLUTION: remove attributeType and deprecate animation of multiple values in x/y
Rossen: that was the big issue with animation - so this chapter is mostly clear
birtles: I need to do some more tidy up but yes
heycam: interact.html ISSUE 1:
should we remove duplicate events like SVGLoad? is already
... lacuna value for pservers.html ISSUE 3: linearGradient y2 lacuna value is already resolved
... the value should really be zero
RESOLUTION: lacuna value of y2 on linearGreadient should be zero
Rossen: what about masking.html ISSUE 2: define how overflow-x,y work ?
krit: being moved
... ISSUE 3: should overflow:auto really be equivalent to visible
... we changed behaviour based on ie
Rossen: thought we discussed in London?
nikos: from London - All viewport-establishing elements will be overflow:visible by default, except for root <svg> of SVG whole documents.
Rossen: seems like a perfect fit for integration spec
krit: do we move overflow to integration spec?
heycam: why is it in our spec?
ed: we have lots of special rules
heycam: remove that section, add
relevant UA rule and that should be enough
... krit can we really remove it all?
... I need to think about it - give me the action
<scribe> ACTION: Cameron to take care of overflow section in the masking chapter [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action14]
<trackbot> Created ACTION-3747 - Take care of overflow section in the masking chapter [on Cameron McCormack - due 2015-02-20].
nikos: a lot of the stuff in Clipping, Masking and compositing will move to rendering chapter or be removed so this chapter will probably go
RESOLUTION: masking.html, issue 2 - Drop overflow-x,y issue and don't do anything specific in SVG
krit: so all these changes are going to integration spec and are being removed from svg 2?
heycam: i'm concerned that it's not valid to state that auto on a particular element computes to a different value
Rossen: we do that all the time
RESOLUTION: masking.html ISSUE 3: should overflow:auto really be equivalent to visible? Should be moved to integration spec and removed from SVG 2
krit: can we remove 15.3 and 15.4 totally?
heycam: think in rendering chapter we need to describe how these things fit into the scheme of things
nikos: I think rendering chapter should say at what point these things occur and that's all
<ed> -- 15 min break --
<Tav> scribe: tav
<scribe> scribenick: Tav
Rossen: , Let's cover issue in color chapter.
Rossen: Issue 1:
... should this be here?
TabAtkins, : Should be in colors4.
scribe: not in yet, will be soon.
krit: What do we need to keep?
Rossen: Tab, what do we need to keep?
Rossen: Motion: move everything in this chapter to color4.
krit: SVG Interface rule should disappear.
ed: will icc-color be part of the <color> grammar in css?
Rossen: Yes, should be in colors4.
SVG color profile rule interface.
... Remove color chapter from SVG 2. Refer to CSS Color 3 and 4.
<scribe> ACTION: TabAtkins Finish CSS Color 4 (with stuff from SVG). [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action15]
<trackbot> Created ACTION-3748 - Finish css color 4 (with stuff from svg). [on Tab Atkins Jr. - due 2015-02-20].
ed: Should go.
<ed> (to be clear, the entire room says that, not just me ;)
RESOLVE: Remove InterfaceSVGCSSRule and InterfaceSVGRenderingIntent.
Rossen: Only two chapters to go from heycam's list: painting & text.
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
heycam: first two issues are to do with arcs line-join
Tav: first issue is the
... nobody suggested a different name
... so let's just leave it as is
... second one is what do you so with miter-limit
... now that we have this clipping option, ...
... it's possible to get a very long arc
... I would suggest that taking the mid point of the end of the stroke before the cap, then measure along the mid-arc the miter limit
RESOLUTION: arc line caps are affected by miter-limit by measuring along the middle arc and clipping a straight line perpendicular at that point
<scribe> ACTION: Tav to make miter-limit work on arc line caps in this way [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action16]
<trackbot> Created ACTION-3749 - Make miter-limit work on arc line caps in this way [on Tavmjong Bah - due 2015-02-20].
<Tav> Scribe: Tav
<scribe> ScribeNick: Tav
heycam: New feature in SVG 2.
... look at pictures in section.
heycam: Illustrator supports.
krit: Illustator dashing different.
heycam: Not the most important issue.
krit: Could we have a stroking
... would like to have a core with what is supported today.
heycam: Not happy with pulling out stroking.
ed, Rossen stroking should be well defined.
krit: doesn't include stroke-alignment...
Rossen: The fact that stroking will be well defined in SVG 2 we could still have a stroking spec.. What would be in it?
heycam: I can summarize the new
... arcs line join
krit, tav: stroke-alignment often requested.
tav: would like to have %
Rossen: stroke-dashcorner: our (IE) implementation for stroking is pretty complicated, could be hard to do.
krit: Used in illustrator.
heycam: Can just stretch dash array.
Rossen: We still don't have interopability with normal dashing today.
roc: SVG stroking is actually rather simple.
<ed> (in comparison to css border dashing)
roc: We need an extensible stroking task force. Lots of neat things you can do.
Rossen: Should there be a new
... What would be in the new SVG stroking module:
ed: Variable width stroking.
Rossen: That's a really cool feature.
krit/Rossen Dashing and Variable width.
Rossen: We extend in CSS specs
with just one new value of a property.
... New specs should only add stuff that's not in already in SVG 2.
krit: But what should we ship here for SVG 2?
heycam: I think there are some things already implemented that should remain.
Rossen: Should we start with stroke-dashcorner? (Moving to new spec)
heycam: Question at approach: we've been telling authors about these new things. How can we maintain the message that things will be coming at the same pace.
Rossen: I think that moving things into modules sends the message that we can move faster than with a big SVG2 spec.
krit: I'm happy to move out new marker stuff to new spec.
heycam: There would be some overlap in text between specs.
Rossen: there are modules that we
would ship ahead of SVG2.
... Interlude: explains IE/Microsoft philosophy towards choosing what to ship.
krit: Can we have a resolution
having a painting module?
... put in paint-order
ed: Don't think that's a good idea.
tav: Would you (Rossen) implement 'paint-order' if it was in a separate spec?
ed: We could say that this section is stable.
Rossen: It's not in a stable spec.
Discussion of where things should go....
Rossen: Should we start an SVG marker spec?
heycam: I'm more concerned about public impression of SVG 2 if things get moved out.
<shepazu> modularization is time consuming and confuses developers
BogdanBrinza: What the SVG working group thinks is more important than public perception.
<ed> (the time consuming part)
heycam: Things in the past that
have been split out tend to mean that we don't want to work on
... One advantage of splitting out is that we would have a well defined owner for the spec.
Tav: A markers spec would be a good trial of this.
ed: Not clear that a marker spec could move faster. There is a lot of stuff tied to SVG core.
Rossen: having something in PR is
much better than having some text in the bigger spec.
... saying this is stable.
krit: marker knockout should be moved to a separate markers spec.
heycam: ignoring the marker knockout, the rest is pretty stable.
Proposal: Start a new marker spec.
ed: Not so sure about this but won't object.
tav: with eric
heycam: Is willing to try it.
RESOLUTION: Move new marker features to a separate marker spec.
Rossen: We won't be discussing the following issues:
<Rossen> ISSUE 23: what to do with marker knockouts
<Rossen> ISSUE 18: name these vertex or segment markers?
<Rossen> ISSUE 30: should paint-order be able to select the different types of markers?
<Rossen> ISSUE 32: should SVGMarkerInstance objects be live? (or should we remove those interfaces?)
Rossen: Let's get back to stroke-dashcorner for rounded rects.
heycam: Dashing will move slower than markers. Dashing should move into a stroking spec.
Moving on to text issues.
Tav: Meta issue: how do we treat all the various text properties?
Rossen: It would be reasonable to expect that paragraph level things would work. (text-indent, etc.)
heycam: Properties that apply to inline elements should work.
roc: some aren't appropriate perhaps.
ChrisL: Don't want a white list.
krit: Text handled by normal code path.
Rossen: So do we.
... In trident we have the concept of paragraphs that are like blocks with out the blocky stuff (padding, etc.)
... text alignment, writing mode, etc. are supported.
... underline, bold are handled in one level down.
heycam: We should have a paragraph guiding our intentions so when new things come along they can be automatically included or excluded.
Rossen: We could ask the CSS working group to add a term that defines paragraph level properties.
roc: CSS does have the concept of anonymous blocks. We want everything that effects these blocks. But there is no name.
krit: We should ask CSS for an "official" name.
'text-indent' applies to <text> as it is part of the CSS
paragraph level properties.
... CSS Paragraph level properties are assume to apply to SVG <text> element with wrapping context.
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
Rossen: so that resolves issues
37 and 38
... shape-inside, shape-outside
Tav: I think I know what to do with these now after discussing with CSS folks
Rossen: I am the editor of that
... so the rest of the issues are shapes related
... issue 2, are dx/dy/rotate ignored for auto-wrapped text
ChrisL: when would you want to do that
Tav: I would be fine with that
ed: I agree
ChrisL: those things were because
we didn't have wrapping text
... and some people wanted to do "better" text on a path
heycam: you could argue from
consistency with single line text
... you could apply the positioning attributes to content area text just as easily
... but it won't be useful
RESOLUTION: dx/dy/rotate are ignored for text with a wrapping context
Rossen: last, issue 4; should x/y specify the corner of the content area or the origin of the first glyph
[Tav draws and shows the two options]
Rossen: I suggest using extent
rather than width/height
... then authors won't think you should be able to put both width and height
RESOLUTION: Change width/height on <text> to extent
<scribe> ACTION: Tav to make the text changes from today's meeting [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action17]
<trackbot> Created ACTION-3750 - Make the text changes from today's meeting [on Tavmjong Bah - due 2015-02-20].
RRSAgent: make minutes
<pdr__> svgwg is rocking it for sticking with the pathseg removal.
<krit> commit 7d2ff7e2f7a1fd55f152f6b308f695915a814408
<krit> Author: Cameron McCormack <firstname.lastname@example.org>
<krit> Date: Fri Feb 13 22:13:02 2015 +1100
<krit> Markers module.
<krit> commit ce33635151342971e99b63c2cf63db8cb82a9e7e
<krit> Author: cconcolato <email@example.com>
<krit> Date: Fri Feb 13 11:39:52 2015 +0100
<krit> fix broken markup
<krit> commit 74e23360c8d7460facb61ef92f7b5919e7518cc3
<krit> Author: Dirk Schulze <firstname.lastname@example.org>
<krit> Date: Fri Feb 13 21:27:37 2015 +1100
<krit> Initial marker spec
<krit> heycam|away: I was ~1h earlier ;)
trackbot, start telcon
<trackbot> Meeting: SVG Working Group Teleconference
<trackbot> Date: 13 February 2015
<scribe> Chair: Cameron
<BogdanBrinza> scribe: BogdanBrinza
<scribe> scribeNick: BogdanBrinza
topic is SVG Markers
heycam: Both Dirk and I took
first step o producing first spec version for SVG Marker Level
... The question is - is this ready for first publish working draft
Rossen: In CSS WG the rule is you
have a short name - which is stated on the module
... so that in mailing list you reference this and a page with issues
heycam: So in the end we should combine two versions
krit: We should decide on short name
shane: so markers would work nice and align with CSS
Tav: should we have a Level 2 already?
heycam: does everybody agree that knockout should be in L2?
Rossen: in FPWD we can have it and then split if needed. no reason to push this off
cyril: What about section 9? how markers are rendered?
heycam: I just missed copied that
initially - will add this soon
... so the current approach is to copy all stuff we had in old spec at the moment
shane: it should be fine to use either
Rossen: again, the rule we follow
in CSS is simple - if you're extending 2.1 you copy whole
section and start extending
... if we're extending from SVG 1.1 this is something we can do, if we're extending from 2 (that is not ready) we can just get the deltas
birtles: As an author I don't like the deltas
<birtles> (because I have to look up two specs)
heycam: so what are we doing? deltas / no deltas?
Rossen: let's agree on consistency
cyril: is there a pointer in CSS that goes from L2 to L3?
Rossen: not really
cyril: this might be confusing if you want to find the latest version - google will give you not the latest
Rossen: CSS snapshots address this and everything that is up to date at certain moment
Tav: pointer up might be useful
cyril: pointer to a stable URL might be useful
SVG Markers Level 1 as FPWD
... All specs would have a pointer to a stable SVG summary spec (snapshot) that lists the status of all modles
heycam: Because I took a text from SVG2 for this section - if SVG2 doesn't progress fast enough we might need to change links to SVG 1.1
Rossen: and you're going to move the section about rounding the markers?
Rossen: no details about the rendering
heycam: yes, I'll move this
... So remaining on the agenda is next F2F meeting, motion path animation and couple of Tav topics
shane: didn't we decide we won't talke about motion path?
Rossen: where we left on
remaining issues is
... we need to sync with Tav on remaining shapes issues
Rossen: next pat is painting where we took issues related to markers
we decided miter limits, arcs and remaining are stroking issues
Rossen: so the discussion was should we keep strokes in SVG2 or move to a new spec and fix the issues on fixed timelines
heycam: strokes are pretty much the same level of readiness as markers - so it should be also splittable if we want to
Rossen: this is great sign that SVG2 spec moved as set of modules
ed: so how do you want to do split? move jsut new things or everything?
Rossen: we should still move
stroke the same way we moved markers
... so when we clean SVG2 strokes sections we should add extensions since 1
... when we ship SVG2 we'll have a section about stroking and new behavior goes to a separate spec
... and we can move or keep the new wording
heycam: it might be easier to take the whole section
Rossen: so who would be editor beside you?
heycam: there are stroke-dashcorner, miter-limit, arcs
someone: what about variable stroke width?
<birtles> birtles: that got deferred because I don't have time to work on it at the moment
Rossen: yesterday we decided we shouldn't move good ready modules - so from previously noted list of stoking features which are stable or ready to move
heycam: there are number of
issues and discussions those features need
... so it would be useful to have implementors to try those features to provide feedback
Tav: Inkscape has prototype for arcs, not yet implementing dashing
Rossen: does anybody has implementation for stroke-dashing?
all: there are no current implementations of dashing
Rossen: so it would be good
candidate to separate
... so arcs can live in current spec
heycam: we can have features at
risk in the spec
... so we're moving this decision a bit earlier
Tav: so why would be pain-order at risk?
heycam: it's not - it's example of feature not at risk
Tav: so what about multiple stroke width?
heycam: it's a new and can be moved
krit: so multiple stroke width can go with multiple stroke layers
heycam: unless we want to decide how we want to ship with / without multiple stroke width
Rossen: so in that case who is going to be the editor of SVG stroking
heycam: it's currently all features I've added
Rossen: so Cameron and Dirk?
cyril: I have a question
... so we went with SVG Markers Level 1
Rossen: every module starts with Level 1 unless you're extending existing one
Tav: so what is extending in this case?
someone: so there was a initial confusion with CSS3 because it became a buzz word
krit: but we can start with Level 1 here
heycam: Let's stick with Level 1
cyril: so you have SVG 2 and
Markers Level 1
... wouldn't they assume it's based on SVG 1?
shane: people who you're talking
about wouldn't read the spec
... and the target audience already understands that state and what is based on what
Rossen: for now let's not give them many levels
birtles: that's wonderful
Rossen: so SVG strokes / stroking / else?
all: SVG Strokes
RESOLUTION: Create new spec SVG Strokes with heycam and krit as editors
Rossen: can we move to FPWD?
heycam: I'd like to check the text and we can review after that
all: we would be happy to resolve to publish
RESOLUTION: Publish FPWD of SVG Strokes
Rossen: that is pretty much all
issues Cameron brought up
... so we currently have two new modules and remaining issues. What else is blocking?
heycam: existing issues and
... so in order to move forward we might need to understand amount of editorial work and assign
Rossen: so let's take a look at the sections in red currently
krit: so document structure?
Rossen: give me one second to log
and put owners names to chapters
... ed you mentioned you can use help from somebody?
ed: Rich send a mail that there
might be changes to better align with HTML and provide better
... there shouldn't be major issues, but need to go through all
... the major one - <use> alignment with web components TabAtkins
... the rest are DOM interfaces, mostly clarifications
Rossen: API design is not somethign to blaze through
ed: this is not API design - this is clarifications
heycam: I'd like to have each chapter to have a single point of contact
Rossen: there is still decent number of issues on Document structure
ed: we did resolve some issues on F2F
Rossen: suggestion - can you take
a first pass at issues and editorials and bring this back to WG
... on Document structure, Erik is primary owner, TabAtkins would help with <use> and rest is mostly editorial changes
... next one is Text and has a clear owner - Tav
Tav: yes, rest of the issues can be addressed pretty soon
Rossen: looking through the spec - we knocked most of them yesterday and at this point it's mostly cleaning up
Tav: for first pass I can take a look and get back with any outstanding issues
Rossen: Paining, etc - most of
the issues have been moved to seprate specs, so cleaning out
would give us a clean state
... the owner was still heycam?
Rossen: next Paint Servers. There were issues on mesh gradients not in heycam's list?
Tav: those are minor issues. Inkscape has mesh gradients implementation for 3 years
Rossen: so in that case - after
cleanup driven by Tav we can take another look and get
... Basic Data Types - owner heycam and he has a good handle on this one
... next Styling
heycam: this might be in poor
state and would need rewrite
... I think what this chapter should become is description on which CSS modules are required
... and description of presentation attributes
Rossen: why this is not part of integration chapter?
heycam: this chapter currently is describing how other things are used in SVG
Rossen: this is an inverse of integration chapter
krit: we also write what specifications we rely on CSS
heycam: we should put specifications SVG relies on
Rossen: so can we assign the owner to clean this and decide the struecture of this one?
heycam: I would like to do that
Rossen: we're having to much on heycam, but let's try this and on next telcons learn what we can do to help
BogdanBrinza: I can take
remaining yellow ones
... so Paths, Embedded content are on me with help from WG
Rossen: next introduction section - cyril
nikos: Rendering model - that should be me
Rossen: next SVG Layout properties
krit: that's me
Rossen: Basic shapes - Rossen
krit: Color section would go entirely with additional work from TabAtkins
Rossen: Clipping and masking - krit, nikos
all: Filter effects are gone
cyril: Linking makes sense to keep with Embedded content
BogdanBrinza: so Linking goes to BogdanBrinza as well
Rossen: Animations -
... Scripting might be close to Animations
birtles: might not be able to take it before April
Rossen: ok, BogdanBrinza and
Rossen will take it
... Metadata - owner ed pending merge with document
ACTION ed to merge Metadata chapter with Document structure
<trackbot> Created ACTION-3751 - Merge metadata chapter with document structure [on Erik Dahlström - due 2015-02-20].
ACTION krit to remove Backwards Compatibility
<trackbot> Created ACTION-3752 - Remove backwards compatibility [on Dirk Schulze - due 2015-02-20].
Rossen: Extensibility - I can take this
ACTION BogdanBrinza to add Addendums to the SVG readiness table
<trackbot> Created ACTION-3753 - Add addendums to the svg readiness table [on Bogdan Brinza - due 2015-02-20].
<heycam> -- 15 min break --
ACTION BogdanBrinza summarize owners for chapters in https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_readiness_assessment
<trackbot> Created ACTION-3754 - Summarize owners for chapters in https://www.w3.org/graphics/svg/wg/wiki/svg2_readiness_assessment [on Bogdan Brinza - due 2015-02-20].
Rossen: how about we put
timelines/cap on chapters
... next telcon is not goign to happen in next two weeks
... so owners of the chapter need to put items on the agenda and highlight most critical issues
heycam: we might not cover all things we have on the next call
Rossen: is there anyone who believes we won't meet 3 weeks for having all of the assessments and starting actual work?
heycam: by March 5th we should
have those things listed in actionable state
... there are couple Appendicies I would propose to remove
... Internatialization support appendix
cyril: I can add things in Introduction chapter?
RESOLUTION: Remove the Appendix F: Internationalization Support
ed: next one Appendix G
RESOLUTION: Remove Appendix G: Minimizing SVG File Sizes
heycam: Next one Appendix N:
Media Type Registration for image/svg+xml
... Chris would check where that links to
ed: this might point to latest TR version of it
<cyril> iana link: [http://www.w3.org/TR/SVG/mimereg.html]
<cyril> check this page: http://www.iana.org/assignments/media-types/media-types.xhtml#image
ACTION ChrisL to check and remove Appendix N: Media Type Registration for image/svg+xml
<trackbot> Created ACTION-3755 - Check and remove appendix n: media type registration for image/svg+xml [on Chris Lilley - due 2015-02-21].
ed: Appendix L: IDL Index - do we need this?
krit: this is just an index
heycam: IDL definitions would
include all, maybe we don't need them in two places?
... so let's leave that in place
heycam: next one Appendix E: Accessibility Support
<BogdanBrinz> ACTION Rich to define the further steps for Appendix E: Accessibility Support
<trackbot> Created ACTION-3756 - Define the further steps for appendix e: accessibility support [on Richard Schwerdtfeger - due 2015-02-21].
<BogdanBrinz> RESOLUTION: SVG WG to publish SVG2 WD
<ed> please sign up
<BogdanBrinz> ed: What is our next after Linkoping?
<BogdanBrinz> Tav: what are the options?
<BogdanBrinz> Rossen: Paris with CSS WG
<BogdanBrinz> all: also SVG Open
<BogdanBrinz> RESOLUTION: Next SVG F2F after June would be TPAC
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
Tav: coons patch meshes suffer
from a flaw
... the derivative of the colour profile can have jumps at patch boundaries
... leading to visible artifacts, bright lines, etc. at patch corners
... this is enhanced by mach banding, where your eye is caught by changes in the color profile
... you can see that the color distribution is continuous, but appears to your eyes that it has bright white bands
... the way illustrator and coreldraw handle this is they smooth their meshes
... for adobe, when you export the mesh, it subdivides a patch into an 8x8 array of patches
nikos: I think it might be adaptive
Tav: at least in one example I've seen 8x8
nikos: certainly a lot of patches
Tav: you can see it on the
... you can see the little patches
... it'd be nice to be able to do that smoothing in SVG, then you can reduce the number of patches in the file
nikos: and it means you don't lose the information in the editor
Tav: so I did some experiments
with various smoothing algorithms
... I show them in 1D
... the top one on that page above is what you get out of a coons patch mesh now
... you can see the discontinuity
... the first thing to try is a hermite, a simple smoothing algorithm where the deriviative across the boundary is zero
... it makes the profile within the patch not to be linear
... looks wavy
... next is to try Catmull-Rom interpolation
... that gives you the hermite function, but what you need is the tangent across the boundaries
... the next three examples on the page does that
... the difference between them is the end treatment
... one doubles the first/last points, one reflects them (the n+1 point is a reflection of the n-1 point)
... the third is insisting that the polynomial is a quadratic
... so you have the magnitude of two points on one side, and you have a tangent. you can fit a quadratic to that.
... that seems to be what's happening in illustrator
cyril: I remember reading a paper explaining what adobe was doing
nikos: by Sun
Tav: the next problem is that
Catmull-Rom curves can produce minimum and maximum values
within a patch
... you can avoid that by restricting the tangent to a value that's 3 times the value of the tangent you get when looking across the whole patch
... it gives you a monotonic profile
... so you adjust the tangents to get that
... now, looking at 2D
... there is a bicubic-interpolation you can do, which I've implemented in inkscape
[shows a demo]
scribe: my proposal is to have a patch have a type, default would be coons patch, second type would be smooth
nikos: this doesn't let you
control the gradient across the boundary
... if you want a sharp boundary you couldn't achieve it
Tav: you could by adding an extra row in
nikos: it'd be nice to have a control
Tav: that complicates things
quite a bit
... this is just one flag
... the algorithm is here, fairly easy to implement
nikos: in Illustrator, can you control the gradient?
Tav: this matches Illustrator's behaviour
cyril: calling it "smooth".... "bicubic" would be clearer
Tav: I'm fine with that
... my proposal is to add this and spec it all out
... I've got the formulas and prototype implementation
cyril: you'll turn off all the other modes in inkscape?
Tav: yes that was just for demonstration
cyril: now that the mode does not say "smooth", it'd be good to ensure we don't preclude adding additional controls in the future
nikos: the reason we were talking
about having different elements was that otherwise you'd have
different attributes depending on the value of type=""
... if we had smoothing and we wanted to add control points for the smoothing...
Tav: I don't see it ever
... you'd need control points for the three different colours?
... that's an order of magnitude more complicated in editing
nikos: if you give them the raw
control, yes it's a lot of work
... but I think you an simplify that through UI for authors
... having a handle to control how far out something is spread would be useful I think
... I just don't want to not have the option to do that later, or for it to be a confusing syntax later
Tav: do you have an idea what syntax you would use?
nikos: not at the moment
... even if you controlled the channels separately for the handles, it's not nice for authors, but could be for converted content
... vectorised photographs for example
Tav: I'm worried that that will delay meshes
nikos: I don't want to do
... I really like this proposal
... we should go with it
... I just want to keep the door open to extending without running into nasty syntax in the ftureu
Tav: you'd have to add a new
thing to the patch
... dx/dy for each of the colours
nikos: would rather have a different element when you have a different mode
cyril: is this part of the SVG 2 spec?
Tav: it's all worked out, I'd just add it to SVG 2
nikos: I'm OK with having a
type="" I think
... if you have something with extra handles you could have a new element later
RESOLUTION: We will have a type="smooth-bicubic" or similar on <patch>
<scribe> ACTION: Tav to add <patch type="smooth-bicubic"> to the spec. [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action18]
<trackbot> Created ACTION-3757 - Add <patch type="smooth-bicubic"> to the spec. [on Tavmjong Bah - due 2015-02-21].
nikos: because the control is on the patch, you can have a mesh made of smooth and coons patches
heycam: is that useful?
Tav: no the type="" goes on the <mesh>
ACTION-3757: Actually type="" is on the <mesh> element.
<trackbot> Notes added to ACTION-3757 Add <patch type="smooth-bicubic"> to the spec..
<scribe> ACTION: Cyril to investigate web-platform-tests for SVG test suite and write up a wiki page [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action19]
<trackbot> Created ACTION-3758 - Investigate web-platform-tests for svg test suite and write up a wiki page [on Cyril Concolato - due 2015-02-21].
<stakagi> last update : June 2012
stakagi, that would be a good page to update
[reads out definitions of "current innermost" and friends]
birtles: I think we can drop half of these definitions
krit: depends where they're used
ed: perhaps this chapter is not where they're used first
<scribe> ACTION: Brian to fix outermost/innermost svg element definitions, checking where they're used currently [recorded in http://www.w3.org/2015/02/12-svg-minutes.html#action20]
<trackbot> Created ACTION-3759 - Fix outermost/innermost svg element definitions, checking where they're used currently [on Brian Birtles - due 2015-02-21].
-- adjourned --
shane: couple of minor issues
shane: some of these are adding
... another is what happens if the position is negative or exceeds the motion path length
... we've decidd that if it's a closed path it wraps, if it's an open path it clamps
... we have one about "more natual names" for auto and reverse
... an issue about how to get the position in more detail
... an issue about path transform computation needing to be more explicit
... and finally do we need to specify an origin of an element in motion so it can be positioned appropriately
... I think of all of those, the only ones we don't have a good answer for is the origin one
... I think we should just use transform-origin in this case
... it says in the issue we probably shouldn't, but we should!
... the motion is going to end up in the transform list anyway
cyril: a problem is that the
motion animation is an additional transform
... you could combine those two; if you think they have the same origin...
shane: the motion path spec isn't
a clean drop in replacement for animateMotion
... you need to be careful about order of application
... and origin setting
... so this is more what the origin should be for a specified motion path use should be
... I think the simplest thing to do is make it the same as transform-origin
... if you're generating equivalent behaviour for <animateMotion>, you might need to fiddle with some translations
krit: I think we will state this
usse on the mailing list again
... but here we just want to note all the open issues
shane: in the absence of
significant discussion, I would say transform-origin we should
... given this is the only substantive issue, I am asking whether we should we can have a FPWD of motion animation
RESOLUTION: We agree on a FPWD of Motion Path Module Level 1.
-- adjourn for real --
RRSAgent: make minutes
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/prens/parens/ Succeeded: s/Porilfe/Profile/ Succeeded: s/SVG// Succeeded: s/Tav/jet/ Succeeded: s/.../Tav/ Succeeded: s/.../Tav/ Succeeded: s/fine/fine with it/ Succeeded: s/taht/that/ Succeeded: s/masking.html, issue 3/masking.html, issue 2/ Succeeded: s/Rossen/Rossen:/ FAILED: s/Rossen,/Rossen:/ Succeeded: s/Rossen,/Rossen:/ Succeeded: s/What about ICC?/will icc-color be part of the <color> grammar in css?/ Succeeded: s/with/width/ Succeeded: s/RESOLVE:/RESOLUTION:/ Succeeded: s/birtles: what about variable stroke width?/someone: what about variable stroke width?/ Succeeded: s/dagshin/dashing/ Succeeded: s/taht/that/ Succeeded: s/use/<use>/ Succeeded: s/(Tav)/TabAtkins/ Succeeded: s/Interactivity/Embedded content/ Found Scribe: Cameron Found ScribeNick: heycam Found ScribeNick: ed Found Scribe: Nikos Inferring ScribeNick: nikos Found ScribeNick: nikos Found Scribe: tav Inferring ScribeNick: Tav Found ScribeNick: Tav Found Scribe: Cameron Found ScribeNick: heycam Found Scribe: Tav Inferring ScribeNick: Tav Found ScribeNick: Tav Found Scribe: Cameron Found ScribeNick: heycam Found Scribe: BogdanBrinza Inferring ScribeNick: BogdanBrinza Found ScribeNick: BogdanBrinza Found Scribe: Cameron Found ScribeNick: heycam Scribes: Cameron, Nikos, tav, BogdanBrinza ScribeNicks: heycam, ed, nikos, Tav, BogdanBrinza Default Present: +61.2.933.6.aaaa, Doug_Schepers Present: +61.2.933.6.aaaa Doug_Schepers WARNING: Fewer than 3 people found for Present list! Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Agenda_proposals WARNING: Date not understood: Fri Feb 13 22:13:02 2015 +1100 Got date from IRC log name: 12 Feb 2015 Guessing minutes URL: http://www.w3.org/2015/02/12-svg-minutes.html People with action items: brian cameron cyril ed heycam jean-claude krit tabatkins tav[End of scribe.perl diagnostic output]