See also: IRC log
<trackbot> Date: 22 January 2009
<trackbot> Meeting: SVG Working Group Teleconference
<trackbot> Date: 22 January 2009
<scribe> Scribe: anthony
<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
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> 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
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
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]