W3C home > Mailing lists > Public > www-svg@w3.org > February 2013

minutes, SVG F2F Pymont, Sydney day 5 (08/02/2013)

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 08 Feb 2013 16:49:15 +1100
Message-ID: <511491DB.8070704@mcc.id.au>
To: "www-svg@w3.org" <www-svg@w3.org>

And as text below:


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

                                - DRAFT -

                     SVG Working Group Teleconference

07 Feb 2013

    See also: [2]IRC log

       [2] http://www.w3.org/2013/02/07-svg-irc


           +1.408.536.aaaa, +61.2.937.4.aabb, GoogleMeetingRoom,
           +1.781.970.aacc, Vlad




      * [3]Topics
          1. [4]SVG in OpenType spec proposals
          2. [5]next f2f
          3. [6]Proposed combined Matrix interface
          4. [7]Matrix continued
          5. [8]Multiple strokes
          6. [9]SVG requirements list culling continued
      * [10]Summary of Action Items

    <trackbot> Date: 07 February 2013

    <scribe> scribe: Cyril

SVG in OpenType spec proposals

    <ed> scribeNick: Cyril

    <heycam> Zakim: who is on the call?

    heycam: as a bit of background, we met with Sairus a year ago
    at Microsoft and we discussed in persons
    ... some issues regarding the SVG in OpenType proposal
    ... I recently started looking at it
    ... in the meantime Sairus has suggested some spec text
    ... and I thought a good way to engage and resolve differences
    was to write down what we have in our implementation
    ... and start to converge both proposals
    ... I'm not looking for any decision today
    ... I don't want to publish
    ... now
    ... edwin who worked on the implementation as an intern
    ... wrote down the behavior that we have
    ... last week I turned the description more like a spec
    ... and sent it to the list last week


      [11] http://dev.w3.org/SVG/modules/fonts/SVG-OpenType.html

    <heycam> That's Edwin's and my write up.



    <heycam> That's Sairus' write up.

    heycam: I think they are not terribly different
    ... there are a few main differences
    ... I've not listed them
    ... do you want to discuss them?

    krit: the number of SVG documents is a good start

    heycam: I think Robert said on the ML and gave some reasons to
    support multiple documents
    ... in our proposal you have an index of byte ranges that
    correspond to each document
    ... and you indicate which range of glyphs are in the document

    <sairus> nick: sairus

    heycam: I believe in Sairus' proposal there is a single
    offset/length pair to indicate where the single compressed
    document is

    sairus: I sent a report
    ... the pros and cons of the multiple svg documents
    ... has been discussed
    ... and a new pro was subsetting glyphs
    ... I think the multiple svg documents approach has multiple
    pros (multiple dictionnaries ...)
    ... emoji in one document
    ... latin in another document
    ... the issue of timeline has been brought against, not to go
    ... I don't know how you feel about the timeline stuff in the
    proposal from last Friday
    ... If we go with multiple documents it is fine with me

    heycam: the main advantage I can think of
    ... splitting avoids the overhead of having one document
    ... for all of the glyphs in the document
    ... you probably want to split the document to reduce the
    number of glyphs active

    sairus: I can imagine big fonts and relate problems

    AlexD: you can also cache easily
    ... caching part of a document is different

    cabanier: the proposal is not to have one document per glyph?

    heycam: not explicitely, it would be good to have guidelines to
    explain how to structure documents

    cabanier: yes because resource sharing is a problem

    heycam: resource sharing is not adressed in my document
    ... there would be no way to share across documents, we could
    define extra tables with URI (blob or multi part)
    ... I'm not sure it's worth at this point

    AlexD: there is no problem with the one document approach, but
    it's more work to use existing font cache

    krit: I'm not sure the font engine would be used for SVG

    AlexD: I would hope they are used, because of performances
    ... we should be thinking of speed and performances

    heycam: there is a difference between reusing existing font
    cache mechanism and designing a new one

    sairus: by subsettability I meant that you can create a font
    with just 5 glyphs
    ... for embedding in another document

    heycam: I remember us dicussing that last time, in one
    document, subsetting changes the document order and so style
    might be affected
    ... it's not trivial

    cabanier: what kind of style would be affected ?

    AlexD: nth child

    cabanier: I thnk the font should be independent of the number
    of child

    heycam: the styling of any element shouldn't change if you
    remove any element

    cabanier: yes, maybe
    ... if you use the 5th letter, it's not going to be the 5th

    heycam: but presumably you are writing styles because they make
    sense with the document

    AlexD: that should be strongly discouraged

    heycam: the work to be done wouldn't be too bad

    sairus: subsetting complexity is already there in truetype
    ... a subsetter has to follow dependencies in truetype
    ... guidelines for SVG may be needed, but you have to take
    TrueType complexity into account

    cabanier: I don't think there is an issue with the order

    heycam: I would be happy with a warning to authors to avoid
    styling documents that change with order
    ... and also warn them to do subsetting properly

    cabanier: what happens if you open that svg file

    heycam: you could set the viewport to view something
    ... you could structure your document to view the svg in some

    cabanier: or use style= display none

    heycam: display none on an ancestor of the glyph definition
    ... I woud want to behave just like use
    ... use elements are displayed even if display none is set on
    the referenced ancestor
    ... one of the big differences btw the 2 proposals, is that you
    have it compressed, we don't
    ... what happens when you serve a document, it may be

    AlexD: WOFF is compressed

    sairus: any place fonts can be embedded there are ways to
    compress with more than WOFF or HTTP compression

    AlexD: we should mandate compression if we allow it, it
    shouldn't be optional

    heycam: agree
    ... It might make it difficult to pass to the XML parser
    ... you have to allocate the uncompressed version in memory

    AlexD: no you decompress it and stream it to your parser

    heycam: I don't have any fundamental objections with having the
    tables compressed
    ... I assumed it was simpler not to

    nikos: one of the other differences is the SVG glpyh class
    ... this is a nice thing

    heycam: yes this is the other major difference

    nikos: it allows you to know if the glyph is present without
    loading the file

    sairus: it is a cache
    ... I defined it to know which glyphs were defined with SVG in
    this font
    ... you could imagine clients that don't support animation
    would appreciate to know it upfront

    heycam: our table has index entries to say which documents
    cover which glyphs
    ... it doesn't say if the glyph is there, if it is, it has to
    be in this document
    ... so you'd have to open it
    ... the glyph range could be more than the glyphs in the
    ... there might be holes in the range

    the table doesn't define the holes

    scribe: say a single document, range 1 to 64000 but with only
    one glyph in it

    sairus: the issue is that it involves calling the svg renderer
    ... we should make it simple for clients to take the first step
    ... really making it easy, no parsing unless they have to

    heycam: I feel the distinction animated/static and determining
    if a glyph is there at all are two different things
    ... right now, you have to search the glyph id
    ... I can see the benefit of having the right range in the
    ... I think the sharing is a separate thing as well

    sairus: we want to be precise in the index table entry

    heycam: I think ti would be better with your proposal

    ed: when you define you SVG glyph can you reference data coming
    from the CFF or glyph tables

    sairus: go across glyph technologies ?
    ... so far they've been seen as mutually exclusive

    heycam: no proposal have this feature

    sairus: I can see it would be useful, for instance style with
    CSS normal glyphs

    ed: I could see use cases were you want multi colored glyphs
    without duplicating the glyph data

    heycam: it would require special adressing

    Cyril: fragment identifiers ?

    sairus: it is probably not worth adding the complexity

    heycam: I'm sure it would be possible to make it work

    <Vlad> Would SVG renderer allow importing binary outline
    descriptions into XML-based SVG document? IF not, I don't <yet>
    see a use case for this references

    <Cyril_> cabanier: is it written that you can't write reference
    to external resources?

    <Cyril_> heycam: yes

    <Cyril_> sairus: could be an extension in the future, not
    required for v1.0

    <Cyril_> heycam: (reading vlad's comment)

    <Cyril_> Vlad: you would need to import them ?

    <Cyril_> Vlad: without being able to enforce it, I don't see
    the use of the reference

    <Cyril_> heycam: the advantages I could see, is avoiding to

    <Cyril_> ... it's basically an optimization

    <Cyril_> ... you'd have to define how path animations would

    <Cyril_> cabanier: hinting is another thing

    ed: I don't think all browsers apply hinting if the outlines
    are fetched for rendering (depending on scale)

    heycam: I feel like it is a reasonnable way to support animated
    and non animated with the same definition
    ... you render the document without the animation element
    ... I might have written a tiny example, how you could animate
    a circle radius to 10 and back
    ... for the non animated version, you ignore the animation and
    render the r attribute base value

    cabanier: you limit yourself to the non animated case as a

    birtles: you could have a set that turns the glyph to something
    different at the beginning

    sairus: I think both main proposals have converged to having a
    single glyph definitions and you render the animation or not
    ... just like when you print an animated svg document

    heycam: people design graphics in this way for viewing animated
    content in IE
    ... there is a way to switch on to some different graphics

    Cyril: I don't know what we have decided with the snapshotTime

    birtles: this requires to apply the animation

    AlexD: yes, you need more than a static engine
    ... I don't think snapshotTime is a very good tool for that

    heycam: if an app using the font wants to say render the font
    statically with a snapshot time
    ... they'd be able to do that

    <heycam> ScribeNick: heycam

    shepazu: when I was reading the font spec… what file are the
    fonts defined in?

    … are they defined in the file that is the font file?

    … or can they be external?

    AlexD: they would be in the font file

    shepazu: it seems almost arbitrary that they need to be in the
    font file, rather than the document that is being rendered

    … what's the limitation that says we can't reference them

    … in which case how does this save us anything from SVG Fonts
    as they are defined?

    cabanier: it's backward compatible; the user doesn't know it's

    … the font just renders

    shepazu: but isn't that also the case with what I said?

    cabanier: this is not just for HTML, but everywhere

    shepazu: one of the use cases I get mailed off list, is that
    people like to be able to define the SVG font in the file

    <Cyril> heycam: the advantage of not having them in the
    document is to not be able to modify them at runtime

    <Cyril> shepazu: it should be explicit in the spec

    <Cyril> AlexD: the big reason is to support complex scripts

    <Cyril> ... there is no advantage for latin

    <Cyril> ... svg fonts can be external documents

    <Cyril> scribenick: Cyril

    heycam: if there are particular reasons why we are choosing
    this model, it should be clarified

    Vlad: this is not really going to be part of the SVG spec
    ... this is going to be in the OpenTYpe spec

    AlexD: it opens up the possibility of HTML to use SVG for text

    ed: but you can already use SVG fonts with HTML

    sairus: next point, I'd like to discuss is
    ... so far the Adobe proposal doesn't change the SVG spec
    ... we want to ease the burden of implementations
    ... there are some aspects of the SVG spec that need to be
    changed in the Mozilla proposal
    ... the glyph id is it absolutely needed ?
    ... and the color by number schemes ?

    heycam: we've started to add the new paint values inSVG because
    they are useful in other context (markers)
    ... we have new keywords: context-fill and context-stroke
    ... you reference the text element that is using the glyph
    ... you can use them in the fill or stroke of the glyph

    sairus: in the proposal there is a single fill or stroke

    heycam: yes, no passing of arrays

    sairus: I can have the base of a lower case i be rendered with
    a color and the dot with another color

    heycam: you could define a gplyh with some parts filled in
    context fill and some other parts to be always red for instance

    <shepazu> (what about passing in "parameters"?)

    heycam: you can override with colors specified in the font

    AlexD: what about gradients ?

    heycam: context-fill uses the same gradient

    AlexD: a gradient right now can be applied to a chunk of text
    ... I don't see how you could do that with the glyph based

    heycam: we've made it work
    ... the rendering of the glyph is not passed to a font engine
    ... normal glyphs only
    ... svg glyphs we paint them ourselves



    heycam: so the gradient is smoothly applied to the run of text
    ... have a look at example 3

    cabanier: that's when the gradient is in the referencing
    document, and it would be different when the gradient is in the
    svg glyph document

    sairus: we'd like fonts to come with various swatches of
    predefined colors (extended to opacity ...) that go together
    ... and the tool would offer these color options
    ... each of them would have a name id
    ... so that the user interface could show them
    ... what would it take to do that?

    heycam: without having thought about it too hard, using CSS
    variables could be the way to do it
    ... how do you pass them in
    ... same thing as parameters

    sairus: are you saying the CSS thing could coexist with the
    context-fill and context-stroke ?

    heycam: when you have text in the outer SVG document (SVG text)
    you can fill and sttroke it. In HTML you can only fill, but
    there are discussion to have stroking
    ... I feel that those 2 operations are special
    ... separate parameterized palette entries

    Vlad: I support the use case that sairus presented
    ... we should make it stronger
    ... designers with specific colors in mind, wouldn't want these
    colors to be modified by the outside
    ... just like they don't want the outlines to be modified

    heycam: it is totally fine
    ... if you specify a fixed color value, that's it, can't be
    ... same thing for patterns

    sairus: stroking can alter the look of the glyph
    ... OpenType doesn't mention stroking
    ... OpenType gives an alpha mask and you're free to color it
    ... I'm not particularly convinced that context-stroke is

    heycam: for me, filling and stroking are the basic primitives
    that you can do to shapes

    cabanier: but you won't be able to stroke an svg glyph

    heycam: you will
    ... you will not stroke the outline
    ... you need to construct the document with stroke in it, if
    you want it

    sairus: I'd like to have a place for palette in the font spec
    ... I don't think it'll be implemented right now
    ... but it needs to be speced
    ... what would eb the values

    heycam: that's what Leonard asked
    ... what we have is very web specifi
    ... we need to define what the context is outside of a web

    sairus: you said SVG has color spaces ?

    heycam: CMYK, spot colors ..
    ... in SVG 2, there is a new color syntax to refer to ICC
    colors, LAB, ...
    ... I'm not sure all of that will be implemented in browsers
    ... you can have a fallback sRGB

    cabanier: the browser would not have to render the spot color,
    but a printer would

    sairus: how would it look like

    Cyril: you can use solidColor to make palettes

    <heycam> [14]https://svgwg.org/svg2-draft/color.html

      [14] https://svgwg.org/svg2-draft/color.html

    <heycam> [15]https://svgwg.org/svg2-draft/pservers.html

      [15] https://svgwg.org/svg2-draft/pservers.html

    heycam: you can reference colors by name (gradient, patterns or
    solid colors)
    ... I'm not sure that would be the best way to do it: defining
    set of names controlled by the outside
    ... there is a proposal for parameters
    ... that could be better or some information in the table

    sairus: that is one way SVG would be extended
    ... but not only for fonts, right?

    heycam: we've added taht to the main SVG spec, because they are
    useful in other situations
    ... markers to be style the same way as the objects they are
    put on

    sairus: what about glyph id

    <heycam> ScribeNick: heycam

    shepazu: I'm wondering about non-Web contexts

    … do we expect SVG glyphs to be used widely in non-Web

    … and what does it mean for these context-* values in non-Web

    … there's a lot of stuff to implement SVG, even with the amount
    that's specified in the SVG-in-OpenType proposal

    … are we going to cut that down?

    <Cyril> heycam: we haven't really talked about what subset of
    SVG is required

    <Cyril> ... should we annotate glyphs with versions of the svg

    <Cyril> ... on the web we add new features and old browser do
    some thing, maybe in font, it could be different handling, I
    don't knonw

    <Cyril> ScribeNick: Cyril

    AlexD: are you expecting different engines than web engines ?

    heycam: it doens't seem to make sense to not use some existing

    Cyril: performances ?

    heycam: you can still write your own ?
    ... Adobe is using webkit ?

    cabanier: not decided yet
    ... it would be silly because SVG would be a lot of work

    sairus: so far the only restriction of the type of SVG content
    is secure animated mode
    ... I have a feeling it is best to stick to that
    ... not have a subset of svg defined

    heycam: I would be similarly concerned with other groups
    subsetting SVG

    shepazu: ePub, and ODF really butchered SVG
    ... I wouldn't claim it to be really SVG
    ... if we do things right, we will be talking to hardware
    ... we should be open to extra characterization
    ... saying this element is not suitable for fonts

    heycam: I'm not so concerned
    ... for instance foreignObject with HTML is this allowed in
    fonts ?

    AlexD: no

    sairus: the SVG integration document should define that

    heycam: we should look at the features in SVG and see if they
    make sense in fonts

    sairus: glyph id is the only remaining extension to the SVG

    heycam: in the Adobe proposal you propose to use the id
    attribute in a particular format
    ... I think it's a bad idea
    ... another attribute would be better
    ... glyph id does not have effect on how things render
    ... it's only used to locate
    ... it could be added to the main SVG spec if it is a concern

    sairus: OpenType and SVG processing should be separated

    AlexD: using straight id, is you can use "use" elements
    ... composite glyphs could use use
    ... if you use glyph id you need to put both id and glyph id

    sairus: the font tool will insure that hte ids are well formed

    heycam: we can continue that one on the mailing list

    Vlad: agree
    ... having both glyph char and glyph id is confusing

    heycam: that is a separate issue

    Vlad: all processing is based on glyph id, definition
    additional things will be confusing

    heycam: glyph char is unnecessary, only added as a convenience,
    to avoid looking at the cmap
    ... I don't mind one way or the other

    sairus: we can discuss color on the list too

    heycam: final question, we don't want to continue with 2

    sairus: I do see 3 specs: defining the OpenType table (in OFF
    spec), SVG extensions (in SVG 2 or separate document as a 1.1
    extension), Mozilla recording what they implement

    heycam: in our spec, there is a description of how to process
    the SVG
    ... where should it go ?
    ... requirements on implementations behavior in case of error

    sairus: if they are not only relevant to SVG in OpenType, they
    should be in the SVG spec
    ... but if they are specific, they should be in OpenType
    ... glyph id should be mentionned in the OpenType spec but
    defined in the SVG spec

    heycam: maybe some wording from my spec should go into the
    OpenType spec maybe

    ------ break -------

    <birtles> scribenick: birtles

next f2f

    heycam: csswg have settled on 5-7 June 2013
    ... in Tokyo
    ... so we want to be there 3-4, and make 5th the day for joint
    ... so that was our plan, but it was contingent on CSSWG
    firming up their dates

    Cyril: if we need an extra day we could schedule things that
    are not of interest to CSSWG members on Thurs

    krit: everything is of interest to me

    heycam: are 2.5 days enough?

    krit: should be ok

    Cyril: will there be a Web Animations f2f?

    birtles: we could have one

    shanestephens_: we could have one before then

    RESOLUTION: The next SVG F2F will be in Tokyo from 3-5 June
    2013 with 5 June being a combined day with the CSSWG

    birtles: Mozilla Japan will host, but the day of the 5 June may
    be at a different location

    krit: what about the following f2f?

    AlexD: you often get less done at TPAC

    stakagi: note that the AC meeting is in Tokyo from 9-11 June

    AlexD: the graphical web conference may be in the Bay Area in

    birtles: where is TPAC?

    AlexD: Shenzhen, China

    heycam: do people think that June, Sept and Nov is too much?
    ... I feel like it is

    krit: what about a shared/split F2F?

    AlexD: I think a lot of people here will be going to the
    graphical web
    ... as opposed to TPAC

    heycam: I think I'd prefer to go to TPAC
    ... for the interaction with other groups

    AlexD: so maybe the graphical web should be decoupled from the
    ... and just make it more of a web conference: focussed on
    ... so it might make sense to just to tpac

    krit: some of us will have conflicts since we need to attend
    css etc.

    cabanier: I think we can find time

    heycam: so is everyone ok to meet at tpac instead of the
    graphical web?

    all: yes

    RESOLUTION: The F2F after Tokyo will be at TPAC in Shenzhen,

    TPAC is 18-22 November

Proposed combined Matrix interface


      [16] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Matrix

    krit: this is a shrunken version of the proposal from Dean
    ... my questions are: rotate is not correct
    ... Dean proposed to have rotateX, rotateY, rotateZ


      [17] https://svgwg.org/svg2-draft/coords.html#InterfaceSVGMatrix

    krit: as separate arguments
    ... but I would prefer if they were not separate methods
    ... the current SVG matrix rotates just around the Z matrix
    ... because it's only 2D
    ... so it just have one argument
    ... Dean's proposal has three arguments
    ... the problem is how is this compatible with the current SVG

    <krit> rotate(x,y,z)

    dino: SVGMatrix has just one argument (around the Z axis)
    ... but in this proposal has a function of the same name that
    takes three arguments

    heycam: you could overload it

    dino: but normally with overloading you remove arguments from
    the end, not add them at the beginning

    Cyril: can you reorder them?

    heycam: you don't really want z, x, y
    ... SVG uses just z
    ... in the three argument version you have x, y, z

    dino: the other option is to use rotateAxisAngle
    ... instead of rotate(0, angle, 0)
    ... rotateAxisAngle(0, 1, 0, angle)

    shanestephens_: if you have rotate with three arguments it's x,
    y, z

    dino: I much prefer the four-argument form

    krit: then there's rotateFromVector(x, y)

    heycam: which is already on SVGMatrix

    krit: and it's 2d
    ... and it transforms the matrix from the centre into the
    direction of the vector

    heycam: it's like apply a rotation from this vector

    Cyril: in some 3d languages you give a vector and then you give
    an angle and rotate around the vector

    krit: so in this case you give it a point, and it rotates it

    dino: I call that look-at

    krit: but the problem is we need to keep the SVG name

    cabanier: does it need to be in the merged matrix too?

    krit: we can make rotateFromVector work with 3D
    ... by adding an optional 3rd argument
    ... it should work
    ... but we can't rename it

    heycam: the name makes it sound like you're doing something
    *from* the vector

    Cyril: and you also want rotate around vector

    krit: it' not in SVG only in CSS
    ... I'd like to have it but it's not used a lot
    ... Dean's proposal is rotateAxisAngle
    ... maybe rotateAroundVector would make more sense?
    ... is that ok? instead of rotateAxisAngle?

    dino: that's fine with me

    birtles: why can't we rename again?

    krit: because SVGMatrix would be an alias for this

    heycam: not sure if it's exactly aliasing but yes, you might
    use this in places where an SVGMatrix is expected

    krit: rotate with 3 arguments is hard to use (for authors)
    ... so it might not make sense to have it at all
    ... and just keep rotate around the z axis

    shanestephens_: I agree the three argument version is hard to

    krit: but CSS transforms supports x and y (with just one
    ... we might want to have that as well to be compatible

    dino: but not on this matrix interface
    ... if you're diving into matrix, you're doing something

    krit: I added skewY and skewX from SVGMatrix
    ... but do we want them?
    ... I'd rather not add them to the interface

    dmitry: I'd like to have rotate around a point
    ... like in SVG transform syntax

    krit: we could add that
    ... but then do we do the same for scale?
    ... scale already has 3 arguments

    heycam: so add another 3?

    dmitry: make them optional and 0 by default

    krit: then you have 6 arguments

    dmitry: it's a technical toolset
    ... as a developer I would really like this

    heycam: if we have rotate from vector, then that's another

    dmitry: if we have rotate from vector I really want rotate from

    cabanier: maybe a new attribute on the matrix interface?

    krit: that's not what dmitry was asking for
    ... that's a global transform origin
    ... dmitry was asking for a per-operation transform origin

    cabanier: but maybe that's what you want? to use the same
    transform point?

    heycam: it's like how transform origin is not as useful as it
    could be already
    ... once you have a transform chain it's no longer useful
    ... in this case you'd have to reset the transform point
    ... I think it's pretty common to rotate/scale around a point

    dmitry: I don't mind math but not excessive math

    krit: do we want rotate with three additional arguments?
    ... scale is more complex, because you have 6 arguments

    birtles: is it worth considering a 3DPoint interface for the
    sake of code readability?

    krit: I don't mind adding the three arguments

    heycam: we already have scaleUniform and scaleNonUniform
    ... I think scaleUniform is more common
    ... for the common-case where you want to scale uniformly
    around a point
    ... we can leave scaleUniform with a single scale factor and
    add optional x/y/z arguments

    krit: I don't think that's useful to scale by the same amount
    in each dimension

    heycam: I think it's common when you want to, e.g. zoom in, but
    not deform the world
    ... when dmitry is doing a uniform scale he doesn't have to put
    a zero in
    ... or 1 in the case of scale
    ... does it make sense to separate uniform and non-uniform

    cabanier: yes

    dmitry: I think it makes simple stuff simple and complicated
    stuff possible

    cabanier: I prefer have a transform point on the matrix, it
    seems more natural

    birtles: what about a point dictionary that you re-use
    ... then you can see { x: 0, etc.

    heycam: we can make these take different arguments
    ... the numbers, a dictionary, a native point etc.
    ... it's possible, but not necessarily what we want to do
    ... just the float arguments would be fine

    krit: the proposal from dean has radians for angles
    ... SVG doesn't say degrees or radians but it's assumed to be
    ... so for backwards-compatibility I suggest degrees

    birtles: I agree

    krit: next, the SVGMatrix interface uses floats
    ... Dean's proposal uses doubles

    heycam: we should use doubles

    AlexD: floats are for wimps

    heycam: each time you return a float you have to extend it out
    to a double

    all: let's use doubles

    krit: next, I added flipZ next to flipX and flipY
    ... just to be consistent
    ... not sure if it's really used
    ... inverse(), inverts the matrix but throws an exception if
    it's not invertible
    ... and determinant() is the same
    ... there are mutable and immutable functions
    ... mutable operations need to reproduce the functionality but
    with different names
    ... the current proposal does that by adding "By" for the
    mutable versions

    heycam: it's unfortunate that SVG uses a mix of nouns and verbs
    when all of them are immutable
    ... some of the names sound like they are modifying the object
    ... why is there no mutable flipX, flipY etc.?

    krit: because they're not important, what would you call them?
    ... I didn't find a better name but you might want to know if a
    matrix is 2D or not so I added is2dMatrix()

    heycam: what about is2D() ?
    ... since you're calling it in the context of a matrix

    dmitry: can you also add a method to split a matrix into
    translations etc.

    krit: that was proposed
    ... but the problem is rotation
    ... how do you describe the rotation?
    ... you could use Euler
    ... but then you could lose information
    ... so an alternative is gimbal lock
    ... in CSS transforms we used quarternions
    ... but I don't think that's really useful for authors

    dino: Euler angles still allow you to specify any angle in 3d
    ... the reason you use quarternions is for animating between
    two points
    ... it takes the best path

    dmitry: is it impossible to do the decomposition of the matrix
    ... could we add that method to the matrix?

    krit: the Euler function?

    dino: yes we could do that

    heycam: is the problem that it's just one possible
    decomposition amongst others
    ... why do we use this one

    dino: because it's the most common one

    heycam: what would be return value of decompose()

    krit: quarternions would be four values to describe one angle

    heycam: if I call decompose() I would expect to get <scale
    amount>, <rotate amount>, <translate amount> etc., not "here is
    a quarternion"
    ... how would we return those values?
    ... a dictionary?
    ... an array of numbers where position in the array determines
    the meaning

    krit: what do we want to return? not a quarternion?
    ... a quarternion just represents the rotation

    dmitry: I want to get "the rotation is 45 degrees" etc.

    [discussion about quarternions, matrices, quarternions,
    matrices, Euler, mass confusion]

    dino: why are we adding this function?

    krit: I think you don't need to get these components

    heycam: I think the point of this is there are things where you
    do need these components

    shanestephens_: I just implemented CSS decomposition in
    javascript because it wasn't available
    ... to say decomposing gives you quarternions complicates the
    ... it gives you the scale etc.
    ... so, do we want this function?
    ... and what format do we want it in?
    ... I want this function

    dmitry: I and at least three others want it

    shanestephens_: is anyone opposed to it except for on the basis
    that it is a lot of work?

    dino: I think if we do it, it should do exactly what CSS
    transforms too

    shanestephens_: I agree

    dino: it's really only use for animations
    ... and in most cases when you write a tool to do the
    animations, typically the user wants to change the scale
    ... the only time you want to decompose the matrix
    ... is when you don't know the steps that built up the matrix
    ... typically you want to know the steps that built up the
    matrix and know where to apply the transformation

    shanestephens_: I agree, but sometimes you're forced to work
    with the matrix you're given
    ... I don't think it's a lot of work to do what CSS transforms
    do since it's already implemented

    dmitry: but often you want to work with content from another
    ... for example, a clock where you know which element the hand
    ... and you want to animate it, or measure the time etc.

    dino: the only problem there is that the decomposition will
    work most of the time but not all of the time
    ... if the matrix is unusual enough you might get an unexpected
    ... you want to go back 90 degrees but you might not go the
    right way
    ... it might not solve all your problems

    shanestephens_: but generally you can decompose and control the
    decomposed result

    dino: I think dmitry's case where you're just changing one
    angle should be fine
    ... but once you're doing more than one thing
    ... you're more likely to run into something you didn't expect
    ... but I don't oppose putting it in
    ... but I want to be clear that it might not solve all cases

    shanestephens_: it feels like when we have these algorithms
    that are part of the web platform we should be exposing them to

    krit: I'm ok with it
    ... the question is how to represent the result
    ... a dictionary?

    heycam: another option would be an array of numbers
    ... where the order of numbers determines the meaning
    ... e.g. position 0 means scaleX
    ... but that's a bit harder to use

    krit: I expect this will be used by people who know matrices

    <scribe> ACTION: Dirk to work together with Cameron on a
    representation of the decomposed values of a matrix [recorded
    in [18]http://www.w3.org/2013/02/07-svg-minutes.html#action01]

    <trackbot> Created ACTION-3456 - Work together with Cameron on
    a representation of the decomposed values of a matrix [on Dirk
    Schulze - due 2013-02-15].

    <heycam> -- lunch break --

    <heycam> ScribeNick: heycam

Matrix continued

    krit: Dmitry pointed out that we also have SVGPoint in the SVG

    … the question is, this seems to be useful in general

    … we've used it on some CSS properties, to convert events from
    one user space to another

    … do we want to provide a Point to other languages? So Point
    instead of SVGPoint? which can also be transformed...

    … if yes, what are the pros?

    … Point is interesting when you want to transform it

    … if you want to transform it with this 4x4 Matrix, so the
    point should have 4 components

    heycam: 3 components?

    … with a 1 on the end

    krit: if you transform a 4-valued Point with an arbitrary 4x4
    matrix, all 4 of these coordinates could change

    heycam: I would say we don't need the fourth component for a 3D

    krit: we need the fourth component for intermediate

    … beside that, why would you need it? can we just drop it?

    birtles: could you have a dictionary that has x, y, z plus
    whatever you call the last one?

    krit: w?

    birtles: the z defaults to 0, the w to 1; as a dictionary it
    wouldn't have methods, but something on the Matrix class could
    take a dictionary and return a dictionary

    … so no need to define a new Point interface

    … when you've got a method that takes a point in, you pass in {
    x: 1, y: 2 } and in 2D space you don't specify any more

    krit: once you set this point, can you still read back the
    fourth component?

    birtles: yes the method could stick the "w" property on there
    and authors could ignore it

    krit: I'm not in favour of a dictionary

    birtles: Matrix.transformPoint() could take a dictionary and
    return a dictionary
    ... it's convenient to use that syntax

    … and you can still get ".x" from the return value

    <birtles> e.g. var ret = matrix.transformPoint({ x: 23, y: 24

    <birtles> console.log(ret.x)

    dmitry: I like this; I don't like `new Point(23, 24)`

    dino: I kind of like the idea of not needing a defined type

    krit: SVGPoint has a transform method

    … what would we do with that?

    ed: could just leave SVGPoint around

    … it's used for SVGAnimatedPoints

    … and it's live there

    birtles: currentTranslate is also an SVGPoint

    heycam: and that's live too

    … so we'll add a new transform method on Matrix? taking a

    krit: yes

    … I think we're deciding to use a dictionary

    birtles: then you could also use that in some of the other
    methods on that interface

    … scale() etc., instead of taking x, y, z you could take a

    … then with 2D transforms you wouldn't need to specify the last
    few arguments

    … also when you read the code it's clearer which is x, y, z

    krit: ok

    dmitry: I like it [again]

    krit: do we also want to have a flatten function, that converts
    a 3D transform to a 2D transform?

    birtles: what's the use case for that?

    krit: to use it in canvas for example

    … you might want a 2d version of a canvas

    krit: what would you do in canvas if you give a 3d matrix as
    the ctm for canvas?

    cabanier: I think canvas should ignore it

    … silently fail

    cabanier: will you be able to set a CSS Transform with this

    krit: yes

    … in CSS OM, in the future

    dmitry: I like it

    heycam: where is this Matrix living?

    krit: in its own spec

    … I'd like to work on that spec

    heycam: so what about Rect?

    krit: I don't care about Rect

    dmitry: Don't forget vectors

    <scribe> ACTION: Cameron to investigate HTML global attributes.
    [recorded in

    <trackbot> Created ACTION-3457 - Investigate HTML global
    attributes. [on Cameron McCormack - due 2013-02-15].

Multiple strokes

    [some freeform whiteboarding about possibilities for multiple
    strokes specified in properties]

    stroke="red, white blue" stroke-position="-50%, 0, 50%" could
    make toothpaste

    like in ed's example from SVG Open

    heycam: sometimes I think that 'stroke' should be a shorthand
    for stroke-width, stroke-opacity, stroke-paint, etc.

    <ed> my example from svgopen:


SVG requirements list culling continued



    [$1\47] Clarify that svgz should be as usable everywhere svg
    files can

    heycam: might mean registering a new mime type for svgz

    ed: not all browsers support opening svgz from the local file

    heycam: is it enough to add a sentence saying svgz can be
    opened from the file system?

    ed: yes

    <scribe> ACTION: Erik to do the "Clarify that svgz should be as
    usable everywhere svg files can" SVG 2 requirement. [recorded
    in [22]http://www.w3.org/2013/02/07-svg-minutes.html#action03]

    <trackbot> Created ACTION-3458 - Do the "Clarify that svgz
    should be as usable everywhere svg files can" SVG 2
    requirement. [on Erik Dahlstrφm - due 2013-02-15].

    RESOLUTION: We will keep the SVG 2 "Clarify that svgz should be
    as usable everywhere svg files can" requirement.

    [$1\47] Have a DOM method to convert a <text> element to
    outline path data

    heycam: it sounded like we went a bit off this idea of direct
    access to the glyph data

    … and instead to use the Path object to do some operations on
    glyph data

    cabanier: it's too bad there are not platform apis to
    consistently get outlines

    RESOLUTION: We will defer the "Have a DOM method to convert a
    <text> element to outline path data" SVG 2 requirement to the
    Path object spec, but just allowing operations on glyph data
    and not direct access to the data.

    [$1\47] Have simpler interpolation between two paths

    birtles: not having the same number of segments

    … I reckon it's really good to do, maybe not part of SVG 2?

    … we could look at that as part of Web Animations

    … and decide when to address that

    <scribe> ACTION: Shane to investigate easier path animations.
    [recorded in

    <trackbot> Created ACTION-3459 - Investigate easier path
    animations. [on Shane Stephens - due 2013-02-15].

    RESOLUTION: We will defer the "Have simpler interpolation
    between two paths" SVG 2 requirement to Web Animations,
    possibly later.

    [$1\47] Explicitly support Web Open Font Format (WOFF)

    heycam: done

    [$1\47] Add snapshot time for animated documents and may
    specify how to get at the rendered image

    heycam: seems like two separate things

    birtles: it doesn't help for UAs that don't do animation
    ... better to define the document in such a way that it looks
    the way it should without animations

    Cyril: are there cases where you can't create content where if
    the animation is not processed it wouldn't produce the same

    AlexD: a cartoon.. frame 0 might be different/empty from what
    you want

    dino: maybe you don't want to show any frame of the cartoon,
    maybe you want something different

    … people embed single frames into youtube videos, it gets used
    as the poster

    RESOLUTION: We will not do the "Add snapshot time for animated
    documents and may specify how to get at the rendered image" SVG
    2 requirement.

    [$1\47] Adopt the requiredFonts attribute

    heycam: I don't think this is good; you need to know that
    specific glyphs are available

    RESOLUTION: We will not do the "Adopt the requiredFonts
    attribute" SVG 2 requirement.

    [$1\47] Add the solidColor element and its properties

    heycam: done

    [$1\47] Follow what HTML does for RDFa and microdata

    heycam: I'll think about that as part of global attributes

    [$1\47] Add buffered-rendering

    ed: that is done I think

    [$1\47] Have the vector-effect property

    ed: that is done too

    [$1\47] Have the viewport-fill and viewport-fill-opacity for
    zoom – now should be background-color etc.

    Cyril: I remember we discussed that background-color is not the
    same thing as viewport-fill

    heycam: nobody is excited about doing it

    RESOLUTION: We will defer the "Have the viewport-fill and
    viewport-fill-opacity for zoom – now should be background-color
    etc. " SVG 2 requirement.

    [$1\47] Have constrained transformations based on SVG 1.2 Tiny

    AlexD: I think they're useful

    … doesn't mean we should have them though

    shanestephens_: we're going to look into having some form of
    constrained transformation

    … based on some of the other requirements

    … I had an action to look into it

    … based on the results of that we can decide in June

    [$1\47] Improve the bounding box text based on SVG Tiny 1.2

    heycam: keep it, leave it to Doug

    [$1\47] Include the improved text from SVG Tiny 1.2 on
    characters and glyphs, text layout, text selection, text search

    heycam: I will redo the whole chapter, will do it as part of

    [$1\47] Have the HTML content editable feature

    heycam: don't know if it's worth doing at this point

    AlexD: think it's too big for SVG 2

    Cyril: defer it

    RESOLUTION: We will defer the "Have the HTML content editable
    feature" SVG 2 requirement.

    [$1\47] Have the transformBehavior feature in its spec or as
    part of the merged transform spec

    Cyril: we talked about this the other day

    … I think Shane will look at that too

    [$1\47] Add the features of the SVG Tiny 1.2 animation element
    but not the element itself

    heycam: we've got iframe element

    Cyril: but there's the timing too

    birtles: time containers

    Cyril: that's also related to the video element

    <scribe> ACTION: Cyril to do the "Add the features of the SVG
    Tiny 1.2 animation element but not the element itself" SVG 2
    requirement. [recorded in

    <trackbot> Created ACTION-3460 - Do the "Add the features of
    the SVG Tiny 1.2 animation element but not the element itself"
    SVG 2 requirement. [on Cyril Concolato - due 2013-02-15].

    RESOLUTION: We will keep the "Add the features of the SVG Tiny
    1.2 animation element but not the element itself" SVG 2

    [$1\47] Have synchronization support from somewhere in the web

    Cyril: this is Web Animations

    RESOLUTION: We will defer the "Have synchronization support
    from somewhere in the web platform" SVG 2 requirement to Web

    [$1\47] Have a solution for specifying focusability and
    navigation order, and be consistent with HTML

    heycam: Rich is looking into tabindex

    RESOLUTION: We will keep the "Have a solution for specifying
    focusability and navigation order, and be consistent with HTML"
    SVG 2 requirement.

    [$1\47] Have a mechanism for controlling focus indication,
    consistent with CSS and HTML

    Cyril: this was focusHighlight attribute from Tiny

    ed: I don't think we even require any behaviour in Tiny

    Cyril: we can leave it to Rich

    RESOLUTION: We will keep the "Have a mechanism for controlling
    focus indication, consistent with CSS and HTML " SVG 2

    [$1\47] Support an API to control focus consistent with HTML

    krit: is this also Rich

    heycam: yes

    RESOLUTION: We will keep the "Support an API to control focus
    consistent with HTML " SVG 2 requirement.

    [$1\47] Have support for key events from DOM Level 3 Events

    heycam: I don't think we need to do anything more than
    reference this spec

    … so, keep it

    RESOLUTION: We will keep the "Have support for key events from
    DOM Level 3 Events " SVG 2 requirement.

    [$1\47] Have the SVGRotate event from SVG Tiny 1.2

    ed: I don't think it's very important

    RESOLUTION: We will defer the "Have the SVGRotate event from
    SVG Tiny 1.2 " SVG 2 requirement.

    [$1\47] Support progress events using the HTML 5 method

    heycam: this could apply to <image>

    … we'll already have this on <video> by using HTML's <video>

    <scribe> ACTION: Cyril to look into whether Progress Events
    should fire on <image>. [recorded in

    <trackbot> Created ACTION-3461 - Look into whether Progress
    Events should fire on <image>. [on Cyril Concolato - due

    [$1\47] Adopt improved SVG Tiny 1.2 text on hit testing and
    event processing

    krit: I think we discussed this

    heycam: I think that was isPointInFill
    ... if there is better wording about hit testing in Tiny we
    should copy it over

    RESOLUTION: We will keep the "Adopt improved SVG Tiny 1.2 text
    on hit testing and event processing" SVG 2 requirement.

    <scribe> ACTION: Erik to do the "Adopt improved SVG Tiny 1.2
    text on hit testing and event processing" SVG 2 requirement.
    [recorded in

    <trackbot> Created ACTION-3462 - Do the "Adopt improved SVG
    Tiny 1.2 text on hit testing and event processing" SVG 2
    requirement. [on Erik Dahlstrφm - due 2013-02-15].

    The next four are basically copying over better text from Tiny.

    [$1\47] Adopt the improved wording on Reference Restrictions

    [$1\47] Adopt the improved wording on Processing External

    [$1\47] Adopt the text from SVG Tiny 1.2 on Indicating links

    [$1\47] Merge the SVG 1.1 SE text and the SVG Tiny 1.2 text on
    fragment identifiers link traversal and add media fragments

    <scribe> ACTION: Erik to do the 104, 105, 106, 107 SVG 2
    requirements. [recorded in

    <trackbot> Created ACTION-3463 - Do the 104, 105, 106, 107 SVG
    2 requirements. [on Erik Dahlstrφm - due 2013-02-15].

    ACTION-3463: Not 107, Cyril will do that as part of

    <trackbot> Notes added to ACTION-3463 Do the 104, 105, 106, 107
    SVG 2 requirements..

    [$1\47] Define how inline scriptable content will be processed,
    in compatible way to HTML5

    heycam: I'll still do this

    [$1\47] Merge SVG Tiny 1.2 improved text on the script element

    heycam: same thing

    [$1\47] Use the relevant parts from SVG Tiny 1.2 and align with
    the HTML script element

    heycam: also the same thing

    [$1\47] Apply the changes from SVG Tiny 1.2 Animations chapter

    birtles: yet to do, will do
    ... it's basically handling bad values in animations

    [$1\47] Support xlink:href on the foreignObject element after
    security verification

    heycam: no, this will be iframe's job

    ed: foreignObject is the defined extension point

    … for SVG

    … so will <iframe> be that in the future?

    heycam: do you need href on <foreignObject>?

    Cyril: if you want to include some HTML in your SVG, you have
    to use foreignObject

    … if you want to reference it you use <iframe>

    ed: it's not just HTML though

    … it's a custom plugin we don't know anything about

    krit: you can use foreignObject for MathML too

    ed: I'm fine with deferring it

    RESOLUTION: We will defer the "Support xlink:href on the
    foreignObject element after security verification " SVG 2

    [$1\47] Use the MicroDOM as input into the DOM improvement

    heycam: we've already got some DOM improvements in line

    … like px, etc.

    ed: I think you can go quite far with the suggested
    improvements we have so far

    … easy typed access is what I want to see, and that's what we
    have now

    krit: and then CSS OM will also improve this

    ed: basically shorter/nicer than SVG 1.1 DOM

    RESOLUTION: Nothing more to do for the " [$1\47] Use the
    MicroDOM as input into the DOM improvement designs " SVG 2

    [$1\47] Have relaxed document error handling (with lacuna
    values etc.) as defined in Tiny 1.2

    heycam: I can take this one

    <scribe> ACTION: Cameron to add relaxed document error handling
    to SVG 2. [recorded in

    <trackbot> Created ACTION-3464 - Add relaxed document error
    handling to SVG 2. [on Cameron McCormack - due 2013-02-15].

    RESOLUTION: We will keep the " [$1\47] Have relaxed document
    error handling (with lacuna values etc.) as defined in Tiny 1.2
    " SVG 2 requirement.

    [$1\47] Add new paint values currentFillPaint,

    heycam: I think these are slightly different from context-fill,

    … these are instead like currentColor

    Cyril: we can leave it with Chris

    … I remember seeing good examples

    RESOLUTION: Deferred " [$1\47] Add new paint values
    currentFillPaint, currentStrokePaint " depending on Chris'

    [$1\47] Clarify radial gradients with focal point on the circle

    Cyril: this is already in the spec

    [$1\47] Add an fr attribute to <radialGradient>

    Cyril: also done

    [$1\47] Use CSS3 definitions for text layout (whitespacing,
    bidi, etc) that is not specific to SVG

    heycam: I will stil do that

    [$1\47] Use updated CSS3 specifications

    heycam: I will help help do those

    [$1\47] Provide a way to get glyph path data via some API

    AlexD: this is a dupe

    [$1\47] Move all events to Element, in accordance with the
    similar move in HTML

    heycam: I will still do this

    [$1\47] Add a path rotation command

    RESOLUTION: Defer the " [$1\47] Add a path rotation command "
    requirement unless Cameron gets time.

    [$1\47] Introduce evt as an alias to event in event handlers

    heycam: I'll do that as part of the script reworking

    [$1\47] Require object-fit and object-position

    heycam: this is a dupe of 71

    trackbot, close ACTION-3001

    <trackbot> Closed ACTION-3001 Gather up issues regarding
    object-fit and it's applied to SVG and email CSS Working Group.

    [$1\47] Add text-overflow

    heycam: done, Erik did it

    [$1\47] Mandate support for SVG Tiny fonts

    heycam: we can come back to it at a more useful time

    [$1\47] Mandate the support for external style sheets, style
    element and style attributes all with CSS syntax

    RESOLUTION: We will keep the " [$1\47] Mandate the support for
    external style sheets, style element and style attributes all
    with CSS syntax " SVG 2 requirement.

    [$1\47] Define how border and background apply to SVG

    krit: to the <svg> root element maybe

    … inside SVG, I don't think there's a lot to define

    RESOLUTION: We will keep the " [$1\47] Define how border and
    background apply to SVG " SVG 2 requirement.

    [$1\47] Define the outline property for use on SVG elements

    heycam: Rich can look at this as part of the focus work

    [$1\47] Clarify how pointer-events can hit the root svg or not

    krit: this just needs some clarifications

    RESOLUTION: We will keep the " [$1\47] Clarify how
    pointer-events can hit the root svg or not " SVG 2 requirement.

    [$1\47] Drop xlink prefix for href

    AlexD: yes

    heycam: Chris has the action, I can pick up the rest if need be

    RESOLUTION: We will keep the " [$1\47] Drop xlink prefix for
    href " SVG 2 requirement.

    [$1\47] Remove the restriction of tref pointing to only an SVG
    document fragment

    heycam: I did that the other day

    [$1\47] Support the feature of SMIL time containers

    RESOLUTION: Defer " [$1\47] Support the feature of SMIL time
    containers " to Web Animations.

    [$1\47] Support animation triggers based on keyboard input,
    pending a proposal on security issues

    RESOLUTION: Defer " [$1\47] Support animation triggers based on
    keyboard input, pending a proposal on security issues " to Web

    [$1\47] Support a means for having SMIL animations start before
    their time container has fully loaded

    birtles: that's in Web Animations too

    Cyril: I think that's already integrated into the spec

    [$1\47] have <discard> element to declaratively discard
    elements from the document tree

    <scribe> ACTION: Brian to add IDL for discard element.
    [recorded in

    <trackbot> Created ACTION-3465 - Add IDL for discard element.
    [on Brian Birtles - due 2013-02-15].

    [$1\47] Support the playbackOrder attribute to inform UA to not
    display controls to seek backwards

    Cyril: it's already in there too

    … Brian had a comment on it

    birtles: what's this one?

    Cyril: this tells you there are no forward references

    birtles: I don't like it

    Cyril: if noone implements it we'll remove it

    [$1\47] Allow masks to use either alpha or luminance or both

    birtles: I've done that

    … in CSS Masking anyway

    [$1\47] Support <canvas> element in SVG 2

    birtles: that's part of Takagi-san's action

    [$1\47] Relax restriction on masks pointing to mask element

    birtles: I thought we fixed that

    ed: if you point to a <circle> directly from the mask property

    krit: yes this is fixed

    <scribe> [NEW] Control the order of painting and filling and

    heycam: that one is done

    -- 15 minute break --

Summary of Action Items

    [NEW] ACTION: Brian to add IDL for discard element. [recorded
    in [30]http://www.w3.org/2013/02/07-svg-minutes.html#action10]
    [NEW] ACTION: Cameron to add relaxed document error handling to
    SVG 2. [recorded in
    [NEW] ACTION: Cameron to investigate HTML global attributes.
    [recorded in
    [NEW] ACTION: Cyril to do the "Add the features of the SVG Tiny
    1.2 animation element but not the element itself" SVG 2
    requirement. [recorded in
    [NEW] ACTION: Cyril to look into whether Progress Events should
    fire on <image>. [recorded in
    [NEW] ACTION: Dirk to work together with Cameron on a
    representation of the decomposed values of a matrix [recorded
    in [35]http://www.w3.org/2013/02/07-svg-minutes.html#action01]
    [NEW] ACTION: Erik to do the "Adopt improved SVG Tiny 1.2 text
    on hit testing and event processing" SVG 2 requirement.
    [recorded in
    [NEW] ACTION: Erik to do the "Clarify that svgz should be as
    usable everywhere svg files can" SVG 2 requirement. [recorded
    in [37]http://www.w3.org/2013/02/07-svg-minutes.html#action03]
    [NEW] ACTION: Erik to do the 104, 105, 106, 107 SVG 2
    requirements. [recorded in
    [NEW] ACTION: Shane to investigate easier path animations.
    [recorded in

    [End of minutes]
Received on Friday, 8 February 2013 05:49:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:40 UTC