W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

Minutes Jan 22, 2009 telcon

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Fri, 23 Jan 2009 08:50:23 +1100
Message-ID: <4978EA1F.8080004@cisra.canon.com.au>
To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>




       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

22 Jan 2009


       [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


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




      * [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
    ... 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

    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
    ... 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
    ... but publishing test suites is a manual process

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

    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
    ... 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

    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

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

    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
    ... 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

    <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

    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
    ... 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
    ... my plan was to have something mostly complete for the
    ... 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
    ... 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
    ... 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
    ... 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



    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

    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

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
    ... 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
    ... 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
    ... 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
    [NEW] ACTION: Chris summarise the current state of the trimesh
    gradient investigations [recorded in

    [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

      [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
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:41 UTC