SVG Working Group Teleconference

22 Jan 2009


See also: IRC log


Shepazu, ed, heycam, [IPcaller], anthony, ChrisL




<trackbot> Date: 22 January 2009

<trackbot> Meeting: SVG Working Group Teleconference

<trackbot> Date: 22 January 2009

<scribe> Scribe: anthony

Focused Telcons

<ChrisL> 1

ED: I think that it would be good to split up the telcons so that we can both work
... on finishing the SVG Errata and work on new things at the same time
... this was also suggested by Doug
... and I think Heycam is also in agreement with the idea
... I suggest we start today in dealing with only the new stuff
... and we'll keep Monday with dealing with maintenance work
... I'm happy to switch chairing of the days as well if you want Heycam

CMC: How will we schedule the discussion of the new things?

ED: On the agenda I've added the road map on the Wiki
... but I wanted to get some idea where we are with all the work items
... so we are suppose to be publishing documents every 3 months
... we published SVG Tiny 1.2 on Dec 22nd
... we have until March I guess

DS: We should be really strict about publishing

CL: I agree
... it's more strict than that
... because it's suppose to be for every document
... it depends on the number of deliverables
... the original intention is if you are work on a document
... you should the public what you're working on every 3 months

<heycam> "To this end, each Working Group SHOULD publish in the W3C technical reports index a new draft of each active technical report at least once every three months. An active technical report is a Working Draft, Candidate Recommendation, Proposed Recommendation, or Proposed Edited Recommendation. Each Working Group MUST publish a new draft of at least one of its active technical reports on the W3C technical reports index [PUB11] at least once every three months."

CL: also publishing test suites counts as publication
... there's a team internal tracking system that detects these things
... but publishing test suites is a manual process

DS: I think being a public working group it's more clear what we are doing

ED: So does it make sense to discuss the modules we have before going into the layout requirements

<ChrisL> http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap

CL: Looking at the road map there is one thing missing from it
... there is no indication to say if we plan on publishing on that date
... or if we missed it
... there should be some styling to show if we achieved it
... I was actually attempted to edit it
... so Filters for example
... we have several publications of that
... and we should have some links to that

ED: Maybe we should go through all the specs
... Compositing is the first module

<jwatt> 7841 is being ignored

<shepazu> we can hear you

<jwatt> grr

AG: The Compositing module is pretty much ready to go
... just need to combine the 'enable-background' def

ED: Does it require much effort to get it published

DS: So which working draft is this?

AG: First

CL: Requires approval from domain leader

AG: I'd like to merge the enable-background definition before publishing

DS: So how soon can we publish?

AG: Very soon, next Friday at worst

<ChrisL> http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap

<scribe> ACTION: Anthony to Merge 'enable-background' definition to align with Filters module [recorded in http://www.w3.org/2009/01/22-svg-minutes.html#action01]

<trackbot> Created ACTION-2412 - Merge 'enable-background' definition to align with Filters module [on Anthony Grasso - due 2009-01-29].

ED: I will call for publication of the module as soon as this action is complete

JW: What version?

<ChrisL> Resolved: publish Compositing module as FPWD once ACTION-2412 is complete

DS: First Public Working Draf

ED: So next on the list is the Filters module
... I think we have published this once or twice

<shepazu> Resolution: publish Compositing module as FPWD once ACTION-2412 is complete

ED: I have a huge backlog of actions to do

<ChrisL> Filters last published 1 May 2007

ED: I would have time to do some things while traveling, so the best possible scenario will be I might have something to publish after the Face-to-face
... I have some things I want to discuss with that

CL: Would it be possible to get a new group draft
... for the group to read, or is that pushing it?

ED: Yeah I might not have so much time for that
... I'm going to say looking after the face-to-face for publishing

<ChrisL> http://en.wikipedia.org/wiki/Perlin_noise

ED: The next thing is Gradients

DS: I think that should encompass things like Diffusion Curves
... we were thinking of things like Gradient Mesh

CL: So we have basic gradients already
... I made a proposal that wasn't so good
... then I made a suggestion which uses an algorithm similar to filters
... but it never got implemented

DS: Can you please send an email to summarise that

<ChrisL> ACTION: Chris summarise the current state of the trimesh gradient investigations [recorded in http://www.w3.org/2009/01/22-svg-minutes.html#action02]

<trackbot> Created ACTION-2413 - Summarise the current state of the trimesh gradient investigations [on Chris Lilley - due 2009-01-29].

ED: We have a Paint Servers module, do we need a Gradients module as well

DS: I think this would go under the Paint Servers obviously
... Paint Servers is just an internal name
... We could call it Paint Servers, Gradients and blah blah blah
... implementers are the ones that typically read the specs
... although I could be wrong, designers also
... is there some term of art that means Paint Servers? Maybe a bit more catchier

CL: SVG 1.1 had patterns, so we need somewhere for those to go
... I guess Gradients was separate chapter in 1.1

DS: I think it's all the same thing
... they are applied to fills and strokes
... ok so there are linear and radial gradients
... are we going to duplicate stuff in Tiny 1.2?
... it might nice to have it all in one place

CL: I think the module is adding on
... rather than duplicating

ED: I agree with that
... I think that Tiny 1.2 doesn't have all the things from 1.1

DS: So we are going to have to put Radial and Linear in there because we are going to extend them
... Diffusion Curves or Shaped Gradients
... we may do the Tri-Mesh
... Patterns
... Solid Colours

AG: What about listing all the colours

DS: Can you reference a raster image as fill?

ED: No

DS: You can as a pattern
... I was thinking directly

ED: You can say it's like pattern with some parameters

<ChrisL> Needs to have resolution independence, like filters have

ED: I think that would be quite a natural extension

CL: It needs to work at multiple resolutions


CL: The colours and RGBA are in the CSS Colour module are already there
... it works very simple
... it has a linear like space which is quite important

ED: There is HSLA

CMC: Should they go in the Compositing module?

ED: They'd have to go in Paint Servers because it defines the syntax

CL: You can put it in the different modules, but you'd probably have different conformance levels

DS: I don't think we define how we treat opacity in PNGs

CL: You're right we don't

DS: These are things we should explicitly state

ED: Who is responsible for Gradients/Paint Servers?

CL: Me
... the question is where the PNG transparency tests go?

<ChrisL> ACTION Chris to test PNG transparency and opacity in the SVG 1.1 test suite

<trackbot> Created ACTION-2414 - Test PNG transparency and opacity in the SVG 1.1 test suite [on Chris Lilley - due 2009-01-29].

DS: Stick them in 1.1 for now

ED: Do we have a date or any estimation

CL: It will probably be after Vector Effects
... Realistically one will be on hold
... while I get the other one out

DS: I'm going to remove Gradients from the deliverables roadmap and say it is part of Paint Servers

CL: I'd say April for Paint Servers

ED: So the next one is Layout Requirements and Use Cases

CM: So earlier in the week I started putting somethings in a requirements document
... Maybe I can get the requirements document done by the Face-to-face
... my plan was to have something mostly complete for the face-to-face
... publication of first draft in March

ED: The next one then is the Layout Module
... so that's related to the requirements

CMC: How about July for the first draft, depending on number of revisions for the requirements

ED: Masking and Clipping is the next one
... might want to remove it or combine it in the table
... do we plan any new masking and clipping features?

CL: I can't think of any

DS: The only thing I can think of is the event clipping

<ChrisL> oh, yes, that should go in

ED: There are a few things I can think of
... I don't think there is anything stopping us from combining those two
... next one is Media Access Events
... have we heard of anything from Ikivo?

DS: I think I had an action to email them

ED: It's relatively close to being done
... it seems like it anyway
... Unless we have someone responding from Ikivo we don't have any idea of how long it will be
... Print

CL: We resolved recently to send that one to CR right

ED: Next one would be Transformations
... I guess that's the 3D, 2.5D stuff

AG: Just finished the Use Case and Requirements
... I'd planned on getting feedback at the face-to-face
... I suspect that it will have a similar time line to the Layout Module
... Next one is Vector Effects
... I'm taking the stuff out of the 1.2 Module
... and splitting out a primer and a language spec
... there is a bunch of explanation that's needed
... I've been adding a bunch of diagrams
... I've been doing some illustrations which are SVG
... I'd like to have an illustration that shows putting the fill on top of the stroke. I have a PNG and an SVG of that and I have an example of
... the code snippet for that
... I'd like to also have the beginnings of a test suite as well

DS: I'd like to start using inline SVG with PNG fallback

CL: There are some specs that already do that

DS: Like if you were doing an example in SVG, you'd do a mock up of the result rather the put in the specific syntax
... it's sort of a visual use case and requirements really

CL: So I'd hope to have a First Public Working Draft for the group to look at in the next few weeks

ED: Next spec is Web Fonts

CL: So web fonts was going to be a joint effort, but then CSS got really keen on it
... so we agreed to drop doing things on our part as long as we can review it closely
... John Dagget has made a new publications of the spec
... and I'd like to do a close review of it
... in general it's good
... And I've also joined the CSS Working Group

DS: There is one thing that Webfonts will not cover is SVG Fonts

CL: the other thing is the XML syntax for web fonts
... which is something that XSL is interested in

DS: We might rename our Webfonts module to SVG Fonts
... and change the scope

ED: Is the latest draft using anything from SVG?

CL: Not really

DS: I thought there was one thing he did add but I could be wrong

<ChrisL> http://dev.w3.org/csswg/css3-fonts/

CL: that's the link

ED: SVG 1.1 Full 2nd Edition

CL: I saw that there was going to be a discussion at the face-to-face
... and when we do publish it would be a proposed edited Rec
... I would say April

ED: We also have to deal with comments on the edits we make?

CL: No it's just an AC review

AG: Might want to triage the edits
... there are about 50

ED: So April for publication

DS: We are not going to publish until after the face-to-face so that will be March

<ChrisL> PERin March, so Rec six weeks after

<shepazu> http://www.w3.org/2007/11/SVG_rechartering/SVG-WG-charter.html#deliverables

ED: So the next is SVG Tiny 1.2
... I guess there isn't much going on, just collecting errata
... the next is SVG 1.2 Full Modular

CL: Are we going with that?
... I guess the red boxes indicate that
... I'd leave it for now

DS: We have conflicting constraints, some of the WHAT WG and Mozilla don't want to use Tiny 1.2 as a base
... but JIS do
... I think we'll be able to resolve this once we know the state of all the modules
... so we've reached the end we have SVG 2.0 Core

ED: Same thing I guess

DS: Have we done a checked that all the features in 1.1 that are not in 1.2 Tiny are in the modules

CL: No we haven't and I know there are some features missed

<ChrisL> example of something which is missing: http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html#multires

DS: This is why I think having Core simplifies some things
... because it would save us making artificial modules that collects the bits together

CL: I just gave a link to one
... multi resolution images

<ChrisL> Alternate content based on display resolutions

DS: We don't specify foreignObject very well

<shepazu> http://www.schepers.cc/svg/blendups/embedding.html

<ed> ...and we should mention html

DS: object, iframe and embed should behave the same way

ED: I think iframe is a bit special in this case
... because it can give you scroll bars

DS: But you can actually do that with object and embed as well

ED: Right, but there are different defaults at play

DS: There is another aspect in that whole question. When you are embedding it, how does the sizing work?
... we don't really address that anywhere

JW: It's better address in Tiny
... the bases are covered
... there are a few weird edge cases
... that I don't expect anyone to hit

DS: I have a table and a chart of how it should behave
... and I think Opera has the most sensible behaviour

ED: So this kind of thing would be nice to have in the SVG spec

DS: you mean the table?

ED: Something similar to this
... tests would be great
... we only test SVG, not how you can use it from other languages

DS: So you're right it is something more of the CDF domain
... there are certain things about foreignObject that we need to clarify

Testing Framework

JW: I'm not sure exactly what state it is in this point
... I haven't looked in to how the testing is done at the moment
... basically what I was thinking was, that I'd like to see a testing frame work
... or a format for tests that we can automate the tests
... for the sake of interoperability
... recycle things into a common frame work
... it's a bit of a shame for interoperability if we test different things
... I'd like to explain at the face-to-face our frame work
... and see if we can combine things

DS: I didn't want Anthony to go to far down the road if we are going to do more changes to the framework
... you'd talked about making automated tests
... automated generation might be good for some things like DOM tests
... but you were talking about something like regression tests

JW: Currently it's a bit tricky to do it because it uses custom builds only
... I've already got that framework hacked up to work for I.E. and we have another one set up for rendering

CL: Are you capturing the image then comparing it?
... how are you comparing rendering?

JW: It becomes a bit of a mess when you have different fonts on a different PCs
... for example
... We test things like the arc command which has the mark up to draw a circle
... then we compare that to a circle

DS: In some of Dr Olaf's tests it goes through some permutations
... if red shows up
... then it fails
... so you could say for example if red comes up in my buffer then something is wrong

JW: You could do things like load your test but then tell the frame work to not get a snap shot
... for animation it shouldn't be too hard to extend it
... you can get various snap shots at points in time
... not sure if people think it's worth pursuing

DS: One thing I like is we spent so much time, whole face-to-faces infact
... if we can get this done in an hour
... it would be so much better
... this would be a very different testing methodology than we do at the moment

JW: There are a lot of technical problems, political problems, and social problems
... one of the biggest problems though is interoperability
... which is one of the disadvantages of open standards

Summary of Action Items

[NEW] ACTION: Anthony to Merge 'enable-background' definition to align with Filters module [recorded in http://www.w3.org/2009/01/22-svg-minutes.html#action01]
[NEW] ACTION: Chris summarise the current state of the trimesh gradient investigations [recorded in http://www.w3.org/2009/01/22-svg-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/01/22 21:26:20 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/CL/ED/
Succeeded: s/over/after/
Succeeded: s/need/needed/
Succeeded: s/exmample/example/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: Shepazu, ed, heycam, [IPcaller], anthony, ChrisL
Present: Shepazu ed heycam [IPcaller] anthony ChrisL
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0056.html
Found Date: 22 Jan 2009
Guessing minutes URL: http://www.w3.org/2009/01/22-svg-minutes.html
People with action items: anthony chris

[End of scribe.perl diagnostic output]