- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Fri, 23 Jan 2009 08:50:23 +1100
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
http://www.w3.org/2009/01/22-svg-minutes.html
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
22 Jan 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0056.html
See also: [3]IRC log
[3] http://www.w3.org/2009/01/22-svg-irc
Attendees
Present
Shepazu, ed, heycam, [IPcaller], anthony, ChrisL
Regrets
Chair
Erik
Scribe
anthony
Contents
* [4]Topics
1. [5]Focused Telcons
2. [6]Testing Framework
* [7]Summary of Action Items
_________________________________________________________
<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> [8]http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
[8] 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> [9]http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
[9] http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
<scribe> ACTION: Anthony to Merge 'enable-background' definition to
align with Filters module [recorded in
[10]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> [11]http://en.wikipedia.org/wiki/Perlin_noise
[11] 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
[12]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
DS: RGBA?
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> [13]http://dev.w3.org/csswg/css3-fonts/
[13] 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>
[14]http://www.w3.org/2007/11/SVG_rechartering/SVG-WG-charter.html#d
eliverables
[14]
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:
[15]http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html#multires
[15] 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> [16]http://www.schepers.cc/svg/blendups/embedding.html
[16] 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
[17]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
[18]http://www.w3.org/2009/01/22-svg-minutes.html#action02]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [19]scribe.perl version 1.133
([20]CVS log)
$Date: 2009/01/22 21:26:20 $
_________________________________________________________
[19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[20] http://dev.w3.org/cvsweb/2002/scribe/
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 [21]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[21] 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: [22]http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMa
r/0056.html
Found Date: 22 Jan 2009
Guessing minutes URL: [23]http://www.w3.org/2009/01/22-svg-minutes.html
People with action items: anthony chris
[22] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0056.html
[23] http://www.w3.org/2009/01/22-svg-minutes.html
End of [24]scribe.perl diagnostic output]
[24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 22 January 2009 21:51:08 UTC