SVG Working Group Teleconference -- 15 May 2008

<trackbot-ng> Date: 15 May 2008

<scribe> scribe: anthony

F2F Agenda recap

<aemmons> http://www.w3.org/Graphics/SVG/Group/wiki/SophiaAntipolisF2F2008

AE: Link to agenda
... is there anything else that we want to add?

<ChrisL> http://www.cg06.fr/transport/lignes-tam/230.pdf

AE: Get an idea of our time spent on each topic
... so if our goal is to make a new publication of the test suite then a bit of time will be spent on that
... do we agree on that

CL: Good idea

DS: Put priority on getting whatever needs to be done to get Tiny 1.2 published
... next is SVG in HTML
... third thing is what is the nature of the SVG IG
... should have a short discussion on this
... what can we get from them
... membership policy, what they can do, etc

AE: Discussion of the new WG home page
... also we have XML HTTP request review

DS: Sort of a moving target
... XH1 is in LC
... should review that
... not necessarily in the F2F

AE: So as far as SVG in HTML, how long will it take to do that?

<ChrisL> (that pdf link has two pages, by the way - page two is the nice to sophia direction)

DS: A couple of us could break off into a scrum

AE: I think for the test suite there will a lot of work there
... put 3 or 4 days to it
... does that sounds like peoples expectations

DS: I would expect 3
... but I could be wrong

AE: We can publish and updated test suite with out an implementation report?

CL: Yes we can

AE: There's no reason to not be able to do one, could be distracting perhaps

ED: Could take a bit of time

<ChrisL> Meet in hotel lobby at 07:50, I wil ltake you on the tram to the bus staion

<ChrisL> then we get the 08:15 sophia express, arriving 09:15

<ChrisL> start meeting at 09:30

Test Review Status

AE: Try to get people to review tests in spare time
... still some tests on the list that don't have a reviewer

1.2 Filter Region Extensions

<aemmons> http://lists.w3.org/Archives/Public/www-svg/2008May/0014.html

ED: I have had a chance to read this
... not sure I agree with this
... can have filter units userSpaceOnUse
... there is a need to have a filter margins to disappear
... Having margins specified in the mark up is ok

CL: Good for authoring tools to specify this

AE: Do we agree with that and should we reply?

ED: We should reply
... I would like to keep filter margins in the spec
... tools can generate the filter-margins markup, and viewers will be able to handle that more efficiently

CL: Think we all agree with you pretty much

<scribe> ACTION: Erik to respond to Robert regarding the removal of SVG 1.2 filter region extensions [recorded in http://www.w3.org/2008/05/15-svg-minutes.html#action01]

<trackbot-ng> Created ACTION-2018 - Respond to Robert regarding the removal of SVG 1.2 filter region extensions [on Erik Dahlström - due 2008-05-22].

feTurbulence clarifications

<aemmons> http://lists.w3.org/Archives/Public/www-svg/2008May/0017.html

ED: This is pretty much resolved as to what he was asking
... in an email thread
... he was asking what one of the parameters to feTurbulence meant

CL: Do people use that C code, does it help them?

ED: I think so

CL: Is it useful as documentation?

ED: I think so

CL: They decided in the past to document using pseudo code
... don't mind putting it in a separate file

ED: Would like to have Cameron to say something about this
... had look at the filter code in Batik
... looked to me like my interpretation was correct

<scribe> ACTION: Eric to clarify parameters to feTurbulence as per Robert's email [recorded in http://www.w3.org/2008/05/15-svg-minutes.html#action02]

<trackbot-ng> Sorry, couldn't find user - Eric

<scribe> ACTION: Erik to clarify parameters to feTurbulence as per Robert's email [recorded in http://www.w3.org/2008/05/15-svg-minutes.html#action03]

<trackbot-ng> Created ACTION-2019 - Clarify parameters to feTurbulence as per Robert's email [on Erik Dahlström - due 2008-05-22].

source-image offset-dimensions control

<aemmons> http://lists.w3.org/Archives/Public/www-svg/2008May/0018.html

ED: was experimenting a bit
... which part of an image you draw
... in an SVG element
... would be useful to pick part of an image

<aemmons> http://lists.w3.org/Archives/Public/www-svg/2008May/0011.html

ED: in image co-ordinates which would be pixels I guess

AE: What feed back did you get on that?

ED: Feedback is positive
... would like to specify percentages of the dimension of the image

CL: so can't you do this in clip?

ED: you can't do any percentages in the clip and you would have to know the dimensions

AE: Interesting if it could be animated

<ed> http://lists.w3.org/Archives/Public/www-svg/2008May/0025.html

ED: Might be possible to do a more general solution
... when referencing an SVG image
... can't override the view box currently

AE: My question is where do you think this would go?
... a future module?

ED: Yes

AE: What kind of module would this be?
... right now it's in structure

ED: Would be useful to discuss how we move forward with the modules
... might be useful to have an SVG Full call module

<ed> s/full call/full core/

ED: certainly a need to add some definitions on top of Tiny

CL: You mean a whole single module that takes Tiny to Full?

ED: Intro definitions need to be updated and what kind of links as well

AE: If there is a general agreement, do we a place on the wiki to put these new ideas

DS: Use tracker and wiki
... Tracker can document individual issues and wiki can be used to give priority

ED: Would like to get feedback from the interest group

<scribe> ACTION: Doug to set up a wiki page that stores our ideas for modules [recorded in http://www.w3.org/2008/05/15-svg-minutes.html#action04]

<trackbot-ng> Created ACTION-2020 - Set up a wiki page that stores our ideas for modules [on Doug Schepers - due 2008-05-22].

DS: What exactly is the first thing I should be putting up here?

AE: The source image proposal that we discussed

filter primitive subregion and feGaussianBlur

<aemmons> http://lists.w3.org/Archives/Public/www-svg/2008May/0013.html

ED: I guess he's correct in restricting calculation is kind of ambiguous
... the section he is quoting is quite generic
... also says it has to be treated like a hard clipping region
... not sure if I replied to this or not

AE: No reply to this
... so is this something that would warrant changing the wording?
... is there something we could change to make it more obvious to others?

ED: Could add implementations are recommended to not perform filtering outside of the hard clipping region

DS: I can't imagine that implementations might want to
... we should make it informative not normative
... this is an implementation tip
... not a conformance criteria

ED: The important part is the clipping region

AE: There's probably no point in adding anything, unless it's a really bad problem

DS: We could make the change and respond

ED: There is a second part here
... haven't had time to study that
... that would need to be addressed as well

CL: What it means it doesn't reflect
... doesn't have an edge
... that says now the filter repeats if it is big enough

<ChrisL> > If the input has infinite extent and is a tile, the filter is evaluated

<ChrisL> with periodic boundary conditions.

<ChrisL> surely if its infinite extent then whether it tiles is irrelevant. there can only be one such tile, so its boundaries are never reached

<ChrisL> check where that sentence comes from, it looks bogus to me.

<scribe> ACTION: Erik to add informative implementation tip regarding filter primitive subregion and research the second question in Robert's email and respond to that as well [recorded in http://www.w3.org/2008/05/15-svg-minutes.html#action05]

<trackbot-ng> Created ACTION-2021 - Add informative implementation tip regarding filter primitive subregion and research the second question in Robert's email and respond to that as well [on Erik Dahlström - due 2008-05-22].

- DRAFT -

SVG Working Group Teleconference

15 May 2008

Attendees

Contents