SVG Working Group Teleconference -- 09 May 2013

<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

- DRAFT -

SVG Working Group Teleconference

09 May 2013

Attendees

Contents

textLength tests

Variable Width Stroke

Summary of Action Items

Scribe.perl diagnostic output