SVG Working Group Teleconference -- 05 Feb 2009

<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_> 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> http://www.ciol.com/Semicon/SemiPipes/News-Reports/ARM,-Quickoffice-conform-to-W3C-SVG-Tiny-12/2209115443/0/

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 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_> 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> 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 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> 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 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> 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 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> 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 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_> 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 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> 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

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

- DRAFT -

SVG Working Group Teleconference

05 Feb 2009

Attendees

Contents