W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

Minutes, Feb 5, 2009 telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 6 Feb 2009 08:02:50 +1100
To: public-svg-wg@w3.org
Message-ID: <20090205210249.GA11145@arc.mcc.id.au>



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

                               - DRAFT -

                   SVG Working Group Teleconference

05 Feb 2009


      [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


          [IPcaller], heycam, ed_, ChrisL, anthony





     * [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


     [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

   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

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

   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


     [16] http://dev.w3.org/SVG/modules/filters/master/SVGFilter.html

   ED: e.g. filter region extensions contains many different
   ... if you take filter primitive subregion, that contains 5 or 7
   ... 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
   ... limitingConeAngle shows the style used currently
   ... i wouldn't like to have them look like this in the final

   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

   <trackbot> Created ACTION-2441 - Fix the mathml <object type>
   attributes in the filters module [on Erik Dahlström - due

   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


   <trackbot> ISSUE-204 does not exist


   <trackbot> ISSUE-2204 -- Improve DOM Interfaces for SMIL Values --

   <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
   ... 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
   ... so you could query the animateMotion element for position on
   ... 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

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

   <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


   <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

   <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

   <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


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

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

   <trackbot> Created ACTION-2445 - Look at the overlap between
   ddailey's proposals and vector effects [on Chris Lilley - due

   <ChrisL> doodle looks rather like LOGO.


     [27] http://en.wikipedia.org/wiki/Logo_(programming_language)

   ED: a bit vague, i wonder if it is more intuitive than using an
   ... 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
   ... 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
   ... 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
   ... not sure about this automatic repetition

   ED: we'll have two telcons next week, hopefully have decent

   trackbot, end telcon

Summary of Action Items

   [NEW] ACTION: Cameron to write up a proposal for SVG type
   constructors [recorded in
   [NEW] ACTION: Chris to look at the overlap between ddailey's
   proposals and vector effects [recorded in
   [NEW] ACTION: Erik to fix the mathml <object type> attributes in the
   filters module [recorded in
   [NEW] ACTION: Erik to investigate and write a draft for motion
   animation dom feature [recorded in
   [NEW] ACTION: Erik to investigate simplex noise filter further
   [recorded in
   [NEW] ACTION: Erik to write up <image> viewBox proposal and test
   current UAs [recorded in

   [End of minutes]

Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 5 February 2009 21:03:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:10 UTC