- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 6 Feb 2009 08:02:50 +1100
- To: public-svg-wg@w3.org
http://www.w3.org/2009/02/05-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
05 Feb 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0086.html
See also: [3]IRC log
[3] http://www.w3.org/2009/02/05-svg-irc
Attendees
Present
[IPcaller], heycam, ed_, ChrisL, anthony
Regrets
Doug
Chair
Erik
Scribe
Cameron
Contents
* [4]Topics
1. [5]Perlin noise function replacement
2. [6]Filters module
3. [7]Compositing module
4. [8]ISSUE-2204: Improve DOM Interfaces for SMIL Values
5. [9]ISSUE-2192: Consider allowing script to implement
certain objects
6. [10]ISSUE-2002: Controlling the implicit viewBox of raster
images used in the <image> element
7. [11]David Dailey's proposals
* [12]Summary of Action Items
_________________________________________________________
<trackbot> Date: 05 February 2009
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
Perlin noise function replacement
<ChrisL> I see the proposal to replace Perlin with Simplex. I
understand that its similar and has lower computational overhead but
am concerned about changing something which already has multiple
interoperable implementations
<ChrisL> I would think that adding it as an addition rather than a
replacement would be more conservative
CL: changing the algorithm would chnage existing content
ED: add a new filter primitive?
CL: if it's in paralell, authors can choose to use the new, less
computationally expensive one
... if we checked over the test cases and found it was almost the
same, or indistinguishable, then perhaps would could replace it
ED: it does look promising performance-wise
<ChrisL> Unless it was visually indisstinguishable of course
<ed_> [13]http://my.opera.com/core/blog/2009/02/04/vega
[13] http://my.opera.com/core/blog/2009/02/04/vega
ED: seems like a good candidate for adding, since it's much easier
to implement in shaders
<ChrisL>
[14]http://www.ciol.com/Semicon/SemiPipes/News-Reports/ARM,-Quickoff
ice-conform-to-W3C-SVG-Tiny-12/2209115443/0/
[14] http://www.ciol.com/Semicon/SemiPipes/News-Reports/ARM
ED: if it turns out to be too different, maybe a new primitive
... or maybe we could do something with a @type attribute on
feTurbulence
CL: for feBlur we say you can do it with gaussian blur, or box blurs
if implementations prefer
... otoh, if it's merely a numerical optimisation that you can't
distinguish in normal operation, then it could be a win to change it
... with filters it's always possible to create something that
"blows up" errors
<scribe> ACTION: Erik to investigate simplex noise filter further
[recorded in
[15]http://www.w3.org/2009/02/05-svg-minutes.html#action01]
<trackbot> Created ACTION-2440 - Investigate simplex noise filter
further [on Erik Dahlström - due 2009-02-12].
Filters module
ED: made some changes, haven't republished
... removed the change bars from the source
... we'll try to use diff tools moving forward
CL: how are you marking up assertions?
<ChrisL> How are you marking up assertions?
ED: i've only marked up a few so far
<ed_> class="requirement" id="assert_fooBar"
ED: the css that this gets doesn't look great, it messes up the
readability
... it displays it with a pink background, i think
CL: we can change the styling
ED: since the filters spec is like the 1.1 chapter, the language in
it is almost all normative text
... not much that wouldn't be marked up this way
... i could mark up small segments that have particular requirements
for attribute values and so on
... not sure if we want to separate authoring requirements and UA
requirements
CL: they should be separate conformance requirements
... there's value in having the IDs on there so that a test can link
to what assertion it's testing
ED: not all the text is worded like MUST/SHOULD, etc.
... sometimes you have to take a whole section of text as a
requirement, not sure if that really helps testing that much
<ed_>
[16]http://dev.w3.org/SVG/modules/filters/master/SVGFilter.html
[16] http://dev.w3.org/SVG/modules/filters/master/SVGFilter.html
ED: e.g. filter region extensions contains many different
requirements
... if you take filter primitive subregion, that contains 5 or 7
paragraphs
... but some of them make sense only in context
... i'd like to avoid making too drastic changes to the text itself
... rewording it to look like a requirement might make the text less
readable
... limitingConeAngle shows the style used currently
... i wouldn't like to have them look like this in the final
document
CL: it's something that could be done as an alternate stylesheet
ED: i tried replacing the image in the introduction
... I now use an <object> referencing the SVG directly, with a
fallback PNG <img>
... didn't look OK in IE when i tested it
CL: shouldn't it display the png?
ED: should, but it didn't
<ChrisL> [17]http://www.w3.org/Graphics/atypical-color-response.htm8
[17] http://www.w3.org/Graphics/atypical-color-response.htm8
<scribe> ACTION: Erik to fix the mathml <object type> attributes in
the filters module [recorded in
[18]http://www.w3.org/2009/02/05-svg-minutes.html#action02]
<trackbot> Created ACTION-2441 - Fix the mathml <object type>
attributes in the filters module [on Erik Dahlström - due
2009-02-12].
ED: does ie display only text fallback, can you put markup?
... i'd like to use png as fallback
... i also included the old "click here to view as svg" link
... another minor change is that we used to link to whatwg, now we
link to the w3c html 5 spec
... but it's only informative
Compositing module
ED: any updates?
AG: not yet
... not many changes to be made for the formula
... do we still want to make a FPWD after putting those formulae in?
... or wait until the f2f?
ED: doug said he'd need to do some things with it first
ISSUE-2204: Improve DOM Interfaces for SMIL Values
ISSUE-204?
<trackbot> ISSUE-204 does not exist
ISSUE-2204?
<trackbot> ISSUE-2204 -- Improve DOM Interfaces for SMIL Values --
RAISED
<trackbot> [19]http://www.w3.org/Graphics/SVG/WG/track/issues/2204
[19] http://www.w3.org/Graphics/SVG/WG/track/issues/2204
ED: i guess doug should be here for this
... there was a question on svg-dev on how to get the animated
position of something animated with animateMotion
... it's a bit less than easy to get that information from the dom
currently
... this is something we could improve
... for example, since the animateMotion element has a path (or at
least is linked to an mpath), then it's actually holding the motion
path
... so you could query the animateMotion element for position on
path
... it would be possible to expose that information
... we could also expose the path itself
... in the case when animateMotion has a d attribute defined, then
it's not accessible in the DOM at all
... possible with the uDOM, but not in 1.1
CM: is path data one of those interfaces that we could mix in to the
animateMotion interface?
AG: is it any easier to just directly query it to get the x/y
position?
ED: the animateMotion element describes a supplemental
transformation, and that transformation is not exposed in the dom
AG: the transformation wouldn't have to be, when you return the
value, wouldn't you just apply the transform at that point?
ED: perhaps you could get the bounding box, but that wouldn't
include the transformation
... wonder if the animated transform value could be exposed
AG: it might be useful for mapping applications
CM: we could expose three attributes: x, y and rotate
ED: so they'd be the current values?
CM: whatever they are at the current time
ED: would be a bit easier
... it'd be easy for us to expose this
CM: would be difficult to compute position when using paced
animation if only the path data were exposed
AG: be more efficient to do that in the UA
<ChrisL> No reason the user should be forced to implement distance
along a path themselves. better to expos it.
ED: I wouldn't mind seeing this added, but we don't have a module to
add it to.
CL: maybe the "wrap up spec" (that takes the base plus the modules)
could hold these minor improvements
AG: would that be Full?
CL: not sure what the name would be
ED: i can write up a definition in a text file and mail it to the
list
... it'd be better if i could check it in to a spec somewhere
AG: check it in to the repository instead?
ED: in the proposals/ directory?
AG: drop the files in there, name them according to their feature
<scribe> ACTION: Erik to investigate and write a draft for motion
animation dom feature [recorded in
[20]http://www.w3.org/2009/02/05-svg-minutes.html#action03]
<trackbot> Created ACTION-2442 - Investigate and write a draft for
motion animation dom feature [on Erik Dahlström - due 2009-02-12].
ISSUE-2192: Consider allowing script to implement certain objects
ISSUE-2192?
<trackbot> ISSUE-2192 -- Consider allowing script to implement
certain objects -- RAISED
<trackbot> [21]http://www.w3.org/Graphics/SVG/WG/track/issues/2192
[21] http://www.w3.org/Graphics/SVG/WG/track/issues/2192
<ed_> CMC: this is how we can improve SVGRect and SVGMatrix and so
on
<ed_> ...had an idea of ducktyping them
<ed_> ...not sure if that's the best idea, since some of them have
methods on them
<ed_> ...so if you represent it with a js object then it would be
different from a real SVGMatrix for example
<ed_> ...the second suggestion might be good though
<ed_> AG: i like it, looks good
<ed_> CMC: some of the objects aren't tied to anything, so it would
be fine to construct them in this way
<ed_> CL: does this relate to live values?
<ed_> CMC: no
<ed_> ...just a shorthand
<ed_> ED: have you made a list of which objects would be possible to
have with constructors?
<ed_> AG: mostly for basic types I guess
<ed_> CMC: yeah, svgnumber, svglength etc
<ed_> CL: will need a proposal for how this would work
<scribe> ACTION: Cameron to write up a proposal for SVG type
constructors [recorded in
[22]http://www.w3.org/2009/02/05-svg-minutes.html#action04]
<trackbot> Created ACTION-2443 - Write up a proposal for SVG type
constructors [on Cameron McCormack - due 2009-02-12].
ISSUE-2002: Controlling the implicit viewBox of raster images used in
the <image> element
ISSUE-2002?
<trackbot> ISSUE-2002 -- Controlling the implicit viewBox of raster
images used in the <image> element -- RAISED
<trackbot> [23]http://www.w3.org/Graphics/SVG/WG/track/issues/2002
[23] http://www.w3.org/Graphics/SVG/WG/track/issues/2002
ED: being able to control the viewBox of a raster image in an
<image> element
... it has an implicit viewBox that you can't affect, currently
... it's the native dimensions of the image
... that is kind of limiting, it means you cannot have for example a
PNG consisting of many small sprites
... the use case for having such PNGs is to reduce network requests,
helps file sizes too
... there are some issues with allowing control
... i mention two of them in the issue
... first is that sometimes you want to be able to specify the
rectangle you want in raster image coordinate space
... sometimes you want to use percentages
... those should probably be resolved relative to the raster image
dimensions
... i'm wondering for cases where you reference an svg file instead
whether we want to allow that there too
... the problem with having percentages supported is that viewBox
doesn't support having percentages in them
CL: if we changed viewBox to do that it would introduce an ambiguity
ED: if you put a viewBox on an <image> element it wouldn't be looked
at, or would it override?
CL: i'd like to be able to say what the range of coordinates of the
raster image
... and say, use this portion of it here, this portion there, etc.
... what about <use>?
... a raster image has dimensions in pixels
... i can see the value in saying "i want this pixel range of this
raster image" but then have that size specified in user units
... you could use this for a cheap animation effect (like a flip
book) with the frames in the one image
<ed_> For most raster content (PNG, JPEG) the bounds of the image
should be used (i.e. the 'image' element has an implicit 'viewBox'
of "0 0 raster-image-width raster-image-height")
<ed_> "most"?
CM: you could have an attribute that says values in the range [0,1]
are interpreted as percentages
ED: i don't think there's a problem with using viewBox on <image>
elements
... on old viewers it wouldn't do anything
... new content using this wouldn't be backwards compatible
... i did a quick test, haven't seen what happens in current viewers
yet when using viewBox on an <image>
<scribe> ACTION: Erik to write up <image> viewBox proposal and test
current UAs [recorded in
[24]http://www.w3.org/2009/02/05-svg-minutes.html#action05]
<trackbot> Created ACTION-2444 - Write up <image> viewBox proposal
and test current UAs [on Erik Dahlström - due 2009-02-12].
<ed_> [25]http://srufaculty.sru.edu/david.dailey/svg/spec.html
[25] http://srufaculty.sru.edu/david.dailey/svg/spec.html
David Dailey's proposals
CL: first is contour/superpath
... seems like a paint server
... paths which determine how the gradient is painted
AG: does the user specify just the start and end path?
CL: the user specifies a set of paths which are tweened to get the
gradient
... similar to the diffusion curves
... so he's using <contour> as a paint server, but <superpath> is
constructing a path from a selection of pieces
... he uses the example where you have a piece of curve that is a
border between two paths, and reuse it in those paths
... it's similar to one of the vector effects features
AG: will we have a thursday telcon next week?
ED: might be able to attend, but not sure
<ChrisL> specifically vePath and vePathRef
ED: sharing path segments sounds good
CL: basically vePath has a bunch of vePathRef children, which are
combined to make a new path
... and there's a reversing operation to change a path's direction
CM: that first <contour> example looks like more than just a paint
server
... seems to be rendering multiple distinct paths, morphed from the
first to the second
... i wonder how difficult this tweening operation is, whether it's
a standard operation
CL: there are multiple algorithms you could choose from
<scribe> ACTION: Chris to look at the overlap between ddailey's
proposals and vector effects [recorded in
[26]http://www.w3.org/2009/02/05-svg-minutes.html#action06]
<trackbot> Created ACTION-2445 - Look at the overlap between
ddailey's proposals and vector effects [on Chris Lilley - due
2009-02-12].
<ChrisL> doodle looks rather like LOGO.
<ChrisL>
[27]http://en.wikipedia.org/wiki/Logo_(programming_language)
[27] http://en.wikipedia.org/wiki/Logo_(programming_language)
ED: a bit vague, i wonder if it is more intuitive than using an
editor
... possibly more intuitive than using the standard path syntax
... but i think it's fairly close to scripting anyway
... you could do it quite readably in script
<ChrisL> to spiral :size
<ChrisL> if :size > 30 [stop] ; an exit condition
<ChrisL> fd :size rt 15 ; many lines of action
<ChrisL> spiral :size *1.02 ; the tailend recursive call
<ChrisL> end
<ChrisL> <script type="application/logo"> ...
CL: i think this falls into the class of things we don't want in the
core language
<ChrisL> <doodle dd="(((M 100 100 radian 330 12) scale .5) iterate
12) (((last duplicate) translate 30) rotate 20 ) iterate 5 >
CL: the suggested syntax isn't super obvious
<ChrisL> its a complete programming language in an attribute, looks
like postscript really
ED: the last paragraph in this section says there might be some use
cases for randomising path data, smoothing, etc.
... that's going to be covered by vector effects?
CL: vector effects doesn't have smoothing or simplification
algorithms
... cartography have a whole field about it
... e.g. simplifying rivers
... seems like something you'd do something between your database
and producing the svg
... the randomising/permuting was included in future work examples
in the svg book
... wouldn't mind including it if we specify it well, but it's not
in vector effects at the moment
<ChrisL> would be interested to add the functionality for
jitter/roughen if it could be specified well
ED: looks like we're passing on this one for now
... <replicate> proposal
CL: this is something that takes one object and produces multiple
derived copies
ED: similar to the doodle proposal, i think
CL: it's parameterised shapes
... you could also specify this as a template which you can
instantiate
... i can see the benefit, but it's a bit underspecified
... if the underlying object changes, do the copies change?
... can you fiddle with the copies?
... it's like the clone behaviour you have in some editors
AG: would it behave like a use?
CL: it's not quite like a use since each replication of the original
object is somehow different (attribute values, etc.)
CM: i'd be in favour of parameterised shapes, like we were going to
have
... not sure about this automatic repetition
ED: we'll have two telcons next week, hopefully have decent
attendance
trackbot, end telcon
Summary of Action Items
[NEW] ACTION: Cameron to write up a proposal for SVG type
constructors [recorded in
[28]http://www.w3.org/2009/02/05-svg-minutes.html#action04]
[NEW] ACTION: Chris to look at the overlap between ddailey's
proposals and vector effects [recorded in
[29]http://www.w3.org/2009/02/05-svg-minutes.html#action06]
[NEW] ACTION: Erik to fix the mathml <object type> attributes in the
filters module [recorded in
[30]http://www.w3.org/2009/02/05-svg-minutes.html#action02]
[NEW] ACTION: Erik to investigate and write a draft for motion
animation dom feature [recorded in
[31]http://www.w3.org/2009/02/05-svg-minutes.html#action03]
[NEW] ACTION: Erik to investigate simplex noise filter further
[recorded in
[32]http://www.w3.org/2009/02/05-svg-minutes.html#action01]
[NEW] ACTION: Erik to write up <image> viewBox proposal and test
current UAs [recorded in
[33]http://www.w3.org/2009/02/05-svg-minutes.html#action05]
[End of minutes]
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 5 February 2009 21:03:34 UTC