W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2014

minutes, SVG WG London F2F 2014 minutes, day 2

From: Cameron McCormack <cam@mcc.id.au>
Date: Sat, 23 Aug 2014 18:14:18 +0100
Message-ID: <53F8CBEA.50206@mcc.id.au>
To: "www-svg@w3.org" <www-svg@w3.org>


       [1] http://www.w3.org/

                                - DRAFT -

                          SVG WG London F2F 2014

23 Aug 2014


       [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


           Rossen, Jonathan, Chris, Doug, Erik, Cameron, Tav, Dirk,
           Rik, Nikos, Brian, Konno


           krit, cabanier, heycam


      * [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



    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


      [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

    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
    ... .. 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
    ... 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

    heycam: are there perf improvements with using types instead of

    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

    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

    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%3E.

    <heycam> ACTION: Make topic scripts capture actions and issues
    too. [recorded in

    <trackbot> Error finding 'Make'. You can review and register
    nicknames at

      [15] http://www.w3.org/Graphics/SVG/WG/track/users%3E.

    <heycam> ACTION: Cameron Make topic scripts capture actions and
    issues too. [recorded in

    <trackbot> Created ACTION-3646 - Make topic scripts capture
    actions and issues too. [on Cameron McCormack - due



    <heycam> ACTION: Cameron to add math for Catmull-Rom curves to
    the spec [recorded in

    <trackbot> Created ACTION-3647 - Add math for catmull-rom
    curves to the spec [on Cameron McCormack - due 2014-08-30].

    <heycam> ACTION-3647:


    <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


    cam: I added a section on Catmull-rom to the spec

    <heycam> heyheycam has joined #svg


      [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
    ... 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

    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
    ... 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
    ... for instance 'y' and possible reuse the catmull rom
    ... 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

    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


    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

    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



    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

    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?



    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

    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


      [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
    ... 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
    ... 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

    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
    ... 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
    ... <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
    ... 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

    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

    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
    ... 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
    ... 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


      [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

    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

    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

    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
    ... 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
    [NEW] ACTION: Cameron to add math for Catmull-Rom curves to the
    spec [recorded in
    [NEW] ACTION: Make topic scripts capture actions and issues
    too. [recorded in

    [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/

      [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
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:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:56 UTC