minutes, SVG WG Leipzig F2F 2014 minutes, day 3 from Cameron McCormack on 2014-04-09 (public-svg-wg@w3.org from April to June 2014)

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

http://www.w3.org/2014/04/09-svg-minutes.html

[1]W3C

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

- DRAFT -

SVG Working Group Teleconference

09 Apr 2014

[2]Agenda

[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

Attendees

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

Regrets
Chair
Cameron

Scribe
Cameron

Contents

* [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>
[15]https://www.w3.org/Graphics/fx/wiki/Filter_effects#Automate
d_Filter_Region_calculation

[15]
https://www.w3.org/Graphics/fx/wiki/Filter_effects#Automated_Filter_Region_calculation

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
objectBoundingBox
... 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
altogether?

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
be

Tav: it's only useful to have turbulence as input for something
else
... 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
size.

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
conclusion?
... 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
10%

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

<ed>
[16]https://webkit.googlesource.com/WebKit/+/master/LayoutTests
/svg/dynamic-updates/script-tests/SVGFEPointLightElement-dom-y-
attr.js is what it generates

[16]
https://webkit.googlesource.com/WebKit/+/master/LayoutTests/svg/dynamic-updates/script-tests/SVGFEPointLightElement-dom-y-attr.js

<krit>
[17]http://trac.webkit.org/export/167007/trunk/LayoutTests/svg/
dynamic-updates/SVGFEPointLightElement-svgdom-y-prop.html

[17]
http://trac.webkit.org/export/167007/trunk/LayoutTests/svg/dynamic-updates/SVGFEPointLightElement-svgdom-y-prop.html

<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"
stdDeviation="2"
result="blur"></svg:feGaussianBlur><svg:feDiffuseLighting
in="blur" surfaceScale="1" diffuseConstant="1"
lighting-color="yellow"><svg:fePointLight x="100" y="180"

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:
[18]http://lists.w3.org/Archives/Public/public-fx/2014JanMar/01
18.html

[18]
http://lists.w3.org/Archives/Public/public-fx/2014JanMar/0118.html

<birtles> original discussion here:
[19]http://lists.w3.org/Archives/Public/public-fx/2014JanMar/00
63.html

[19]
http://lists.w3.org/Archives/Public/public-fx/2014JanMar/0063.html

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,
blur(4)
... 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
skew(22)skew(22)skew(22)
... 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
behaviour
... 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
numbers

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
type

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
list
... 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
animations
... 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
types
... 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 --

<nikos>
[20]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Advanced_
Gradients

[20]
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Advanced_Gradients

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
gradients
... 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>
[21]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Advanced_
Gradients

[21]
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Advanced_Gradients

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
sufficient

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
method
... 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
lines

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
that
... 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
appropriate

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
continuity

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
accurate
... 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
one

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
products

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

<heycam>
[24]http://www.timeanddate.com/worldclock/meetingtime.html?iso=
20140409&p1=37&p2=152&p3=248&p4=224&p5=179

[24]
http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140409&p1=37&p2=152&p3=248&p4=224&p5=179

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

<heycam>
[25]http://www.timeanddate.com/worldclock/meetingtime.html?iso=
20140409&p1=37&p2=152&p3=248&p4=224&p5=24&p6=179

[25]
http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140409&p1=37&p2=152&p3=248&p4=224&p5=24&p6=179

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

[26]http://www.timeanddate.com/worldclock/meetingdetails.html?y
ear=2014&month=4&day=9&hour=14&min=0&sec=0&p1=37&p2=152&p3=248&
p4=224&p5=24&p6=179

[26]
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=4&day=9&hour=14&min=0&sec=0&p1=37&p2=152&p3=248&p4=224&p5=24&p6=179

Ignore the selected day, just look at the time

[27]http://www.timeanddate.com/worldclock/meetingdetails.html?y
ear=2014&month=4&day=9&hour=13&min=0&sec=0&p1=37&p2=152&p3=248&
p4=224&p5=24&p6=179

[27]
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=4&day=9&hour=13&min=0&sec=0&p1=37&p2=152&p3=248&p4=224&p5=24&p6=179

RESOLUTION: new telcon is 3PM Thursday Euro time

Variable-width stroke

'vector-effect' non-scaling features update

<stakagi>
[28]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/vector_ef
fects_extension

[28]
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/vector_effects_extension

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

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

[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
vector-effect

stakagi: such as non scaling size and fixed position or non
rotating objects, etc
... this wiki page shows an enhanced proposal for vector
effects
... 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>
[30]http://svg2.mbsrv.net/devinfo/devstd/non-scaling-objects-2/
VectorEffectTest.html

[30]
http://svg2.mbsrv.net/devinfo/devstd/non-scaling-objects-2/VectorEffectTest.html

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>
[31]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/vector_ef
fects_extension#Transformation_Formula

[31]
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/vector_effects_extension#Transformation_Formula

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

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
viewports...

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
perspective
... 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
documents?
... 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
now

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
that

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
well

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
brackets
... 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
property

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
[32]http://www.w3.org/2014/04/09-svg-minutes.html#action01]

<trackbot> Error finding 'Takagi-san'. You can review and
register nicknames at
<[33]http://www.w3.org/Graphics/SVG/WG/track/users>.

[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
[34]http://www.w3.org/2014/04/09-svg-minutes.html#action02]

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

<ChrisL> scribenick#: cabanier

<ChrisL> scribenick: ChrisL

Variable stroke width

<birtles>
[35]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Variable_
width_stroke#Syntax_proposal

[35]
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Variable_width_stroke#Syntax_proposal

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

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

[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
asymmetric
... 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
issue
... 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
to

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
drop
... 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
shorthand

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
normalization

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
shapes

(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
page

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
version

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
issue
... 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
definitions

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
works

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

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
fallback

[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
interesting
... 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
content

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
needed

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
chapter
... 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
had
... 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
elements?

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
colour
... 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
value

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
[37]http://www.w3.org/2014/04/09-svg-minutes.html#action02]
[NEW] ACTION: Takagi-san to add vector effects extension
proposal to SVG 2 specification [recorded in
[38]http://www.w3.org/2014/04/09-svg-minutes.html#action01]

[End of minutes]
__________________________________________________________

Received on Wednesday, 9 April 2014 15:48:45 UTC