Minutes, 9 May 2013 SVG WG telcon

Minutes from this week's SVG WG telcon are below.

http://www.w3.org/2013/05/09-svg-minutes.html


    [1]W3C

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

                                - DRAFT -

                     SVG Working Group Teleconference

09 May 2013

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0100.html

    See also: [3]IRC log

       [3] http://www.w3.org/2013/05/09-svg-irc

Attendees

    Present
           +1.425.373.aaaa, [IPcaller], birtles, heycam,
           +61.2.980.5.aabb, nikos, Doug_Schepers, cabanier,
           +33.9.53.77.aacc, Tav

    Regrets
    Chair
           Cameron

    Scribe
           nikos

Contents

      * [4]Topics
          1. [5]textLength tests
          2. [6]Variable Width Stroke
      * [7]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 09 May 2013

    <scribe> scribenick: nikos

textLength tests

    Thomas_Smailus: the plan is to take the existing test (from
    1.1) and tweak it to bring it up to speed and deploy
    ... looks like it will be one of the first tests for SVG 2
    ... might take me a couple of weeks

    heycam: we still don't have the test harness that CSS WG uses
    set up yet
    ... so tests will just sit in the repository for the moment
    ... we did agree on a template
    ... it's on the wiki
    ... the format is a bit different from the 1.1 tests

    Thomas_Smailus: textLength was a feature that has tests but no
    one implemented

    heycam: I'd try Opera, but don't know

    Thomas_Smailus: there was something about if at least one
    browser supports then it's supported?

    heycam: if we have two implementations we normally keep a
    feature when looking to remove

Variable Width Stroke

    heycam: Brian could you summarise?

    birtles: I posted to the list a particular use case I have
    ... which is related to manipulating a path when you want to
    bind the width to points on the path
    ... one example is a drawing application where the path is
    built from touch events

    <Tav> I am having trouble phoning in... says 26631 is
    restricted.

    birtles: another example is a shape and you want to set the
    width of the stroke at particular points and it sticks to the
    points when you resize the shape
    ... for my two examples, it's useful to attach the stroke width
    to points in the path -details in the mail
    ... Rik replied with another use case which is where you want
    to reuse a particular stroke width profile
    ... on paths which have different number of points to widths
    ... his example is an illustrator tutorial

    nikos: that was always the use case I imagined when talking
    about variable stroke width

    Thomas_Smailus: it would mimic writing with fountain pen right?

    birtles: yes

    cabanier: it's a poor mans version of that - it's simple to
    implement but doesn't mimic the pen exactly

    birtles: the application I'm involved in is a variable on that
    theme, where if you push harder it gets thicker

    cabanier: pressing harder need not match up to a point though

    birtles: that's a detail, even if you bind stroke widths to
    points, you can have more widths than points
    ... so to summarise, we have two use cases, one where it's
    desirable to attach stroke widths to points, and one where you
    use percentages along the path
    ... in inkscape they are kind of tied to points, but you have
    offsets from the points
    ... I think we need to come up with a proposal to cover both
    approaches
    ... I'd like to make sure we don't make it difficult for
    applications like I described
    ... it would be unfortunate for my application if we only had
    percentages

    cabanier: I don't think it would be that hard
    ... it feels like we are going to do the same thing twice
    ... and it depends how we apply the curve to the variable
    stroke width
    ... I'm not sure you can add points to Catmull-Rom
    ... beziers might be overkill
    ... what does InkScape do?

    Tav: there are 4 different types of interpolation
    ... cubic bezier, cubic bezier johan, linear, and spiral
    interpolator
    ... spiral path is complicated, it uses parts of spirals, hard
    to explain quickly
    ... font forge has an implementation
    ... it gives nice smooth paths but can go crazy sometimes

    heycam: Brian, Rik, what do you think we should do initially?

    cabanier: we definitely don't want straight line interpolation

    shepazu: what do you mean by straight line interpolation?

    heycam: I mean just linear

    shepazu: I experimented a lot in the past on how to do variable
    stroke width
    ... the syntax is the hard part
    ... tying it to particular nodes is extremely unintuitive,
    percentages is probably more intuitive

    Tav: when editing in InkScape, I think you want to tie it to
    the nodes somewhat

    cabanier: do you really think about the nodes when editing?

    Tav: suppose you want to modify the existing curve and you want
    the changes to follow that

    shepazu: percentages would do that

    cabanier: you can just calculate where the percentages are, and
    adjust those
    ... you have all the information in the application so you can
    recalculate the percentages

    shepazu: thats an authoring tool implementation detail
    ... suppose you have a percentage, in one mode of your tool, if
    you change the length of the path the percentages stay the same
    ... stroke width changes remain at the same percentages
    ... in another mode when you make the path longer, the
    percentages change
    ... I'm trying to avoid tying it to modes

    Tav: try live path effects on InkScape
    ... it's not tied exactly, if you drag a width point along, it
    moves to the next node

    shepazu: Here's another possibility; we could allow units
    ... if we had a property that had a list of links at which it
    changes
    ... we could have units and allow em, percentages, pixels

    birtles: I think that's good

    shepazu: we have two scenarios
    ... fixed positions of the width node
    ... and variable positions of the width node
    ... and both these are supported by using different units
    ... by pixels I mean unit less device co-ordinates
    ... I have to give a caveat - I have never tried this, it's my
    intuition
    ... I have a third option, if we say widths are tied to
    percentages or pixels
    ... there could be a third thing where we have a keyword or
    something where we tie it to particular nodes

    birtles: I thought that was what you were suggesting

    shepazu: we have different kinds of segments, and they have a
    differing number of nodes, and the nodes may not be on the line
    ... e.g. a bezier
    ... if we are talking Catmul-Rom, I can see a lot of value in
    attaching to the nodes

    cabanier: the control points of the bezier are not useful for
    attaching widths to

    shepazu: so we have a third option - put it at a node on the
    path
    ... so for beziers control points would not be included
    ... I don't know how much complexity that would include, but I
    think those three options will provide real flexibility

    heycam: when Brian was talking about the nodes, I thought he
    was talking about the endpoint of each segment
    ... perhaps with an offset

    shepazu: I think that gets very complex syntactically

    Tav: that's what InkScape does

    cabanier: an author would never think like that

    shepazu: and for hand editing it seems unintuitive

    birtles: I suggested an example on the list, where you are
    resizing a box

    cabanier: do you need to know that in the markup?

    heycam: boxes are simple, I'd be interested to know if it
    applies to other more complex shapes?

    nikos: the box is a simple example but it shoes that it can get
    complicated to keep stroke width profiles attached to segments
    without Brians idea of attaching widths to indexes

    birtles: perhaps we need to consider different syntax proposals
    on the list

    Tav: it would be interesting to look at what we are trying to
    do and craft syntaxes for them

    shepazu: do we agree that we would want to have different
    stroke widths for inner and outer stroke?

    cabanier: no
    ... we discussed in Sydney

    shepazu: I think that will frustrate people, I think they would
    want asymmetry more

    birtles: would you be able to show some examples?
    ... I think we discussed it may be nice to have but for SVG 2
    we could add later

    shepazu: Let's say we have a property, it lets you do pixels or
    percentages and it's a list
    ... we say that's good enough for version 1 - symmetrical
    stroke width
    ... it makes it harder to do the syntax later on if we want to
    add asymmetrical stroke widthds

    birtles: when we make proposals perhaps we can include ways we
    could extend

    cabanier: I think there's a lot of complexity with asymmetrical
    variable stroke

    heycam: I don't think it would be too complex unless they
    overlap

    birtles: once you have asymmetrical strokes, does it suggest
    you want negative widths?

    shepazu: what is the proposed syntax?
    ... for asymmetrical strokes, you have a stroke width and you
    want the stroke width to be applied at ...
    ... you have three values for asymmetrical and two for
    symmetrical
    ... width along the path, and how wide you want it at that
    point
    ... 100% is 100% of the overall stroke width?
    ... e.g. stroke width = 15, 100% at 10 pixels means 100% at 10
    pixels, and you could say 120% or whatever
    ... and that modifies the stroke width at that point

    Tav: InkScape does absolute length. I don't see an advantage to
    using percentages

    cabanier: You can reuse profiles

    shepazu: I was thinking the width would be specified as a
    length for each point, but I like the idea of it being a
    percentage of the stroke width
    ... one of the things we were talking about was the
    interpolation
    ... how would we control that, would it also be a list?
    ... e.g. at some point it's one type of interpolation and at
    another use another type

    Tav: you could always put nodes close together if you want
    sharp edges

    shepazu: so we'd have a third property?
    ... stroke width, variable stroke width, and the third is the
    variable stroke width interpolation - it's a keyword to select
    the interpolation

    cabanier: You can use Catmull-Rom as it does not need extra
    control points

    shepazu: let's say we might have asymmetrical stroke width and
    I go from 0 - 100% and I want it nicely curved - shaped like a
    C
    ... somewhere along the curve we would want it to be a certain
    width
    ... are we talking about widths being defined along the
    normals? or is it always flat

    cabanier: what do you mean by normals?

    shepazu: if you draw a line that is the tangent

    cabanier: yes it should be the normal

    Tav: there's something else to think about - how do we handle
    end caps and line joins?
    ... this is where the arc line join in InkScape comes from

    cabanier: Whats the deal with line joins?
    ... you would still cap it out - it would just be modified by
    the width

    Tav: what does it mean to have a bevelled cap, or a square cap?
    ... if your lines aren't coming in parallel anymore
    ... comes up in asymmetrical and symmetrical cases
    ... suppose you specify the end of your path to be 2 pixels
    wide and away from the end it's 10 pixels wide

    heycam: so at the point where the semicircle connects to the
    path, the path isn't continuous anymore
    ... for a normal stroke they would be going in parallel

    cabanier: let me try in illustrator
    ... it seems like it's capping with respect to the angles of
    the edges of the stroke

    birtles: I wonder what all the different topics are we need to
    follow up on
    ... first would be syntax - I'm happy to start discussion on
    the list
    ... other issues we can also follow up on the list
    ... just want to clarify - Doug you were talking about
    different interpolation modes
    ... is that something we want or not ?

    shepazu: personally I feel we should have different modes - but
    perhaps only two at first - Catmull-Rom and straight

    birtles: I wasn't sure if Tav and Rik were agreeing with that

    nikos: I'd like to see some examples

    Thomas_Smailus: yeh without seeing some graphical use cases I'm
    not sure how it would look

    heycam: If we have curves, they at least degenerate nicely into
    straight lines
    ... that's not to say it might not be nice to have syntax to
    specify sharp changes

    birtles: Doug do you want to produce some pictures and start a
    new thread?
    ... if we decide it's complex, we can only allow one to start
    with

    shepazu: I think it's a minor use case to have anything other
    than a smooth interpolation
    ... so I'd be comfortable with only having a single
    interpolation now and later introduce an interpolation property
    if we see the need
    ... it should be a simple change to the syntax

    heycam: I wonder if you had control over the interpolation,
    whether it would be per segment or overall

    shepazu: I think for calligraphic writing you would want to
    control per segment
    ... would be great for fonts
    ... you could use weights

    Tav: I've experimented with fonts and it was quite difficult

    nikos: it seems like for calligraphy, tuning the variable
    stroke widths would be so complex that you might as well just
    use complex paths to start with

    heycam: Brian do you want to gather up the proposals on the
    wiki page?

    birtles: there's still a lot that's changing so for now I'll
    send some stuff to the list with a straw-man proposal

Summary of Action Items

    [End of minutes]
      __________________________________________________________


     Minutes formatted by David Booth's [8]scribe.perl version
     1.138 ([9]CVS log)
     $Date: 2013-05-09 21:38:05 $
      __________________________________________________________

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

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
Check for newer version at [10]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/describe/described/
Succeeded: s/Brian,/Brian, Rik,/
Succeeded: s/co-ordinate/co-ordinates/
Succeeded: s/that was my suggestion originally/I thought that was what y
ou were suggesting/
Succeeded: s/nomral/normal/
Found ScribeNick: nikos
Inferring Scribes: nikos
Default Present: +1.425.373.aaaa, [IPcaller], birtles, heycam, +61.2.980
.5.aabb, nikos, Doug_Schepers, cabanier, +33.9.53.77.aacc, Tav
Present: +1.425.373.aaaa [IPcaller] birtles heycam +61.2.980.5.aabb niko
s Doug_Schepers cabanier +33.9.53.77.aacc Tav
Agenda: [11]http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun
/0100.html
Found Date: 09 May 2013
Guessing minutes URL: [12]http://www.w3.org/2013/05/09-svg-minutes.html
People with action items:

      [11] http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0100.html
      [12] http://www.w3.org/2013/05/09-svg-minutes.html


    End of [13]scribe.perl diagnostic output]

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

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Thursday, 9 May 2013 21:40:25 UTC