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

minutes, SVG WG Leipzig F2F 2014 minutes, day 3

From: Cameron McCormack <cam@mcc.id.au>
Date: Wed, 09 Apr 2014 17:47:58 +0200
Message-ID: <53456BAE.9070607@mcc.id.au>
To: "www-svg@w3.org" <www-svg@w3.org>


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

                                - DRAFT -

                     SVG Working Group Teleconference

09 Apr 2014


       [2] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Leipzig_2014/Agenda

    See also: [3]IRC log

       [3] http://www.w3.org/2014/04/09-svg-irc


           Cameron, Rik, Dirk, Tav, Satoru, Brian, Erik, Chris,




      * [4]Topics
          1. [5]Automated filter regions
          2. [6]animation of filter effects
          3. [7]Advanced gradients beyond SVG 2
          4. [8]Telcon time
          5. [9]Variable-width stroke
          6. [10]'vector-effect' non-scaling features update
          7. [11]Variable stroke width
          8. [12]svg integration
          9. [13]Text issues
      * [14]Summary of Action Items

    <trackbot> Date: 09 April 2014

    <heycam> Scribe: Cameron

    <heycam> ScribeNick: heycam

Automated filter regions



    krit: I'm currently working on automated filter region
    calculation code
    ... I know blink did some work on that
    ... to minimize the effected area as much as possible
    ... I'd be happy if there would be some contributions on how
    this should work
    ... the main problem is if you do not have limits at the
    beginning, and you use primitives like feTurbulence, that don't
    have bounds
    ... or lighting effects
    ... this could affect the whole canvas
    ... which isn't necessarily what you want
    ... currently we have the 10% bounds around the
    ... getting rid of that for gaussian blur would be good
    ... you can calculate the boundaries automatically
    ... for displacement map, turbulence, etc., there's no bounds
    ... what should we do for them
    ... should we clip to the viewport -- possible, but a lot
    bigger than you need -- or take the old 10% filter margins?

    heycam: did roc suggest getting rid of those attributes

    krit: no, but he said if you don't specify them then the bounds
    should be calculated automatically

    Tav: you can calculate the maximum displacement

    krit: it could still be huge though
    ... and for turbulence, there's no hint about how big it should

    Tav: it's only useful to have turbulence as input for something
    ... so you have to work backwards to work it out

    heycam: you must be able to work it out

    Tav: the filter is applied to the object. you have the object

    krit: feTurbulence is not limited to the object size

    cabanier: what about keeping the current behaviour but special
    casing blur, color matrix, etc.?

    heycam: what about finding the maximum rectangle based only on
    the primitives that you can work it out for
    ... and then use the union of those rectangles for the
    remaining ones like turbulence

    krit: the 10% fallback might be easier, since implementations
    already handle that, but it's not good for authors

    heycam: what is more useful for authors if they use only an
    infinite extent filter primitive?
    ... I don't like the 10%

    krit: who prefers viewport and who prefers the 10% limit?

    pdr: viewport, though that will be slower

    Tav: if you have a flood fill, that will now go everywhere
    ... could break content

    krit: you can always specify x/y/width/height if you need to

    ed: leaning towards 10% margin

    pdr: how does CoreImage handle this? or other native APIs?

    krit: don't know how CoreImage does it

    cabanier: you have to set it up yourself right?

    krit: you give the images as input, so you don't run into the
    infinite extent issue

    cabanier: doesn't IE have all of these optimizations?

    Tav: how does turbulence work, does the pattern shift?

    krit: I think it would

    davve: are users complaining about this?

    krit: new users don't understand these 10% margins at all

    ed: it's usually people using gaussian blur

    heycam: would content break if we just said turbulence defaults
    to 0,0,100%,100% unless attributes are given on the primitive?

    krit: I think it would
    ... should we defer this decision, or can we come to a
    ... I'd be fine with using 10% margin for now, but at least for
    things that are unbounded
    ... and try to be smart for other cases

    Tav: if there is a primitive you cannot figure out, you use the

    heycam: are you able to write down in the spec exactly when we
    have to use the 10% then?

    krit: yes
    ... a lot of authoring tools in the past set the filter region
    to the whole viewport

    ed: if you don't optimize it's going to be super slow
    ... I know I saw some diagram with lots of little cloud shapes,
    and each had a filter applied
    ... it was very slow

    Tav: there is badly authored content out there

    heycam: I think Omnifgraffle at one point was outputting large
    filter regions

    RESOLUTION: For filter primitives that are unbounded, and the
    size cannot be computed automatically, the default filter
    region will be -10%,-10%,120%,120%

    krit: next is the lighting filters
    ... in Blink/WebKit, they are treated as infinite extent
    ... but not in Gecko

    [dirk shows an example]

    <krit> SVGFEPointLightElement-svgdom-y-prop.html

    scribe: in Firefox the output of the lighting primitive is
    limited to exactly the size of the input

    Tav: I think that's wrong, and Blink/WebKit are right

    attr.js is what it generates




    <krit> <svg:svg width="300" height="300"><svg:defs><svg:filter
    id="myFilter" filterUnits="userSpaceOnUse" x="0" y="0"
    width="200" height="200"><svg:feGaussianBlur in="SourceGraphic"
    in="blur" surfaceScale="1" diffuseConstant="1"
    lighting-color="yellow"><svg:fePointLight x="100" y="180"

    </svg:defs><svg:circle width="200" height="200" cx="100"
    cy="60" r="50" filter="url(#myFilter)"></svg:circle></svg:svg>

    heycam: I think it is just a bug in firefox

    krit: and IE11 matches Blink etc.
    ... so I will leave the spec as is

animation of filter effects

    krit: Brian wrote a good summary
    ... we got one reply

    birtles: we talked about it a bit further in Web Animations

    <birtles> some discussion here:


    <birtles> original discussion here:


    birtles: I'll summarise
    ... there's different ways of adding things together
    ... if you have two animations which are targetting the same
    element, and they're independent animations, and they're both
    applying a filter to the element, then visual result you expect
    is equivalent to building up a list
    ... suppose they're both applying a blur of radius 2
    ... the equivalent visual result is blur(2)blur(2)
    ... so you append onto the list
    ... but for SVG there's also cumulative animation
    ... where the same animation builds on its own result
    ... that should give you a different result after 2 iterations,
    ... this comes up with transforms as well
    ... if you have skew(22)
    ... if you accumulate that three times, you should get skew(66)
    ... after three iterations
    ... but if you have three indepedent animations with skew(22)
    and they're additive, you use post-multiplication to get
    ... so that's two different kinds of "addition"
    ... that's something we've realised in Web Animations, we know
    two different ways to add
    ... for most things they're identical, say for lengths
    ... but for some types they're different
    ... for filters that's an example where they're different

    heycam: is it just when you have lists?

    birtles: doesn't have to be
    ... for transform lists you don't have to build up the list,
    you can use post-multiplication
    ... the effect is the same there

    heycam: do you have an exhaustive list?

    birtles: so far it's just filters and transforms where this has
    come up
    ... another reason it's important to make the distinction, with
    cumulative animation, the list gets longer each time you repeat
    ... so it's advantageous to define the operation differently
    for filter lists
    ... it's basically a component-wise addition rather than an
    independent combination
    ... so we've defined this already in Web Animations
    ... for any data type we define how to interpolate, how to
    compute distance, how to add, and how to accumulate
    ... you don't have to define all of these operations
    ... the definitions say if there's no cumulate addition
    operation for this type, use normal addition
    ... if that's not defined, it uses "non-additive" addition,
    i.e. just use the RHS

    krit: this relies on Web Animations defining the types
    ... for filter effects, I don't want to have infinite lists

    birtles: for filters we need to define how accumulation works
    ... and I think we need to define that in terms of matching up
    filter primitives, starting from the rhs, and adding the
    component values

    krit: another problem is that a lot of the values that pass are
    not linear
    ... greyscale for example
    ... and just adding these numbers would give a non-linear
    ... for some of the filter functions it's not even computable

    ChrisL: can the distance metric not linearise it?

    birtles: it's up to the spec to define how to combine the
    numbers for the cumulative addition

    krit: for some primitives I just don't know how to combine the

    Tav: if you apply a gaussian blur twice to something, it's not
    the same as doubling it

    birtles: it's up to you to think for each one
    ... if you were to make this animation, and run it twice and
    build on the result, what's the expected result of that
    ... define the operation in those terms
    ... it's up to the spec author who introduces a new animatable

    krit: I'd rather not allow the addition then

    birtles: I think we should work it out
    ... I think it's useful to have additive animations
    ... as long as you're defining that additive animation, you
    should define the cumulative one as well, so you don't get
    longer lists

    krit: additive is one part
    ... if you have two blurs you add the two numbers

    birtles: if they're independent animations you do append to the
    ... you don't have the problem of the list building forever

    krit: I think that's what I specify at the moment
    ... assume that all of the primitives are linear
    ... not sure how to figure it out

    birtles: might work just to add for blur
    ... if you're animating a blur from 0 to 2, and then you say
    run it again and build on your result, going 2-4 is what you're
    asking for

    krit: I think that's what we do right now. if you animate
    stdDeviation on the SVG filter, you have linear accumulation
    ... therefore that's what you do at the moment with SMIL
    ... so for blur and drop-shadow maybe you can do the same
    ... so what about distance, for paced animations?

    birtles: there are a bunch of definitions for different data
    ... if there's no meaningful sense of distance for a datatype,
    don't define it

    krit: I don't think distance makes sense for filters

    birtles: in the short term we can say there is no distance
    function for filters

    -- break --



Advanced gradients beyond SVG 2

    nikos: I wanted to have a high level discussion on the
    possibility of extending the advanced gradients in SVG after
    SVG 2
    ... it might seem premature to talk about that now, but the
    reason I bring it up is that Canon is willing to put some time
    towards this
    ... and we want to get feedback from the group if they're
    interested in in the future
    ... if it's a good way to spend our time
    ... we think there are two ways to extend the advanced
    ... one is diffusion curves, which is something we're
    particularly interested in
    ... we gave a talk at SIGGRAPH last year about our research
    ... and I talked last year at Graphical Web about them in SVG
    ... the other thing is a stepping stone, or maybe
    complementary, is to extend the mesh gradients
    ... SVG 2 has the coons patch gradients
    ... but there are some issues with those, and there are some
    other representations we might want to look at



    nikos: to start with diffusion curves, there are some examples
    on the wiki page
    ... I'm assuming everyone knows how they work

    birtles: is the same as edge blends?

    nikos: not totally sure

    ChrisL: so diffusion curves, the curves are a boundary, and I
    was talking with some font designers getting interesting in
    coloured fonts
    ... they wanted the center curve of the shape to be what
    constrained the gradient

    nikos: see the tube example on the wiki page
    ... see also the biharmonic model. both the inria people and we
    have a colour on the left and on the right, and you can also
    control the gradient along each curve
    ... that lets you get a smooth profile through the curve
    ... then you can conceptually assign one colour to the curve,
    and get a smooth gradient through the center

    <ChrisL> [22]https://gist.github.com/mbostock/4163057

      [22] https://gist.github.com/mbostock/4163057

    nikos: is that a linear gradient along the path?

    ChrisL: yes

    nikos: if you were to do that with diffusion curves, you would
    have the outside paths, and assign green at the control points
    at one end and red to the points at the other end

    ChrisL: I was talking to John Hudson and he said font designers
    were worried that linear and radial gradients weren't

    nikos: diffusion curves and gradient meshes make the same sort
    of images
    ... smooth transitions, and discontinuities
    ... the benefit of diffusion curves, and I think it fits well
    with SVG, is that it's a more compact representation
    ... the initial motivation was to mimic what artists draw
    ... outlines first, then fill between them with colours
    ... and it also lends itself well to animation
    ... inria have contacted me, and they're interested in
    collaborating on diffusion curves for SVG or some other kind of
    mesh for SVG
    ... they'll be releasing a library soon that implements their
    ... so will be interesting to see performance of that

    ChrisL: the coons patches have the property of smoothness
    within a patch, and no continuity between patches
    ... is there a way to have a type of patch that you can specify
    a type of continuity between catches?

    nikos: there are a few mesh formats that satisfy that
    ... inria's solver generates a triangle mesh that does have
    those properties, since it follows that biharmonic model with
    smooth transitions across boundaries
    ... illustrator's representation they show to the author have
    those properties, but they subdivide when exporting to patches

    Tav: if you look at an output from Illustrator, you can see the

    ChrisL: seems like an easier way than subdividing and bulking
    up the content
    ... just have formulation of the patches that have the property
    you want

    nikos: that's something the inria guys wanted to see in SVG
    ... it's more general, better for vectorisation of images too
    ... I think that could complement diffusion curves
    ... diffusion curves for simpler gradients, and meshes for
    great big areas
    ... I think we'd be interested in following both paths

    ChrisL: I like the suggestion to rename the mesh gradient
    ... either rename it, or put an optional type on it
    ... since they'd have different content models etc.

    Tav: I've thought about autosmoothing patches

    ChrisL: not talking about hacking it in to the existing one,
    but adding a different type of patch that does have continuity

    Tav: we know how illustrator does this, so we could just add
    ... one good thing about coons patch meshes is that PDF,
    postscript, etc. already support them

    ChrisL: to some extent, it ties us to that one type since we've
    called it "meshGradient"

    nikos: I don't see a strong case for having an attribute that
    specifies the type, rather than having a different element

    ChrisL: if we end up with multiple elements, and they take the
    same list of attributes, that's not a problem
    ... if we have one thing with type="", but that determines
    which attributes you use, that's messy

    heycam: I agree

    Tav: if we decide to have this smoothing, that's no longer a
    coon's mesh gradient
    ... so the suggestion to rename it to coonsMesh might not be

    nikos: I think you would keep the coon's mesh as is, and if you
    had a different type you'd name it smoothMesh or whatever

    Tav: I think you can add smoothing to coons patch

    ChrisL: what's it called in PDF?

    nikos: "gradient mesh"
    ... that's what it's called in illustrator
    ... in PDF there's coons patch, and tensor-product patch
    ... that doesn't give you full continuity
    ... what's recognised as "gradient meshes" is the full

    ChrisL: we did look earlier at tri-mesh and we abandonded that
    ... I suggested using Phong shading, since we already have that
    in filters

    Tav: triangle meshes aren't easy to use for the artist

    ChrisL: I had proposed using a scatter field of dots, and
    delauny triangulation

    nikos: if the structure is not going to change, it's
    appropriate to call it "coons patch mesh gradient"
    ... it's still based on an array of coons patches
    ... I think it's safe to give the current SVG 2 representation
    a more specific name

    Tav: not sure "coons" is the right name though
    ... doesn't that describe how you fill it to?

    nikos: no
    ... the interpolation of the colours is what makes it a mesh
    gradient, but a coons patch mesh doesn't have to be filled in a
    particular way
    ... you could change some parameters of the blending, and it
    would still be accurate to call it an array of coons patch
    ... so calling it a coons patch mesh gradient would still be
    ... the issue is that it might not exactly match what's in PDF
    for example

    ChrisL: a subset of it would

    heycam: "coons patch mesh gradient" is quite long as a name

    ChrisL: cmesh? cpmesh?

    heycam: I don't really like coonsMeshGradient but I can live
    with it
    ... feel like there might be a better name but can't think of

    <krit> <coonsPatchMesh>

    heycam: might be ok to drop "Gradient" from the name, since it
    gets rendered directly (and also can be used as a paint)
    ... I like coonsPatchMesh more than coonsMeshGradient
    ... <cpatchGradient>?

    Tav: we should add tensor products I think
    ... it's not any harder
    ... when you render the mesh, it's no hard to handle the tensor

    heycam: what about calling it patchGradient, and then the child
    elements indicate what kinds of patches are being used?
    ... what about: <meshGradient><meshRow><coonsPatch>
    ... and the <coonsPatch> can be used for both regular coons
    patches and tensor-product patches, if we add that
    ... any other non-coons patches we might add later would have a
    name different from <coonsPatch>

    RESOLUTION: We will rename <meshPatch> to <coonsPatch>.

    ChrisL: you were also concerned about working on this in
    parallel, and working in a community group
    ... would allow the inria guys to contribute
    ... another possibility is a taskforce

    nikos: community groups you have to keep things on track, and
    keep people contributing

    ChrisL: seems like a reasonable way forward

    heycam: I don't have a good sense of how difficult this would
    be to implement

    nikos: we would hope to implement it in webkit, and probably
    provide a reference implementation / library
    ... could demo stuff ~ at the end of the year

    ChrisL: the group is not going to say definitely no at this
    stage, and not definitely yes
    ... needs to be demonstrated and looked at
    ... so it's not a total waste of time
    ... I think with the existing stuff, people will want to get
    rid of the lines
    ... concern with the gradient meshes was that you need this
    solver to calculate the pixel values which people would be
    scared about speed

    Tav: inkscape's rendering of mesh gradients is fast

    cabanier: it's also easily GPU implemented

    heycam: acceptable to say to put in some more effort so we can
    make a better judgement with more data?

    nikos: yes I think so

    ChrisL: having regular updates from the CG would be good too

    <nikos> [23]http://patate.gforge.inria.fr/html/

      [23] http://patate.gforge.inria.fr/html/

    RESOLUTION: SVG WG is happy for CG to be formed to begin
    looking into diffusion curves.

    <nikos> scribenick: nikos

Telcon time

    heycam: all the daylight savings changes have been made now
    ... it would be good to make a time that Chris can call in

    ChrisL: I'm available 6am to 8 or 9 pm
    ... 9pm finish

    Tav: i have trouble before 9am



    krit: Need to consider Rich as well
    ... he's something like 2 hours after Seattle



    heycam: 6am Europe seems like a good spread
    ... midnight in New York, 11pm in Austin
    ... times that are possible but not present - 4pm paris,
    midnight Melbourne, 7am SFO



    Ignore the selected day, just look at the time



    RESOLUTION: new telcon is 3PM Thursday Euro time

Variable-width stroke

'vector-effect' non-scaling features update



    stakagi: I had an action about non scaling object

    <ChrisL> action-3578?

    <trackbot> action-3578 -- Satoru Takagi to Add the new
    transform(ref) functionality to svg 2 -- due 2014-02-07 -- OPEN


      [29] http://www.w3.org/Graphics/SVG/WG/track/actions/3578

    stakagi: I prepared this wiki page
    ... it was also pointed out that the variation of the effect
    should be prepared

    <birtles> stakagi: At the Seattle F2F we decided that we should
    approach non-scaling effects not using transformRef but with

    stakagi: such as non scaling size and fixed position or non
    rotating objects, etc
    ... this wiki page shows an enhanced proposal for vector
    ... one effect is non scaling size, another is non rotating,
    and last is fixed position
    ... additional parameters is viewport, screen, device, number
    ... I prepared a web application that emulates this



    stakagi: The demo is using the equivalent of the viewport
    keyword. The other options such as screen and so on are not
    part of the demo
    ... each effect is also described as a formula
    ... a transformation formula - see section 1.3



    stakagi: my question is may I add this to the SVG 2

    ChrisL: I've had a look and it seems generally good to me
    ... I had one comment that non scaling by itself was a little
    odd. Suggested non-scaling-size
    ... I've had a play with the app and it seems self explanatory
    ... in general this seems to be the sort of stuff that the
    action covered
    ... can't remember the url
    ... is it like in svg 1.2 we had ref where you could transform
    relative to another element?

    stakagi: yes, but bits in grey I may remove

    heycam: what's the difference between screen and viewport?

    birtles: I don't quite understand, but in the formula it's all
    split out
    ... we have get screen ctm in SVG already and that's what
    screen refers to
    ... viewport is a subset of that

    ChrisL: viewport only goes one level up so if you have nested

    birtles: if you have nested viewports, then viewport will give
    you the closest
    ... while screen always gives the outermost
    ... the third keyword device includes the transformations
    applied by the browser chrome and so on
    ... such as pinch zoom
    ... and device pixel ratio

    ChrisL: it would be useful to put that in the explanation

    ed: the equations have a division by the square root of the
    determinant of the ctm
    ... is it specified what happens when that is zero?

    stakagi: when that happens nothing should be displayed

    ed: does that need to be stated somwhere?

    stakagi: I haven't written the spec text yet

    heycam: what was number?
    ... goes this number of viewports up?

    ChrisL: yes
    ... we worked out the common cases were going one level up or
    all so there's keywords for that

    heycam: don't know if there's features that let you reference
    things in the hierarchy

    ChrisL: you mean by counting?

    heycam: or by name

    ChrisL: we have lots of things where you point to an id
    ... sometimes we restrict but in general terms its a uri

    heycam: but they're generally things that are downwards

    ChrisL: this is basically what we had before with the ref where
    you might want to reference other svgs and have them pan
    together for example
    ... what we've done in the past is to use a uri reference for
    pointing to things in the same or in other documents
    ... and restrict to the same document if needed

    heycam: if your containing document is a few levels up, where
    script would be restricted from accessing it, is it ok to get
    the ctm?

    ChrisL: I was imagining it would always be on the same domain

    <ChrisL> reasonable to allow cross document but not cross
    domain. same restriction as with script

    birtles: wonder how much number will be used

    ChrisL: suspect it will be used the least

    stakagi: I'm not fussed either way

    heycam: is the use case of having the document you stop at
    being somewhere in the middle of the chain an important one?

    stakagi: seems like it would be useful for tiles of maps, but
    it's hard to know

    [Chris gives a use case example of a map where the size of
    symbols is fixed]

    ChrisL: in some ways it's easier to track with an id

    heycam: think numbers might be hard for an authoring
    ... especially with an adaptive number of levels - you'd have
    to update the numbers
    ... if the use case is knowing where the top level of the map
    is then it's similar to screen
    ... it's near screen

    ChrisL: you could put an id and point to it
    ... seems like an obvious place to put an id
    ... I do think we need to point to intermediate levels
    ... think numbers are going to be more trouble than they're
    worth though
    ... not hearing anyone arguing for numbers

    birtles: could perhaps add it later once we understand the use
    case better

    ChrisL: we're not taking away functionality, only syntax
    ... use cases aren't affected
    ... do people have any other issues?

    heycam: still not convinced url is the ideal way to referene

    ChrisL: I'd rather see url than an id ref

    heycam: if you're in control of all these docs and you can put
    an identifier then you can say go to that

    ChrisL: doesn't seem like the web architecture way to do it
    ... you'd point to a uri

    heycam: let's say you've designed your mapping thing and it's
    embedded ( which is why we need more than screen)
    ... if you want that available in different contexts then you
    might need something other than url

    ChrisL: you're right number would be useful there

    heycam: I still don't like number though. You're not
    necessarily going to have the same number of steps all the time
    to get to where you want

    ChrisL: so we need a way to point to somewhere higher up
    without knowing the name of the document that contains that

    birtles: I don't see whats wrong with id

    heycam: implies the same document
    ... I think something like id is needed, but not exactly id as
    in the proposal
    ... I wonder if in Thomas's use cases if he ever has other
    ... I think maybe that feature may be ok but not sure of exact
    way to do the referring.
    ... could think about that later

    ed: you mean start without it ?

    heycam: is Takagi-san sure the feature is needed?

    birtles: no I think he's happy for us to decide

    heycam: if that's the case then I lean towards not adding for

    stakagi: I don't have a particular opinion, but in Seattle
    Chris and Doug proposed it

    ChrisL: so if you do the multi pane mapping thing you have to
    always go to the top
    ... so you can only have one level

    heycam: I meant drop url and id as well as number

    ChrisL: it's really common to do multi pane things and have
    them transform together
    ... I understand you don't want to bake uri in so that
    components are reusable but I'd rather that than no uri at all

    stakagi: I still want to look into the needs of the specific
    use cases and add what's needed after
    ... so I think it's ok to leave off the grey parts of the
    syntax until after the investigation

    ChrisL: I'd rather have it in
    ... it's easier to define everything within the model and then
    remove things
    ... if we do it in terms of pointing at elements, then we say
    you point at the element and there's syntactic sugar for
    nearest and furthest

    heycam: Brian was wondering if we could just use id and look at
    each document for that id
    ... but I was a bit uncomfortable with that
    ... maybe a new attribute is needed
    ... if it's documents and not viewport establishing elements
    within documents then maybe the name attribute on iframe could
    be used

    birtles: can we leave this as agree on the requirement but we
    don't know what the addressing mechanism should be ?

    ChrisL: yes

    heycam: I can see the use case for identifying a top level
    document somewhere in the chain which is the root you want to
    trasform things relative to
    ... but not sure about individual viewport establishing
    elements within documents somewhere up the chain

    birtles: Takagi-san was wondering about screen ctm and whether
    that should include the browser chrome trasnform
    ... spec not clear currently, wondering if anyone knows about

    heycam: I know there's a lot of confusion about
    window.devicePixelRatio and that's part of what Ted was going
    to investigate

    krit: did someone check if screen ctm goes outside of svg root?

    heycam: when an object is fixed position, what point on the
    object is fixed?

    birtles: I don't quite understand but I think it's the 0,0 part
    of the shape
    ... but if you put a translation on it then it's the x,y of
    that translation
    ... specified under fixed position
    ... if it has a transform on it then it uses the tx,ty

    stakagi: I think it would be better if there were separate
    attributes for that but don't have any ideas on what that would
    look like

    heycam: I'm having trouble getting my head around what
    fixed-position actually means
    ... in the demo, if I zoom then the arrow remains centered on
    the magnifying glass thing
    ... what defines that that is the origin?
    ... seems like one of the main use cases for fixed-position is
    location markers on the map where you want the icon to get
    bigger on zoom but position to stay fixed
    ... are all the combinations sensible?

    I'm wondering if there's only a couple of combinations that
    you'd want to use and then there's a better name for each

    ChrisL: with the transform attribute you can say rotate, scale,
    translate in any combination and these ones are basically the
    same choices but stopping them happening
    ... so if we allow the transforms in any order then should also
    allow them all to be switched off

    heycam: guess there will always be some combinations that don't
    make sense
    ... can we use the names translate, rotate, scale?
    ... fixed-position is pretty descriptive
    ... compared to non-translation
    ... so we're deciding whether takagi-san will go ahead and add
    these to the property?

    ChrisL: yes

    ed: yes

    heycam: have a feeling these will cover Thomas's use cases as

    ChrisL: once there's spec text he'll be able to see more easily

    heycam: so we have a separate keyword for non-scaling stroke
    ... that's a bit different to others that say which bit of the
    transform isn't applied
    ... maybe non scaling stroke should be taken out of the
    ... since it's more canned

    ChrisL: so you can't say non-scaling-stroke and non-rotation?

    heycam: yes

    ed: what if you had hatching that wasn't meant to be rotated?

    heycam: that was one of Thomas's use cases

    Tav: there's two independent things. Positioning something and
    then how it's transformed

    birtles: it's actually non scaling stroke width that
    non-scaling-stroke refers to

    heycam: ok I was confused.
    ... so we might have additional keywords like non scaling
    stroke to keep the pattern oriented for example

    birtles: begs the question of whether it should be a separate

    Tav: makes sense

    heycam: but we can discuss that sort of thing later

    birtles: think it's worth splitting off now
    ... vector-effects makes more sense when referring to the
    stroke but less when referring to the transform

    ed: would prefer if names didn't have 'non' at the beginning

    heycam: is it ok to decide the name later?

    <birtles> property name suggestions so far:
    transform-constraint, transform-limit, transform-lock,
    untransform, fixed-transform non-transform etc.

    <birtles> keyword values: fixed-scale, fixed-rotation etc.

    <birtles> heycam: 'transform-context' ?

    <birtles> ... since it specifies not only the parts but also
    the point of reference

    heycam: we do need to decide if Takagi-san should add it

    ChrisL: he should

    ed: yes

    Tav: yes

    RESOLUTION: Takagi-san to add vector effects extension proposal
    to SVG 2 specification

    <scribe> ACTION: Takagi-san to add vector effects extension
    proposal to SVG 2 specification [recorded in

    <trackbot> Error finding 'Takagi-san'. You can review and
    register nicknames at

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

    <scribe> ACTION: stakagi to add vector effects extension
    proposal to SVG 2 specification [recorded in

    <trackbot> Created ACTION-3619 - Add vector effects extension
    proposal to svg 2 specification [on Satoru Takagi - due

    <ChrisL> scribenick#: cabanier

    <ChrisL> scribenick: ChrisL

Variable stroke width



    birtles: some tweaks from last time
    ... also a polyfil, not finished


      [36] https://rawgithub.com/birtles/curvy/master/index.html

    birtles: syntax proposal had consensus last time but people
    asked for a polyfil to test algos with
    ... does parsing and processing of values, does not draw the
    stroke yet
    ... most syntax implemented

    heycam: can you explain the syntax

    birtles: choice of algo, and some predefined test cases
    ... can write your own
    ... and permalink to sendto other people
    ... three properties plus a shorthand. list of widths, can do
    ... percentages are % of computed value of stroke width
    ... absolute distances, issue if they should allow relative
    ... drawn segments can be adressed

    krit: all absolute?

    birtles: yes

    ed: order of values, is it order in path?

    birtles: yes, parallel arrays in ascending order else clamped
    like css gradients

    krit: comma separated list
    ... are you sure, shorthand has list too

    birtles: formal syntax not specced out yet

    ChrisL: is it piecewise linear or what?

    birtles: that is why there is a choice of algo in the polyfil,
    not decided yet

    heycam: so you walk the path and interpolate
    ... catmull-rom with warping would look good

    birtles: only get gaps if you use the shorthand
    ... have only looked at sytntax parsing and calculation, not
    done rendering
    ... negatives not allowed

    heycam: catmull-rom can overshoot into negative

    ChrisL: just clamp to zero if so

    birtles: can have negative positions for strokes, probably
    unduly complex

    ChrisL: need extra points at ends to get flaring

    birtles: like stroke-offset, maybe a separate property? open
    ... repeat is if you have less data than needed. maintain final
    value or repeat pattern
    ... (goes through examples in proposal)
    ... want to have a width at start of every segment. eg path in
    response to direct input with touch/pressure/tilt
    ... align each with segment on the path
    ... else editing is complex with two arrayts in sync

    heycam: what if you use the longhand and no positions?

    birtles: equally distributed

    ChrisL: ok so you can have one width per segment but not forced

    birtles: yes

    ed: how does this work with dash arrays and line caps

    heycam: cap is as small as the point it is at
    ... trapezoid for square caps?

    cabanier: yes, like in Illustrator

    heycam: so stroke warping is after dashing and capping

    krit: horribly complex

    birtles: there was an action to write a polyfuil but it wasn't
    done so this is a start
    ... important question is relative vs. absolute

    Tav: how to do segments that cross?
    ... trap off the part

    ed: zero length segments?


    Tav: not a problem

    birtles: can have two widths at same position, gives sudden
    ... its value then position, to align with css gradients
    ... to get a smooth repeat it needs to come back to first value

    Tav: corners?

    birtles: needs to be worked out
    ... not clear if computational complexity makes it too slow

    heycam: markers that have size relative to stroke width?

    birtles: at the point where the marker is

    ed: mitre joins can just out a long way, how to handle

    birtles: hmmm
    ... should be able to animate positions and values, perhaps not

    heycam: expand out shorthand on each keyframe
    ... so lets decide on relative vs absolute

    Tav: prefer absolute

    ChrisL: is it an either or, or would we want both?

    heycam: not hard to convert from one to the other

    birtles: relative and absolute differ if the path is extended

    ed: like uppercase/lowercase for rel/abs in path

    birtles: markers should be relative distances

    heycam: another difference is that didnt have sepaate
    properties for positions and markers
    ... single property letts you have multiple markers at same
    place though you could just repeat the position
    ... for repeating, easier to think of relative, copy the values

    birtles: instead of a property for repeat mode, separate
    property that specifies a pattern as a mode swidth

    Tav: as you widen stroke does the pattern widen?

    birtles: no
    ... not sure how to make it line up with markers
    ... implementability comments

    Tav: implemented, popular feature

    krit: will be a performance hit

    cabanier: fairly simple

    Tav: we have dash array, works fine. converts path to a fill,
    puts dash onit, ends up on stroke

    heycam: like the feature

    birtles: will continie to work on syntax

    krit: that is detail, important thing is rendering

    birtles: ok, work out bugs with the polyfil

    ed: very sharp corners, linejoins etc

    krit: need path planarization to do this

    cabanier: just draw all path segments, make sure turn same way,
    then fill
    ... so no need for planarization
    ... no unions

    heycam: width=0 widths=list, is that ok

    birtles: yes
    ... next step is to do an implemnetation

    krit: interop needs a defined algo
    ... kinda the same is not a goal

    heycam: ok with seg values?

    Tav: yes

    krit: yes
    ... each moveto is one segment

    birtles: sense is to count the drawing segments

    Tav: (draws) how to specify a gap

    birtles: yes, 2 segments

    Tav: 2,5,3,5

    birtles: (draw)

    Tav: so it knows to skip
    ... its haow we did in inkscape, per segment basis

    ed: generated path can vary by impls. so does not match what
    author intended
    ... seg might not match due to internal normalization

    heycam: no, its bassed on path as specced not after

    cabanier: unless you specify normalization

    krit: and you don't want to
    ... result can be a path object

    cabanier: would be cool. would need an acessor on path

    krit: would help canvas too

    heycam: with abs positions how can you do segment based
    patterns? (draws things with calc())

    if doing a pattern on first segment, its a mode to opt into

    birtles: seprsate property for segment based patterns
    ... not for VWS, just for markers
    ... authoring hard with different modes
    ... 2 issues in wiki

    a) negative positions (as with css gradients) b) repeating
    patterns with vws, can start pattern part way through

    ed: couldbe useful

    cabanier: not sure how

    birtles: set position as -10 +10 then starts half way through
    ... or a flag for that like stroke-dash-offset

    heycam: prefer negative offset

    birtles: need values greater than 100% so if you can at one end
    should at other (negative) too

    heycam: can you animate length ofpath ... hmm dasharray so it
    works, animate d attr

    birtles: ok so issue 2 solved, do allow negative
    ... stroke widths lining up per seg without repeating them
    ... empty list is the initial

    heycam: needs a keyword for that
    ... for one per seg
    ... keyword plus value, or list of pairs

    birtles: yes

    heycam: reflect value?

    birtles: yes

    heycam: add to spec

    birtles: next step, finish impl to render

    heycam: if you want linear, for sawtooth

    Tav: inkscape has bezier or spiro as interpolators
    ... and linear, two types of bezier

    heycam: (worries about double plurals)

    ChrisL: its not replacing stroke-width, it is modulasting it

    Tav: yes, easy to sanimate width

    krit: interesting to implement in canvas

    birtles: prefer to see to get another path

    krit: cost is calculation not rendering

    ChrisL: (tangent on CR interpolator for linear gradients)

    (people making spirographs in the air and giggling slightly)

    heycam: squashing repetitions on a circle

    Tav: multiple of four only
    ... no, four thirds segments

    birtles: do need to specify equivalent path for all basic

    (we have already)

    ed: ooh you could do stars

    birtles: hoping for help on the rendering part

    heycam: have lost an example that would have helped

    birtles: wait to solve issues before adding to spec

    heycam: add by end of june

    birtles: ok

svg integration

    <nikos> scribenick: nikos

    heycam: SVG in OT spec needs to define or reference the
    referencing modes (to turn of script or other features that
    don't make sense)
    ... also it has some things like UA style sheet that it defines
    to make contextFill and contextStroke work by default
    ... and describes mapping of colour palette to css variables
    ... question is - where do each of those things get defined?
    ... in the OT spec itself?
    ... or in one of our specs that we control?

    ChrisL: anything that might include a list of elements or
    definition of list of elements I'd prefer we control
    ... don't have a strong opinion about UA style sheets

    heycam: one part about UA style sheet is where it forced
    display:none on text

    ChrisL: if we add another element that's like text but does
    different things then technically it would still be allowed and
    that would be bad
    ... so I don't like to see lists of our elements in other specs

    heycam: my feeling before was that some parts should eb defined
    in the SVG integration spec
    ... given it's already trying to define referencing modes
    ... integration spec never published as a WD

    ChrisL: it's been around for a while and not moving forward
    ... so we need to get it published

    heycam: I thought it would be ok to publish a FPWD
    ... so OT spec can reference an un-dated url of the spec
    ... so it will get updated as we make changes
    ... and sort out details of referencing modes that might still
    need defining in the near future
    ... but importantly because their spec is solidifying soon
    (this week or next week) then we will have reference to the TR

    ChrisL: if we have a short name without a date they can link
    and always get the latest version
    ... much better than referring to an editors draft or a dated

    heycam: OT spec doesn't publish regularly so will be difficult
    to revise in future

    ChrisL: we should learn lessons from the past and keep control
    of our stuff that's referenced

    cabanier: didn't they want another secure mode?

    ChrisL: we could use secure animated + a couple of lines that
    stop text being displayed
    ... our we could make a new mode that incorporates all that
    ... all the text to date has pointed to secure animated mode

    krit: the issue I have with the spec is that it does not solve
    the issues of security (which it should solve)
    ... it has weird text saying what you should and shouldn't do
    ... but not what you can and cannot fetch
    ... and that's the most important part of the spec
    ... don't expect this to be fixed soon
    ... so I don't want it published as FPWD without fixing this
    ... no issue with having additional modes for SVG in OT
    ... I would like the doc to go forward
    ... would like it to have a higher priority
    ... but most important issue should be fixed
    ... the issue is you can't just say script isn't allowed
    ... especially for images, doesn't what you can fetch
    ... in the introduction it says something about cross origin
    but no further details

    ChrisL: thought secure animated mode disallowed referencing
    other resources

    heycam: but you can use data urls

    krit: spec doesn't specify what it really means

    ChrisL: don't understand why you don't want it published?

    krit: it's not marked as an issue
    ... it should be
    ... and someone should add parts that you need to reference
    from OT fonts
    ... we resolved that Cameron and myself were added to editors
    list, but haven't had time to work on it

    ChrisL: What I'm asking for is that we have editors that are
    present and clearly mark the issues
    ... and go to FPWD
    ... not trying to blow off fixing that
    ... but for FPWD the normal thing to point out known issues and
    get review

    krit: that would be ok for me

    heycam: if you can list the issues that should be pointed out,
    I can add them to the draft

    krit: Doug points out a lot of things in the introduction. All
    of them should be issues

    ChrisL: normally issues should be displayed prominently
    ... I agree with the points you're raising
    ... HTML5 has some good stuff that we can point to for

    heycam: I agree that for things like fetching there's a lot of
    work to go into the SVG 2 spec for the right hooks

    krit: I have a new document that has text that can be copied
    into the integration spec
    ... in the meantime we can link to my document for things like
    fetching strategies

    heycam: so can you provide me with the list of issues?

    krit: yes

    heycam: when is next committee draft being done?

    ChrisL: think that ship has sailed
    ... had to put it in their own document
    ... but Vlad is waiting for a reference to switch to
    ... so we do have a few months

    heycam: let's work on it tomorrow
    ... then maybe publish at next telcon

    ChrisL: a fresh resolution to publish would be good

    heycam: would people be happy to publish the document as is
    plus the list of issues from Dirk?

    ChrisL: yes

    RESOLUTION: Publish FPWD of SVG integration once list of issues
    is included

    <heycam> Scribe: Cameron

    <heycam> ScribeNick: heycam

Text issues

    Tav: I have 46 text issues
    ... first one, foreignObject
    ... it says in text from SVG 1.1 "if more complex layout is
    required [ ... ] such as XHTML in foreignObject, the exact
    semantics are not completely defined at this time"

    ChrisL: we take out the mention of XHTML
    ... and just say HTML
    ... and if you're using XML serialization fine

    heycam: we should define exactly how HTML in foreignObject

    ChrisL: we need to say that the very common thing, HTML, is
    ... and say that it establishes an outermost continaing block

    ed: I think that's in SVG Integration

    ChrisL: I'd like for it to say that foreignObject can have all
    sorts of stuff, but one thing is html, and here's how it works
    with the CSS box model

    Tav: next, issue 8

    <ChrisL> establishes an outermost containing block

    Tav: we talked about using height and width for providing a
    wrapping context
    ... I think that causes problems, in that our origin is not the
    upper left corner, it's the text baseline for horizontal text
    ... which if you just have a width is not a problem
    ... same thing if you have a height
    ... the origin is the center of the kanji glyph for example
    ... as soon as you say width and height it's a problem
    ... I think for the purpose of text in a rectangle, we should
    use shape-inside for that, rather than mess around with
    width/height and define how you shift down
    ... it also makes it hard to do the SVG 1.1 text position

    [explains how to use tspans with x/y to do fallback]

    heycam: so the presence of width="" controls whether x/y on
    <text> are ignored
    ... is that a problem?

    Tav: no

    heycam: I think x/y/width/height should be the rectangle into
    which to lay out the text

    Tav: but then the y value on the <text> doesn't match the
    non-rectangular-layout position of the first line of text
    ... makes the fallback harder to write, you have to shift the
    lines down to fit into the box
    ... I think instead you should use shape-inside to define the
    rectangle to lay text into

    heycam: what happens if you put width and height then?
    ... you should use the one appropriate for the writing-mode on
    the <text>?

    Tav: yes
    ... next, issue 16
    ... shapes define an inset rectangle, which I thought might be
    ... this has to do with syntax, being able to define something
    inside a different shape
    ... inset-rect

    heycam: not sure how different this would be from padding?

    Tav: should we allow elements inside other elements, and use
    the geometry of those elements
    ... for connectors it would be useful to have a point defined
    in terms of the bounding box of the object
    ... should you be able to define a text box in terms of an
    outer element
    ... next thing is issue 22
    ... there are a number of issues here
    ... I assume we want to reference CSS writing modes
    ... they do things a bit differently
    ... from what SVG 1.1 has done
    ... if I copy them directly, I don't know if it will break

    heycam: I would say it wouldn't break content

    Tav: there is direction, unicode-bidi and writing-mode

    ChrisL: at one point we thought that unicode-bidi and
    writing-mode was all we needed, but we were told direction was

    Tav: there are values like lr-tb, ... in SVG 1.1
    ... and horizontal-tb, etc. in css3-writing-modes

    ChrisL: the SVG 1.1 ones are copied from XSL

    Tav: we should just move to the CSS values?

    heycam: yes

    Tav: writing-mode also misses the mongolian direction
    ... in SVG 1.1
    ... next, issue 28
    ... glyph-orientation-vertical, etc.
    ... it has additional values upright and inline in css3-text

    heycam: seems to be not in the latest draft of css3-text
    ... if it's not there, we shouldn't have it

    Tav: next, issue 30
    ... we use "current text position" over 100 times in the Text
    ... and I don't think that's a CSS layout term
    ... I think that needs to be purged somehow

    ChrisL: is there an alternative term to use?

    heycam: I reckon you won't need that term, since you'll be
    deferring to CSS box layout

    Tav: next, issue 35
    ... baseline-shift is still in css3-line
    ... useful for super/subscripts
    ... Inkscape uses it for
    ... vertical-align is a shorthand for baseline-shift etc.

    heycam: [talks about how that spec is not being worked on, but
    might soon by Alan]

    Tav: in general, CSS has more features on text than we've ever
    ... text-indent hanging-punctuation
    ... do we pull all those things in?

    heycam: I think for text/inline stuff yes assume it works

    Tav: next, issue 42
    ... text-overflow:clip
    ... it's already possible to do clipping with clip path, this
    is only clipping if the text overflow
    ... convenient shorthand
    ... in issue 41 it's argued this property is useless
    ... it would be useful if you move the mouse to the ellipses
    and show the remaining text
    ... do we agree we should have text-overflow?

    heycam: what does text-overflow apply to? block or inline

    ed: makes sense to keep clip
    ... applies to block container

    heycam: I think the hover to show the overflow should be done
    in the document

    text { text-overflow: ellipsis; overflow: hidden; } text:hover
    { overflow: visible; }

    Tav: next, issue 45
    ... I assume we're linking to css3-fonts
    ... font-variant has been completely reworked

    ChrisL: yes

    Tav: next, issue 46
    ... css3-text-decoration
    ... it's a bit different from what SVG has done in the past
    ... you can set the colour on the underline
    ... I assume we want to preserve the text-decoration like it's
    shown in the figure
    ... you can have the stroke and fill different on underline,
    but at the same time allow text-decoration-color to set the
    ... would that remove the stroke?

    ChrisL: they don't really distinguish between fill and stroke
    ... they tend to talk about "the" colour of the text

    heycam: maybe make text-decoration-color affect only the fill
    of the decoration
    ... not sure how to deal with currentColor being the initial

    Tav: we should define how/whether text-decoration on text on a
    patch works

    ed: that's been undefined for a while
    ... some people use textPath for multi-line text
    ... and would expect underlines to work there

    RESOLUTION: text-decoration doesn't paint on a <textPath>

    -- end --

Summary of Action Items

    [NEW] ACTION: stakagi to add vector effects extension proposal
    to SVG 2 specification [recorded in
    [NEW] ACTION: Takagi-san to add vector effects extension
    proposal to SVG 2 specification [recorded in

    [End of minutes]
Received on Wednesday, 9 April 2014 15:48:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:19 UTC