minutes, SVG Working Group Mountain View F2F, day 2

Minutes here:


and below as text:


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

                                - DRAFT -

                    SVG Working Group Teleconference

28 Oct 2011


       [2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda

    See also: [3]IRC log

       [3] http://www.w3.org/2011/10/28-svg-irc


           Chris, Erik, Daniel_Holbert, Jen, Jun, Takagi-san, Cyril,
           Vincent, Cameron

           Erik, Cam



      * [4]Topics
          1. [5]SVG2 Requirements Input
          2. [6]Custom data attributes
          3. [7]randomisation
          4. [8]Consider adding certain HTML attributes used in
          5. [9]Consider relaxing case sensitivity of presentation
             attribute values
          6. [10]Fluorescent colours/extended colour specifiers
          7. [11]non-scaling stroke
          8. [12]non-scaling rounded rect corners
          9. [13]variable stroke-width
         10. [14]perpendicular stroke
         11. [15]define behavior of stroke-dasharray
         12. [16]adaptive stroking
         13. [17]hatch fills
         14. [18]arbitrary fill
         15. [19]SVG using webgl filters
         16. [20]consider adding an href to style element to link to
             external stylesheets
         17. [21]add HTML5 style-element attributes to SVG's style
         18. [22]alternative transforms
         19. [23]other 2.5D effects
         20. [24]Support getting bounding boxes that include stroke
             and/or markers
         21. [25]Consider allowing rotations to be relative to their
             bounding box center
         22. [26]vector effects
         23. [27]stroke-related feature requests
         24. [28]stroke-dash adjustments
         25. [29]SVG Params
         26. [30]Catmull-Rom curves
         27. [31]stroke-dash-corner
         28. [32]SVG 2 Requirements
         29. [33]shared paths
         30. [34]Connectors
         31. [35]Skeleton frames
         32. [36]Declarative drawing
         33. [37]Turtle graphics
         34. [38]Smooth curve through points
      * [39]Summary of Action Items

    <heycam> ... there was a level of zoom requirement item too

    <heycam> ... just put an attribute for minimum/maximum zoom level on
    any element

    <heycam> CM: the Tiling/Layering will be a separate document, right?

    <heycam> CL: that won't allow you to do the complex/simpler path
    kind of level of detail though

    <heycam> [discussion of differences between tiling, LoD, auto

    <heycam> RESOLUTION: We won't include automatic fetch/discard in



    <heycam> CM: this one sounds more interesting to me



    <heycam> RESOLUTION: We will support Level of Detail control in



    <heycam> CC: now the one we should go back to is templating for
    controls and widgets

    <ed> ED: already resolved earlier this morning



    <heycam> ED: next, transform on svg elements

    <heycam> CL: what does that help with?

    <heycam> ED: nested svg elements

    <heycam> CM: seemed odd to me not to allow transform on svg

    <heycam> ... but it might be confusing for authors wrt order of
    application of transform and viewBox

    <heycam> RESOLUTION: We will allow transform on <svg> in SVG2.

    <heycam> ED: next, allowReorder on switch



    <heycam> CL: this came out of a request from mozilla that switch
    with requireLanguage is less useful when you have a list of ordered
    preferred user languages

    <heycam> ... it got added in SMIL3

    <heycam> CM: it has a bad name

    <heycam> RESOLUTION: We will support a mechanism like or the same as
    allowReorder from SMIL3 in SVG2.



    <heycam> ED: next, allow referencing root external files with use

    <ChrisL> ISSUE-2238:

    <heycam> DH: with <use>, you get the same animation timeline, vs if
    you use image

    <heycam> CM: also with events you can distinguish which shadow tree
    elements was clicked, for example

    <heycam> DH: would this apply to other things that reference
    external elements, like mask?

    <heycam> ED: maybe wouldn't make sense there

    <heycam> CC: there is the animation element in 1.2T, is that
    relevant here?

    <heycam> ED: but that only references a whole document anyway

    <heycam> CL: in 1.2T we split it up into <image> for more static
    images, and <animation> for animated ones

    <heycam> ... with <animation> you can use the SMIL timing attribtues
    on it, so you can control its timeline separately

    <heycam> ... but you can't do that with animated SVG referenced from

    <heycam> ... the name animation is confusing though, compared to

    <heycam> ... in the end though image was able to point to svg

    <heycam> ... so we may or may not want to keep <animation>, possibly

    <heycam> RESOLUTION: We will relax referencing requirements to
    particular elements to allow dropping fragments to mean referencing
    root element, where it makes sense, such as with use, in SVG2.

    <heycam> ACTION: Cyril to investigate whether more than use would
    benefit from relaxing reference requirements so that "blah.svg"
    refers to the root element [recorded in

    <trackbot> Created ACTION-3157 - Investigate whether more than use
    would benefit from relaxing reference requirements so that
    "blah.svg" refers to the root element [on Cyril Concolato - due



    <heycam> ED: next, in the Attributes section, is Parameters

    <heycam> CC: we need this

    <heycam> DS: we decided last time that we would not make this

    <heycam> CC: in what sense?

    <heycam> DS: in the sense that this would not be a CSS thing, it's
    an SVG thing

    <heycam> ... although people are going to want to pass things in to

    <heycam> ... in CSS embedded in SVG, you would want a legal value to
    be a param

    <heycam> ... I think we thought it would take too long to get into
    CSS as well

    <heycam> ... but having it attribute only would have this downside

    <heycam> ... especially if people are using SVG and CSS together

    <heycam> CM: I would really like to see if we can use CSS Variable
    as the in-CSS way to reference parameters

    <heycam> DS: maybe we should move ahead with it as a separate spec

    <heycam> CL: Tab is in general happy to add new values to CSS Values

    <heycam> DS: it's effectively like calc, in terms of scope

    <heycam> ... I see param working with calc really well

    <heycam> CC: do we want to allow params to work with presentation
    attributes, style properties, geometry attributes, SMIL

    <heycam> DS: I want it to apply to every SVG attribtue, and maybe
    property values as well

    <heycam> CC: how about using them in script?

    <heycam> DS: there's the DOM interface that exposes params and their

    <heycam> ... anything I do with params I would like to decompose a
    shorthand for Component Model

    <heycam> [discuss some details of Params]

    <heycam> DH: I would be a bit concerned about being gated on CSS

    <heycam> DS: we could say that for now, it works only in attributes,
    but that we're open to the CSS WG allowing this in property values

    <heycam> ... and I'd expect there'd be experimental implementations
    to see if there are any issues with allowing that

    <heycam> CL: we did already talk about this within FX

    <heycam> RESOLUTION: We will have Parameters in SVG2, worked on in a
    normatively referenced separate spec.

    <ChrisL> Meeting; SVG WG f2f Mountain View

    <heycam> shepazu,

      [48] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/

    1075 La Avenida

    Mountain View, CA 94043

    Tel: (650) 693-1005

    Building 5

    <shepazu> thanks

    <trackbot> Date: 28 October 2011

    <heycam> Meeting: SVG Working Group Mountain View F2F 2011, day 2

    <heycam> Chair: Cameron

    <ChrisL> Scribenick: ChrisL

SVG2 Requirements Input



Custom data attributes

    heycam: this is to align with HTML5
    ... confusing to not be abletodio this in mixed html5/svg

    (general agreement)

    resolution: we willadd data-* attributes in SVG2 to align with HTML5


    ed: this could be done in script

    cc: there is not much of a proposal here

    resolution: we will not add declarative randomisation functionality
    in SVG2



Consider adding certain HTML attributes used in microformats


    <trackbot> ISSUE-2048 -- Consider adding certain HTML attributes
    used in microformats -- raised

    <trackbot> [51]http://www.w3.org/Graphics/SVG/WG/track/issues/2048

      [51] http://www.w3.org/Graphics/SVG/WG/track/issues/2048

    ChrisL: ARIA isalso somethig that should be supported - related

    heycam: higher level goal is to bring across globalattributes
    thatmake sense, ratherthan thesespecific ones
    ... consider together with aria

    resolution: we will align with HTML5 globalsemantic attributes
    wherethese make sense for SVG

    <scribe> ACTION: ChrisL to look at global attributes [recorded in

    <trackbot> Created ACTION-3158 - Look at global attributes [on Chris
    Lilley - due 2011-11-04].



Consider relaxing case sensitivity of presentation attribute values

    heycam: there were complaints about this at svgopen

    vhardy: the complaint was actually attribute and element names being
    case sensitive
    ... we could deprecate oneset of names and introduce new ones

    ChrisL: makes more confusion than it helps

    vhardy: example is textPath, cant search for getElementbyTagName

    ChrisL: so it does work as long as you spell it consistently

    heycam: tested just now, it recognises the statndard spelling but
    does not recognised the fixed-up name

    <heycam> If you have `<!DOCTYPE html>...<textpath ...>` then you do
    document.getElementsByTagName("textpath"), it won't find the element

    <heycam> but if you do ...getElementsByTagName("textPath") it will

    <heycam> If you have `<!DOCTYPE html>...<textPath ...>` and you do
    document.getElementsByTagName("textPath"), it will find it

    ChrisL: it only fixes up when parsing, not in script

    heycam: wonder about adding magic to getElementsByTagName

    cyril: two issues,values and element/attribute names.

    heycam: any objections to making property values as attributes case

    cyril: IDs are case sensitive

    erik: all presentation attributes are safe to do this with

    resolution: make property values case insensitive

    ChrisL: so in the dom the case is preserved?

    heycam: yes

    ChrisL: sad that the dom is still required to preserve whatever case
    combination was used each time, in case you ask for it back
    ... could this be normalised like we did in udom?

    heycam: hellno



Fluorescent colours/extended colour specifiers

    (chris talks at lemngth and forgets to minute)


      [55] http://dev.w3.org/SVG/modules/color/publish/SVGColor.html

    <scribe> ACTION: chris to reply to alex explaining how wide gamut
    colours and flourewscent/metallic printing are accomodated in SVG
    color [recorded in

    <trackbot> Created ACTION-3159 - Reply to alex explaining how wide
    gamut colours and flourewscent/metallic printing are accomodated in
    SVG color [on Chris Lilley - due 2011-11-04].


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

    ChrisL: have several offers of reviews for this. would like to
    publish, get the review, then go to w3c last call

    heycam: should this be normatively required by SVG2

    this is something operating systems all do not (but not onmobile)

    cyril: name is confusing can we rename to color-management
    ... intro shouldsay it is a supersetof SVG color chapter and of CSS3

    ChrisL: yes it should state that explicitly

    ed: what t do with css3 images and css gradients as they affect
    ... ok with the conformance class that does color managed images

    heycam: we can have several conformance clasees in this spec then
    decide later which ones svg2 requires

    ChrisL: happy with that

    resolution: svg2 will depend on svg colormanagement subject to
    deciding the exact conformance classes required

    ChrisL: this could be a separte module or it could be a chapter, its
    written as a drop-in replacement actually
    ... makes more sense to have this as the color chapter in fact


    resolution: svg colormanagement becomes a chapter in SVG2

    <scribe> ACTION: ChrisL to edit the svg colormanagemtn spec into a
    chapter in SVG2 [recorded in

    <trackbot> Created ACTION-3160 - Edit the svg colormanagemtn spec
    into a chapter in SVG2 [on Chris Lilley - due 2011-11-04].

    <scribe> scribenick: dholbert



non-scaling stroke

    CM: lots of people want this, and it's not too hard to implement

    CL: Yes

    <tbah> Hi, phone?

    resolution: svg2 will include non-scaling stroke

    <ChrisL> tbah: inkscape has non scalingstroke and non scalling



non-scaling rounded rect corners

    ED: maybe things in general that are non-scaling could go into
    another coordinate system

    CM: might be interesting to look into other things that you might
    want to not scale

    CC: e.g. rectangle with radius=5 on the corner, you might want to
    grow the rectangle but not grow the radius of the corner
    ... there's also non-scaling whole objects, e.g. legends in a map

    CL: doesn't tiny 1.2 let you do something like that, by saying "this
    part is in the coordinate system over there"?

    CC: we also have the transformBehavior attribute, for video

    <stakagi> ref(svg,x,y)?

    CC: it has the value 'pinned' which would help with this as well

    ED: it'd be nice to hear more about the non-scaling things in

    CL: non-scaling patterns (inkscape option) sounds interesting

    CM: perhaps tav can write up a summary of inkscape's non-scaling

    TB: sure

    <scribe> ACTION: tav to write up summary of inkscape's non-scaling
    features, as possible candidates for svg2 [recorded in

    <trackbot> Created ACTION-3161 - Write up summary of inkscape's
    non-scaling features, as possible candidates for svg2 [on Tavmjong
    Bah - due 2011-11-04].

    resolution: svg2 should include non-scaling features, aside from
    non-scaling stroke. (2 separate components: non-scaling part of the
    object, and non-scaling entire object)

variable stroke-width



    CL: we're lacking a fully fleshed-out proposal for this
    ... we don't want to be forced to put stroke-width "stops" only at
    the nodes
    ... more like a gradient, with stops that can be specified
    ... and each stop has a stroke-width specified

    VH: how do you author variable stroke-width in inkscape?

    TB: there are 2 ways. the one in inkscape is
    ... you draw a path, and then a second path the "skeleton", and the
    first path is warped along the skeleton
    ... one path describes the width, and that gets put along the other
    ... e.g. you could draw a lizard, and bend the lizard along the path
    ... so that's the first method. the second method is: you add nodes
    along the path, and manipulate those (like what CL described with



    VH: warping is interesting, since we need to do that for text anyway

    CL: but the "stops" way is more natural for e.g. drawing with a
    pressure-sensitive pen

    resolution: svg2 shall include variable stroke-width

perpendicular stroke



    ED: I think this is roughly the same as stroke-position

    CM: This is something many people want to be able to do

    resolved: svg2 shall include a way to specify stroke-position

    resolution: svg2 shall include a way to specify stroke-position



define behavior of stroke-dasharray



    CM: what isn't defined at the moment?

    CL: the start point of the dashing on basic shapes like circles
    ... and on multi-segment paths, e.g. if you're partway through a
    dash at the end of one segment, do you start the next segment with
    just a partial dash

    resolution: svg2 shall specify stroke dashing more precisely

adaptive stroking



    CM, to be able to do things like align dashes exactly on corner of a

    resolution: svg2 shall allow more author control over positions of

hatch fills



    TB: Couple problems with trying to use patterns for this. one is, if
    you use a diagonal line, you'll often get misalignments
    ... also, SVG is used for e.g. engravers, who want to be able to do
    one continuous stroke across a background.

    CL: same applies to plotters

    CM: not sure if this would have a predefined set of hatches, or let
    you define your own

    CC: could be useful for cartoons

    ED: though in that case you could probably just use a pattern

    <ChrisL> Hatching (hachure in French) is an artistic technique used
    to create tonal or shading effects by drawing (or painting or
    scribing) closely spaced parallel lines

    <ChrisL> [69]http://en.wikipedia.org/wiki/Hatching

      [69] http://en.wikipedia.org/wiki/Hatching

    VH: I've encountered the issue with patterns. the main convincing
    argument to me is TB/CL's points about one needing continuous lines
    for certain use-cases

    CM: It seems like something worth looking into

    resolution: svg2 should support hatching without the artifacts that
    patterns currently impose

    <ChrisL> [70]http://fr.wikipedia.org/wiki/Hachure has more detail

      [70] http://fr.wikipedia.org/wiki/Hachure

arbitrary fill



    CM: sounds like we've got this already solved by CSS image-values

    CL: seems like this could be simpler than that though, just
    expanding the types of things that are allowed as paint servers

    CC: would we need to specify preserveAspectRatio=meet|slice?

    JY: would we need the background-* properties? e.g.
    background-position, background-size

    CM: SVG doesn't really know about background images at the moment

    CL: but we could model the behavior off of that, perhaps

    resolution: svg2 shall support filling and stroking from arbitrary

SVG using webgl filters



    ED: I think it's covered by CSS shaders, depending on the outcome of
    the discussion there

    CM: there's a question of whether that's a hard dependency

    CL: the ability to write custom shaders is pretty important

    resolution: svg2 shall support custom filters (shaders)

consider adding an href to style element to link to external



    CM: I wouldn't like to be different from HTML's syntax for this
    ... and note that you can already @import from inside of style

    <ChrisL> ISSUE-2049: this would diverge ftom HTML, better to add the
    link element. Can also do @import

    <trackbot> ISSUE-2049 Consider adding an href to the style element
    to link to external stylesheets notes added

    JY: perhaps this is wanting to bring in the <link> element? (that's
    what is used for this in HTML)

    resolution: svg2 shall not add href to the <style> element

add HTML5 style-element attributes to SVG's style element



    CM: this is e.g. 'media' and 'scoped' attributes




      [76] http://www.w3.org/TR/html5/semantics.html#the-style-element

    resolution: svg2's style element shall be aligned with the html5
    style element

alternative transforms



    CC: jasper proposed nonlinear transforms; that's what vertex shaders
    are about

    VH: you actually deform a texture; you're not deforming the geometry

    <tbah> Conference timed out, could you restart?

    <tbah> Thanks

    CC: jasper wanted to separate the gradient map from the
    transformation map
    ... the transformation map could be used for text warping or object
    ... I think it's very similar to vertex shaders; you have an initial
    object, you give the end object, and you interpolate in between

    CM: If we have vertex shaders, do we need this?

    CL: Shaders are about transforming the rendered result; this is
    about transforming the geometry

    VH: For example, if you're transforming a straight line into a
    curve, a vertex shader would transform it into small line segments -
    not actually transform the geometry

    CM: we're already getting perspective transforms from CSS3
    transforms, right?

    VH: yes, but that's transforming the rendered output, not the
    ... in SVG, with geometry transforms, we think about it transforming
    the bounding box. With a warp filter, you wouldn't get the bounding
    box from the resulting rendered output

    TB: How do you define these transforms?

    CM: That's an open question

    TB: mathematical equations?

    CC: or you provide a grid before/after
    ... I'm concerned in terms of authoring, that you'd end up with lots
    of shaders, lots of GLSL - not really declarative.
    ... it should be possible to specify a transformation without
    writing a shader

    CM: In some ways I'd like to be able to do fancy warping, but it
    seems like a really open-ended/big feature

    CL: mercator was one of the suggested transformations; if we were to
    make a fixed list of allowed transformations, someone's always going
    to want a different one
    ... so it'd need to be customizable
    ... so I have concerns over complexity & extensibility

    <ed> [78]http://blockses.appspot.com/1246403

      [78] http://blockses.appspot.com/1246403

    CM: we also haven't seen people using script to do these kinds of
    ... but with a nicer API, we might see people doing more of this

    ED: that example I just pasted is a 3D projection of a world map, so
    people are doing that kind of thing

    (demo of spinning globe, with SVG countries painted onto it)

    CC: It'd be really cool to be able to animate a globe like this with
    declarative animation, without needing any script

    CM: to be happy moving forward with something, I'd want some kind of
    proposal & people really championing it / wanting to implement it

    resolution: svg2 shall not include alternative transforms, in the
    absence of a convincing proposal

other 2.5D effects



    CM: <replicate> is listed here, but that belongs under 'declarative
    ... and the other things fall under the previous topic
    ... and in fact the next one as well ('non-rectilinear layout
    models') -- that sounds like arbitrary warping transforms as well.
    ... that sound like the same use-case as like the mesh transforms

Support getting bounding boxes that include stroke and/or markers



    CL: I think we went over this in the 1.1 timeframe; we decided not
    to put it in 1.1 but we thought we'd put it in 2
    ... we definitely decided to add it, and it's been asked for since
    ... [expresses displeasure for markers]

    resolution: svg2 shall include better bounding-box querying

Consider allowing rotations to be relative to their bounding box center



    TB: this is a good idea; you also need to be able to specify the
    center of rotation

    CL: We get this for free in the CSS transforms

    CM: hopefully all the CSS properties we support will have
    presentational attributes, too

    CL: yes

    CC: So in CSS, this is the "transform-origin" property?

    CL: yes. CSS defaults to rotating about the center, whereas SVG
    defaults to rotating about upper-left corner

    TB: how do you get the center of e.g. a rotating 5-pointed star,
    where the bounding box changes as it rotates?

    VH: the center of rotation would be chosen pre-transform

    resolution: we will ensure there is a way to specify rotations
    around particular points and shapes

    TB: Inkscape stores a transformation center; used for scaling, for
    ... not just for rotations

    VH: something similar in illustrator, too

    <ed> scribeNick: ed

vector effects

    CL: geometry api?

    CM: vincent wanted to talk about that
    ... maybe we can have that discussion later

    <ChrisL> action-1?

    <trackbot> ACTION-1 does not exist

    <ChrisL> action-100?

    <trackbot> ACTION-100 does not exist

    CM: we were discussing having better interfaces for points, paths,
    and combining and offsetting

    CL: the other one was stroke-below-fill
    ... assuming this ends up as a vector-effect value

    DS: i suspect that CSS ppl are going to think it's like an underline

    CL: fill then stroke then markers

    DS: what if it's the middle thing?

    CL: markers, fill, then stroke?

    DS: it's not the full functionality, it's a shorthand

    CC: what if you wanted to have both non-scaling-stroke AND
    ... what's the philosophy behind the vector-effects property?

    CL: it's like a filter effect
    ... I could do add combination value keyword

    CM: concerned about using vector-effect for this

    CL: most things in filter effects are called 'feSomething', and in
    vector effects 'veSomething'

    DS: is the property vector-effect appropriate and intuitive to what
    ppl would expect?
    ... what if you wanted the fill on top of the stroke for text in
    ... do we have the same mechanism for that?

    CM: so you want a slightly differnt way to express this, rihgt?
    ... mapping the "i want stroke under the fill" to using
    "vector-effects" perhaps is not so intuitive
    ... though having them separate might make it harder for linking it
    to vector-effects
    ... we have existing stroke and fill, and that's input to the vector

    CL: plus the styling

    <ChrisL> stroke-order: above-fill (default) | below-fill

    CM: it's not the order that's below the fill

    DS: maybe we could have a poll to what's most intuitive?

    CM: but maybe we could resolve on separating the property out, not
    making it a vector-efffect shorthand

    <ChrisL> paint-order: fill-stroke-marker| stroke-fill-marker | and
    so on

    RESOLUTION: we will have a property that means stroke underneath
    fill vector-effect shorthand, but not using the vector-effect

    CL: do we want to use vector-effects=non-scaling-stroke as is, or
    separate it out?

    DS: could be a threshold, scale up as much as it can go, but min
    value is 1

    CM: would like to see this as a separate property for

    DS: helps discoverability

    ED: so vector-effects would only be the url() syntax?

    CM: if we don't come up with something else that we can use as

    ED: slight concern about backwards compat, since it's implemented as
    a vector-effect shorthand already
    ... also non-scaling-stroke="yes|no"? seems a bit silly
    ... and all other stroke properties are prefixed 'stroke-'

    DS: to me it's a vector-effect, underneath it's the same thing
    ... doesn't need to be called vector effect...

    CM: it's not terrible in vector-effects, but i'd prefer it as a
    separate attribute
    ... the painting order is a simple thing compared to the vector

    RESOLUTION: we will keep vector-effect=non-scaling-stroke as is

    <stakagi> Initially, I thought that ref (svg, x, y) made it
    satisfied for non-scaling-whole-objects.

    <stakagi> But, another fixed-size-shapes may be required.

    <stakagi> Differ from the ref(svg,x,y), for map usecase totally
    fixed-size-shape are required, such as line-width of vector effects.
    By ref(svg,x,y), shape size is fixed but initial size is not fixed
    according to ( SVG user agent viewport and viewBox))

    <heycam> stakagi, I think the performance concern's true, as long as
    the appropraite coordinate space is the root element

    CL: yes, we mentioned ref before, it's on the requirements list

    <stakagi> This matter is pointed by Alex

    CM: so you want to get around the outermost svg scaling and get a
    fixed pixel size for the scaling to screen



    CM: thinking about viewBox, lack of viewBox, and how wide things are
    in screen pixels
    ... just sizing the viewport to the size of the window

    DS: things that are meant to be a fixed size could be optimized,
    render to that size and then cached
    ... like buffered-rendering

    CM: right, like how "position: absolute" in css means it's usually a
    hardware layer
    ... we can leave the details of the mapping and layering until next
    week at TPAC

stroke-related feature requests

    CM: first, stroke-position, proposed by Jeremie
    ... we already resolved to include the feature in SVG2


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

    CC: what's the lneght valiue?

    CM: positive means outwards, negative inwards

    [CL draws stroke on whiteboard]

    CM: length is in user units

    CC: it doesn't say what the range of the length, where is e.g 1, 0
    and -1

    CL: you could have a percentage which is relative to stroke-width
    ... or an absolute value in user units

    CM: there are some image attachments on the page above, showing
    different scenarios


      [84] http://lists.w3.org/Archives/Public/www-svg/2011Sep/0057.html


      [85] http://lists.w3.org/Archives/Public/www-svg/2011Sep/0062.html

    DS: i can imagine having a stroke around and then wanting a second
    ... multiple strokes could be very useful

    CM: that's possible with vector effects

    DS: the figleaf example is nice
    ... if there was a way to fill the space beween the fill and the

    CC: so what is the conclusion?

    DS: i'm in favor of this proposal

    CM: we should put it in draft

    CC: some drawing APIs don't have the capability to do this I think

    CM: is it too much to ask?

    DS: in the 0062.html mail, the third image seems intuitive, and the
    figleaf is intuitive... the first one though, how do you get that?

    [CC draws on whiteboard]

    <heycam> Path flattening/offsetting algorithm:


    DS: do we need something like stroke-rule, similar to fill-rule?

    CC: what happens with miter-limit?
    ... are the definitions we have capable of handling these new
    functionality when strokes are outside or inside?
    ... it's probably not so easy to define what's inside and outside

    CM: we already know for a path what the stroke will be
    ... so to get the new stroke just offset the stroke more or less
    than is currently done with stroke middle
    ... the paper just looks at left and right sides of a stroke, for
    determining what parts should disappear when the stroke folds over

    CC: let's say you want to animate the stroke-distance

    [CC draws a star, with a hole in the middle]

    scribe: i think it uses fill-rule=non-zero
    ... you don't use even-odd when you're filling the strokepath
    ... but we're talking about different things, the stroke isn't the

    CM: in the end what you get from a stroking operation is a normal
    path that you can fill
    ... might be interesting to experiment with implementing
    ... for the syntax of the proposal, no specific suggestions for

    DS: we should play with it and see how well it works

    CL: paper addresses performance of this, and it's just as good as
    any other stroking operation

    CM: are you likely to get seams if you offset from the fill?
    ... that is, the space between the fill and the stroke, if you have

    DS: think people would like this situation to produce no seams

    CC: should we also have a more general shape-offset that offsets the
    shape geometry by a certain amount?
    ... i think that's a vector effect

    CM: yes, I think this might be a less common operation, so that's
    probably fine

    CL: you do get a problem if the tesselation is dfifferent for the
    stroke and the fill
    ... some pixles may end up with less coverage and the background
    might bleed through

    <scribe> ACTION: CM to put the stroke-position proposal into the
    SVG2 spec [recorded in

    <trackbot> Sorry, amibiguous username (more than one match) - CM

    <trackbot> Try using a different identifier, such as family name or
    username (eg. charles, cmccorma)

    <scribe> ACTION: cameron to put the stroke-position proposal into
    the SVG2 spec [recorded in

    <trackbot> Created ACTION-3162 - Put the stroke-position proposal
    into the SVG2 spec [on Cameron McCormack - due 2011-11-04].





stroke-dash adjustments

    CM: i wrote this proposal to address adaptive stroke-dashing

    [CM draws on whiteboard]

    CM: to adjust the dashes to e.g get a dash at the start and the end
    of a path, and then space the rest out along the curve

    CL: another case is for rectangles, where you want the corners to
    have dashes

    CC: if you have percentages for stroke-dasharray / dashoffset maybe
    it would address some part of this

    CL: stroke-dasharray-adjust

    CM: either stretch the gaps, or stretch the dashes, or both

    CC: or compress

    CM: maybe what this proposes is too much control

    DS: yes, DWIM or auto might be better

    CC: i think having stretch and compress is enough
    ... so compress, take an integer number, say you have 2.5 times the
    dashes, it would do 3 and the compress it to fit

    CL: in some cases you don't want to change the lenght of the dashes

    CC: if it's closed you keep the last gap, otherwise remove it

    CM: my proposal is a little bit different

    [general discussion and drawing on whiteboard]

    CC: so maybe it's more about keeping the last gap or not

    DS: which case are you optimizing for CM?

    CM: maybe we should get rid of compress, and just have stretch?

    CC: both are useful, if you end in the middle of a dashpattern
    ... it's like a rounding

    CL: whichever one has the least change

    DS: people probably rather want dashes that are of equal size
    ... and the rect corner thing

    CM: my proposal addresses that, bottom half of the page
    ... i'm unconfortable with having 4 options

    CL: people that are pushing for this want more control

    DH: as long as there's good fallback behavior

    CM: you want auto to be something like round gaps

    CL: you want auto to do what is done currently, otherwise it would
    change current behaviour

    CC: are dashes fixed? if you increase length of path, you get more
    and more dashes and gaps, right?
    ... if you animate it it will blip when it does the rounding to an
    integer number of dashes/gaps

    CM/CL: yes, that's unavoidable

    CC: maybe we can start with this proposal, even if it's too much

    RESOLUTION: the proposal for stroke-dash-adjust pending modification
    for edge-cases (open path vs closed path, impossible compression of
    gaps, round vs ceil)

    <scribe> ACTION: cameron to update the stroke-dash-adjust proposal
    to address the edge-cases mentioned in the above resolution
    [recorded in

    <trackbot> Created ACTION-3163 - Update the stroke-dash-adjust
    proposal to address the edge-cases mentioned in the above resolution
    [on Cameron McCormack - due 2011-11-04].

    <cyril> s/round vs ceil)/round vs ceil) is accepted/

    <cyril> scribe: cyril

SVG Params

    CL: Sairus Patel was yet another person who raised the problem that
    colors are baked in, and Params could be a solution

    DS: I thougt about this use case before

    CM: I'm curious how the params would be set
    ... in the font URL or on the text element

    ED: it would be nice to pass it on the whole font face

    CC: what's the status of the spec right now? stable ?

    DS: no, there are 2 models and I can't decide which one is the best
    ... I don't define what happens when the types are wrong, it's not
    strongly typed

    CM: in the first you declare the params that the document is
    expected and you provide fallback
    ... in the second, you don't provide fallback but the use of the
    param has to provide fallback

    DS: I think the one implemented by Adobe is the one in TR, with one
    level of indirection

    <shepazu> [92]http://www.w3.org/TR/SVGParam/

      [92] http://www.w3.org/TR/SVGParam/


      [93] http://dev.w3.org/SVG/modules/param/master/SVGParam.html

    CM: I can go through the specs and give my opinion

    <scribe> ACTION: heycam to review the Parameters specs and comment
    appropriately [recorded in

    <trackbot> Created ACTION-3164 - Review the Parameters specs and
    comment appropriately [on Cameron McCormack - due 2011-11-04].

Catmull-Rom curves

    CM: We've resolved that's a req for SVG 2
    ... but Chris found some conflicting pages


      [95] http://www.w3.org/Graphics/SVG/WG/wiki/Path_Enhancements

    CL: we agreed to have CatmullRom Curves with a tension parameter
    ... but for CR curves the tension is 0
    ... if not 0, it's a Cardinal curve
    ... but no one implements that
    ... can we resolve CR without tension ?

    DS: yes

    CL: it fits better in the path syntax

    RESOLUTION: We will have Catmull Rom Curves (with 0 tension) in SVG

    CC: can you close smoothly a CR curve, without a Z ?

    DS: I don't know

    CL: (drawing a gradient interpolation on board)
    ... linear interpolation of color creates a band
    ... as well as using a path syntax, we could add smoothness

    CC: we should add this to the Advanced Gradients Req doc

    CL: in our interpolation methods for animation, we don't guarantee
    that there is no discontinuity in the speed

    <scribe> ACTION: Cyril to edit the Advanced Gradients requirements
    document to include support for smooth gradients [recorded in

    <trackbot> Created ACTION-3165 - Edit the Advanced Gradients
    requirements document to include support for smooth gradients [on
    Cyril Concolato - due 2011-11-04].

    CL: for animation, we have ease-in and ease-out but that's it
    ... I'm proposing that we have a way to have smooth interpolation
    for animations
    ... in 2d, we could have a motion path
    ... with smooth animation

    CC: the general idea of having a better interpolation, smoother, is

    CL: the advantage is reusing the same syntax as CR curves

    JY: in the context of CSS animations, there are problems with smooth
    interpolation, CR curves could be a solution

    RESOLUTION: SVG 2 should have smooth interpolation of animation
    values and gradient stuff, such as Catmull Rom curves

    <scribe> ACTION: heycam to add all resolutions of the pre-TPAC F2F
    meeting minutes to the SVG 2 Req document [recorded in

    <trackbot> Created ACTION-3166 - Add all resolutions of the pre-TPAC
    F2F meeting minutes to the SVG 2 Req document [on Cameron McCormack
    - due 2011-11-04].

    DS: that could be interesting to interpolate between paths that
    don't have the same number of segments

    CL: rather that adding nurbs into path, we could have a conversion

    CC: According to Tav, we could have S-basis curves


    CM: in the cases of dash a path with corners, like a rectangle, we
    want to control the dash

    CC: how do you define a corner

    CM: I don't think we can reuse existing dash, so I came up with a
    new one



    CL: we have to see with users of dashes how much distortion of the
    path is acceptable

    DS: in his original proposal, the dashes start at the corner, and to
    have it balanced on both sides of the corner, you have to use offset
    ... I'm proposing that the default is when the center of the dash is
    on the corner
    ... and the offset can still be used
    ... I agree with Chris, we need to check with people using dashes\

    CM: graphics libraries tend to not support dashes adjustment and you
    have to do it yourself
    ... this is very similar to marker start, mid and end

    DS: this would work well with rounded rectangles

    CL: we should put this as a starting proposal

    CM: I'll put more examples on the wiki page
    ... and mail Andreas and CGM people

    CL: and Bessetti people

    <heycam> s/and Bessetti people/and Ann Bassetti/

SVG 2 Requirements


      [99] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input

shared paths



    <heycam> ScribeNick: heycam

    <cyril> CM: wondering about the stroking of a shared path

    <cyril> CL: the vector effect constructs the fill and the stroking
    is done afterwards

    <cyril> ... so stroking should not happen twice

    <cyril> (drawing on the board)

    <cyril> CM: the issue I see is how the stroke happens on joining

    <cyril> CL: you could use vector effect (union, intersection) to
    define the right stroke

    <cyril> ... but the result would be a path and could not be stroke

    <cyril> s/could not be stroke/could not be dashed/

    DS: you may also want to dash the different edges of the countries,
    how do you control that?

    RESOLUTION: We will have a solution to shared path segments in SVG2.

    <scribe> ACTION: Chris to talk to map and CGM people about
    requirements for dashing and shared path edges [recorded in

    <trackbot> Created ACTION-3167 - Talk to map and CGM people about
    requirements for dashing and shared path edges [on Chris Lilley -
    due 2011-11-05].


    <ed> previous resolution:


    CC: We already have a resolution to consider it

    DS: we will leave it open

Skeleton frames

    [doug draws examples on board]

    <ed> [103]http://cs.sru.edu/~ddailey/svg/lizard2.svg

     [103] http://cs.sru.edu/~ddailey/svg/lizard2.svg

    CM: how is this different from mesh transforms?

    CL: it's affecting the underlying geometry



    CM: I am still wondering how this is different from general e.g.
    mesh transforms
    ... I don't know if this is a subset of mesh transforms, which we
    said no on
    ... if this is a sufficiently subset of functionality, that is
    simpler enough, then maybe we can say yes to this
    ... but it's not clear to me that is the case

    DS: I would be happy with it in a separate specification

    CC: can we have a separate spec with these skeleton frames, and mesh

    RESOLUTION: We will not have skeleton paths in SVG2, but we will
    work on it in a separate module.

Declarative drawing

    DS: I have seen some really cool things done with replicate

    CC: I think it's almost too powerful
    ... the problem I can see is that the browser will have difficulties
    handling the result and optimising it
    ... if you end up with many paths, you can do an extrusion, but
    there are many ways you can do an extrusion

    ED: depends if you generate DOM nodes
    ... could be cheaper not to generate additional exposed DOM nodes

    CC: the replicate proposal is just a single element AIUI

    CL: it effectively makes a bunch of shadow dom elements

    DS: it makes me wonder if it can be done with Web Components

    <ChrisL> <script type ="text/logo" />

    s/Web Components/Component Model/


     [105] http://en.wikipedia.org/wiki/Logo_%28programming_language%29

    CM: I share that concern

    JY: it makes it a lot easier to do something ridiculous
    ... like replicate a trillion times

    CL: if you are adding 1000s, it would be better if it's not in the

    CM: there's a balance between usefulness and complexity here, and
    I'm not really sure it lies on the right side of that to include in



    DS: all these things on the page look really cool
    ... the tubefy thing interests me

    CM: but I think this is the wrong solution to achieve that gradient

    ED: the tubefy thing is what I've heard the most requests for

    DS: the extruded text also interests me
    ... but I don't see people wanting to do this in production apps
    ... for 3D things they would use WebGL

    CM: I love these effects, but I am worried about this not being
    practical enough for the complexity of a performant implementation

    ED: the script library is very small

    JY: have other people been using his script?

    DS: that tubefy example is Israel Eisenberg redoing his gradient
    worm with replicate
    ... I think that is a good point, is anyone else doing stuff with

    JY: if people use this script library, then it's a good hint to
    include the functionality, because you get the advantage of not
    needing DOM nodes in the native implementation

    DS: two things would change my mind
    ... one, if we saw an uptake of people using the script library to
    solve the problems they have
    ... and two, if we saw more concrete examples of practical uses of
    the library
    ... using it to solve a problem

    CC: we have browsers, and authoring tools in the group, and we
    haven't had any people crying out that they really want this

    RESOLUTION: We will not include replicate in SVG2 unless accompanied
    by concrete use cases and demonstration of author/implementor

    DS: I would like to see a spec just to see if it can yield other
    solutions, to see what emerges from it

Turtle graphics

    DS: there are two aspects of turtle graphics
    ... there's the replicating patterns, which is more ambitious
    ... and the other is Cameron's proposal, which does not include

    CM: I think we need to see some justification for extending my
    turtle graphics to the more general form
    ... since mine are grounded in particular use cases, for example
    animating angles between path segments, easily creating pie chart
    shapes, etc.
    ... general logo-like graphics, I'm not sure what the practical
    reason to include that

    RESOLUTION: We will not include general turtle graphics in SVG2
    without examples of practical reasons to do so.

Smooth curve through points

    CM: this is just catmull-rom curves
    ... which we have already decided to include

    RESOLUTION: We will include smooth path between points functionality
    in SVG2.

Summary of Action Items

    [NEW] ACTION: cameron to put the stroke-position proposal into the
    SVG2 spec [recorded in
    [NEW] ACTION: cameron to update the stroke-dash-adjust proposal to
    address the edge-cases mentioned in the above resolution [recorded
    in [108]http://www.w3.org/2011/10/28-svg-minutes.html#action08]
    [NEW] ACTION: chris to reply to alex explaining how wide gamut
    colours and flourewscent/metallic printing are accomodated in SVG
    color [recorded in
    [NEW] ACTION: Chris to talk to map and CGM people about requirements
    for dashing and shared path edges [recorded in
    [NEW] ACTION: ChrisL to edit the svg colormanagemtn spec into a
    chapter in SVG2 [recorded in
    [NEW] ACTION: ChrisL to look at global attributes [recorded in
    [NEW] ACTION: CM to put the stroke-position proposal into the SVG2
    spec [recorded in
    [NEW] ACTION: Cyril to edit the Advanced Gradients requirements
    document to include support for smooth gradients [recorded in
    [NEW] ACTION: Cyril to investigate whether more than use would
    benefit from relaxing reference requirements so that "blah.svg"
    refers to the root element [recorded in
    [NEW] ACTION: heycam to add all resolutions of the pre-TPAC F2F
    meeting minutes to the SVG 2 Req document [recorded in
    [NEW] ACTION: heycam to review the Parameters specs and comment
    appropriately [recorded in
    [NEW] ACTION: tav to write up summary of inkscape's non-scaling
    features, as possible candidates for svg2 [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [119]scribe.perl version 1.136
     ([120]CVS log)
     $Date: 2011/10/29 01:04:09 $

     [119] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [120] 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 [121]http://dev.w3.org/cvsweb/~checkout~/200

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/CC/CM/
Succeeded: s/heycam/CM/
Succeeded: s/heycam/CM/
Succeeded: s/transforming a curve/transforming a straight line/
FAILED: s/round vs ceil)/round vs ceil) is accepted/
FAILED: s/and Bessetti people/and Ann Bassetti/
FAILED: s/could not be stroke/could not be dashed/
FAILED: s/Web Components/Component Model/
Succeeded: s/that/the performance concern/
Found ScribeNick: ChrisL
Found ScribeNick: dholbert
Found ScribeNick: ed
Found Scribe: cyril
Inferring ScribeNick: cyril
Found ScribeNick: heycam
ScribeNicks: ChrisL, dholbert, ed, cyril, heycam

WARNING: Replacing list of attendees.
Old list: +1.650.693.aaaa [IPcaller] AD
New list: Doug_Schepers +1.650.693.aaaa

WARNING: Replacing list of attendees.
Old list: Doug_Schepers +1.650.693.aaaa
New list: +1.650.693.aaaa tbah

WARNING: Replacing list of attendees.
Old list: +1.650.693.aaaa tbah
New list: tbah

Default Present: tbah
Present: Chris Erik Daniel_Holbert Jen Jun Takagi-san Cyril Vincent Cam
Agenda: [122]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agend
Found Date: 28 Oct 2011
Guessing minutes URL: [123]http://www.w3.org/2011/10/28-svg-minutes.htm
People with action items: cameron chris chrisl cm cyril heycam tav

     [122] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda
     [123] http://www.w3.org/2011/10/28-svg-minutes.html

    End of [124]scribe.perl diagnostic output]

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

Received on Saturday, 29 October 2011 01:06:36 UTC