- From: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au>
- Date: Fri, 10 May 2013 07:39:52 +1000
- To: <www-svg@w3.org>
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