See also: IRC log
<trackbot-ng> Date: 23 May 2008
<scribe> scribe: erik
<scribe> scribeNick: ed
<anthony> http://lists.w3.org/Archives/Member/w3c-svg-wg/2008AprJun/0111.html
AG: my idea was to organize by
spec / module
... it's easier to make testsuites per module then
... you can link the tests with the spec and vice versa
... the relative links would be smaller
DS: for errata and revisions of
the module we can do it in this structure
... what mistakes in the old structure were in the old
structure?
AE: [drawing on whiteboard]
... explaining new structure
... separate old specs from the new ones, like have an
'archive' directory with the old stuff
- root
+ modules
ED: is it necessary to move the old specs over to the new cvs?
DS: well, the files but not the history
AE: well the history can't be moved anyway I guess
* root
- modules
+ compositing
+ filters
- core
+ 1.2T
+ 2.0
+ XP
- profiles
+ 1.1F
+ 1.2F
- archive
+ <old specs>
- tools
AG: the testsuite revision numbers will change, which is a problem
DS, AE: true, let's publish the testsuite update first, then move it to new cvs-space
scribe: which means we'll have to regenerate the reference images and fix revision numbers for the next publication
AE: so who moves the specs to public cvs?
DS: that would be me
... you will also need cvs access to the new structure /WG and
/IG
TZ: there are many problems to solve parsing, compound documents etc
DS: at this point the parsing
thing is the focus
... we should list the other issues though, but it's probably
something for the CDF group to look at
... to be included in the proposal
TZ: some things are very important to SVG, and I think SVG should specify them
DS: though some things like navigation are generic, and apply outside of SVG too
<zlatinski> Here are the considerations about integrating SVG in HTML (and any other hosting languages):
AE: would be good to move the module table to the new wiki
<scribe> ACTION: AG to move the svg module table to the new wiki [recorded in http://www.w3.org/2008/05/23-svg-minutes.html#action01]
<trackbot-ng> Created ACTION-2037 - Move the svg module table to the new wiki [on Anthony Grasso - due 2008-05-30].
<zlatinski> Parsing
<zlatinski> Re-flow management
<zlatinski> Rendering/Drawing
<zlatinski> CSS integration
<zlatinski> JS context
<zlatinski> Scripting language (JS) DOM access from the hosting to hosted language
<zlatinski> Focus Navigation
<zlatinski> API integration
<zlatinski> Parsing
<zlatinski> Re-flow management
<zlatinski> Rendering/Drawing
<zlatinski> CSS integration
<zlatinski> JS context
<zlatinski> Scripting language (JS) DOM access from the hosting to hosted language
<zlatinski> Focus Navigation
<zlatinski> API integration
<zlatinski> Parsing
<anthony> http://www.w3.org/Graphics/SVG/Group/wiki/SVG_Tiny
http://www.w3.org/2007/11/SVG_rechartering/SVG-WG-charter.html
<aemmons> Scribe: aemmons
ED: Have we published compisiting as first public WD yet?
<anthony> http://www.w3.org/Graphics/SVG/Group/repository/spec/compositing/master/
AG: Not yet
... Pretty straightforward from 1.2 Full WD proposals
... Formatted like print spec
... Does it contain 1.1 compisiting?
... No
AE: Should it? To bring it up to 1.1 full?
AG: Perhaps separate module? Masking and clipping?
AE: Depends on how small we want
our modules
... Ahh, yes it is in our charter
... Two different modules there
TZ: Where is global opacity fit?
AG: Yes, global opacity with 1.1 should be in this module
<scribe> ACTION: Anthony to add 1.1 full opacity to compositing module [recorded in http://www.w3.org/2008/05/23-svg-minutes.html#action02]
<trackbot-ng> Created ACTION-2038 - Add 1.1 full opacity to compositing module [on Anthony Grasso - due 2008-05-30].
ED: These should not be specific
for SVG - good if it can be used for a different language
... Would like to see it as a requirement
AE: What about print?
AG: I have to respond to comments, been busy with SVG testsuite
ED: Compititing defines
enable-background and filters does as well
... It defines how to build a background image
... I am saying we should not try and define again
AG: How is it defined in
filters?
... I thought it was filters only
ED: It would probably be the same,
AG: If you want compositing but
not filters, what do you do?
... Have done a complete description for enable-background
incompositing
... In the primer
<ed> http://www.w3.org/TR/SVGFilter12/#AccessBackgroundImage
ED: In the filter module there is wording to say host language is responsible for defining a set of element
AE: [ Discussion on what to do
with common attributes]
... We can have common attributes, definitions, etc in a
seperate document and peices taken from them when the spec is
generated so that they re-use the same definition
DS: We could have a separate spec
what has these that modules reference
... Perhaps same concept with full, brings in all modules as it
generates the spec
TZ: Should have a dependency graph
DS: Yes
... I think we should ask other implementers what the most
usefl formt would be. Seperate modules in the final form or
seperate modules?
AE: What about gradients?
ED: We need an editor for all modules, this does not have one
http://www.w3.org/Graphics/SVG/Group/repository/spec/compositing/master/SVGCompositing.html
Resolution: We will have assertions tagged and formatted directly in the module specifications like SVG Print and Compositing. This will help testsuite development
DS: I do not like MUST in ALL
CAPS
... Helps readability
... Also may be a large section
... Assertions are really small
... Looks like a list of things as opposed to spec
prose
<scribe> ACTION: Erik to mark up assertions in current filter module specs [recorded in http://www.w3.org/2008/05/23-svg-minutes.html#action03]
<trackbot-ng> Created ACTION-2039 - Mark up assertions in current filter module specs [on Erik Dahlström - due 2008-05-30].
ED: perhaps different classes for
different assertions
... Transformations module?
Resolution: Canon to be editor of Transformations module
<anthony> http://www.w3.org/TR/2004/WD-SVG12-20041027/
AE: The issue is normalizing Q
and T to C
... JSR-287 does not normalizae in this way
... Also, helps implementations which are based on OpenVG
... Still maintain hardware acceleration benefits for various
curve types
... Because OpenVG can do this
ED: It is defined differently in
SVG 1.1 - will be incompatible and need an eratta
... SVG 1.1 full tells you you must normalize it to curve
to
... how it is drawn it is the same
... SVGPathAnimatedPathData
... It is implemented in Opera and Batik
<ed> http://www.w3.org/TR/SVG11/paths.html#InterfaceSVGAnimatedPathData
ED: The Tiny specs says you must
normalize quads - will have to change 1.2 and 1.1
... But, little content using the 1.1 SVGAnimatedPathData
AE: Summarize - increased
compatibilty with JSR-287 and better opportinuty for hardware
acceleration using OpenVG
... con - incompatible with 1.1
remove Translate command Q to command
change: Translate command T to command C
to Translate command T to command Q
Resolution: We will remove Q to C normalization requirement from 1.2 and 1.1
<scribe> ACTION: Aemmons to make and errata item for 1.1 and modify uDOM spec to remove Q to C path normalization [recorded in http://www.w3.org/2008/05/23-svg-minutes.html#action04]
<trackbot-ng> Created ACTION-2040 - Make and errata item for 1.1 and modify uDOM spec to remove Q to C path normalization [on Andrew Emmons - due 2008-05-30].
ED: XHR is in Last Call
... Dues date for comments beginning of June
... Have asked us for comments
<shepazu> http://www.w3.org/TR/XMLHttpRequest/
ED: 2nd of June
... Should ask people on the group for comments
... To me it looks fine
<scribe> ACTION: Erik to send e-mail to the list asking for XHR feedback to be discussed on the May 29th telcon [recorded in http://www.w3.org/2008/05/23-svg-minutes.html#action05]
<trackbot-ng> Created ACTION-2041 - Send e-mail to the list asking for XHR feedback to be discussed on the May 29th telcon [on Erik Dahlström - due 2008-05-30].
<ed> http://www.w3.org/TR/SVGFilterPrimer12/
<ed> http://www.w3.org/TR/SVGFilter12/
<ed> http://www.w3.org/TR/SVGFilterReqs12/
<ed> http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0015.html
AE: Do you think we need a change to the spec to make it more clear?
ED: Yes
... We should add to uDOM normalization section
<shepazu> "Relative commands (c, h, l, m, q, s, t, v, and z) are converted to their absolute counterparts."
<ed> "A command Z is always normalized to command Z, even in the cases where an implicit lineto is added before the path is joined."
<shepazu> "Translate command Z to command Z. Although a 'closepath' has a superficial visual resemblance to a 'lineto', command Z must not be normalized to a 'lineto'."
Action, Ed to add path normalization wording to uDOM. "A command Z is always normalized to command Z, even in the cases where an implicit lineto is added before the path is joined."
<scribe> ACTION: Ed to add path normalization wording to uDOM. "A command Z is always normalized to command Z, even in the cases where an implicit lineto is added before the path is joined." [recorded in http://www.w3.org/2008/05/23-svg-minutes.html#action06]
<trackbot-ng> Created ACTION-2042 - Add path normalization wording to uDOM. \"A command Z is always normalized to command Z, even in the cases where an implicit lineto is added before the path is joined.\" [on Erik Dahlström - due 2008-05-30].
AE: and the wording above that: Relative commands (c, h, l, m, q, s, t, v, and z) are converted to their absolute counterparts."
ED: We should list the max index value for each comand to have it interropable
AE: MOVE_TO, LINE_TO 2
... CURVE_TO, 6
... QUAD_TO, 4
... CLOSE , 0!
... CLOSE, 0
Action, Aemmons to add clarification to getSegmentParam for the max index
AE: Approved:
udom-svgpath-201-t.svg
... Approved: udom-svgpath-202-t.svg
<zlatinski> scrab: atanas
<zlatinski> AG: Talks about Shear transform
<zlatinski> AG: 2.5 vs. 3D
<zlatinski> AG: TO do a real 3D perspective, we really need 4 x 4 matrixes
<zlatinski> because with 3 x 3 we can only rotate in one of the planes
<zlatinski> TZ: THis sounds great, except that the processing power requared for that will be prohibitive
<zlatinski> We did experiment with 3 x 3 and this added significant overhead in the pipeline, but was acceptable
<zlatinski> Considering 4 x 4, i think would be unacceptable from performance perspective
<zlatinski> I would suggest extending the Markup to follow OpenGL/ES spec and utilize the real 3D HW pipeline available today in the market
<zlatinski> The idea is to have the XML be structured the way OpenGL would expect to find and utilize the power of the HW on that - so this would be a real 3D extension (Module)of SVG.
<zlatinski> AG: Cannon believe that to achieve some of the features we need to support 4 x 4
<zlatinski> AE: Do we have to be concern about mobile or SVG in general is a different question.
<zlatinski> DS: Does it really fit in SVG, I would really concentrate the resources on integration with HTML and so forth.
<zlatinski> CL: What are other rendering libraries are doing (other than OpenVG)
<zlatinski> AG: They normaly do 3 x 3
<zlatinski> CS: AG: Can we animate matrix
<zlatinski> CL: There shall be a way to do that
<zlatinski> CL: To support 3 x 3 we also have to normalize it, because how are we going to do calculation of 2 x 3 with 3 x 3
<zlatinski> AE: Are you satisfied with the conclusion
<zlatinski> AG: Not sure if 3 x3 would be OK yet
<zlatinski> AG: I was also looking at the reflection filter - angle and scale offset do a similar effect.
<zlatinski> ED: I think it is possible to do that.
<shepazu> DS: I'd like to do a flip keyword
<zlatinski> CL: TO add more stuff to animate transforms - like scale, flip, around arbitrary point and to add extra filter to take optional transform �.
<zlatinski> ...
<shepazu> ... a vector filter that uses those transform keywords
<zlatinski> CL: I would want to also use % in rotate and in relation to what
<scribe> Scribe: aemmons
<ed> ...and xsl
DS: Change in members, chairs,
would like to make sure we are on the same page
... work together on the same page
... Apple has interesting proposals for CSS
... would like to work with CSS in incorporating these
... most of our presentation properties are CSS properties
ED: Technically not in the CSS spec
DS: Any transforms, etc should
also talk to whoever is specifying Canvas
... we both have transforms
... XSL as well
AG: We've always had a good working relationship with XSL
DS: And want the same for CSS,
etc
... Webfonts a good start to coordinate with them
... Chris has talked with chairs, - a way forward is a joint
task force
... We need to schedule a time with them during the Tpac for a
meeting
<scribe> ACTION: Erik to setup a time to meet CSS during TPac [recorded in http://www.w3.org/2008/05/23-svg-minutes.html#action07]
<trackbot-ng> Created ACTION-2043 - Setup a time to meet CSS during TPac [on Erik Dahlström - due 2008-05-30].
DS: As I understand it is not a high priority for them to do transform enhancements but is a good chance for us to move the web forward
<shepazu> http://dev.w3.org/SVG/
<shepazu> cvs -d dev.w3.org:/sources/public co SVG
<ed> macbookED:~/w3.org ed2$ cvs -d dev.w3.org:/sources/public co SVG
<ed> Permission denied (publickey).
<ed> cvs [checkout aborted]: end of file from server (consult above messages if any)
<shepazu> cvs -d username@dev.w3.org:/sources/public co SVG
<zlatinski> http://weblogs.mozillazine.org/tor/archives/2007/03/svg_priorities_in_firefox_3.html
<shepazu> http://www.svgopen.org/2007/papers/svgopen2007-paper/index.html
<shepazu> Cameron's Layout stuff
Demos layers in SVG using a 'layeredG' element, with level attribute that indicates draw order that can be animated, etc
general discussion between structured approach or flat approach. Drawbacks and benifits to both.
rename layeredG to layers and level attribute to layer
perhaps own 1.2 module, layers
Demonstrated SCXML and SVG working together for complex state machines with no scripting
Mostly adds SMIL events for state entry, exit, change
Very useful for UI
<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_Overview
<shepazu> http://www.w3.org/Graphics/SVG/Group/repository/testsuite/1.2T/resources/http_php.txt
<ed> rrs-agent, make 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/AN/AG/ Succeeded: s/Aprroved/Approved/ Succeeded: s/staff/stuff/ Found Scribe: erik Found ScribeNick: ed Found Scribe: aemmons Inferring ScribeNick: aemmons Found Scribe: aemmons Inferring ScribeNick: aemmons Scribes: erik, aemmons ScribeNicks: ed, aemmons WARNING: No "Present: ... " found! Possibly Present: AE AG CL CS ChrisL DS MikeSmith TZ aemmons anthony change deane ed ed__ jdaggett_ joined left macbookED scrab scribeNick shepazu svg trackbot-ng zlatinski You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Found Date: 23 May 2008 Guessing minutes URL: http://www.w3.org/2008/05/23-svg-minutes.html People with action items: aemmons ag anthony ed erik[End of scribe.perl diagnostic output]