See also: IRC log
<trackbot> Date: 05 February 2009
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
<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
... 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: seems like a good candidate for adding, since it's much easier to implement in shaders
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
... 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].
ED: made some changes, haven't
... 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
... 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
... 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: 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
<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
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
<trackbot> ISSUE-204 does not exist
<trackbot> ISSUE-2204 -- Improve DOM Interfaces for SMIL Values -- RAISED
ED: i guess doug should be here
... 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
... 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].
<trackbot> ISSUE-2192 -- Consider allowing script to implement certain objects -- RAISED
<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].
<trackbot> ISSUE-2002 -- Controlling the implicit viewBox of raster images used in the <image> element -- RAISED
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")
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].
CL: first is
... 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
... 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.
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> <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
... 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
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/text/link/ Succeeded: s/countour/contour/ Found Scribe: Cameron Found ScribeNick: heycam Default Present: [IPcaller], heycam, ed_, ChrisL, anthony Present: [IPcaller] heycam ed_ ChrisL anthony Regrets: Doug Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0086.html Found Date: 05 Feb 2009 Guessing minutes URL: http://www.w3.org/2009/02/05-svg-minutes.html People with action items: cameron chris erik WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]