See also: IRC log
<trackbot> Date: 09 May 2013
<scribe> scribenick: nikos
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
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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at 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 you 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 nikos Doug_Schepers cabanier +33.9.53.77.aacc Tav Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0100.html Found Date: 09 May 2013 Guessing minutes URL: http://www.w3.org/2013/05/09-svg-minutes.html People with action items:[End of scribe.perl diagnostic output]