- From: Erik Dahlstrom <ed@opera.com>
- Date: Tue, 09 Jun 2009 19:33:50 -0400
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Minutes from day 2:
http://www.w3.org/2009/06/09-svg-minutes.html
or as text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
09 Jun 2009
See also: [2]IRC log
[2] http://www.w3.org/2009/06/09-svg-irc
Attendees
Present
Cameron, Erik, Doug, Jonathan, Chris
Regrets
Chair
Erik
Scribe
Cameron
Contents
* [3]Topics
1. [4]SVG2
2. [5]making things properties
3. [6]Fonts
4. [7]Print / Color
5. [8]Compositing
6. [9]Transforms
7. [10]WebCGM digression
8. [11]back to transforms
9. [12]SVG 1.1 Second Edition
* [13]Summary of Action Items
_________________________________________________________
<trackbot> Sorry, heycam, I don't understand 'trackbot, hello'.
Please refer to [14]http://www.w3.org/2005/06/tracker/irc for help
[14] http://www.w3.org/2005/06/tracker/irc
<trackbot> See [15]http://www.w3.org/2005/06/tracker/irc for help
[15] http://www.w3.org/2005/06/tracker/irc
<trackbot> Date: 09 June 2009
<ChrisL> ScribeNick: ChrisL
SVG2
CL: we have a bunch of open issues on svg2 now, things to discuss
that wewre deferred
ED: Start from a spec
CM: Start from scratch, no grandfathering. More concise
... examples are fine, but crisper conformance statements
JW: should not need the examples to understand the rest
CM: Not as pseudocodey as HTML5
ED: Goal is to pick parts from tiny 1.2 and full 1.1, merged into
one spec
CM: Also some things that are not the right thing that we could
change
CL: Is it possible to conform to both svg2 and svg 1.1/1.2T? Need to
decide on expectetions for older user agents etc
CM: Once svg2 is in the repo it will lead away from fixing up 1.1
ED: merging does not exclude mobile, this is a spec for desktop and
mobile. new iphone supports acid 3 as an example
... opera 9.7 on windows mobile also passes
CM: Forwards/back compat like Tiny, not a complete break
CL: So not a new mime type for example
CM: Userr base is more adapatble
<ed> s/also passes/gets a 100/100 score/
cl: we bneed to not piss off existing adopters like inkscape, kde,
xslfo+svg users
<ed> s/scored 100 out of 100/gets a 100\/100 score/
CL: perhaps we could list our hated or unuseful features
JW: eRR needs better defined
ED: vertical text needs better defined
JW: Lets have a wiki page for this
CL: two secions, one hitlist for dropping and one underdocumented
list
[16]http://dev.w3.org/SVG/modules/color/master/color-syntax.txt
[16] http://dev.w3.org/SVG/modules/color/master/color-syntax.txt
<heycam> ACTION-2550:
[17]http://dev.w3.org/SVG/modules/color/master/color-syntax.txt
[17] http://dev.w3.org/SVG/modules/color/master/color-syntax.txt
<trackbot> Sorry... adding notes to ACTION-2550 failed, please let
sysreq know about it
[18]http://a.deveria.com/caniuse/#agents=All&eras=All&cats=SVG,Summa
ry&alts=j&statuses=rec,cr,wd,ietf
[18] http://a.deveria.com/caniuse/#agents=All&eras=All&cats=SVG
CL: so i think that gradients which link to other gradients has
turned out to be a misfeature
... Markers are an issue, in a new language i would not have
markers, instead i would have a separate polymarker element
... painted bounding box
JW: getting pbb is very expensive
ed: yes, it can be. requires off screen painting in many cases
(some yes it is, no it isn't ratholing)
my it seems to be almost lunchtime
[19]http://www.selenic.com/mercurial/wiki/CvsConcepts
[19] http://www.selenic.com/mercurial/wiki/CvsConcepts
<ed> break for lunch
<ed> back from lunch
DS: Like to lookat the polar element, and nurbs
[20]http://en.wikipedia.org/wiki/Nurbs
[20] http://en.wikipedia.org/wiki/Nurbs
making things properties
ED: CSS wg seemed to think some of our attrs were suitable as
properties, not all of them
CL: So you want to make all attrs properties, doug?
DS: Yes prtetty much
CL, JW: Why?
<ed> ACTION-2569?
<trackbot> ACTION-2569 -- Erik Dahlström to draft a proposal to have
width and height properties -- due 2009-05-27 -- OPEN
<trackbot> [21]http://www.w3.org/Graphics/SVG/WG/track/actions/2569
[21] http://www.w3.org/Graphics/SVG/WG/track/actions/2569
DS: Want to use classes to affect other things than style. d== no,
href, id, no....
JW: Prefer to add on a case by case basis
ED: yes
DS: More a thought exercise
CM: Could use stuff from css3 values and units, so calc()
CL: Would rather have a calculation facility that would work on
attrs and properties
CM: My thinking was that if its easy to turn attr to prop to get
that functionality then do that
... if we can ger a syntax that works on non-property attrs that is
good
ED: So see which of ourt attrs have an existing css property, width
and height obvious ones
CM; If they have the same meaning
<heycam>
[22]http://dev.w3.org/SVG/profiles/1.1F2/publish/attindex.html
[22] http://dev.w3.org/SVG/profiles/1.1F2/publish/attindex.html
s/outs/our/
ED: Is there a global list of all css properties from all css3
drafts?
CL: Not as far as I know
document.properties.iterate()
(discussion on the difficulty of aggregating specs from multiple
WGs)
ED: transform is going into css, so there is anothetr one. need to
define for 2dtx
CM: Likely that animatable attes should be properties (as a first
cut)
... transform, width, height
ED: x1 y1 cx cy etc do not have a direct mapping, but could be more
useful
DS: rx ry has applicability, rounded corners
CL: thats border-radius
JW: Properties that inherit into stuff need to have consistent
meanings from html and css. not so critical for non-inherited
properties
... Concerned over making everything a property
CL (amusing tale of xml:id becoming inherited in C12n)
ED: Could get benefts by yusing transform together with width and
height
CM: Not with rounded corners
... rx has different meaning on rect and ellipse
DS: Not terribly different
... Yesterday I mentioned wanting rx, ry and stroke on image, as a
poor mans clippath
... Is there an optimisation hit for that ... not sure its worth it.
But typically can see the thing you are clipping
CM: Can use 'use' in clippath
... pointing to a graphical shape
(brief discussion about ITU liaison as we remember they meet soon)
ED: Some things that udom is good for and full dome does not cover,
like pulling out a path from a glyph element
... missing from 1.1, should be added
... typed access is better for presentation properties, better than
dom2 style
CM: onclick, not a property
(digression on JSRs)
CM: things that have lengths
DS: Things that don't have complex types
cm: polyline - list of numbers, nt lengths
ds: often wanted a percentage on a path.
CM: Or H 2em
ED: How does css transform integrate into svg, and what about
gradient transform?
... why is it even called gradient-transform and not just transform
... and pattern-trandform
CL: and svg:transform
CM: Points is ok as a property value, but not things more complex
than lists of simple types
(digression on consistent list syntax in SVG2)
ED: Mozilla has transforms in css. does it aply to svg, currently
JW: No it does not, yet
... need to say the property is mapped , or that it takes precedence
... practicval difference if its made to inherit
ED: Not difficult to make it inherit
JW: what if therre is an animateTransform
ED: Works on the eventual transform, after cascading
<ed> CL: (explains CSS and XML animation)
<heycam> CL: doing <animate attributeType="XML"
attributeName="stroke"> animates the property, it's not possible to
animate the presentation attribute separately
ed: JW could you look into how svg transforms and css transforms
interact on svg content?
JW: sure
<scribe> ACTION: jwatt to look into how svg transforms and css
transforms interact on svg content? [recorded in
[23]http://www.w3.org/2009/06/09-svg-minutes.html#action01]
<trackbot> Created ACTION-2603 - Look into how svg transforms and
css transforms interact on svg content? [on Jonathan Watt - due
2009-06-16].
[24]http://dev.w3.org/csswg/css3-values/
[24] http://dev.w3.org/csswg/css3-values/
[25]http://dev.w3.org/csswg/css3-values/#the-calc-function
[25] http://dev.w3.org/csswg/css3-values/#the-calc-function
so calc only does constant expressions on lengths
which must have a unit
<atomic-length> := <number><length-unit>
Issue: At a later date new operators such as min/max, conditionals,
new constants, division by length units etc. may be added.
<trackbot> Created ISSUE-2278 - At a later date new operators such
as min/max, conditionals, new constants, division by length units
etc. may be added. ; please complete additional details at
[26]http://www.w3.org/Graphics/SVG/WG/track/issues/2278/edit .
[26] http://www.w3.org/Graphics/SVG/WG/track/issues/2278/edit
<heycam> CM: it'd be a bit annoying to have to say <rect
width="10px"> instead of <rect width="10">
<heycam> CM: oh no, it's the scientific notation that is restricted
<heycam> CM: so you couldn't say <rect width="1.23e5">
<heycam> CM: and scientific notation is primarily useful for
geometric attributes like width="" on <rect>
<ed>
[27]http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/presentationattr-s
cientificnotation.svg
[27]
http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/presentationattr-scientificnotation.svg
<ed> Opera, Firefox and Safari all behave slightly different on that
testcase
(we agree to try again to get sci.not accepted in css)
CM: units optional in presentation attrs, but required in
stylesheets
<scribe> ACTION: jwatt rock the roc re sci.not [recorded in
[28]http://www.w3.org/2009/06/09-svg-minutes.html#action02]
<trackbot> Created ACTION-2604 - Rock the roc re sci.not [on
Jonathan Watt - due 2009-06-16].
Fonts
<ed> scribeNick: ed
CL: we have a fonts module, but it's not checked in
... john daggett has done some of the work
... subsetting to the parts that are implemented
... extended fontmatching stuff dropped
... things that are missing: standalone spec for svgfonts with
different conformance levels, for xsl
... though they might also want opentype fonts
... extensions of fonts, vertical text
... other things missing: xml syntax
... svgs xml syntax, other spec could cameleon it into another spec
... commenting on css3 fonts
... jdaggett is writing tests
... I'm converting them to svg syntax
... want to put them into the svg testsuite
... he's only testing HTML implementation
CM: saw the mail you sent out about existing implementatioins
... among which are several svg impls
CL: i feel we need more font tests
... good to see opera shipping with support for svgfonts and
truetype fonts
CM: what about hte module?
CL: if it's useful to make a module then I can do the work
CM: useful if we need to define something for xsl
... wopuld the module have @font-face equivalent, would it require
svgfonts?
CL: don't think so, they're more interested in opentype fonts
... downloadable fonts
DS: they're doing print stuff right
... why wouldn't they want svgfonts?
... having a supplementatry spec to svgtiny12 would be good for JIS
... for vertical text
CM/CL: good point
CM: just wondering if it was worth having a module
DS: for vertical text yes
... but does it belong in a font module?
CL: font support for vertical text belongs in a font module
(discussion of vertical text missing in tiny12)
CL: easy to make fonts standalone with added support for vertical
... difficult if it ties into the rest of svg, gradients etc
DS: (draws on whiteboard)
... want to annotate text
... and selectable
CL: you could do one glyph with complex subshapes
... inkscape added some functionality for drawing svgfonts
... do you want an ALT tag?
DS: just some way of saying something is text, and this is what it
represents
... title with a role=text?
... talked to designers, making svg posters made more difficult
because of lacking support
CL: who in moz is working on that btw?
JW: jdaggett I think
CL: happy to help if it's needed
JW: he started asking about svgfonts
(discussion about blocked bugs)
CL: making a module that does tiny fonts + vertical font
... we're not sure about the xml serialization of @font-face (for
possible reuse by xsl)
CM: if JIS is interested question is, what use is it without support
for vertical text?
CL: yeah, it's more useful when combined
<scribe> ACTION: CL to commit the SVG Fonts module, removing the
parts already covered by CSS3 Fonts [recorded in
[29]http://www.w3.org/2009/06/09-svg-minutes.html#action03]
<trackbot> Created ACTION-2605 - Commit the SVG Fonts module,
removing the parts already covered by CSS3 Fonts [on Chris Lilley -
due 2009-06-16].
break for a moment, waiting for anthony to join for discussion on
print/transform/color/compositing modules
Print / Color
AG: CL you split out color right?
CL: yes
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
CL: i was at csswg last week and they want to add cmyk support
... i objected on the grounds that they weren't clear on whether
they wanted icc cmyk or device color
... implementors are demanding it
... hakon doesn't really understand the difference
... response he got back from implementors is that they want both
... so if you look at the current spec it still has the old stuff
about device color
... it says device color is a name followed by a list of numbers
... and the name takes you to a device-color element, which olds an
href that points out to who knows what
... and the example uses a numberOfComponents attribute that's not
used anywhere, and extension namespaces
... the info about what the colours actually are are in a comment
block
... for the common case where you want to say this is device cmyk,
how do you do that?
... what uri should i use/mint to represent device cmyk? there isn't
an easy way to do that.
... so i started changing the device-color element to make that work
... but the css folks just want a simple property value for that,
not indirecting through an xml block
<ChrisL> [30]http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html
[30] http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html
CL: looking at this DoC, all the comments on print
... so you can take a copy of this to make the DoC for the Page
module, changing some bits
... there's a lot of green there, except for one purple item "we
need to change this"
... i've got proposed text in there to accede to the commentor
... "device color would be better using pseudo profiles ...", and i
said we disagree
... but i propose we change that to green/agree, since at the end of
the day what you want is device cmyk (very important), device rgb
perhaps, device grey, and device multi channel which is just as
vague as the current spec
... hexachrome, you could probably do that with an icc profile
... and photo rgb printers like the epsons: cyan, light cyan,
magenta light magenta.... 7 colour printers
... but that's no big deal they take sRGB input
... so i've change the device-color token to be one of device-grey,
device-cmyk, ...
... device-grey takes one colour
... device-rgb takes three colours
... device-cmyk takes four colours
... unlike the current spec, it tells you what those colour
parameters mean
... device-multichannel thing takes how many every colours it takes,
and you don't know what they mean
... but that's by far the least useful case anyway
AG: would you have a list of numbers that you don't know the length
of?
CL: yes
... that's the weak part of the proposal
... jeremias from fop wanted these
... so we're giving them exactly that
... csswg wanted something quite similar to this
... so the vendors who want this functionality get both of the
things what they want
... and we keep inkscape/scribus happy, who also wanted device cmyk
... so i propose that we adopt this, then i add it, which is easy
... and i'll also add the syntax appendix part
<ChrisL>
[31]http://dev.w3.org/SVG/modules/color/master/SVGColor.html
[31] http://dev.w3.org/SVG/modules/color/master/SVGColor.html
AG: did we want to lift any content from my 2007 paper?
CL: yes but that would mostly go in the primer
... another thing i've done is i've changed all the defs of the
rendering intents
... so it uses HP's wording
... (from the DoC)
... at LGM they were happy about splitting the spec apart
DS: people still do want a pagination model, though
CL: they may have misunderstood split to mean throw out
DS: right
... is canon still interested in pagination?
AG: not at the moment
... they're more focussed on the UI stuff at the moment still
... can i get this master version of the spec reviewed by my guys
yet?
CL: i'd like to publish this, i need to do some responses to the
commentors
... so 2 weeks response time for that
... it's public anyway, so you can point them to dev.w3.org
AG: many more changes in the next 2 weeks?
CL: not apart from folding in that syntax change
... i'm likely to beef up the primer
... add the stuff from your paper
AG: we might take the language spec and review it then
CL: sure
... i don't think is just ready for another LC yet
... but fairly shortly after this it should
... i do want to move it forward to CR, since there are implementors
waiting for it
... one of the other things i've put in is a clear conformance
requirement that UAs colour match embedded images
... firstly, the old spec assumed that but didn't mention it really
... it only told you how to override the colour profile with a
different one, which is of less interest
... the reason that's important is that firefox and safari both do
colour management of images now
... so they would conform to that part, and we can raise bugs if
they colour manage images in html and not in svg, and they can reuse
code and just hook it up
AG: can we still add bits and pieces to the language spec?
CL: yes, i'm not asking for a second LC yet, but it's getting close
... so i'll bring that to a telcon, but in a couple of weeks
AG: i think it would be good to have something like "preserve black"
in there, for text
... so if you have text that's black, and set a preserve black on
it, so that it uses the black ink at the cmyk end
CL: if you look at the rendering intents, i've change the language.
one of the changes is that primarily you should be using
relative-colorimetric
... and using that with black point compensation, so if the target
device black is not 0, but some measured value of black, you'll map
your blacks to that
AG: yes but if you wanted to use a different rendering intent, or
the one on the profile isn't there since not all profiles support
it, then you might run in to problems
... i would like to see preserve black in there
... it's also useful for images
CL: so that'd be a second attribute on the <color-profile> element?
AG: yeah probably
... although i'll check with the guys here
CL: i can add it in to the spec so it sounds reasonable
AG: should i propose some wording?
CL: yes please
<scribe> ACTION: anthony to propose wording for "preserve black"
attribute for color profiles [recorded in
[32]http://www.w3.org/2009/06/09-svg-minutes.html#action04]
<trackbot> Created ACTION-2606 - Propose wording for "preserve
black" attribute for color profiles [on Anthony Grasso - due
2009-06-16].
CL: i'm going to start on test cases, tho it's a bit difficult
without an implementation
AG: does opera support colour management?
ED: no
CL: firefox 3.5 does, 3.1 did not
... unless you switched on specific prefs
... only on embedded images
AG: we'll have to think up of some crafty colour values for the
tests
CL: for input i found documentation for the macbeth colour checker
with measured colour values
... got those values converted to cielab
... from that i can produce srgb values etc., so i've done that here
AG: are we going to allow... i know we have solid colour, viewport
fill... what other things use colour? feFlood?
CL: yes
... flood-color
... it's missing viewport-fill though
... there is an outstanding issue that many profiles don't have all
four rendering intents specified, so what do you do if you ask for a
rendering intent that's not supplied?
AG: i think this was mentioned in the first round of comments from
guys here
... they said something on the lines of using fallback, or ignoring
it
CL: if you allow it to use any rendering intent, you need it to
definitely work if it has those rendering intents
... if it only has a single rendering intent, then allow it to use
that
AG: be good to say in the spec if the rendering intent is not in the
profile, then just do colour conversion as normal
... there are also some minor editorial notes that unintentionally
limit things, i'll send those in in the next week or so
... the sentence that begins "if icc based named colours are
provided"
... in "icc named colour", in the first red box
CL: it says it must use it in preference to the fallback
AG: we should remove the "use profile connections other than ciexyz
or ..."
CL: why?
... are there profiles that use other connection spaces?
AG: those are two common ones that i know of, don't know, but they
could
... it's just limiting
CL: i wanted to say that if you get a profile connection space that
you don't know about, then you don't use it
... so you use fallback
AG: ok i like your wording better
<ChrisL> or uses an unsupported profile connection space
<scribe> ACTION: Chris to follow up to all commentors on the colour
module that haven't been responded to [recorded in
[33]http://www.w3.org/2009/06/09-svg-minutes.html#action05]
<trackbot> Created ACTION-2607 - Follow up to all commentors on the
colour module that haven't been responded to [on Chris Lilley - due
2009-06-16].
<scribe> ACTION: Chris to fold in the edits to the colour module
that were discussed at this meeting [recorded in
[34]http://www.w3.org/2009/06/09-svg-minutes.html#action06]
<trackbot> Created ACTION-2608 - Fold in the edits to the colour
module that were discussed at this meeting [on Chris Lilley - due
2009-06-16].
Compositing
AG: haven't done much on that, just letting it sit
... still have to fold in cameron's and erik's comments in
... we haven't worked out any common wording for enable-background
ED: we did publish a first draft of compositing right?
AG: yes
DS: there are a few things that would be good to get done by svg
open, that you are working on
... compositing e.g., what needs to be done for that?
AG: just folding in erik's and cameron's comments
Transforms
DS: did you respond back to dino about the openvg stuff?
AG: openvg is a bit higher level than opengl
... haven't responded back to him about that
... i did ping him and ask him if we can sit down and work out some
common ground for the specs, but he seems to be a bit busy at the
moment
... he'll get in touch with me some time soon
... i did some reading up on perspective transformations in 3d and
looked a number of different ways of doing it
... from what i can tell, and other guys here tell, the way that
canon's proposed matches what's currently known and done out there
... we don't understand the use case & reqs that css have
... e.g. for stringing along multiple perspective transformations in
the one transform property
... so that's the first thing i need to talk to dino about
... i've played around with webkit for a bit, since they implement
the transform stuff
... the results it produces when you apply a perspective transform
seem a bit odd
... it's as if it doesn't implement it at all
... so not sure what's going on there
CM: it might just be the iphone build of safari
AG: i did some testing between the css proposal and ours
... with both you can get the same effects
... but i would like to understand why they want the chainable
perspective transformations
... a lot of the other things are similar, and we could use the same
syntax/spec for
DS: might be useful to still write up why the matrices are the way
they are, and the openvg reasons
AG: using openvg, you need to render all your graphics to a buffer,
flatten it, then apply a 3x3 perspective transform
... the maths is in the spec
... what sort of write up are you looking for?
DS: a rationale about why it doesn't hinder the spec to do it this
way
AG: compared to what css proposes, it doesn't really change anything
DS: but we need to justify it
AG: another thing we'll need in the transforms spec is, and i'd like
the group's opinion on, is an xml syntax for transforms, like we've
discussed with paths
<anthony> <svg>
AG: it's similar to the stuff CRF in EXI have done
<anthony> <defs>
<anthony> <transform id="rotateX_rotateY">
<anthony> <rotateX angle="45" />
<anthony> <rotateY angle="45" />
<anthony> </transform>
<anthony> </defs>
<anthony> <rect ... transform="#rotateX_rotateY" />
<anthony> <circle ... transform="#rotateX_rotateY" />
<anthony> <svg>
AG: one of the advantages i can see is that you don't need to supply
a group around objects to apply a transform, have them referenceable
DS: i can see this useful for grouping logically and according to
appearance
ED: if you have the css transform, it's quite easy to reuse
transforms with that
DS: so yes i see a use case for it. if it's handled by making
transform a property, ...
... probably it's better if we duplicate that functionality [with
the xml syntax]
AG: with css can you animate a component of the transform? say, the
x component?
ED: i don't know exactly if it's easy to do that. you'd have to
split the transfrom property into several parts.
AG: that was one of the other ideas i was thinking of. with the
above example, you can animate individual components of a transform.
CM: that's the same reasoning for separating out the path commands
DS: true
... it reminds me of some things dino wanted to do with scaleX,
scaleY, breaking them out into separate commands
... if they are going to be css properties, aren't the going to be
svg properties as well?
ED: [nods]
<ed> [35]http://dev.w3.org/csswg/css3-3d-transforms/#animation
[35] http://dev.w3.org/csswg/css3-3d-transforms/#animation
CL: if the properties are mapped, you get that for free
CM: i think the css proposal doesn't have separate properties for
scaleX, scaleY, just separate commands in the one property
ED: with css, you can animate individual items
CM: and we have weirdo transform animations
DS: but as separate attributes, then you don't have the ordering any
more
... so it wouldn't work
ED: so it doesn't sound like the broken-up xml syntax is what we
want
CM: will we adopt the css transform animation, or stick with what we
have?
ED: the decomposition?
CM: yes
DS: it'd break backwards compat
ED: other things break tho, such as center point rotation
DS: we should work with css to make sure we all have what we want
WebCGM digression
CL: their transforms now have a center point for rotations
<scribe> ACTION: Chris to mail comments about WebCGM [recorded in
[36]http://www.w3.org/2009/06/09-svg-minutes.html#action07]
<trackbot> Created ACTION-2609 - Mail comments about WebCGM [on
Chris Lilley - due 2009-06-16].
back to transforms
AG: so how do we want to handle animations
... the same as tiny?
<ed>
[37]http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformEl
ement
[37]
http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformElement
<ed>
[38]http://www.w3.org/TR/SVGMobile12/animate.html#complexDistances
[38] http://www.w3.org/TR/SVGMobile12/animate.html#complexDistances
CM: we just do single component animations
ED: makes less sense to interpolate individual components in a 3d
matrix
AG: yeah i guess so
... wondering if there's a use case for it though
... interpolating the whole matrix is definitely useful, individual
ones not sure
... e.g. you might translate something then only animate a rotation
CM: we could add an <animateTransform type="list">
ED: we could keep the current behaviour, then add this to align with
css
CM: i like that, maybe it could even be the default if no type="" is
specified
... though decomposing the matrix and doing linear interpolation on
the components won't give you the same result as linearly
interpolating a rotate() parameter
ED: so would this go in the 3d transforms spec?
AG: i think it belongs in animations chapter of svg 2
ED: yeah
<scribe> ACTION: Anthony to raise an issue on SVG 2 about
animateTransform with matrix-decomposed interpolation like css
[recorded in
[39]http://www.w3.org/2009/06/09-svg-minutes.html#action08]
<trackbot> Created ACTION-2610 - Raise an issue on SVG 2 about
animateTransform with matrix-decomposed interpolation like css [on
Anthony Grasso - due 2009-06-16].
AG: other than that, nothing else to discuss on transforms
ED: nothing to say on print?
AG: no
SVG 1.1 Second Edition
AG: i'm writing up the script at the moment to run through the xslt
to transform the tests
... that should be done tonight
CL: make sure you copy across any attributes on the root <svg>
element, since some tests put some there
AG: ok i'll change the xslt to do that
<xsl:copy-of select='@*[local-name() != "id" and local-name() !=
"width" and local-name() != "height" and local-name() != "viewBox"/>
<anthony> <svg id="svg-root" width="100%" height="100%"
<anthony> viewBox="0 0 480 360"
xmlns="[40]http://www.w3.org/2000/svg"
[40] http://www.w3.org/2000/svg
put that as the first child of your <svg id="svgroot" width=".."
...> result element
<anthony> xmlns:xlink="[41]http://www.w3.org/1999/xlink">
[41] http://www.w3.org/1999/xlink
AG: cdata sections will get stripped out
[42]http://www.w3.org/TR/xslt#output
[42] http://www.w3.org/TR/xslt#output
<karl> hi ChrisL
Summary of Action Items
[NEW] ACTION: anthony to propose wording for "preserve black"
attribute for color profiles [recorded in
[43]http://www.w3.org/2009/06/09-svg-minutes.html#action04]
[NEW] ACTION: Anthony to raise an issue on SVG 2 about
animateTransform with matrix-decomposed interpolation like css
[recorded in
[44]http://www.w3.org/2009/06/09-svg-minutes.html#action08]
[NEW] ACTION: Chris to fold in the edits to the colour module that
were discussed at this meeting [recorded in
[45]http://www.w3.org/2009/06/09-svg-minutes.html#action06]
[NEW] ACTION: Chris to follow up to all commentors on the colour
module that haven't been responded to [recorded in
[46]http://www.w3.org/2009/06/09-svg-minutes.html#action05]
[NEW] ACTION: Chris to mail comments about WebCGM [recorded in
[47]http://www.w3.org/2009/06/09-svg-minutes.html#action07]
[NEW] ACTION: CL to commit the SVG Fonts module, removing the parts
already covered by CSS3 Fonts [recorded in
[48]http://www.w3.org/2009/06/09-svg-minutes.html#action03]
[NEW] ACTION: jwatt rock the roc re sci.not [recorded in
[49]http://www.w3.org/2009/06/09-svg-minutes.html#action02]
[NEW] ACTION: jwatt to look into how svg transforms and css
transforms interact on svg content? [recorded in
[50]http://www.w3.org/2009/06/09-svg-minutes.html#action01]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [51]scribe.perl version 1.135
([52]CVS log)
$Date: 2009/06/09 23:29:25 $
_________________________________________________________
[51] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[52] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20
Check for newer version at [53]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[53] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
WARNING: Bad s/// command: s/also passes/gets a 100/100 score/
WARNING: Bad s/// command: s/also passes/gets a 100\/100 score/
Succeeded: s/also passes/scored 100 out of 100/
FAILED: s/outs/our/
Succeeded: s/cs/cx/
Succeeded: s/different/difference/
Succeeded: s/of/me of/
Succeeded: s/note/not/
WARNING: No scribe lines found matching ScribeNick pattern: <Cameron> .
..
Found ScribeNick: ChrisL
Found ScribeNick: ed
Found Scribe: Cameron
Found ScribeNick: heycam
ScribeNicks: ChrisL, ed, heycam
Present: Cameron Erik Doug Jonathan Chris
Found Date: 09 Jun 2009
Guessing minutes URL: [54]http://www.w3.org/2009/06/09-svg-minutes.html
People with action items: anthony chris cl jwatt
[54] http://www.w3.org/2009/06/09-svg-minutes.html
End of [55]scribe.perl diagnostic output]
[55] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Tuesday, 9 June 2009 23:39:25 UTC