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

minutes, SVG WG Seattle F2F 2011 day 3

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 29 Jul 2011 22:38:02 -0700
Message-ID: <4E3398BA.1020708@mcc.id.au>
To: www-svg@w3.org
http://www.w3.org/2011/07/29-svg-minutes.html and below as text.  Note 
that again the minute taking bot has become confused, so the HTML 
version linked above has both

Present were: Cameron McCormack, Erik Dahlström, Vincent Hardy, Rik 
Cabanier, Doug Schepers, Jennifer Yu, Cyril Concolato, Sylvain Galineau, 
Tab Atkins Jr., Chris Lilley (phone), Tavmjong Bah (phone)


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

                                - DRAFT -

                    SVG Working Group Teleconference

29 Jul 2011

    See also: [2]IRC log

       [2] http://www.w3.org/2011/07/29-svg-irc


           ChrisL, +1.206.675.aaaa


           TabAtkins_, heycam, TabAtkin1_, vhardy, jenyu


      * [3]Topics
          1. [4]SVG Color
          2. [5]SVG Vector Effects
          3. [6]SVG Compositing
          4. [7]Advanced Gradients
          5. [8]current gradient issues.
          6. [9]fr attribute on radialGradients
          7. [10]Compositing
          8. [11]css dependencies
          9. [12]Next F2F
         10. [13]SVG 2 scope
         11. [14]Media resources spec review
         12. [15]sharing path segments
         13. [16]polar element
      * [17]Summary of Action Items

    <trackbot> Date: 29 July 2011

    <ChrisL> Meeting: SVG f2f Seattle

    <TabAtkins_> ScribeNick: TabAtkins_

SVG Color

    ChrisL: Some links to start.



    ChrisL: That's a link to a list of stuff I need to get done and want
    to discuss.


      [19] http://dev.w3.org/SVG/modules/color/master/SVGColor.html

    ChrisL: That's the actual spec.



    ChrisL: This is the rougher notes on impls and other stuff that
    we'll get to if necessary.
    ... On the first link, I've had a bit of review on the spec recently
    from interested and knowledgeable people.
    ... I'm in the middle of editorial revisions to take into account
    their feedback.
    ... Also I have an offer of review from the chair of ICC.
    ... But I want to get the spec into proper shape first so they can
    focus on important issues.
    ... Hence this list of editor's issues.

    heycam: Are any of these open issues where we need to decide on

    ChrisL: Some are.
    ... Let's start with tagged images.
    ... It's possible to have an image that says it's in a profile but
    doesn't embed the profile.
    ... Mostly they do embed their profile.
    ... The spec says "you must apply the profile if it's available",
    defined as present, not malformed, etc.
    ... If it's not present, that counts as not available, so that's

    heycam: What's the fallback?

    ChrisL: Treat as sRGB.
    ... We used to have something about overriding the profile.
    ... Which was a weird thing to want to do.
    ... Most people questioned the utility.
    ... So, I've removed that.

    heycam: In no-profile situations, is that a use-case?

    ChrisL: Yeah, but we specifically say to treat as sRGB there.
    ... Having looked, there's rarely an issue with mistagged images.
    ... Authors or authoring tools almost always get it right.
    ... The problem was that the spec took too much time talking about
    overriding the profile, and not enough about applying the profile
    that exists.
    ... So I've beefed that up with some conformance requirements.
    ... There used to be a 1.1 test for that, but since it wasn't
    testable we eventually removed it.
    ... So I'll move it into the testsuite for this spec, since it is
    clearly defined.
    ... The last thing on tagged images is about fallback images.
    ... We do fallback for colors, but not really for images.
    ... So maybe something like <switch>, but for some image attribute.
    ... So if you don't do color matching, use this image; if you do,
    use this better image.
    ... So what do we want to do here?
    ... It's like a feature-string for this module.

    heycam: I think that's reasonably simple to do.

    vhardy: If you don't do color management, when would you design your
    content to switch to a different image?

    ChrisL: If you do everything in sRGB, and you have a photo, you can
    convert that photo to sRGB, and it'll match.
    ... But you'll lose out-of-gamut colors, which the cameras can
    ... It's easy to save the image as both high-quality and

    vhardy: And that's better than just ignoring the color profile and
    interpreting as sRGB?

    ChrisL: No, you actually get different RGB values depending on your
    gamut. If you did that, all the colors would be wrong.

    vhardy: So you actually end up with a lower-quality image if you
    just reinterpret the wide-gamut image.

    ChrisL: That's right.
    ... So should I just make up a feature-string?

    shepazu: I have a suggestion, one moment...

    <shepazu> for feature strings, I propose the syntax
    attributeNameOrPropertyvalue" e.g. "svg.textPath.method.stretch"

    <ChrisL> so that is a very different sysntax to the 1.1 feaure

    <ChrisL> [21]http://www.w3.org/TR/SVG/feature.html

      [21] http://www.w3.org/TR/SVG/feature.html

    <shepazu> could be

      [22] http://www.w3.org/TR/SVG11/feature#textPath.method.stretch

    TabAtkins_: CSS is also essentially defining feature strings via
    @supports, and we've decided to be as specific as possible; you must
    provide a full property/value pair, not just a property.

    <ChrisL> if the future syntax id feature strings is undecided, i can
    just mark it as an issue and fill it in once we have a system in


      [23] http://www.w3.org/TR/DOM-Level-3-Events/#feature-detection

    <heycam> ScribeNick: heycam

    DS: we need something consistent
    ... so that's for attributes and properties
    ... for APIs we could say some other similar syntax

    ED: you can always test if the properties exist

    DS: I think we should come up with a consistent feature string

    <scribe> ScribeNick: TabAtkins_

    <heycam> ScribeNick: heycam

    CL: the next things is the section on definig colours

    <TabAtkins_> ScribeNick: TabAtkins_

    <heycam> ... this is a complete replacement fro the section in 1.1

    <heycam> ScribeNick: heycam

    CL: I define all the stuff, so there's a consistent grammar
    ... in the sRGB section there is a part I no longer agree with
    ... it says "sRGB" is predefined, and if you point a specific sRGB
    profile it's ignored
    ... but there is a need for that
    ... since there are differences between ICC versions of sRGB
    ... so I'm going to remove that section
    ... there's also a need to specify what the transfer curve is for
    sRGB values that are outside teh gamut
    ... because the syntax allows that, negative values and values >
    ... but we don't say what the gamma curve is beyond those points
    ... so I'm going to propose something there, that the curve is
    reflexive about the origin and follows a tangent at the end point
    ... I noticed the way the industry seems to be going is that if
    people want to use wide gamut sRGB they go with a linear transfer
    ... that's sxRGB
    ... so I wonder whether we should add that
    ... the question about what to display with the wrong colour
    profile, I think that's why this exists
    ... if you use a wide space and interpret it witj sRGB you get a
    desaturated image
    ... but if you use sxRGB, then devices that don't understand it will
    treat it as sRGB and just clip
    ... the movie industry, bluray seems to be going for that sort of
    ... at this point I think I'll just add an issue for review, saying
    wondering whether we should add it, and get advice on it

    RC: when you talk about the transfer curve, what do you mean?

    CL: it's the graph between the inptu and output
    ... sRGB has a particular transfer curve
    ... it's like a gamma 2.2 function, but a bit more complicated
    around the origin
    ... it's a graph of input values to light level output

    RC: from RGB to device independent colour?

    CL: no, from RGB to light levels you would measure with a probe

    RC: so it's like a combination of two different profiles?

    CL: no, it's the final stage when you're generating light at the end
    of the day
    ... the maximum level is white, the minimum is black
    ... the mid value isn't going to be 127

    RC: do you as SVG need to worry about a transfer curve? isn't that
    handled by the monitor and graphics card?

    CL: it does handle that...

    RC: and you cannot give more than 100% to the graphcis card

    CL: you know the CIE horse shoe diagram?
    ... and the triangle defines the primaries
    ... so now extend those lines of the triangle out, so instead of
    meeting at the points they cross and continue on
    ... you can now make colours outside the triangle, as long as you
    can use values < 0 or > 100%
    ... you can now specify the colours anywhere on the gamut
    ... if that's the physical device, and that's the last device in
    your chain, you can't go outside
    ... but if oyu're using it as an input, which might be composited,
    then you can specify values outside that
    ... and then would be converted to the rendering colour space

    RC: but as soon as you go outside the gamut of the profile, things
    don't make sense any more?
    ... how could you ever measure and construct a profile for taht?

    CL: you can measure it easily

    RC: the profile just describes what the device is capable of

    [more discussion of out of gamut colours]

    <TabAtkins_> ScribeNick: TabAtkins_

    ChrisL: Next is uncontentious.
    ... CSS3 Color adds hsl, hsla, rgba.
    ... In CIELAB you need to specify the whitepoint.

    TabAtkins_: How does SVG handle transparent colors?

    ChrisL: The opacity property combines with the color's own opacity.

    TabAtkins_: What about transitions between colors, like in

    ChrisL: That should be handle by color-interpolation, likely
    expanded in the manner you suggested.

    heycam: SVG2 is going to reference CSS3 Color, I thought?

    ChrisL: SVG Color will also reference CSS3 Color.
    ... next is rendering-intent.
    ... If you have a range of colors in an image, and you're trying to
    map that to a smaller or different gamut, then all the colors which
    are in the intersection of the gamuts are fine.
    ... But the outside colors need to be manipulated somehow. How you
    do this depends on what you want to do with the result.
    ... In the ICC model, there are four different rendering intents.
    ... There's absolute-colorimetric (same color if possible),
    relative-colorimetric (same, but scale the whitepoint), saturation
    (keep saturation steady, even if hue changes), and finally
    ... If you just clamp colors outside the gamut, gradient's'll look
    weird, etc, so perceptual scales the whole gamut down so you keep
    the overall look.
    ... In SVG 1.1, you can specify a color using ICC.
    ... You get an sRGB back, but still.
    ... This guy is working on desktop publishing which goes back to
    color-managed printing.
    ... So he's interested in what happens to rendering intent.
    ... in SVG the only compositing space is sRGB.
    ... So you convert your CMYK to sRGB, composite, then go back to
    CMYK for the printer, and you've lost your rendering intent.
    ... So right now it's an open issue how to preserve that.
    ... It's unclear in 1.1 whether colors which have opacity are
    treated differently than solid colors.
    ... So you can (a) imagine that everything is composited (even if a
    solid color)
    ... or (b) only composite if you need to, so opaque colors will be
    preserved exactly with their rendering intent.
    ... That has implications with anti-aliasing, etc.
    ... There may be need for different rendering intents on different
    elements (photos want perceptual, solid colors want
    ... So I'm going to put an idea in. Impls would get more complex
    because they'd need to hang onto the original color and rendering

    cabanier: If PDF and PS, you tag the element with the rendering

    <cabanier> cabanier: in pdf and postscript, the document, the
    printer and the device can all specify the default rendering intent

    ChrisL: Next is black-point compensation. We don't have a way to
    specify that right now; I'm wondering if we should have it.
    ... So imaging you have two color-spaces, and they're mapped to a 3d
    diagram (black on bottom, white on top)

    <cabanier> in addition to that, elements can override the default
    rendering to get results that are applicable to that content

    ChrisL: Imagine a vector from black to white.
    ... So in one colorspace, the white is a little duller, a little to
    the side, and you can map between these because you've specified the
    ... Similarly for black-points, with different color-spaces having
    different "deepest black".
    ... It's not clear to me how to specify it.
    ... But people have asked for it.

    vhardy: Are there precedents we can look at?

    ChrisL: When ICC updated sRGB to version 4, they produced two
    profiles, one with and one without blackpoint compensation.
    ... And in Photoshop, the dialog box has a checkbox for blackpoint
    compensation when converting between colorspaces.
    ... So if it's purely something for the output stage, it should be
    defined in the device profile (which SVG doesn't specify).
    ... If that's the only place you need, SVG doesn't need to say
    ... But if you need to do it on input, so you can compensate
    blackpoint for an image but not the surrounding color, then we'll
    need something for that.

    vhardy: A use-case for input is you taking a picture and knowing
    that the blackpoint is different?

    ChrisL: If the blackpoint for the output device is higher (less
    dark), then there will be a range of dark colors in the input which
    will clamp to the single output black.

    cabanier: PDF defines it on the input.

    ChrisL: So I suggest marking an issue and waiting for feedback.

    cabanier: Whitepoint and blackpoint mapping are used on calibrateRGB

    ChrisL: last issue is preserving black.
    ... For example, in ICC if you specify cmyk(0,0,0,1),
    color-management systems tend to have a switch that specially treats
    that value.
    ... So even if the system does color-manipulation normally, that one
    color will instead stay solid, total black.
    ... This is so black text stays pure black and doesn't mix in other
    ... So, similarly, we need to see if we need it, and see if it's an
    input or output feature.

    cabanier: We have it in InDesign, and it's an output feature there.
    ... So we have some special cases there again; you don't want to
    preserve black on an image.

    ChrisL: So that's basically actually being an input feature.

    heycam: Does it make sense to have this controllable on images, or
    if we can magically just apply it to solid-color fills and strokes?
    ... Also, if you have some colored shapes which are composited
    together, and you happen to get black out of that, should that be

    TabAtkins_: So it sounds like we can just specify that solid-color
    strokes and fills automatically preserve black, and nothing else
    does. It can be applied on output, and doesn't need to be specified
    on input.

    cabanier: So we look at the operator on printing - if a shape is
    filled with an image or gradient, we don't preserve black. If it's
    filled with a color, we preserve.

    TabAtkins_: So if you composite a partially-transparent gradient
    over a black rectangle, you wouldn't preserve the black in it.

    heycam: So basically, for any image, track if the result color comes
    partially from a gradient or image. If so, don't preserve black;
    otherwise, preserve it.

    TabAtkins_: So it sounds like we can do this automatically at the
    end, and thus don't need a property for it.

    heycam: And in PDF, it's not controllable; it just happens

    ChrisL: That's it for Color. I'll do another round of edits, then
    announce it for review and feedback.

    heycam: Is the plan to resolve all these issues and then publish, or
    did you want to publish before that.

    ChrisL: We'll need a TR publication with some of these notes and
    issues in place, for feedback, but it won't be acceptable for LC.
    ... So after we get feedback, we can clean it up.

    shepazu: So is the plan that we make this an SVG feature, and if
    people ask for it to be in CSS we can merge it in then?

    ChrisL: There was some color management in CSS earlier, but there
    wasn't impl interest so it was removed.
    ... This is mainly requested by people who want to use SVG and then
    go straight to print.
    ... So we'll see print industries implement it first, and then it'll
    gradually bleed over.
    ... So right now it's good to have it defined just here in SVG.
    ... I think it'll be an optional module for SVG2 right now.
    ... Actually, one more issue to discuss.
    ... How are we doing tests for SVG2?
    ... I would like to start putting together some tests for these
    ... Are we doing reftests, or what?

    ed: Unless you can test things with script, I'd go with reftests.

    [24]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements (see
    test section)

      [24] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements

    ChrisL: Some of them I can script test, so that's fine.
    ... Are we using plinss's test harness?

    shepazu: That's the plan.

    vhardy: I have an action for that. We should have a space for SVG
    tests right now, and we'll do more when we formalize the framework.

    heycam: It should be a simple matter to convert formats when we need

    vhardy: Couple of questions.
    ... Re tagged images, you said overriding profiles didn't make much
    ... What's the history of this feature?

    ChrisL: i think it was there from very early on. It was in SVG
    ... I think at that point color management on the web and on OSes
    wasn't as good, and there was a concern that people would put the
    wrong profiles on things.
    ... But it turns out that's not the case now; if people don't
    color-manage, they just don't add a profile; if they are, the
    software tags properly.
    ... So it's just not a problem today.

    vhardy: So it's not a question of someone needing a feature who
    happens to not be around now?

    ChrisL: No.

    vhardy: Ok. Is it okay that we didn't actively capture resolutions

    ChrisL: Yes. I have notes, and I'll bring questions back to the ML.

SVG Vector Effects


      [25] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Vector_effects

    ChrisL: I have two questions.
    ... The first feature on the page started in vector effects, and I
    request that we move it out into SVG proper.
    ... Currently we have currentColor, which takes the current animated
    value of the color property.
    ... So this is well-defined tree-structure inheritance.
    ... So I can say fill:currentColor or whatever.



    ChrisL: So I propose taking this as the basis and expanding it to
    six values.



    ChrisL: currentColor, currentFillPaint, and currentStrokePaint.
    ... This lets you do the common thing of "how do I do markers that
    are the same color as the line they're on".
    ... And then three more which are identical, but rather than coming
    from the point in the tree, they come from use.
    ... So you can use this in a <symbol>, and it'll pick up different
    values from each place it's used.
    ... Right now we have some magic handwaving that makes it work for
    <symbol>, but this would remove the handwaving and let you use it

    heycam: If we can use this to remove the magical inheritance, we
    should try to kill the magic handwaving.

    ChrisL: Yes, I think we can do this.

    heycam: And I think this is more obvious.

    <heycam> ScribeNick: heycam

    CL: there are two sets of values
    ... one is "on define" and the other is "on use"

    CM: ok

    CL: I think these are reasonable
    ... I want to propose this, can we accept it?

    CC: no objection, just a comment
    ... the currentColor is already something that is not that simple to
    implement when you consider inheritance, animations
    ... so adding new values means adding complexity
    ... I understand the use cases, just pointing out that it's complex

    CL: I understand that
    ... CSS uses inheritance all over the place, so that ship has
    already sailed
    ... this is going to be much simpler than the magical inheritance
    into use

    <TabAtkin1_> ed: I think this solves most use-cases; there may be
    more things you want to inherit than just fills and paints, but this
    is a good start.

    RESOLUTION: We will add new paint values currentFillPaint,
    currentStrokePaint etc. to SVG 2

    <scribe> ScribeNick: TabAtkin1_

    <scribe> ACTION: ChrisL to write up spec text for currentFillPaint,
    etc. [recorded in

    <trackbot> Created ACTION-3094 - Write up spec text for
    currentFillPaint, etc. [on Chris Lilley - due 2011-08-05].

    vhardy: Since we have a req document for SVG2, perhaps we can
    annotate for things with resolutions as hard requirements.

    ed: Sounds like going through the last few f2f and tracker.

    <scribe> ACTION: ed to go through the last few f2f minutes to find
    resolutions for SVG2 items, and add them to the wiki page. [recorded
    in [29]http://www.w3.org/2011/07/29-svg-minutes.html#action02]

    <trackbot> Created ACTION-3095 - Go through the last few f2f minutes
    to find resolutions for SVG2 items, and add them to the wiki page.
    [on Erik Dahlström - due 2011-08-05].

    ChrisL: Second things is about constructive geometry.
    ... Basicall union and intersection to produce new shapes.
    ... Widely used in 3d.
    ... It's being criticized as being computationally intensive, and as
    being possible non-interoperable as getting slightly different
    results between impls.
    ... Same rendering, but different underlying nodes.
    ... These are valid concerns.
    ... Though, looking at the sbasis library, it does this.


      [30] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Vector_effects

    ChrisL: And it apparently isn't particularly computationally
    ... So, while accepting that we do have some problems, really the
    whole of VE gets its value from these things.
    ... You can still do some other useful things, but really the main
    expressive power is being able to union/intersect geometry here.
    ... So we either need to resolve these problems, or else just split
    up VE into bunches of little features. It's like doing Filter
    Effects without compositing.
    ... So I'd like to resolve one way or another on whether we're going
    to pursue it.

    vhardy: Can you elaborate on the criticisms?

    ChrisL: I think Alex Danilo said it was heavily unspecified.
    ... There's also concern that if you take the resulting path and
    know where the nodes are, could you produce another path and animate
    between them?

    heycam: The fact that it doesn't guarantee particular paths... we
    already have that with normalized path seglist.

    ChrisL: Yeah. At the end of the day you get a path that'll render
    the same in different impls, but if you drill down and try to get a
    particular control point, you'll get different results.
    ... Unless we put some pretty rigid constraints on the algorithms.

    vhardy: I think that it's a very useful feature. It's in
    Illustrator, and is used all the time.
    ... For the platform it's a useful capability.
    ... So I think our process is to go ahead and spec, and deal with
    impl feedback as it comes in.

    heycam: One of Chris's questions was "will this be easy to specify?
    ... So I guess we just need someone to try.

    cabanier: Is this a scripting API or declarative?

    heycam: Declarative, though there may be APIs layered on top later.

    ChrisL: Yeah, like asking for a copy of the path so you can use it

    heycam: And eventually being able to get a path and call
    .union(otherpath) would be useful later.

    ChrisL: So I'm hearing that it sounds useful, we should proceed and
    see if we run into problems.

    heycam: I was one of those that had concerns.
    ... obviously authoring tools can do it performantly (because they
    do it)

    ChrisL: Yeah, and now we know how some of them do it (convert
    everything to sbasis curves and do magic).

    cyril_: So the intersection always decomposes into a normal path. Is
    there any real benefit over doing this totally in authoring tools?
    ... Beyond just basic geom semantics.

    ChrisL: I think the main benefit is that if you keep the individual
    parts, they stay live, so if you change one of the underlying paths
    the VE is reintepreted.

    cyril_: What about filesize benefits?

    cabanier: Sometimes smaller.

    shepazu: The big benefit is doing this in the browser. Moving things
    out of the authoring environment into the browser is a good thing.
    ... I think another thing we don't do in VE right now is, it doesn't
    have an API.

    <ChrisL> It would be interesting to investigate that. I think the
    result of stroke to path is going to be larger than the original
    path plus the vector effect elements

    shepazu: So anything available through the element-based syntax
    should also be doable via API.
    ... Then we can also do this in Canvas, frex.

    heycam: I think the arguments for doing VE are similar to the
    arguments for doing text warping, etc.

    RESOLUTION: Keep constructive geometry operations in VE and see if
    it's possible.

    heycam: I think it's still possible that in the end we discover that
    it's too complex, but we totally want to try and do it first.

    shepazu: So is this part of SVG2, or is it part of a module?

    <ChrisL> currently its edited as a module

    heycam: I think keep it as a module for now. It gives it better

    <ChrisL> it can always be merged later

    <br duration=15min>

    <tbah> OK, I'll call in anyway. The girls are in bed. Peace has

    <vhardy> ScribeNick: vhardy

SVG Compositing

Advanced Gradients

    <tbah> [31]http://tavmjong.free.fr/SVG/MESH/Mesh_Inkscape.html

      [31] http://tavmjong.free.fr/SVG/MESH/Mesh_Inkscape.html

    tav: I have taken what was proposed as a structure for
    mesh-gradients and patched InkScape to use that
    ... I added this in my private copy of InkScape.

    tab: I have also Coons patch mesh gradients in Canvas

    tav: So you have a way to defining them?

    tab: yes, and an implementation.

    <TabAtkin1_> Apropos of text stroking,

    tab: it is a JS impl

    <TabAtkin1_> [32]http://www.xanthir.com/etc/text-stroke-start.html

      [32] http://www.xanthir.com/etc/text-stroke-start.html

    heycam: I came up with a syntax and then got feedback from tab

    tav: I have produced some interseting gradients.
    ... cairo has bugs with that type of gradients.
    ... I get crashes in some casess.
    ... you can see the definition of the gradients in the code sample.
    ... there is a <meshGradient>, a <meshRow> and a <meshPatch>
    ... then there is a sphere with four patches
    ... then there is conical gradients that can be done with meshes as

    <scribe> ... done with one zero-length size.

    UNKNOWN_SPEAKER: then a 6x6 patch mesh gradient.
    ... the performance is good enough.

    <tbah> [33]http://tavmjong.free.fr/SVG/MESH/Mesh.html

      [33] http://tavmjong.free.fr/SVG/MESH/Mesh.html

    UNKNOWN_SPEAKER: the gray box half way down is the syntax proposed.
    ... the way it is defined is an array of patches aligned in rows.

    <ChrisL> like a table

    UNKNOWN_SPEAKER: ther eis a <meshRow> which defines the begining and
    then a <meshPatch> with has four stops. The stops have a stop-path.
    ... you could have a curve or a line. Cairo supports curveto and
    ... you need a Bezier curve. If you need other curves, you need to
    translate to Bezier.

    shepazu: this seems pretty verbose.
    ... I am not sure how to make it more concise.

    tav: you could combine the paths into one and then you could specify
    the colors for the corners.
    ... I think I like this better.
    ... it is always a quad.
    ... if the last two points coincide, you could skip them.
    ... the moveto is needed to start the path. That is the x/y of the
    meshGradient. Then you have the additional the curves. For the last
    one, you do not need the last point because it is a closed path.

    cabanier: can you have disjoined patches?

    tav: no.
    ... if you want to be able to edit that, then you start with a
    single patch and then start dividing.
    ... the second patch is attached to the right of the first patch.
    ... you can distort the array any way you want, like in the conical
    gradient example.
    ... conceptually, you need an array, top, left right.
    ... Moving on to <!-- New row --> in the gray section.
    ... note that the first path is ommited because it is taken from the
    bottom patch of the patch above.
    ... next patch, you only need to specify 2 of the paths, because the
    top and left path are coming from the previously specified colors.

    heycam: if you specify a color which you already know?

    tav: it is ignored.
    ... then I list changes from what Tab had proposed.

    heycam: I am not sure stop-path is the best name. Attributes with a
    dash are properties, e..g, stop-color is a property.
    ... it should probably be path.

    vhardy: or 'd'

    RESOLUTION: rename stop-path to 'd' or 'path'

    shepazu: since it is not exactly the same syntax as 'd', it probably
    better to use 'path'
    ... I wonder if we are going to have Catmull Rom curves, it might be
    useful to have that.

    tab: we should allow any given path segment that <path> has.

    <ChrisL> yeah but if libraries are constraind to bezier paths then
    that is what you would need to use

    cyril: how do you use stop-opacity?

    tav: yes, you can. I have not done an example, but the Cairo code
    allows it.

    cyril: do you have spread and pad methods.
    ... I think it is not a good idea.
    ... how would you use it?

    tab: it feels more like a geometric primitive, and not a fill?

    tav: in the last example I did, it fills the rectangle completely.
    ... the edges are outside the rectangle.

    cyril: what is the coordinate system for the mesh?

    tav: same as other gradients.

    <ChrisL> gradientUnits="userSpaceOnUse"

    cyril: so what about padding and reflection?

    tav: how do you reflect somethign that is not a straight line?

    tab: there is no notion of padding and reflecting.

    cabanier: how would you do that?

    tab: there is a possibility to extend the gradient outside the edges
    of the patch, by reflecting the mesh.

    tav: what I have shown are symetrical gradients. People will use it
    to shade car seats, facial features. I am nto sure it is useful to
    pad and reflect.

    cyril: don't you want the geometry of the shape to match the mesh's

    tab: yes, the mesh would match the geometry.

    cyril: if you are going to use these gradients with a rectangle,
    fine, but if you use them with a path, shouldn't we use the path
    geometry for the mesh's defintion.

    tab: I thought of that initially.
    ... the last example (the lamp head), looks like it should be a

    tav: the lamp is one mesh gradient defined with many small patches.
    Four rows of patches.
    ... this shows how an authoring tool would work.
    ... the mesh structure is important to be able to edit the mesh
    easily in a tool.
    ... Illustrator only does arrays for meshes as well.

    cabanier: using an array of patches is the most common use case by
    far. PDF has more capabilities, but they are less commonly used.
    ... we have techniques to compress the mesh data.
    ... is this needed in SVG?

    tab: yes, it is commonly used in authoring tools.
    ... should it be a geometric primitive?
    ... I could see the path warping used for other things (warping
    shapes, text, images, four color interpolation).
    ... the mesh could be a geometric primitive and then take a fill of
    its own.

    heycam: we cannot do the square patch gradient right now.

    tab: we would need to define a new gradient for that.

    heycam: I am not sure. Some are very object specific, some are not.
    ... e.g., a rainbow.

    tab: yes, I can see that. But very often, you want to have the mesh
    and the object geometry match.

    heycam: what about having a patch reference the outside edge of a

    cabanier: that does not always work, like in the mesh wild example.

    heycam: yes, that would not work.

    shepazu: we ran into this with other case.

    heycam: there seem to be different use cases, one where it is
    generic and reusable and one where the mesh matches the object.
    ... neither way seems exactly right.
    ... what about PDF?

    cabanier: for meshes, there is a fill operator that does not rely on
    having a path.
    ... so the mesh is an object and you cannot stroke it.
    ... there is a second way where it is like a paint server.
    ... one is a geometric primitive and the second way is a paint

    tab: It could be done where the paint server renders if not in a
    <def> but can be referenced like other paint servers.

    shepazu: in SVG 1.1, you cannot just use anything as a marker or a
    clip-path and we went to have elements that defined the marker or
    the clip-path.
    ... you need to specify additional information.
    ... like transform, coordinate space.

    <ed> s/<def>/<defs>/

    heycam: I like tab's idea.

    RESOLUTION: mesh gradients are accepted by the WG for SVG 2.0.

    <scribe> ACTION: tbah to update the coon's mesh proposal to make it
    both a geometric primitive and a paint server. [recorded in

    <trackbot> Created ACTION-3096 - Update the coon's mesh proposal to
    make it both a geometric primitive and a paint server. [on Tavmjong
    Bah - due 2011-08-05].

    <tbah> I just got kicked out.. what was the conference code?

    <ChrisL> i got kicked out as well

current gradient issues.



    <tbah> zakim +39.537 is me


      [36] http://apike.ca/media/svg/exampleRadGradFP.svg


      [37] http://perso.telecom-paristech.fr/~concolat/exampleRadGradFP.svg

    ed: this behaves differently in all browsers

    <ed> <radialGradient id="myRadGrad" fx="80%" r="10%"
    spreadMethod="reflect" >

    heycam: when the focal point is within the shape and you have
    reflect or repeat, you are supposed to reflect the whole gradient to
    fill the shape, but the spec. does not say how to do that exactly.

    cyril: the issue is when the focal point reaches the edge of the
    gradial gradient

    <ChrisL> more is the pity, zakim

    <cyril_> s/gradial/radial/

    <ed> [38]http://www.w3.org/TR/SVG11/pservers.html#RadialGradients

      [38] http://www.w3.org/TR/SVG11/pservers.html#RadialGradients

    ed: FF has the most sensible interpretation.

    <ChrisL> so I see lack of sub-pixel precision in the opera rendering

    ed: if we want interoperable behavior, this needs to be clarified in
    the spec.

    heycam: it seems like the Firefox behavior looks the most

    ed: may be some people would like something different.

    vhardy: is that really a spec. problem?

    <ed> "Indicates what happens if the gradient starts or ends inside
    the bounds of the object(s) being painted by the gradient. Has the
    same values and meanings as the ‘spreadMethod’ attribute on
    ‘linearGradient’ element."

    <ed> this is for spreadMethod on radialGradient

    ed: yes, because the spec. for reflection on radialGradients is not
    precise enough, it only says to do the same thing as linear.

    <ed> this is what it says for spreadMethod on linearGradient:

    <ed> "Indicates what happens if the gradient starts or ends inside
    the bounds of the target rectangle. Possible values are: 'pad',
    which says to use the terminal colors of the gradient to fill the
    remainder of the target region, 'reflect', which says to reflect the
    gradient pattern start-to-end, end-to-start, start-to-end, etc.
    continuously until the target rectangle is filled, and repeat, which
    says to repeat the gradient pattern start-to-end, start-to-end,
    start-to-end, et

    <ed> c. continuously until the target region is filled.

    <ed> If the attribute is not specified, the effect is as if a value
    of 'pad' were specified."

    (group experimenting with the example)

    <ed> "If the point defined by ‘fx’ and ‘fy’ lies outside the circle
    defined by ‘cx’, ‘cy’ and ‘r’, then the user agent shall set the
    focal point to the intersection of the line from (‘cx’, ‘cy’) to
    (‘fx’, ‘fy’) with the circle defined by ‘cx’, ‘cy’ and ‘r’."

    Summary of the issue: when the focal point is on the circle edge,
    with repeat, then the distance between the first and last stop for
    the repeating colors is 0 and the spec. does not define what should

    tab: for the same problem with linear gradients in CSS, we resolved
    to have the average color of all the gradient stops.

    RESOLUTION: the spec. should say that when the focal point is on the
    circle edge, with repeat, then the distance between the first and
    last stop for the repeating colors is 0 and the paint should
    generate a color that is the average of all the gradient stops.

    <ed> s/the average/the weighted (by offset) average/

    <scribe> ACTION: ed to propose wording for the edge case where a
    radialGradient's focal point sits on the edge of the circle and the
    gradient repeats. the spec. should say that when the focal point is
    on the circle edge, with repeat, then the distance between the first
    and last stop for the repeating colors is 0 and the paint should
    generate a color that is the average of all the gradient stops.
    [recorded in

    <trackbot> Created ACTION-3097 - Propose wording for the edge case
    where a radialGradient's focal point sits on the edge of the circle
    and the gradient repeats. the spec. should say that when the focal
    point is on the circle edge, with repeat, then the distance between
    the first and last stop for the repeating colors is 0 and the paint
    should generate a color that is the average of all the gradient
    stops. [on Erik Dahlström - due 2011-08-05].

fr attribute on radialGradients

    ed: canvas can define the inner circle that the radial gradient
    focuses on. SVG could/should align to that by adding an fr attribute
    to control the focal radius.
    ... fr would define where you would hav the zero offset for stops.

    RESOLUTION: add an fr attribute to <radialGradient> for SVG 2.0.

    <scribe> ACTION: ed to provide spec. wording for the fr attribute on
    <radialGradient> [recorded in

    <trackbot> Created ACTION-3098 - Provide spec. wording for the fr
    attribute on <radialGradient> [on Erik Dahlström - due 2011-08-05].


    <heycam> ScribeNick: jenyu


    <cyril_> [41]http://www.w3.org/TR/SVGCompositing/

      [41] http://www.w3.org/TR/SVGCompositing/

    <cabanier> comments from Alex: The main problem I see now (after

    <cabanier> all this time not bothering to notice) is that we've
    mixed two orthogonal

    <cabanier> things into the one property.

    <cabanier> P-D dictates the combination logic for each of the 4
    alpha blend

    <cabanier> areas, namely src, dst, src&dst, no src or dst as the
    diagram at the top

    <cabanier> of the compositing spec. shows (the big square with
    coloured areas - yellow,

    <cabanier> mixed, blue and white).

    <cabanier> What the blending modes do is apply only to the top
    triangle which

    <cabanier> manages how you mix src & dst. In all the blend modes, we
    are assuming

    <cabanier> P-D src over which is compatible with PDF, etc.

    <cabanier> But the problem I see now is that's too restrictive. It
    may well

    <cabanier> be nice to use an 'in' operator to restrict the effect to
    the intersection

    <cabanier> of two objects but have them combined with a blend mode
    (like overlay, etc.)

    <cabanier> That seems an obvious thing to do, but there is no way to
    do it as the

    <cabanier> spec. is written now. We've overloaded 'comp-op' and this
    isn't possible.

    <cabanier> So the only way to achieve that is to use a clip path and

    <cabanier> one object against the other and use the correct comp-op
    to get the

    <cabanier> color mix correct which is quite a hack.

    <cabanier> In hindsight I'm a bit surprised this hasn't been noticed

    <cabanier> but that's most likely due to lack of implementations and

    cabanier: question: do we keep the adobe blending modes (aligned
    with current spec) or porter duff?
    ... porter duff seems too primitive for SVG

    <cyril_> adobe blending modes:


    : what's the hardware support for the blend modes like?

    cabanier: adobe modes can be done in hardware; pixel shaders are
    always possible anyway

    <cyril_> chapter 11, table 136, in


    heycam: can you do these with filters? there's feComposite and

    <vhardy> [44]http://www.w3.org/TR/SVG/filters.html#feBlendElement

      [44] http://www.w3.org/TR/SVG/filters.html#feBlendElement

    vhardy: we should be consistent in our blend modes in filters and

    cabanier: alex proposed that we should remove the underspecified
    compositing features and spend time carefully specifying the needed
    ... you can achieve effects with filters but it makes it hard to

    heycam: given that we are introducing the filter property, does it
    make sense to make compositing a shorthand to a filter?

    vhardy: describing it as a comp-op is a much clearer model than
    using filters

    heycam: what's the difference between blend and general compositing

    vhardy: blend modes -- you have a destination and need to composite
    a shape onto it; porter duff -- take 2 bitmaps and figure out how to
    combine them



    vhardy: blend is a function of destination and source pixels <--
    definition of compositing operation. clip-to-self adds a clipping
    operation to that compositing operation. porter-duff and adobe blend
    modes just use different formulas for the compositing operations

    cyril: is it implicit that compositing operations are chained?

    vhardy: the painting algorithm is followed, so yes comp-ops apply in
    a sequential chain

    cabanier/cyril: [drawing nested g elements on the board with comp-op

    vhardy: [drawing more nested groups and shapes on the board, some
    with comp-op]
    ... [top-level group contains enable-background="new" for the
    comp-op operations in its child elements]

    heycam: why do we even have enable-background=accumulate? why don't
    we just start a new buffer every time there's a compositing

    cabanier: this was discussed previously. peter has a use case for it
    and feels strongly about it

    heycam: it will be hard to reach a resolution. not many people
    understand this completely

    cabanier: the pdf file describes this in detail (which is very
    similar to compositing described in the SVG spec)
    ... the knock-out property seems ill-defined. the formulas are not
    quite correct

    vhardy: we need 1) a description that the group can easily
    understand about why to split out porter-duff and blend modes and
    what the differences are, with examples and 2) is enable-background
    the same for compositing as it was in SVG1.1?

    <scribe> ACTION: Give a description of how porter-duff behaves
    differently from blend modes (group invariance) [recorded in

    <trackbot> Sorry, couldn't find user - Give

    <scribe> ACTION: cabanier to Give a description of how porter-duff
    behaves differently from blend modes (group invariance) [recorded in

    <trackbot> Created ACTION-3099 - Give a description of how
    porter-duff behaves differently from blend modes (group invariance)
    [on Rik Cabanier - due 2011-08-05].



css dependencies



    ChrisL: In SVG2, we should depend on CSS2.1. SVG1.1 depended on
    CSS2. There have been some changes between the two, primarily the
    box model (doesn't affect SVG) and selector precedence (but
    practically speaking, this isn't an issue since everyone aligns with
    CSS2.1 here, including the svg 1.1 tests)

    ed: the clip property is another one that changed from CSS2 and 2.1
    ... browsers aren't interoperable on the clip property so no one
    uses it anyway

    resolution: SVG2 will depend on CSS2.1
    ... SVG2 will depend on CSS3 Fonts

    ChrisL: Virtual text and bidi is implemented in some of the plugins
    that supported SVG but not in many browsers

    heycam: text layout should occur according to writing modes and have
    text positioning and glyph layouts occur afterwards

    resolution: SVG2 will depend on CSS3 writing modes
    ... SVG2 will use CSS3 definitions for text layout (whitespacing,
    bidi, etc) that is not specific to SVG
    ... SVG2 will depend on CSS3 Color

    ChrisL: Media queries are useful for conditional formatting such as
    for printing

    heycam: do we want to require support for CSS
    ... it's too early to depend on it

    vhardy: maybe we can depend on the result of the results of the FX
    task force

    resolution: SVG2 will depend on CSS3 Media Queries

    schepazu: SVG2 should point to a bunch of different modules -- eg
    filters can point to the Filters spec, animations can point to CSS
    animations. The spec itself can be smaller.

    heycam: we are not going to depend on CSS Transitions/Animations

    shepazu: what's the timeframe for SVG2?

    ChrisL: CSS3 Image Values

    cyril: CSS3 image values as SVG paint servers, we should include it

    sylvaing: CSS3 Image values was split into 2 specs -- CSS3 and CSS4
    image values. 3 includes gradient, element,

    resolution: SVG2 will depend on CSS3 Image Values and CSS4 Image

    ChrisL; SVG 1.1 depends on selectors in CSS2, but there's now CSS3
    selectors that's about to be published and proposed rec status

    ChrisL: We should adopt the selector and namespace spec for SVG2
    ... CSS style attribute syntax

    resolution: SVG2 will depend on CSS style attribute syntax

    <ChrisL> [50]http://www.w3.org/Style/CSS/specs#text

      [50] http://www.w3.org/Style/CSS/specs#text

    <ChrisL> "The Text module has been split into three parts: Text,
    Writing Modes, and Line Grid."

    resolution: SVG2 will depend on CSS3 Selectors and CSS3 Namespaces

    <ChrisL> Line Grid describes text where each symbol in a line is
    aligned to an invisible grid, so that symbols in all lines line up

    resolution: SVG2 will depend on WOFF

    <ChrisL> draft css charter for next 2 years


      [51] http://www.w3.org/2010/09/CSSWG/charter.html#deliverables

    resolution: SVG2 will depend on CSS UI and CSS Values and Units

    <heycam> ScribeNick: heycam

Next F2F

    CM: I think we agreed to meet both adjacent to SVG Open and at TPAC

    <ed> [52]http://www.w3.org/2011/11/TPAC/

      [52] http://www.w3.org/2011/11/TPAC/

    CL: I think we agreed to meet for a couple of days before SVG Open
    ... plus the 2 days at TPAC
    ... and I think we decided before SVG Open so that we could give
    status updates at the conference

    <cyril> SVG Open 2011: October 17-20

    <cyril> TPAC 2011: 31 October to 4 November 2011

    CC: some people would want to come just for one of the halves of the
    WG meeting
    ... or maybe both meetings but not SVG Open



    CL: the workshops are on the fourth, the thursday

    <ChrisL> s/fourth/fourth day/

    <ChrisL> in my calendar we have thurs and fri as the f2f

    <ChrisL> [54]http://www.w3.org/2011/11/TPAC/#Finalized

      [54] http://www.w3.org/2011/11/TPAC/#Finalized

    CC: how about moving the two days of additional F2F meeting time to
    just before TPAC instead of just after SVG Open

    CM: that makes sense to me

    CL: have the two days on 27th and 28th (Thursday and Friday)?

    CM: ok, let's ask MS to host, and if not perhaps Google can

    RESOLUTION: We will meet on 27th and 28th October for the first half
    of our F2F

SVG 2 scope

    DS: I can see two ways of approaching the problem
    ... we can either go at it from a schedule perspective, or a feature
    ... in the former, just see how much we can get done in a certain
    ... alternately, we could say these are the features we want to
    have, we take as long as it needs

    CL: I thought we would go somewhere in between
    ... decide roughly what features we want, see how it goes, drop some
    features if they are slowing things down

    DS: I would kind of like to have a schedule we can work with

    CC: you will have to keep to your schedule
    ... you were talking about 1, 2 or 3 years?
    ... I don't think 1 year is possible

    CL: I think a year is ridiculous unless we're already in CR
    ... I also don't want to just produce an SVG 1.1 rewritten in new
    words but has exactly the same features

    CC: if we say to the world we are starting on a new version, people
    may come forward with new features they want
    ... and we'd have lots of things to deal with
    ... I agree 1 year is impossible

    JY: if you throw out unrealistic numbers ...

    CM: so two years until what?

    CC: rec?

    VH: in software development you set out a date for when you want to
    do something that seems on the outskirt reasonable, achievable
    ... and try to lay out a plan to get there, think about your
    ... and then you start executing
    ... when you get through the milestones you adjust your schedule, or
    you lighten the boat and still make the date

    SG: features, quality, ship date. you can have only two.

    VH: I think it's good to have a goal
    ... if you have a schedule like doug is asking, we can have
    milestones for what we want to achieve
    ... maybe by the next F2F we can freeze our requirements document

    CM: that's a good concrete suggestion

    DS: one reason I'm asking is that we got pushback on our charter
    since we didn't have any dates in there
    ... they want milestones in terms of "when are you getting to FPWD,
    LCWD, etc."
    ... I think there's another way of gauging milestones
    ... when are we going to have a test suite, complete
    implementations, etc.

    VH: if you take the regular track process, we additionally need a
    goal for the requirements document in some form
    ... and then a goal for the test suite

    DS: I'd rather have that worked on continuously while we're doing it

    VH: so we may set ourselves our own goals

    SG: in CSS we have someone who owns the test suite to check for
    normative statements, etc.

    DS: in one group I'm in, we didn't do it, but we thought hard about
    saying the criteria for going from Editor's Draft to FPWD is to have
    tests for it
    ... which is a pretty heavy discipline, we didn't end up going for
    it, but we should consider it
    ... everyone agrees it's a great idea, right?
    ... what are the incentives and mechanisms we're going to use to
    decide if a spec section is mature?

    ED: I liked how the CSS test harness listed how many tests there
    were for a given section

    DS: if we pair that with markup with the spec itself, that indicates
    thte normative assertions, and we can say there are 14 testable
    assertions and 25 tests

    VH: I really like what Sylvain was saying. a good way to ensure we
    make progress is to try to have people focus on different things.
    for SVG 2.0 we need to do work on tests, we need to do work on new
    features like RIk on Compositing
    ... that's clearly work as well
    ... the other part would be integration of new features in the spec
    and adapting the spec to the new CSS references
    ... we need one or two editors that integrate new work, changes to
    references, and people who provide content for the spec
    ... so we should authors for sections
    ... and we should have people assigned to work on tests
    ... for SVG 1.0 we had nearly all the group work on the test suite
    ... now we have a whole body of tests...

    CM: people who are working on new features are probably the best
    people to write tests for it, though

    DS: when I write tests it helps me with the prose writing

    VH: if we follow what Sylvain was saying, should we try to organise
    our work around these roles?
    ... we have clear milestones for the spec overall -- a first one is
    just to get the spec building
    ... and then we can grow that

    DS: I think it would be really good if we could demonstrate rather
    quickly, some time this year, to have a FPWD
    ... by mid november say

    ED: I agree
    ... it should include some new features by then too

    CC: we already have decided on some new things here, like
    catmull-rom curves

    ED: we should highlight these new things

    DS: we could have the catmull-rom curves specced out fairly quickly
    ... we have a script implementation

    VH: how do we capture that? on the wiki?

    ED: yeah

    VH: I will create a page

    ED: I think it's a good idea to have at least two people driving
    each feature
    ... so they can review each others' work

    VH: we should have a "what's new in SVG 2" section in the spec

    CL: I'm a bit worried about overpromising
    ... but I like the idea of testing up front

    ED: I think we should have one person at least driving a feature,
    and one person assigned to be the reviewer of that section

    CC: coming back to timeframe
    ... it's difficult to say when we want to produce a final REC or PR
    ... but I think we can say what we don't want to do
    ... five years is too much
    ... one year is too little

    <ChrisL> 3

    CM: having issued First Last Call WD by two years?

    <ChrisL> sure

    VH: I think we should have feature list settled by TPAC
    ... like gradient meshes, path improvements, etc. and say that's

    DS: also we have to worry about how long implementations will take
    to catch up
    ... we definitely need new features, but once we have the momentum
    going we can always add more

    CC: do you plan to have a "call for features"?

    DS: we talked a bit about that before. we have already sort of made
    a bit of an open call for features. we'll ask again, when they see
    we're serious... with a FPWD

    VH: let's have a proposed requirements document to bring in to TPAC
    ... and to resolve on it at that meeting

    DS: we should have use cases for them, too

    VH: they should be in that document

    CC: and examples of existing technologies doing it

    VH: I will add some proposed milestone dates to the wiki page and we
    can discuss that on a telcon soon

    DS: one set of use cases and requirements that I'm interested in is
    looking at WebCGM and seeing what precisely SVG would need to have
    to replace WebCGM
    ... we've had a lot of people ask for this

    SG: that's a source of use cases there

    <cyril> s/existing technlogies/existing technologies (proprietary or

    CC: we should look at SVG Tiny 1.2 to see what features there we
    want to bring forward

    <scribe> ACTION: Cyril to look at SVG Tiny 1.2 and come up with a
    list of major features that aren't in 1.1 [recorded in

    <trackbot> Created ACTION-3100 - Look at SVG Tiny 1.2 and come up
    with a list of major features that aren't in 1.1 [on Cyril Concolato
    - due 2011-08-05].


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

    VH: somebody should own the requirements document


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

Media resources spec review

    ED: I posted some comments to our list for review



    <cyril> [59]http://www.w3.org/TR/mediaont-api-1.0/

      [59] http://www.w3.org/TR/mediaont-api-1.0/



    <scribe> ACTION: Cyril to respond with comments on the API for Media
    Resources 1.0 spec [recorded in

    <trackbot> Created ACTION-3101 - Respond with comments on the API
    for Media Resources 1.0 spec [on Cyril Concolato - due 2011-08-06].

sharing path segments

    CC: if you look at this wiki page


      [62] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements

    scribe: the shared/reverse path link is an SVG Open presentation my
    colleague presented last year
    ... one use case is maps, the other is comics
    ... in those kinds of content, you re-use many paths
    ... sometimes you use them as a border of two regions
    ... sometimes when you mkae holes in a shape, by overlapping another
    shape on top of it, you may have shared borders there
    ... he tried to work on solutions to reuse this path
    ... if you look at slide 16 he proposed a syntax using superpath and
    ... he discovered vePath and vePathRef in SVG 1.2 Full
    ... the gist of it is, we think it's important to have this feature
    in SVG, the ability to create apath by concatenating existing paths
    and reversing them
    ... it's important for animation, file size reduction, doing
    adaptation like LoD with consistent degredation of paths
    ... so we think it's important to be in SVG 2
    ... don't care if it's vePath or superpath

    DS: this seems very closely linked to the idea of the extended path
    syntax where it expands out into elements

    CC: the canon proposal?

    DS: the one used for EXI
    ... instead of a compact syntax...

    CC: it's a different thing
    ... compact vs non-compact has dom implications
    ... I just want to talk about requirements first
    ... do you agree it would be nice?

    DS: yes

    CM: yes

    CC: then syntax discussion

    DS: styling, if they're shared paths -- if the outline of germany is
    one colour and the outline of france is another, what would be
    ... you could have only inner strokes and then the countries edges
    would not overlap

    <scribe> ACTION: Cyril to write up proposal page for path shared
    edges [recorded in

    <trackbot> Created ACTION-3102 - Write up proposal page for path
    shared edges [on Cyril Concolato - due 2011-08-06].

polar element

    DS: there were some discussions, Dr O made a proposal

    <shepazu> [64]http://svg-whiz.com/svg/StarMaker.svg

      [64] http://svg-whiz.com/svg/StarMaker.svg

    DS: we never ended up having a regular polygon/star shape
    ... you can do them, but it's not trivial
    ... it would be good for dynamic updates to have a geometric star
    shape than a path you have to change the geometry of

    <ed> [65]http://hoffmann.bplaced.net/svgueb/polar.php

      [65] http://hoffmann.bplaced.net/svgueb/polar.php

    DS: Olaf's page can do more complex things than mine

    CC: why does it need to be declarative? for animations?

    DS: you can do it in JS, but sometimes I just want to say "I want a
    hexagon that fits in this box"

    CM: with the path rotation command it becomes reasonably easier to
    do regular polygons
    ... stars too

    CC: so we agree on the use case
    ... we have these three ways we can do it, your polar, olaf's polar,
    path rotation command

    DS: spirals is another one

    <scribe> ACTION: Doug to make a wiki proposal page for
    polar/star/polygon/path extensions [recorded in

    <trackbot> Created ACTION-3103 - Make a wiki proposal page for
    polar/star/polygon/path extensions [on Doug Schepers - due



    vhardy, [68]http://www.w3.org/Graphics/SVG/WG/track/actions/3045

      [68] http://www.w3.org/Graphics/SVG/WG/track/actions/3045

Summary of Action Items

    [NEW] ACTION: cabanier to Give a description of how porter-duff
    behaves differently from blend modes (group invariance) [recorded in
    [NEW] ACTION: ChrisL to write up spec text for currentFillPaint,
    etc. [recorded in
    [NEW] ACTION: Cyril to look at SVG Tiny 1.2 and come up with a list
    of major features that aren't in 1.1 [recorded in
    [NEW] ACTION: Cyril to respond with comments on the API for Media
    Resources 1.0 spec [recorded in
    [NEW] ACTION: Cyril to write up proposal page for path shared edges
    [recorded in
    [NEW] ACTION: Doug to make a wiki proposal page for
    polar/star/polygon/path extensions [recorded in
    [NEW] ACTION: ed to go through the last few f2f minutes to find
    resolutions for SVG2 items, and add them to the wiki page. [recorded
    in [75]http://www.w3.org/2011/07/29-svg-minutes.html#action02]
    [NEW] ACTION: ed to propose wording for the edge case where a
    radialGradient's focal point sits on the edge of the circle and the
    gradient repeats. the spec. should say that when the focal point is
    on the circle edge, with repeat, then the distance between the first
    and last stop for the repeating colors is 0 and the paint should
    generate a color that is the average of all the gradient stops.
    [recorded in
    [NEW] ACTION: ed to provide spec. wording for the fr attribute on
    <radialGradient> [recorded in
    [NEW] ACTION: Give a description of how porter-duff behaves
    differently from blend modes (group invariance) [recorded in
    [NEW] ACTION: tbah to update the coon's mesh proposal to make it
    both a geometric primitive and a paint server. [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [80]scribe.perl version 1.136
     ([81]CVS log)
     $Date: 2011/07/30 01:04:08 $

      [80] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [81] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43
Check for newer version at [82]http://dev.w3.org/cvsweb/~checkout~/2002

      [82] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/icc/cmyk/
Succeeded: s/sbasic/sbasis/
Succeeded: s/test/mesh/
Succeeded: s/yes/no/
Succeeded: s/tab/tav/
Succeeded: s/case/cases/
FAILED: s/<def>/<defs>/
FAILED: s/gradial/radial/
FAILED: s/the average/the weighted (by offset) average/
FAILED: s/fourth/fourth day/
FAILED: s/existing technlogies/existing technologies (proprietary or no
Found ScribeNick: TabAtkins_
Found ScribeNick: heycam
Found ScribeNick: TabAtkins_
WARNING: No scribe lines found matching ScribeNick pattern: <TabAtkins_
 > ...
Found ScribeNick: heycam
Found ScribeNick: TabAtkins_
WARNING: No scribe lines found matching ScribeNick pattern: <TabAtkins_
 > ...
Found ScribeNick: heycam
Found ScribeNick: TabAtkins_
Found ScribeNick: heycam
Found ScribeNick: TabAtkin1_
Found ScribeNick: vhardy
Found ScribeNick: jenyu
Found ScribeNick: heycam
Inferring Scribes: TabAtkins_, heycam, TabAtkin1_, vhardy, jenyu
Scribes: TabAtkins_, heycam, TabAtkin1_, vhardy, jenyu
ScribeNicks: TabAtkins_, heycam, TabAtkin1_, vhardy, jenyu

WARNING: Replacing list of attendees.
Old list: +1.206.675.aaaa tbah ChrisL +39.537.7.aabb
New list: +1.206.675.aaaa ChrisL

Default Present: ChrisL, +1.206.675.aaaa
Present: ChrisL +1.206.675.aaaa

WARNING: Fewer than 3 people found for Present list!

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 29 Jul 2011
Guessing minutes URL: [83]http://www.w3.org/2011/07/29-svg-minutes.html
People with action items: cabanier chrisl cyril doug ed give tbah

      [83] http://www.w3.org/2011/07/29-svg-minutes.html

    End of [84]scribe.perl diagnostic output]

      [84] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Saturday, 30 July 2011 05:38:49 UTC

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