- From: Cameron McCormack <cam@mcc.id.au>
- Date: Sat, 23 Aug 2014 18:14:18 +0100
- To: "www-svg@w3.org" <www-svg@w3.org>
http://www.w3.org/2014/08/23-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG WG London F2F 2014
23 Aug 2014
[2]Agenda
[2] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda
See also: [3]IRC log
[3] http://www.w3.org/2014/08/23-svg-irc
Attendees
Present
Rossen, Jonathan, Chris, Doug, Erik, Cameron, Tav, Dirk,
Rik, Nikos, Brian, Konno
Regrets
Chair
Cameron
Scribe
krit, cabanier, heycam
Contents
* [4]Topics
1. [5]Getting rid of uses of const enums in SVG DOM
2. [6]Raw cubic bezier coordinate list accessors
3. [7]Catmull-Rom
4. [8]Parameterised SVG
* [9]Summary of Action Items
__________________________________________________________
<krit> scribeNick: krit
Getting rid of uses of const enums in SVG DOM
ed: Ties in tinto disucssion yesterday
... would get rid of const enums from SVG DOM
... might fall out of SVG DOM removal
... I prefer replacing it by simple DOMStrings
... I am concerned about new units getting new values
... we did not expose these new values
... this causes complexity in implementation. which values are
exposed, which aren't
... do we want do wait until we experimented with removing SVG
DOM first?
heycam: would be interesting what is kept
... SVGTransform has individual enums as does SVGPath
... interested if they are used and useful
krit: no
ed: there are convertTo methods on SVGLength for instance
... same for SVGAngle and others
heycam: preseverveAspectRatio
krit: filters have a lot of these enumeration
heycam: we should keep SVGLength around every though we remove
SVGAnimated objects
<heycam>
[10]http://www.w3.org/TR/SVG/types.html#__svg__SVGLength__conve
rtToSpecifiedUnits
[10]
http://www.w3.org/TR/SVG/types.html#__svg__SVGLength__convertToSpecifiedUnits
krit: don’t think that there is
heycam: there are some conversions used in SVGLength
krit: point is, people just convert to px
heycam: If you are able to remove SVGLength all together then….
krit: we should discuss enums in isolation from SVG DOM removal
heycam: yeah
ed: should we do it in addition?
heycam: in addition would be easy
... we could have type()
... and take then IDL enum type
ed: I added a unit turn to SVGAngle which is not exposed as an
enum value in Blink
krit: for SVGLength alone we have a huge amount of new units
... which enumerations are you thinking about? In all IDL files
or all of them?
ed: everywhere
... and use new unit types
... also, there is no way to know if an implementation is
supporting certain units
heycam: could create a new SVGAngle object
... and apply “7turns"
... and look at the unit less value and look if it is 7
krit: for a short term it is reasonable
heycam: I wonder how many improvements should we do before
knowing if we remove SVG DOM or not?
krit: Implementations removing SVG DOM now, obviously don’t
need to care. The spec can still be ahead and change SVG DOM in
case experiment fails
ed: we have the existing method take a number or string
... can you have multiple types on a property with WebIDL?
heycam: yes
<heycam>
[11]http://dev.w3.org/SVG/proposals/improving-svg-dom/#enumerat
ions
[11] http://dev.w3.org/SVG/proposals/improving-svg-dom/#enumerations
krit: sure you want a string and not a enum value in the sense
of WebIDL
heycam: I think you do
krit: they are still basically string with special exception
handling
ed: yes, that is what i want
heycam: still wonder if it is worth to do now
ed: I think it is ok to have it in parallel
heycam: if we need to keep the object around and have new
stuff….
... .. in my proposal I had a hard cut
... I suppose it makes sense if we need to keep SVG DOM
ed: I would still go ahead with both,… experimenting with
removing SVG DOM and implement the new enum
krit: so you suppoty old enums and the new? where is the
benefit for you? complexity stays?
ed: so I will probably remove the old const enums and replace
it with new enums
krit: if you break the old one… do you think it is worth still
having enums at all? will ppl move over?
ed: seeing where the experiment goes probably makes more sense
... ok, I’ll bring up the topic again
Raw cubic bezier coordinate list accessors
birtles: proposal was to add a method to get the points of a
path as an array of dicts
... we talked about details in the past… open vs closed paths
... tow motivations: simplicity
... and performance
... in many implementations there is a perf hit from switching
from JS to native code
... with Cameron’s DOM we get a bunch of dict objects as an
array
... performance is less significant
Tav: can you handle arc?
birtles: approximations
... didn’t work out on details
Tav: how about markers
birtles: doesn’t take markers into account just path data
... same data structure for setting and getting on path
generation
heycam: are there perf improvements with using types instead of
arrays?
birtles: no
... I can still shim and implement it
heycam: do you have comparisons between my proposal and yours?
birtles: we can do that fairly easy
... seems worth while investigating
... question if we bother at all
heycam: think it is reasonable
... think the normalization is nice
birtles: we also do not implement normalized path segments in
Mozilla
ChrisL: why?
krit: heycam: difficult to keep live objects in synch
birtles: also, it is an array of arrays
... because of subpaths
krit: I think for normalization you don’t care too much about
precise results, but you want to have the same amount of
segments with the same order
... that is where Opera Presto and WebKit behave totally
different sometimes
shepazu: we should say how a basic shape transforms into a path
heycam: I didn’t do that yet
Tav: we had the discussion at least
krit: didn’t you do that for dash array heycam ?
<Rossen_> can somebody let me into the bldg please
heycam: yes, it would be a reason to support it
shepazu: do you have anything about animating shapes?
birtles: really do want to do that
shepazu: we are not going to make it perfect :)
... lets pick it up another time
<Tav> [12]http://tavmjong.free.fr/blog/?p=741
[12] http://tavmjong.free.fr/blog/?p=741
action birtles Try implementing path data array and get
performance numbers
<trackbot> Created ACTION-3645 - try implementing path data
array and get performance numbers [on Brian Birtles - due
2014-08-30].
ISSUE: look into shape morphing
<trackbot> Created ISSUE-2461 - Look into shape morphing.
Please complete additional details at
<[13]http://www.w3.org/Graphics/SVG/WG/track/issues/2461/edit>.
[13] http://www.w3.org/Graphics/SVG/WG/track/issues/2461/edit%3E.
<heycam> ACTION: Make topic scripts capture actions and issues
too. [recorded in
[14]http://www.w3.org/2014/08/23-svg-minutes.html#action01]
<trackbot> Error finding 'Make'. You can review and register
nicknames at
<[15]http://www.w3.org/Graphics/SVG/WG/track/users>.
[15] http://www.w3.org/Graphics/SVG/WG/track/users%3E.
<heycam> ACTION: Cameron Make topic scripts capture actions and
issues too. [recorded in
[16]http://www.w3.org/2014/08/23-svg-minutes.html#action02]
<trackbot> Created ACTION-3646 - Make topic scripts capture
actions and issues too. [on Cameron McCormack - due
2014-08-30].
<Tav>
[17]https://stackoverflow.com/questions/9489736/catmull-rom-cur
ve-with-no-cusps-and-no-self-intersections/23980479#23980479
[17]
https://stackoverflow.com/questions/9489736/catmull-rom-curve-with-no-cusps-and-no-self-intersections/23980479#23980479
<heycam> ACTION: Cameron to add math for Catmull-Rom curves to
the spec [recorded in
[18]http://www.w3.org/2014/08/23-svg-minutes.html#action03]
<trackbot> Created ACTION-3647 - Add math for catmull-rom
curves to the spec [on Cameron McCormack - due 2014-08-30].
<heycam> ACTION-3647:
[19]https://stackoverflow.com/questions/9489736/catmull-rom-cur
ve-with-no-cusps-and-no-self-intersections/23980479#23980479
[19]
https://stackoverflow.com/questions/9489736/catmull-rom-curve-with-no-cusps-and-no-self-intersections/23980479#23980479
<trackbot> Notes added to ACTION-3647 Add math for catmull-rom
curves to the spec.
<heycam> ACTION-3640: This should be done for symbol, marker
and foreignObject.
<trackbot> Notes added to ACTION-3640 Add |symbol { overflow:
visible; }| to the ua style sheet and add authoring suggestion
to say to design symbols around (0,0).
<heycam> -- actions session --
<heycam> fg
<ed> bg
<ed> ^C^C^C
<ChrisL> issue-59?
<trackbot> Sorry, but issue-59 does not exist.
<ChrisL> issue-58?
<trackbot> Sorry, but issue-58 does not exist.
<cabanier> scribenick: cabanier
Catmull-Rom
cam: I added a section on Catmull-rom to the spec
<heycam> heyheycam has joined #svg
<heycam>
[20]https://svgwg.org/svg2-draft/paths.html#PathDataCatmullRomC
ommand
[20] https://svgwg.org/svg2-draft/paths.html#PathDataCatmullRomCommand
cam: syntax wise, I added just what Doug's polyfill said
... you need 3 coordinates
... the curves take a sequence of point and the path goes from
the second control point to ???
shepazu: in my implementation, the first point is the moveto
and the last 2 points are the same
... technically it needs an extra control point
(lots of discussion at the whiteboard)
shepazu: I suggest that we have 2 point
heycam: I think it should be a minimum of 1 point
shepazu: then it should be a line
... I agree that it should only be 1 point
heycam: the spec at the moment, if the previous is a moveto...
ChrisL: I think there should be a minimum of 2. (draws on
whiteboard)
... you always need 4 points
... you always go between 2nd and third point
... you make up first and last by doing the tangent
... you always start drawing from the first point
... you can do a fictitious last point
shepazu: the point you start from is the last point from the
previous
heycam: it's the current point
ChrisL: yes
... currentpoint is inferred
ed: what would it look like if you do a circle
Tav: would 4 points make a circle?
shepazu: I don't think so?
Tav: how do I close the path?
ChrisL: closepath will be a straight line
... to do it smoothly we need a different symbol
... which is a new requirement
shepazu: I don't agree
... that is not the point of this
ChrisL: suppose you draw a set of CR pieces, he wants a new
command that does the continuity
shepazu: so, I understand what Tav is asking for but I'd rather
not take on that requirement since it makes the model so
complex
... you can do it. we don't have it for beziers
ChrisL: I don't agree. you just get the data differently
shepazu: I would like to split it into 2 different issues
... CR and the issue of soft closing
... I can see a reasonable additional command that closes
smoothly
... for instance 'y' and possible reuse the catmull rom
algorithm
... we rejected tangient parameter to keep it simple
... we just want point
<krit> RRSAgent: q+
Tav: in order to make a closed path you might need to choose
... given a circle a, b,c,d you may want to consider point d to
do a smooth close to point a
... you might want to consider d to a, to draw a to b
shepazu: why do you want it to be a circle?
tav: I don't. it can be any shape
shepazu: rather than treat this a catmull-rom curve, let's call
this a smooth closed path
... and it would act differently if it was a bezier
ChrisL: not quite
shepazu: catmull rom is the only one where the previous point
changes the next point
(more heated discussion)
heycam: if you have beziers it's not always possible to
calculate the point
krit: why does inkscape need it?
Tav: it doesn't
krit: as an implementor, I don't need this and wouldn't
implement
ChrisL: are you making an informed decision?
krit: can you do it today with bezier?
ChrisL: given an arbitrary sequence of points can you today
make a smooth curve through them?
heycam: yes, we can use beziers.
ChrisL: and the group agreed to do it
krit: that doesn't really matter.
ChrisL: so you don't want new features in SVG?
<Rossen_> The circle of Tav
[21]https://onedrive.live.com/redir?resid=DA0535041C44EB4D!2632
7&authkey=!AL_LeXmaTwrSbZc&v=3&ithint=photo%2cjpg
[21]
https://onedrive.live.com/redir?resid=DA0535041C44EB4D!26327&authkey=!AL_LeXmaTwrSbZc&v=3&ithint=photo%2cjpg
krit: I didn't say that?
ChrisL: are you opposed to new features
jwatt: are you against bezier curves?
Tav: it's about authors just doing smooth graphs
... and I'm against it because it will be used incorrectly
ChrisL: people can do a lot of things wrong
krit: is catmull rom the best algorithm?
... it's the most known
shepazu: and the easiest to do
... but it's not trivial to do
krit: but you can do it with bezier unlike with line to
approximate beziers
shepazu: I'd like to stay with the resolution that we'll
implement this
... everytime I mention this, people like it
... authors have asked for this
... what is the point of your objection?
... if you have a better implementation, please put it forward
krit: I think we have primitives to do this.
shepazu: let's not waste f2f time on this
krit: there's no proposal.
... we've discussed this many times already
shepazu: that is inaccurate. you're trying to knock us back
ChrisL: we have a formula and a couple of issues
heycam: I think we should talk about the issues
shepazu: the smooth close path is a separate issue
ChrisL: agreed
shepazu: I would be ok to do a smooth closed path command
tav: inkscape has that problem, but I don't want to distract
... a smooth bezier to catmull-rom transition
... you can get the first point from the handle
ChrisL: I propose that we'll just address the issues
... should we add a tension parameter?
resolution: Catmull-Rom will not add a tension parameter and
will stay with the standard
... Catmull-Rom will not add a tension parameter and will stay
with the standard parameters
... should we allow less than three coordinate pairs?
heycam: if you're building up a path, you need them
<shepazu> [22]http://schepers.cc/svg/path/dotty.svg
[22] http://schepers.cc/svg/path/dotty.svg
ChrisL: as long as we define what it is so we don't get
degenerate behavior
... one point is a straight line from the current point
... two points will give you a smooth curve
RESOLUTION: the r command will take at mimum 1 coordinate pair
that will draw a straight line
ChrisL: issue 8 is no longer a problem then
... the moving without drawing anything was solved by the
previous resolution
<ed> (for reference, issue 8 was: "Is it a problem that the
command will move then pen from the current position to (x1,
y1) without drawing anything? If so, should we made the first
control point explicit in the command rather than implicitly
taken from the current position? That would then mirror the
behavior written above for how the current position is left at
the second-last control point.")
heycam: I think it's more about having the implicit points
ChrisL: we now move what multiple r commands means
... a single r with give you continuity
... by having multiple ones, you will not get the continuity
shepazu: I don't really like that. it's a bit confusing
ChrisL: if it didn't have that behavior it would act as if it
was one command
heycam: I think I prefer that each r is its own smooth curve
Tav: bezier to catmull rom needs a way to break it
ChrisL: can we agree that we don't get continuity
heycam: a new r command will not be continuous with the
previous?
shepazu: I agree with that
RESOLUTION: multiple R commands will not have curve continuity
between them
ChrisL: issue 9: Where should we link to for a definition of
Catmull-Rom curves so that we don't have to redefine them here?
... there's a wikipedia with the math
heycam: there were a couple of different options
<ChrisL>
[23]http://en.wikipedia.org/wiki/Centripetal_Catmull%E2%80%93Ro
m_spline
[23]
http://en.wikipedia.org/wiki/Centripetal_Catmull%E2%80%93Rom_spline
heycam: mostly about the implicit begin and end points
Tav: they're mostly about how to avoid loops
ChrisL: I propose to use the Centripetal one from the wikipedia
article
heycam: I think that's a good idea
... I'm going to read up on it
... do we want the formulation that doesn't introduce the loops
and cusps?
<heycam>
[24]https://stackoverflow.com/questions/9489736/catmull-rom-cur
ve-with-no-cusps-and-no-self-intersections/23980479#23980479
[24]
https://stackoverflow.com/questions/9489736/catmull-rom-curve-with-no-cusps-and-no-self-intersections/23980479#23980479
RESOLUTION: catmull-rom will use the formula that doesn't
introduce the loops and cusps
Tav: the stackoverflow with the six votes is the one we want
shepazu: can we also put in the spec on how to deform this to
beziers?
heycam: we don't have to do that
... informally, it might be good to have it
shepazu: can we call it 'p' instead of 'r'?
heycam: it doesn't really matter
ChrisL: sure
jwatt: I want more than one letter
ChrisL: people don't really care
heycam: people will just fiddle with it
RESOLUTION: the name of the Catmull-Rom command is 'p'
reflecting 'points'
heycam: one final issue is that we should decide that we get
the implicit points from the tangent
shepazu: wasn't there a good pdf?
ChrisL: yes, I will drop it in
<ChrisL>
[25]http://www.cemyuksel.com/research/catmullrom_param/catmullr
om.pdf
[25] http://www.cemyuksel.com/research/catmullrom_param/catmullrom.pdf
heycam: this does limit the set of curves that you can produce
shepazu: I would contend that you're not looking for precision
but convenience
heycam: that's reasonable
... so, at the start of the p command and the previous is a
curve, how do you determine the preceding point?
... if it's cubic or quadratic, since we have the control
point, we will use that
... if we don't, we continue the line and use the point from
the same distance
cabanier: do you need to remember an extra point?
heycam: you have to do that anyway
... to summarize: if you have a previous command other than
'p', the implicit first point is based on the tangent just
preceding the curve
... you always know the one coming in if it's a line or curve
shepazu: can you come back with a more concrete proposal?
heycam: I'll make an issue in the spec
<heycam> ScribeNick: heycam
Parameterised SVG
jwatt: we have a need that I want to discuss
... it stems from Firefox OS people who need performance, and
keep memory usage down -- they use icon fonts
... I'd like to move them away from icon fonts towards using
SVG
... I ran through some alternatives to make performance of
SVG-in-<img> enough for their needs
... I think we can get close to that, but one thing they want
is to be able to do what they do with icon fonts
... the color font on the <span> element they apply the font
to, can be used to style the content of the icon
... right now we have no mechanism to do that
ChrisL: not any style across that boundary
jwatt: they want to have a way to reference out of the SVG to
get a computed value
... or pass it in, either way
... they want to do it with CSS selectors, so set a property on
it
... rather than like the params spec, where you have to add
something to the query string or param elements
heycam: why?
jwatt: because that's going to be more convenient to theme
things
shepazu: the way I've rethought parameters, in the context of
CSS Variables --
... params consisted of two things. the way to specify how you
pass the things into the file, the second was how to propagate
those values and use them in the file
... they're two separate problems
... I think Variables are probably good enough for the second
half
... I'm proposing we're left with the problem of the behaviour
of passing the values in, and/or having implicit behaviour
... I don't care if parameters are explicitly declared, or if
you can implicitly extract them from the context
... both seem reasonable to me
krit: my question first is, does it need to be <img>? can it be
<object>?
... <img> has security implications
... the webapps sec wg asked us not to have selectors
... you could change the appearance of things in the document,
and thus time things
... <object> doesn't have these restrictions
... not only timing attacks, but tricking with the appearance
shepazu: [explains the :visited style restriction]
jwatt: a mechanism other than the document reaching in and
styling stuff would be sufficient
shepazu: for the SVG document to be able to say what things
change under what circumstance
<ChrisL> itslike passing a bundle of computed style values
across the boundary for re-use in styling the image
jwatt: essentially what they need for parity with icon fonts,
is to be able to get the computed value of the color property
shepazu: currently in params you explicitly have a name/value
pair
... color=foo, foo=orange
... then in the image you use "foo"
... we could have keywords that say you want to pass in the
color and the background-color, then the SVG file says how to
use those
... my original proposal was saying name/value pairs, but now
you choose the set of values you pass in
... let's say the icon wants to use the background-color of the
page as the foreground color in the image
... and the color from the document as some accent in the icon
... on the outside you pass in background-color and color
... on the inside you use those two things whereever you need
them
heycam: [explains how context-fill and palette variable work in
SVG-in-OpenType fonts]
krit: people want to use @media queries based on width/height.
not sure if passing width/height into that would help with
that?
Rossen_: you could tie in the vw/vh values to that
shepazu: thinking outside the icon use case for a second
... [draws a spark line]
... I want to pass in the values in the spark line to the SVG
<img>
... not propose that we do this, but it's the sort of thing you
could allow if you support more than just color passing in
... two good things about icons, they take on the context size
and color
... but you can't pass in multiple styles, and they aren't
responsive
... if the icon is big I want more detail
krit: does it need to be <img>?
jwatt: for us we want it to be possible with <img> because we
are able to optimize <img> that we can't do with <object>
... we want to be able to get rid of as much memory as possible
for small devices
birtles: if it's <object> you can do it all in script anyway
heycam: unless it's cross domain
jwatt: our people want parity. so the parameterisation that
allows more than just style property mapping sounds like a
bigger thing to nail down.
shepazu: I have also heard from people wanting to use SVG as an
icon that at different sizes you get different crispness things
... when we're trying to solve icons as SVG that's another
thing to discus
<jwatt>
[26]https://svgwg.org/svg2-draft/intro.html#TermContextElement
[26] https://svgwg.org/svg2-draft/intro.html#TermContextElement
jwatt: is it acceptable to have the context element be the
<img> referencing the SVG?
heycam: I would say only if you opt in to that
krit: I agree
ChrisL: so maybe foo.svg#context-fill=currentColor
krit: can we just say the fill and stroke applied to the image?
they don't do anything on image
jwatt: it's problematic if you need an opt in
... well not sure how big a problem
... this person wants to be able to change style sheet to say
all img are fill:red
... he doesn't want to add something to each <img> element
... I want it to be opt in in the SVG, but not in the embedding
document
shepazu: I think both
... img { context-fill: currentColor; context-stroke: red; }
p { color: blue; }
<p> <img> ...
jwatt: what about one property that represents the set of
properties that can be accessed
... you could have a list of the properties
heycam: will-pass-through: color, background-color;
krit: you could also list a custom property
shepazu: "parameters" might be a good name for it
ChrisL: sounds like we have agreement on a principle, can
discuss the name
jwatt: what about same origin <img>s? can we avoid the opt in
from the outside?
... what about not having to write { pass-through:
context-fill, ... } for same origin images
... it would be less standardisation effort
shepazu: I'd like this to apply to other cases like <use>
krit: this is one specific use case from a pool of use cases
shepazu: I think the mitigating factor is that what jonathan is
asking for the minimal support for context-fill use in the
<img> document
... this is not going to restrict us from doing more expansive
things in the future
... this is just the simplest case of it
... so it doesn't lock us out of other solutions in the future
krit: I tend to agree
Rossen_: I'm not sure. I wanted to get back to the opening
remarks -- you're after this because of performance and memory
pressure from using fonts?
jwatt: no, fonts is good. I want embedded SVG closer to the
performance of fonts.
... this is so they can do theming of icons without having to
go through each icon element
Rossen_: so the performance memory relief will come later on
jwatt: yes that's a different thing
... if the feature parity barriers are eliminated, then there
is value in us pushing memory usage down
ChrisL: one obvious benefit from icon fonts is you get them all
from one file
jwatt: you can use fragment IDs to get that same benefit
<ChrisL> yes, agreed using fragment ids
krit: presumably you share images across documents. is it safe
to share these across?
jwatt: that's an implementation detail for us to make sure it's
not possible to get the wrong images in other documents
... so for now I want to go ahead with same origin
context-fill/context-stroke with <img> being the context
element
shepazu: short of us thinking through that the expanded uses
are ok, we can agree that it will be ok with <img> same origin
krit: is there something we need from the HTML WG on this?
heycam: probably not
krit: worried about others saying no after jwatt goes ahead
with this
Rossen_: I wouldn't necessarily object to it, I'm just not sure
if/how sufficient this is
ed: I agree with Rossen. I've used params myself for passing
strings e.g. across, that wouldn't be covered by this
heycam: would we do this for all of the context-* values?
jwatt: would think for consistency it would be all
shepazu: maybe just limit it to context-fill/context-stroke for
now
jwatt: I don't think the spec decisions should be driven by
Firefox OS deadlines
Rossen_: if the general intent was to probe the temperature for
this, I wouldn't stop with proceeding
... with your implementation
... push it to your nightlies, tryi t out
... to reiterate your situation, you want to start driving on
perf
... to do this you need to allow this one property passing
... try it out
... I don't think there's strong pushback
Summary of Action Items
[NEW] ACTION: Cameron Make topic scripts capture actions and
issues too. [recorded in
[27]http://www.w3.org/2014/08/23-svg-minutes.html#action02]
[NEW] ACTION: Cameron to add math for Catmull-Rom curves to the
spec [recorded in
[28]http://www.w3.org/2014/08/23-svg-minutes.html#action03]
[NEW] ACTION: Make topic scripts capture actions and issues
too. [recorded in
[29]http://www.w3.org/2014/08/23-svg-minutes.html#action01]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [30]scribe.perl version
1.138 ([31]CVS log)
$Date: 2014-08-23 17:11:50 $
__________________________________________________________
[30] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[31] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11
Check for newer version at [32]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/no don’t want to do that/really do want to do that/
Succeeded: s/cam/heycam/
Succeeded: s/wikipedia/stackoverflow/
Found ScribeNick: krit
Found ScribeNick: cabanier
Found ScribeNick: heycam
Inferring Scribes: krit, cabanier, heycam
Scribes: krit, cabanier, heycam
ScribeNicks: krit, cabanier, heycam
Present: Rossen Jonathan Chris Doug Erik Cameron Tav Dirk Rik Nikos Bria
n Konno
Agenda: [33]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agen
da
Got date from IRC log name: 23 Aug 2014
Guessing minutes URL: [34]http://www.w3.org/2014/08/23-svg-minutes.html
People with action items: cameron make
[33] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda
[34] http://www.w3.org/2014/08/23-svg-minutes.html
WARNING: Possible internal error: join/leave lines remaining:
<heycam> heyheycam has joined #svg
WARNING: Possible internal error: join/leave lines remaining:
<heycam> heyheycam has joined #svg
[End of [35]scribe.perl diagnostic output]
[35] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Saturday, 23 August 2014 17:15:07 UTC