- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 19 Sep 2012 17:34:45 +0200
- To: SVG WG <public-svg-wg@w3.org>
http://www.w3.org/2012/09/19-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
19 Sep 2012
[2]Agenda
[2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2012/Agenda
See also: [3]IRC log
[3] http://www.w3.org/2012/09/19-svg-irc
Attendees
Present
Erik, Cameron, Nikos, Doug, Tab, Rik, Cyril, Takagi-san,
Tav, Konno-san, Brian
Regrets
Chair
Cameron
Scribe
nikos, Cyril, cabanier, TabAtkins, heycam
Contents
* [4]Topics
1. [5]radialGradient @fr
2. [6]Mesh Gradients
3. [7]GetSVGDocument deprecation/removal
4. [8]SVGDocument interface (alias to Document?)
5. [9]XLink deprecation
6. [10]Cameron's stuff
7. [11]Hatchings
8. [12]extrapolated line join
9. [13]GetSVGDocument interface
10. [14]spaces/commas in SVG view specification
11. [15]HTML integration
12. [16]SVG DOM improvements
13. [17]rendering-mode: animate
14. [18]SVG documentation
15. [19]CSS Variables and Params
16. [20]rounded corners
17. [21]JSON serialization
18. [22]JSON serialization of SVG
* [23]Summary of Action Items
__________________________________________________________
<heycam> trackbot, start telcon
<trackbot> Date: 19 September 2012
<nikos> scribenick: nikos
radialGradient @fr
ed: I have a couple of questions about the spec
... 1: is fr allowed to be negative?
... I think the thread decided no
2: should the focal point be constrained to be in the circle?
... do we want to be fully compatible with canvas or not?
TabAtkins: I think Canvas behaviour is bad
... whatever we do here I'd like to do it there too
cabanier: in Canvas you get a cone if drawing outside
TabAtkins: that behaviour doesn't make sense - there's a
discontinuity in the behaviour for no good reason
heycam: would you ever want that effect?
TabAtkins: I don't think so
cabanier: all implementations come from PDF
... I think you should match what most people do
... you should do it in CSS as well
TabAtkins: it'
... s not good behaviour
cabanier: so how would you define radial gradients?
TabAtkins: I think the last colour should extend outside the
plane
... or restrict them to clamp
cabanier: I think SVG should match Canvas
heycam: we do clamp right?
ed: yes
TabAtkins: mesh gradients are too complex for CSS
... so what is ill defined about the clamping right now?
... I don't think authors want it to extend, so I think it's
better that we clamp
ed: a secondary issue - what happens if the focal circle radius
cuts through the other circle
TabAtkins: project out where the focal point would be. The
definition should be in terms of the focal point and the fill
shape
... which behaviour do we want? turn it into a cone or clamp?
cabanier: I think it should match what everybody else is doing
ed: even if we wanted to have canvas behaviour we have to keep
old behaviour when it's exactly on the circle
... so we don't break old content
<heycam>
[24]http://jaspervdg.wordpress.com/2012/09/03/specifying-radial
-gradients/
[24]
http://jaspervdg.wordpress.com/2012/09/03/specifying-radial-gradients/
heycam: I'm leaning towards allowing it outside the circle
TabAtkins: I'm not a fan of the cone effect
cabanier: I agree, but I think consistency is important
heycam: what happens when you put the focal point on the edge
in Canvas?
cabanier: they don't have repeat so it's not a problem
ed: I think I agree that consistency with Canvas is important
Resolution: SVG radial gradients will align with Canvas for
behaviour where the focal point is outside the circle
ed: for the case where it's exactly on the circle we are going
to keep the old clamping behaviour for backwards compatibility?
... when the focal point is exactly on the circle
Tav: what colour space do you do the averaging in ?
TabAtkins: CSS takes the easy answer and converts to sRGBA
Tav: optically you would want to use linear
cabanier: the gradient doesn't interpolate linearly
TabAtkins: the averaging should be in the same colour space as
the rest
... I think to get correct colours you average in the same
colour space as you interpolate
<TabAtkins__>
[25]http://dev.w3.org/csswg/css3-images/#find-the-average-color
-of-a-gradient
[25]
http://dev.w3.org/csswg/css3-images/#find-the-average-color-of-a-gradient
<scribe> ACTION: Tav to specify radial gradient behaviour when
the focal point is outside the circle [recorded in
[26]http://www.w3.org/2012/09/19-svg-minutes.html#action01]
<trackbot> Created ACTION-3374 - Specify radial gradient
behaviour when the focal point is outside the circle [on
Tavmjong Bah - due 2012-09-26].
Mesh Gradients
<Tav>
[27]http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_ar
tists.svg#36_0
[27]
http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_artists.svg#36_0
Tav: The basic issue with the gradients right now is how to
handle non-smooth transitions between boundaries
... they cause banding
... that point of the transition looks brighter
... Adobe and Corel draw handle this by doing smoothing that's
hidden from the user
... it gets exported as 8x8 patches in the PDF
... we could do what they do, but that would end with lots of
patches
... or we try some kind of smoothing
... either automatic smoothing or we allow a more complex
syntax that allows colours to be set at points on the handles
or tensor points
heycam: is it like specifying easing?
Cyril: if you have two patches next to each other and you
specify the colour derivatives at the shared points, then you
have a continuous derivative and no banding
Tav drawing on board
Tav: If you have two patches, you want to smooth the join
... what I did is use auto smoothing by looking at the slope
and use that to construct a curve
Cyril: the problem with that is the rendering of patches is not
isolated
Tav: You could define colours at the control points and add
tensor points
Cyril: generally that's not what people do, the colour is
separate from the geometry
shepazu: If you're trying to do patches you are probably trying
to match them to a geometric shape - in most uses
Cyril drawing on board
Cyril: typically a coon's patch is something where you start
with a unit square, with parameters u and v. You have a colour
aspect where you have 4 colours on the corners, you have a
bilinear interpolation inside
... then you have a transformation, from u &v you get x & y on
one side and a colour value on the other side
... what you are proposing is the difference between coon's
patches and tensor patches
... there is also a ferguson patch
... from simplest to more complex - coons, tensor and then
ferguson
... what you are proposing is something like what PDF does with
tensor patches but in the colour dimension and not the
geometric dimensions
Tav: in 1 dimension, you interpolate the colours using a bezier
Cyril: I don't think that is a simple transition to 2
dimensions
... I would need to think about it
Tav: I am always proposing to have the extra points at 1/3rd
and 2/3rd
TabAtkins__: I'm ok as long as there's an automatic way to do
the interpolation
heycam: Are you describing extra things the author has to
specify?
Tav: yes. Or if it's not specified you get the linear
interpolation
heycam: I would like a boolean that enables a way for us to
specify the method of smoothing
shepazu: I'd like to see this proposal in terms of a syntax
Tav: for auto smoothing it would simply be a flag
... I have a proposal syntax
... I think we really need the tensor points as they allow you
to draw how the colours spread inside and helps to remove some
of the banding effects
... <mesh><meshrow><meshpatch><stops>
... when defining tensor points, you could replace that with an
array of rows by columns with a colour array as well
... one mesh consists of 16 points. These points could be
described in an array of points.
shepazu: I don't know if that's simpler
Tav: The points and handles defining the patch map into the
array
... if you are going to add the tensor points inside the patch,
you cannot define them using the path syntax
... slide 33 has an example syntax
shepazu: I'd like to see real world examples of how this is
used and how many patches are needed
Cyril: it's heavily used
... requires many many patches to make an image
shepazu: is this a good use for SVG?
TabAtkins__: it's a very good use for an SVG viewer
shepazu: is this something you could see being added CSS?
TabAtkins__: no.
shepazu: what we want is browser output that is consistent with
the author's view in illustrator and inkscape
heycam: I'd like to avoid having the subdivision in the SVG
shepazu: This seems like something that 1) can't be done
elsewhere in the web platform 2) couldn't be done in CSS (needs
markup) and 3) will meet the real-world needs of authors, which
are good criteria for inclusion in SVG 2
TabAtkins: is this a paint server or just geometry?
Tav: we decided if it's in the defs section it's a paint
server, if it's not then it's geometry
... you need to be able to clip if it's a paint server
Resolution: SVG mesh gradients should have a method for
enabling smoothing and smoothing should be default behaviour
<scribe> ACTION: Rik to find out what method Adobe uses for
smoothing mesh gradients and report to group [recorded in
[28]http://www.w3.org/2012/09/19-svg-minutes.html#action02]
<trackbot> Created ACTION-3375 - Find out what method Adobe
uses for smoothing mesh gradients and report to group [on Rik
Cabanier - due 2012-09-26].
cabanier: if the patches are not hand editable then why not
just make them really compact
shepazu: even if they're not hand editable they still need to
be animatable
ed: One of my main concerns is a lot of details are missing
from the spec at the moment
Tav: they will be added
ed: I'd like references to the algorithms used - they should be
in the spec
Cyril: I'm not sure all the algorithms are royalty free
... at least one has a patent
... I think we won't be mandating a specific algorithm
TabAtkins: that's right, you require a certain output
... it just has to be black box compatible
ed: My other point is about hand authoring - it doesn't seem to
be really possible
... if we were to have a simplified syntax that (perhaps)
wouldn't provide the same accuracy but gives something that
could be manipulated would be useful
shepazu: so it's common for people to use multiple meshes to
create an object
... what's the bounding box?
TabAtkins: if it's geometry then the bounding box is the edges
cabanier: they fold over themselves
TabAtkins: that would be as if any path folds over itself
shepazu: this is different to SVG in some ways - normally in
SVG you have a shape which is the geometry and it might be
affected by properties
... then you fill it with some other thing that doesn't have
geometery/size
cabanier: well we resolved that now radial gradients will have
a boundary
shepazu: but you can't use getBBox on it
heycam: I think doug is saying it can be a mesh object as well
as a paint server
shepazu: under what circumstances would you use it as a paint
server?
... I don't think it is the primary purpose
... we have talked several times about integrating canvas and
svg and having a similar path model
... now we are introducing a new element where you can't do
that path stuff
... for the pepper, I might want to just get the outline
Cyril: you can
cabanier: what about when it folds over itself?
... the outline may not be the outermost path
heycam: if we had this method on circles, etc then it should
work on the patch geometry as well
Cyril: if a patch overlaps itself the path would also, that's
fine
shepazu: if I had line art and I want to colour it using mesh
gradients how would I do that?
TabAtkins: you would use a paint server to contain the colour,
the patches wouldn't match the geometry
... effectively, you would need to trace over the line art
shepazu: I think this has path like characteristics so it
should have path like powers
Tav: I talked to the NVidia guy about HW acceleration and he
said no problem.
Cyril: it's very simple
... When we selected Coon's patches, we also considered
triangle patches.
... the more I read about vectorisation, the more I see this
being used
... I am suggesting we add the triangular representation for
meshes to SVG
heycam: is it wasteful to do the triangles using bezier paths?
Cyril: I would have to investigate but I suspect so
shepazu: Cyril, could you come up with a concrete proposal that
shows syntax and outputs
<scribe> ACTION: Cyril to write up a proposal for a triangular
representation for gradient meshes [recorded in
[29]http://www.w3.org/2012/09/19-svg-minutes.html#action03]
<trackbot> Created ACTION-3376 - Write up a proposal for a
triangular representation for gradient meshes [on Cyril
Concolato - due 2012-09-26].
GetSVGDocument deprecation/removal
SVGDocument interface (alias to Document?)
ed: this is a bout merging all the interfaces of SVGDocument
onto document
... this is the direction HTML is going
... we would want a minimal representation for backwards
compatibility
shepazu: what is the syntax in HTML5
<ed>
[30]http://www.whatwg.org/specs/web-apps/current-work/multipage
/dom.html#document
[30]
http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#document
TabAtkins: HTMLDocument is an alias for document
heycam: if you create a document, the type is defined by the
root element, it can't change mid-life so whatever
functionality for SVGDocument and HTMLDocument should be
available on all documents
shepazu: in HTML, when you try to get forms and there are no
forms, would the result be different in SVG compared to a HTML
doc that has no forms
heycam: document.forms would be a HTML collection object with
length zero
... HTML collection is named HTML collection but it's really
just a collection of any element
shepazu: what difference would this make to authors?
heycam: the difference will be additional properties
shepazu: we can remove details from our specification and refer
to HTML5
... I'm in favour of this, we can special case things as we
find them
TabAtkins: i.e. SVG links are returned as well as HTML links
heycam: we need to discuss the alias
... firstly in the IDL it becomes a partial interface for
document
... the aliasing of the interface, presumably HTML does that
for HTMLDocument
TabAtkins: it just aliases to document. We would use the same
line in SVG
<TabAtkins> "For historical reasons, Window objects must also
have a writable, configurable, non-enumerable property named
HTMLDocument whose value is the Document interface object."
heycam: we will do the same thing
Resolution: SVGDocument will be an alias for document
<scribe> ACTION: ed make SVGDocument into an alias for document
[recorded in
[31]http://www.w3.org/2012/09/19-svg-minutes.html#action04]
<trackbot> Created ACTION-3377 - Make SVGDocument into an alias
for document [on Erik Dahlström - due 2012-09-26].
XLink deprecation
heycam: We might have already decided on this
... whether all attributes become href or whether some become
source and some become href
TabAtkins: I think they should be whatever they all are right
now
... we shouldn't change it, just drop the xlink prefix
... I think we should align script
heycam: there are quite a number of elements that have
xlink:href
shepazu: the idea was that we use xlink:href for any external
resource
... I don't mind if you can use href or src
... we are going to have to xlink:href and href so we might as
well allow src too
<heycam> [32]https://svgwg.org/svg2-draft/attindex.html
[32] https://svgwg.org/svg2-draft/attindex.html
list of things that use xlink:href
a - makes sense
alt-glyph is a reference to an element so should be href
animate elements - makes sense
color-profile - being removed
cursor - represents an external image so could be src, but
cursor is probably not similar to anything in HTML so can be
left as href
image - should allow src
TabAtkins: the ones I'm concerned about are image and script
shepazu: with image, it behaves differently in SVG than in
HTML, so they don't have to align
TabAtkins: script is the one I feel really strongly about
... I might want script to accept 3 attributes, if there are
not strong objections
shepazu: we resolved that href overrides xlink:href
... but there's more to it - i.e. how it is represented in the
DOM
<ed> [33]http://www.w3.org/Graphics/SVG/WG/wiki/Href
[33] http://www.w3.org/Graphics/SVG/WG/wiki/Href
heycam: I like allowing src for script
shepazu: authors expect src
heycam: I propose that src overrides everything
TabAtkins: I'd put src between href and xlink:href
heycam: I'd like to encourage src
shepazu: me too
heycam: set always sets 'src' and 'get' gets the attribute that
exists with the highest precedence.
shepazu: this makes me reconsider image, why are we doing src
in some things and not src in others?
... we could align on src but say there's a couple of quirks
with SVG image.
... so anywhere that HTML has a general kind of element that
uses src instead of href, SVG will also allow src and it will
be the default
heycam: feImage should remain href because it can point to
trees
TabAtkins: I'd like to stay doing what we currently do unless
aligning with HTML
heycam: all the remaining elements in the list are href
... one final issue - on image the href DOM property is an
animated string
... we should make .src be a DOM string that just reflects the
base value, not the animated value
TabAtkins: There's 3 things
... firstly the xlink:href gain a plain href
... secondly, script and image gain a src attribute
thirdly, when getting from any, you get the highest precedence
(src -> href -> xlink:href), when setting you set the highest
that is available
Resolution: We will allow href on all elements that have
xlink:href and allow src on image and script. With details as
in the minutes.
<scribe> ACTION: Cameron to add href on all elements with
xlink:href and add src to image and script [recorded in
[34]http://www.w3.org/2012/09/19-svg-minutes.html#action05]
<trackbot> Created ACTION-3378 - Add href on all elements with
xlink:href and add src to image and script [on Cameron
McCormack - due 2012-09-26].
<Cyril> scribeNick: Cyril
Cameron's stuff
heycam: we have previously described ways of determining
whether pointer-events were within the stroke region or the
fill region or hte marker
... we settled on a method to tell you which region was hit
... I have done that
... it's in the spec
[35]http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSe
p/0194.html
[35]
http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSep/0194.html
<heycam>
[36]https://svgwg.org/svg2-draft/types.html#InterfaceSVGGeometr
yElement
[36]
https://svgwg.org/svg2-draft/types.html#InterfaceSVGGeometryElement
scribe: I took upon myself to add a new interface
... on elements that can be filled and stroke
... there are 2 methods:
isPointInFill
isPointInStroke
scribe: initially it is taking a Point object in user space
... because often you will have a mouse event and you want to
take the coordintes of hte mouseevent and translate them into
the user space
... that's a separate thing that's handy to do
... oh, I forgot to make that change
... SVGPoint should have a constructor that takes an element
and a mouse event
... if the element is not provided, it is assumed to be the
target of the event
... I had the conversion integrated but this is cleaner this
way
... I also worked on markers
... there is a separate interface
<heycam>
[37]https://svgwg.org/svg2-draft/painting.html#InterfaceSVGMark
ableElement
[37]
https://svgwg.org/svg2-draft/painting.html#InterfaceSVGMarkableElement
scribe: it's implemented on elements that can have markers on
... rahter than having a method is point in markers, which
doesn't tell you whjich marker is used
... it uses a marker index
... this covers the automatic marker and the children marker
<cabanier> scribenick: cabanier
<Cyril> scribeNick: Cyril
scribe: in the same order as the rendering order
first the automatic ones and then the positioned ones
scribe: SVGMarkerList gives you a list of marker instances
<heycam>
[38]https://svgwg.org/svg2-draft/painting.html#InterfaceSVGMark
erInstance
[38]
https://svgwg.org/svg2-draft/painting.html#InterfaceSVGMarkerInstance
scribe: giving you the marker, its position ...
... as a length along the path
... the actual point that it's at and the angle
andreas: can you get the segment it's on?
heycam: there is a method for that in PathSegment
... in fact angle and point are not strictly needed, but they
are convenient
rik; can you change hte marker that you get?
heycam: yes, you can change the definition
andreas: sometimes you want to highlight hte marker that is
selected
heycam: that would be difficult for the automatic markers,
because you can't change just one
<birtles> (the method for getting the segment is
SVGPathElement.getPathSegAtLength)
heycam: you probably need to use child markers
tab: I agree
heycam: the marker has now two new attributes: position and
reference
... the SVGMarkerList does not let you add new markers
... it's only access to the computed list of all markers
... it might be a bit tricky to change that
... if this was useful for adding/removing makers
... we could have markers and childMarkers
brian: I noticed that the PathSegList throws an exception
... it is not consistent
heycam: if you use the squared brackets you will not get
exceptions
brian: on marker list the getter is defined to return null if
the index is out of range
... but other interfaces SVGPathSegList it is defined to throw
an Index Size Error
... so we need to make them consistent
... one detail of that is that if you use square brackets
syntax, you won't get an exception regardless of the index and
range
... that's due to the behavior defined in WebIDL
heycam: you could use path.markers[n]
... if you use that even if me make the method throw an
exception this won't
... but I'll add the exception to the method
<scribe> ACTION: heycam to make SVGMarkerList item method
return an exception when the index is out of range [recorded in
[39]http://www.w3.org/2012/09/19-svg-minutes.html#action06]
<trackbot> Created ACTION-3379 - Make SVGMarkerList item method
return an exception when the index is out of range [on Cameron
McCormack - due 2012-09-26].
<scribe> ACTION: heycam to make the SVGPoint changes to take a
mouse event in the constructor [recorded in
[40]http://www.w3.org/2012/09/19-svg-minutes.html#action07]
<trackbot> Created ACTION-3380 - Make the SVGPoint changes to
take a mouse event in the constructor [on Cameron McCormack -
due 2012-09-26].
Hatchings
<Tav>
[41]http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_ar
tists.svg#15_0
[41]
http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_artists.svg#15_0
tav: this is a fairly common technical drawing in maps
... but you can use patterns but there are anomalies at
boundarys
... but there is also a problem for plotters, because the pen
goes up and down at each boundary
... open source plotters use SVG for that
... I'd like to have some feedback on a new syntax
... you specify an angle, origin, pitch and width
... if you want multiple fills you want to use multiple
elements
tab: you are using the line element and it should probably a
path element
tav: yes you could specify a pattern that gets extruded (slide
18)
heycam: dasharray is pitch: gap and width and gap ...
tav: by using the path syntax you can have more complicated
hatchings
tab: would you do a line to if start and end don't match
tav: yes
tab: you determine how large the tile is by using the bounding
box
cyril: how is it different from a pattern
tab: when you tile patterns you should paint each tile
separately
... and that's not what you want for engravers for instance
cyril: what makes this behavior not possible with pattern?
(heycam drawing)
cyril: I don't understand why we need to introduce a new
element just to change the rendering algorithm
doug: this makes it simpler to define a pattern that has
overlaps with other pattern elements
... because it overlaps with itself
(doug drawing example of the zig-zag pattern)
brian: in some cases, when you have cross hatching
tab: I like the syntax on the second slide
... I don't like the more compact representation using the dash
syntax
<birtles> brian: this would make it more easy to detect the
situations andreas showed us yesterday when you want to rotate
the cross-hatching so that the lines don't end up parallel with
the edges of the shape
doug: it would easier to animate this kind of pattern
(andreas showing point hatching)
tab: I like the idea, this is good!
doug: especially given the parameters that control the pattern
repetition
brian: cross-hatching?
tav: easily done with multiple fills
cyril: what about nested hatchings?
tab: no, this just accepts paths
... what happens if you put more complex strokes?
... filling a stroke with a gradient or an image
... does it repeat on a per tile basis or more
... what is the gradientUnit
tav: I haven't thought about it
brian: how important is it to specify colors?
... couldn't you do it on the referencing?
... if you want a gradient, you could do it in a mask
tab: maybe we need to change line to hatchline so that its
stroke property takes only a color and not a paint server
heycam: I'm nto sure it's impossible to have it work for
gradients
... but I can see that so that markers don't go on there
tab: and also filling would be a non-sense
heycam: but it could be made consistent for the model
... I would still be fine with path and line instead of
hatchpath and hatchline
brian: clip-path has restrictions
... already
heycam: it is analogous to clip-path
rik: yes, it's the opposite
<birtles> (that is, children of the clipPath element)
tab: if we say that some attributes are ignored, I would be
fine with it
tav: offset tells you where you start with the pitch
tab: you could use the x,y attributes to encode the offset
brian: how do multiple fills work?
tab: we have to work that out yet
heycam: at some points, we want to allow multiple fills and
multiple strokes without vector effect
tab: that is copy what CSS has done with background and that's
the wrong way
... having a compound fill would be better
rik: I agree
brian: you could bundle a cross-hatch with a background for
instance
RESOLUTION: SVG 2 will have a modified version Tav's hatch
proposal
<scribe> ACTION: Tav to work out the details of the
modifications of the initial proposal [recorded in
[42]http://www.w3.org/2012/09/19-svg-minutes.html#action08]
<trackbot> Created ACTION-3381 - Work out the details of the
modifications of the initial proposal [on Tavmjong Bah - due
2012-09-26].
<scribe> ACTION: Tab to think about a compound paint server
proposal [recorded in
[43]http://www.w3.org/2012/09/19-svg-minutes.html#action09]
<trackbot> Created ACTION-3382 - Think about a compound paint
server proposal [on Tab Atkins Jr. - due 2012-09-26].
(andreas showing a marker centroid example)
<TabAtkins> ScribeNick: TabAtkins
andreas: [shows a mapping example where patterns are placed at
the centroid of the various geometric objects]
TabAtkins: You could do that maybe as a marker positioned at
the centroid?
shepazu: If we exposed that kind of thing, you'd want an
explicit DOM API on <path> returning the centroid as well.
<scribe> ScribeNick: Cyril
doug: centroid is actually not trivial to calculate
heycam: we could make the hatching large enough so that it does
not repeat
... actually you can use a pattern for that
doug: do we add a keyword for centroid
<shepazu>
[44]http://mathforum.org/library/drmath/view/57665.html
[44] http://mathforum.org/library/drmath/view/57665.html
<stakagi>
[45]http://www.georeference.org/doc/transform_centroids.htm
[45] http://www.georeference.org/doc/transform_centroids.htm
(discussion on the centroid properties)
lunch!!
<andreas> Centroid:
[46]http://user.gs.rmit.edu.au/rod/files/publications/MSIA_Cent
roid.pdf
[46]
http://user.gs.rmit.edu.au/rod/files/publications/MSIA_Centroid.pdf
[47]http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_ar
tists.svg#19_0
[47]
http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_artists.svg#19_0
<Tav>
[48]http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_ar
tists.svg#19_0
[48]
http://tavmjong.free.fr/SVG/SVGOpen2012/ARTISTS/svg_2012_artists.svg#19_0
<heycam> ScribeNick: heycam
extrapolated line join
<Tav> [49]http://tavmjong.free.fr/SVG/LINEJOIN/index.html
[49] http://tavmjong.free.fr/SVG/LINEJOIN/index.html
Tav: we talked about this last time
… the question at that point was "what about the math"
… so I've provided it here
… it's straightforward
… you're looking at the curvature at the end of the path where
the two segments join
… using that to draw circles, and you shrink or expand circles
to the edges of the path, and extrapolate from there
TabAtkins: it's just expanding the circle so that it matches
the edge of the path, rather than the center of the path
Tav: you can have a straight line, and then displace that by
half a stroke width
… because sometimes these lines aren't going to intersect
… you might also want to apply a miter limit
TabAtkins: seems reasonable, thanks for working out the math
Cyril: the curvature doesn't take into account the stroke, just
the path?
TabAtkins: correct
Tav: it's going to be the same thing
Cyril: is this implemented somewhere?
Tav: Inkscape has something similar but not quite the same
… the person implementing it just mirrored the path to get the
curvature
… which I don't think you want to do
s/TabTakins/Tav/
cabanier: if they become a line, you miter them?
Tav: there are cases where the circles won't intersect, or if
they're both lines
… then you fall back to miter
heycam: would you want to apply miter-limit to this join, and
also to the fallback to a miter-limited miter?
TabAtkins: no, if the extrapolation doesn't work you fall back
to bevel
… but yes apply miter-limit to extrapolated join
RESOLUTION: We will add extrapolated line joins to SVG 2, using
Tav's proposal.
<scribe> ACTION: Tav to add extrapolated line joins to the
spec. [recorded in
[50]http://www.w3.org/2012/09/19-svg-minutes.html#action10]
<trackbot> Created ACTION-3383 - Add extrapolated line joins to
the spec. [on Tavmjong Bah - due 2012-09-26].
GetSVGDocument interface
heycam: [explains what GetSVGDocumentdoes]
ed: contentDocument doesn't work on embed
[51]http://lists.w3.org/Archives/Public/www-svg/2012Aug/0095.ht
ml
[51] http://lists.w3.org/Archives/Public/www-svg/2012Aug/0095.html
heycam: from my testing there it looks like it is consistently
not render on embed, yes
TabAtkins: I'm fine with keeping it in, for legacy purposes
… would be good to amend the spec to say that it returns the
same as contentDocument for legacy purposes
<ed> from the spec: "This interface is deprecated and may be
dropped from future versions of the SVG specification. Authors
are suggested to use the contentDocument attribute on the
EmbeddingElement interface to obtain a referenced SVG document,
if that interface is available."
RESOLUTION: Keep GetSVGDocument in SVG 2.
spaces/commas in SVG view specification
heycam: just wanted to confirm what our decision was
ed: we decided to allow commas and spaces in viewBox and
preserveAspectRatio attributes, and to only allow comma
separation in the view specification (for fragments)
heycam: ok
HTML integration
TabAtkins: I've started to push on getting html elements
directly in svg
… but not the other way around
…but I will do that just for the resource-like elements (like
clipPath)
[for view fragments, heycam has an action to check if spaces
would work after unescaping url fragments, and then allow
spaces in there if that works]
SVG DOM improvements
heycam: I've added some constructors to SVG type interfaces
… for example
[52]https://svgwg.org/svg2-draft/types.html#InterfaceSVGLength
[52] https://svgwg.org/svg2-draft/types.html#InterfaceSVGLength
… three constructors there
… one initializes it to 0
… another takes the separate value and unit types
… and another takes a string
TabAtkins: the direction for CSS OM values api, is a
constructor named "px"
<TabAtkins> el.style.width = CSS.px(5)
TabAtkins: then the length object has attributes for converting
into various units
birtles: we had a proposal like that already
TabAtkins: this part of the CSS OM proposal is uncontroversial
heycam: how do SVGLength and CSSLengthComponentValue relate
then?
TabAtkins: don't care, but they should behave the same
... you could also have CSS.length("20px")
heycam: would we use CSS.px() objects in place of SVGLength?
TabAtkins: you could make SVGAnimatedLength inherit from
CSSLengthComponentValue
… and then add your baseVal animVal on there
<scribe> ACTION: Tab to write up how SVG types should work with
CSS OM objects [recorded in
[53]http://www.w3.org/2012/09/19-svg-minutes.html#action11]
<trackbot> Created ACTION-3384 - Write up how SVG types should
work with CSS OM objects [on Tab Atkins Jr. - due 2012-09-26].
rendering-mode: animate
shepazu: there are various rendering modes like
geometricPrecision
… when you try to snap to pixels, this affects the rendering
… they're optional anyway, it's a hint
… one of the cases we talked about is when you're animating
… if you use crispEdges for text animation, it'll be jerky
… I'm proposing a hint "animate" so that the user agent know
that this is going to be animated
TabAtkins: so it can switch to a low cost rendering mode?
cabanier: it's higher cost
shepazu: you should switch to a mode that gives the best visual
effect for being animated
ed: if you render a rectangle slowly across the screen you'll
see the snapping happening
… or the blurring if you use the normal one
cabanier: how would you solve it? draw half pixels?
heycam: how is it different from geometricPrecision?
shepazu: an author won't know that the way to make text look
good when you're animating is "geometricPrecision"
… but if you have a mode called "animate", the author will know
… you could say in the spec "if you're animating, use
geometricPrecision", but it will be hard for authors to
discover
… I don't feel too strongly about it, just thought it would be
easier to use
birtles: I think most UAs already detect if something is being
animated and optimize it
Cyril: I think the difference is geometricPrecision, some
heuristic could not detect what the user would prefer
… the browser can detect it's going to be animated
shepazu: maybe we should add in for crispEdges that browsers
may wish to disregard this when animating text
ed: I think it depends on the device
heycam: we could add a note for "auto" to say that text
shouldn't be pixel snapped when it is being animated
<Cyril> hand
RESOLUTION: {shape,text}-rendering should say that "auto" means
that pixel snapping shouldn't be done when animating
<Cyril> hand
<Cyril> hand-
<TabAtkins> Gotta hand it to Zakim, he's pretty weird
<TabAtkins> On the other hand
<scribe> ACTION: Doug to add notes to {shape,text}-rendering
auto to mention not doing pixel snapping when animating
[recorded in
[54]http://www.w3.org/2012/09/19-svg-minutes.html#action12]
<trackbot> Created ACTION-3385 - Add notes to
{shape,text}-rendering auto to mention not doing pixel snapping
when animating [on Doug Schepers - due 2012-09-26].
<Cyril> -hand
SVG documentation
shepazu: for W3C's documentation, I'd like to automatically
extract element/attribute/property names and values from the
spec
… if you could also send me tutorials you'd like to see
CSS Variables and Params
shepazu: params should use the variable mechanism for
substituting values
… for text content, we need something to render it into the
DOM, possibly <tref>
TabAtkins: make it accept a var() function in addition to a
url()
shepazu: I'll work with Tab on this
rounded corners
shepazu: [draws a star with rounded corners]
… [but only on the outer points]
shepazu: my proposal is that you bisect the angle, the center
point of the circle is the point on that line in which a circle
of that radius will fit
… you specify a radius
TabAtkins: this is like a custom line join?
shepazu: yes, basically
… a comma separated list that repeats like dash array
… you give a list of radii, and it applies them in sequence
when a corner is encountered
TabAtkins: this is the arcTo from canvas
heycam: is this like a line join?
shepazu: but this should affect the fill
... with my proposal, you would say r="5", with Tab's proposal
you'd have to change each edge in the path data
heycam: is this only straight line segments?
shepazu: no any segments
TabAtkins: you want to preserve curve continuity when you come
into the arc
shepazu: Tab's counterproposal is better than what you can do
in path today
TabAtkins: yes because you have to do trig
shepazu: this proposal could also apply to rect, polyline,
polygon, star, connector
… on a connector, you might want it to go through an
intermediate point (with an orthogonal connector)
… but with a rounded corner there
… this proposal reduces the amount that you have to type
… even on a <path>, it's easy then to style it differently
… rather than tweaking the path data
TabAtkins: sounds good to me
… the math shouldn't be hard to describe
shepazu: I also want there to be a way to pull this out
… toPathData() on a shape
… I'm not sure I want to see it on path, but on all other
polygon-like elements
… on straight lines it's really easy
… but there could be some odd beziers that would have a bad
effect with this
… so for paths leave it to arcTo, but r on other elements
… this property wouldn't give you control of x and y, just a
single radius
… I'd like to see the difficulties it would introduce to path,
because I'd like to see it there
TabAtkins: there will be some cases that will be difficult to
translate into paths, and some that will look weird
shepazu: I don't mind about the edge cases
... sometimes it will add to the fill and sometimes it will
remove from the fill
heycam: it always goes on the smaller angle? (<180 degrees?)
shepazu: yes
... the property would be dasharray-like, a sequence of radii
TabAtkins: if the r argument on a rect applied in the same
order as border-radius that would be good
heycam: what about applying this to <rect rx ry>?
shepazu: rx ry should win
... if it's not possible to fit the circle between the
segments, then it gets skipped
TabAtkins: is this an attribute or a property?
shepazu: property
<TabAtkins> also a presentation attribute
TabAtkins: just call the property "r"
<ChrisL> @tab all properties are also presentation attributes,
in svg
ed: I want to allow the same thing that border-radius could do
on rect
… different x/y radii
<ChrisL> @ed but then you need to specify how to align the
major and minor axes of the ellipses. circular radii are much
easier for rounding arbitrary shapes
shepazu: ellipses would be hard
<ed> ChrisL, yes, I meant to make <rect> a specialcase
TabAtkins: and you'd have to worry about rotation
shepazu: let's not do radii
s/radii/different x and radii/
*x and y
shepazu: the only element it wouldn't be allowed on is ellipse
<krit> Why not on a per element basis in general
<krit> circle, rect, ellipse doesn't make sense for me with a
new r
rect does, since you can have different things at different
corners
circle and ellipse I don't think it's needed
<krit> heycam: Isn't rx and ry enough on rect?
<birtles> krit: they set the same radii on all vertices
<ChrisL> @krit only one value for the whole rect, though
<krit> ok
<ChrisL> although we could extend rx and ry on rect to allow
(1..4) values
that's also an option, but if we allow this new property on
polygon, polyline, etc. I think it makes sense to use it on
rect too
birtles: when do you want to set different radii on different
points?
TabAtkins: for the star example, you want radius, no radius,
radius, no radius, ...
<ChrisL> as noted earlier, rect differs by allowing elliptical
arc (already). only circluar arc on plyline, polygon and path
though
elliptical arcs make less sense (at least, they're harder) on
non 90-degree angles
<ChrisL> so, i thnk it does not make sense on rect and instead,
the existing rx and ry should be extended to take a list
i.e. not rect
<shepazu> ChrisL, we're proposing both
TabAtkins: we can extend rx/ry attributes too
<ChrisL> while adding the new r property on path, polygon,
polyline and star
<ChrisL> ok
RESOLUTION: We add Doug's r="" proposal for rounded corners for
shape-y elements, and pending the math, for paths too.
... We also allow rx/ry to extend to multiple values on rect.
<scribe> ACTION: Doug to add the r="" proposal to SVG 2.
[recorded in
[55]http://www.w3.org/2012/09/19-svg-minutes.html#action13]
<trackbot> Created ACTION-3386 - Add the r="" proposal to SVG
2. [on Doug Schepers - due 2012-09-26].
<ChrisL> i can take the rx ry extending action
<scribe> ACTION: Chris to extend rx/ry on rect to allow lists
of values. [recorded in
[56]http://www.w3.org/2012/09/19-svg-minutes.html#action14]
<trackbot> Created ACTION-3387 - Extend rx/ry on rect to allow
lists of values. [on Chris Lilley - due 2012-09-26].
there might be some complications with the DOM there, they're
SVGAnimatedLengths now -- would they become
SVGAnimatedLengthLists? not sure.
<ChrisL> yes I suspect so
<ChrisL> do people depend on that in code?
it's possible
<ed> since we're making them properties we'd need to probably
change the DOM somehow anyway
less likely than x/y/width/height but certainly possible
<ChrisL> so that could be a script breaking change
could be
it should be thought about ):
s/):/:)/
JSON serialization
<shepazu>
[57]http://www.w3.org/Graphics/SVG/WG/wiki/Path_toJSON
[57] http://www.w3.org/Graphics/SVG/WG/wiki/Path_toJSON
TabAtkins: the one change I made to your page was removing the
ability to do multiple segments with the one command letter
cabanier: you could make x/y/etc. into an array
shepazu: you could have p[$1\47].x, p[$1\47].y, p[$1\47].x,
p[$1\47].y
TabAtkins: what does that buy you?
<krit> what? ZAKIM!!!
cabanier: it would help you iterate over them
TabAtkins: you would never want to do that
shepazu: you also changed sweepFlag to clockwise
TabAtkins: yes
birtles: what's wrong with an array of points in each command?
TabAtkins: it's a bit harder to work with
… for a MoveTo, for example, instead of blah.x you have to do
blah.p[$1\47].x
<krit> couldn't it also mean that the number of input elements
is unpredictable?
birtles: if you take this and turn it back into a string, it's
easier if it's an array
... there was one library I was using...
<TabAtkins> s/p\[0\].x/p\[0\]/
… it uses points
… but I can see that could be cumbersome
heycam: if you have a fixed number of points per command (<= 4)
which we do, then I think not use an array is better
shepazu: one downside to this is that it doesn't map to the
existing path command letters
<krit> paper.js also has a Path API you could look at
[58]http://paperjs.org/reference/
[58] http://paperjs.org/reference/
shepazu: this current proposal it's more verbose but clearer
cabanier: it doesn't use more memory really
ed: will we have path commands that take arbitrary parameter
lists?
TabAtkins: you can't, because you can't do the automatic
segment repetition that the existing commands do
... the catmull-rom command takes a list of points though
shepazu: yes I wanted to have a new "p" start a separate
catmull-rom curve
<scribe> ACTION: Tab to investigate paper.js' arcThrough
[recorded in
[59]http://www.w3.org/2012/09/19-svg-minutes.html#action15]
<trackbot> Created ACTION-3388 - Investigate paper.js'
arcThrough [on Tab Atkins Jr. - due 2012-09-26].
<cabanier> *krit: we're looking at the paper.js stuff *
JSON serialization of SVG
shepazu: there are some reasons to want a standardised JSON
serialisation of markup in general, including SVG
… this is something that some script libraries do anyway
… it would be good to have a unified way for them to use JSON
serializations of SVG
… rather than each have an ad hoc one
… another thing is it would be useful for postMessage
… this is more general than SVG really
… it wants to be able to serialise any given markup
… this is not recommended for browsers to implement
TabAtkins: we would attach a toJSON to Element, and a fromJSON
to Document
-- end --
<stakagi>
[60]http://www.w3.org/Graphics/SVG/WG/track/issues/2050
[60] http://www.w3.org/Graphics/SVG/WG/track/issues/2050
stakagi: for the JSON path syntax, the names should align with
the proposal for expanded path segment elements
RRSAgent: make minutes
Summary of Action Items
[NEW] ACTION: Cameron to add href on all elements with
xlink:href and add src to image and script [recorded in
[61]http://www.w3.org/2012/09/19-svg-minutes.html#action05]
[NEW] ACTION: Chris to extend rx/ry on rect to allow lists of
values. [recorded in
[62]http://www.w3.org/2012/09/19-svg-minutes.html#action14]
[NEW] ACTION: Cyril to write up a proposal for a triangular
representation for gradient meshes [recorded in
[63]http://www.w3.org/2012/09/19-svg-minutes.html#action03]
[NEW] ACTION: Doug to add notes to {shape,text}-rendering auto
to mention not doing pixel snapping when animating [recorded in
[64]http://www.w3.org/2012/09/19-svg-minutes.html#action12]
[NEW] ACTION: Doug to add the r="" proposal to SVG 2. [recorded
in [65]http://www.w3.org/2012/09/19-svg-minutes.html#action13]
[NEW] ACTION: ed make SVGDocument into an alias for document
[recorded in
[66]http://www.w3.org/2012/09/19-svg-minutes.html#action04]
[NEW] ACTION: heycam to make SVGMarkerList item method return
an exception when the index is out of range [recorded in
[67]http://www.w3.org/2012/09/19-svg-minutes.html#action06]
[NEW] ACTION: heycam to make the SVGPoint changes to take a
mouse event in the constructor [recorded in
[68]http://www.w3.org/2012/09/19-svg-minutes.html#action07]
[NEW] ACTION: Rik to find out what method Adobe uses for
smoothing mesh gradients and report to group [recorded in
[69]http://www.w3.org/2012/09/19-svg-minutes.html#action02]
[NEW] ACTION: Tab to investigate paper.js' arcThrough [recorded
in [70]http://www.w3.org/2012/09/19-svg-minutes.html#action15]
[NEW] ACTION: Tab to think about a compound paint server
proposal [recorded in
[71]http://www.w3.org/2012/09/19-svg-minutes.html#action09]
[NEW] ACTION: Tab to write up how SVG types should work with
CSS OM objects [recorded in
[72]http://www.w3.org/2012/09/19-svg-minutes.html#action11]
[NEW] ACTION: Tav to add extrapolated line joins to the spec.
[recorded in
[73]http://www.w3.org/2012/09/19-svg-minutes.html#action10]
[NEW] ACTION: Tav to specify radial gradient behaviour when the
focal point is outside the circle [recorded in
[74]http://www.w3.org/2012/09/19-svg-minutes.html#action01]
[NEW] ACTION: Tav to work out the details of the modifications
of the initial proposal [recorded in
[75]http://www.w3.org/2012/09/19-svg-minutes.html#action08]
[End of minutes]
Received on Wednesday, 19 September 2012 15:35:36 UTC