- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Tue, 24 Feb 2009 10:09:01 +1100
- To: Leonard Rosenthol <lrosenth@adobe.com>
- CC: Erik Dahlstrom <ed@opera.com>, "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Hi Leonard,
That'd be great thanks! It'll make things a bit easier for me ;)
I guess the working group can discuss at telcon on Thursday the idea of
referencing ISO 32000-1. From my point of view I don't see any problems with
adding the reference in though.
Regards,
Anthony
Leonard Rosenthol wrote:
> Be aware that Adobe is in the process of publishing a correction to the algorithms for ColorDodge and ColorBurn, as we discovered that the published versions were incorrect for edge cases.
>
> I can send you the revised info if you want.
>
> Leonard
>
> -----Original Message-----
> From: public-svg-wg-request@w3.org [mailto:public-svg-wg-request@w3.org] On Behalf Of Erik Dahlstrom
> Sent: Tuesday, February 17, 2009 2:11 AM
> To: public-svg-wg@w3.org
> Subject: Minutes Sydney 2009 F2F day 2
>
> Minutes available here:
>
> http://www.w3.org/2009/02/16-svg-minutes.html
>
> or as text here:
>
> [1]W3C
>
> [1] http://www.w3.org/
>
> - DRAFT -
>
> SVG Working Group Teleconference
>
> 16 Feb 2009
>
> See also: [2]IRC log
>
> [2] http://www.w3.org/2009/02/16-svg-irc
>
> Attendees
>
> Present
> Regrets
> Chair
> SV_MEETING_CHAIR
>
> Scribe
> jwatt, Cameron
>
> Contents
>
> * [3]Topics
> 1. [4]Transforms module
> 2. [5]CSS Animations spec
> 3. [6]Compositing spec
> 4. [7]Comments from roc
> 5. [8]SVG 1.1 errata
> * [9]Summary of Action Items
> _________________________________________________________
>
>
>
> <trackbot> Date: 16 February 2009
>
> <ed__> jwatt: [10]http://www.opera.com/company/jobs/
>
> [10] http://www.opera.com/company/jobs/
>
> <ed__> not keyboard navigable in FF
>
> <jwatt> scribe: jwatt
>
> <scribe> scribenick: jwatt
>
> Transforms module
>
> <ed__>
> [11]http://dev.w3.org/SVG/modules/transforms/SVGTransforms.html
>
> [11] http://dev.w3.org/SVG/modules/transforms/SVGTransforms.html
>
> AG: I've been working on use cases and requirements
> ... as per concerns raised at the tech plenary last year
>
> <anthony>
> [12]http://dev.w3.org/SVG/modules/transforms/SVGTransformsReqs.html
>
> [12] http://dev.w3.org/SVG/modules/transforms/SVGTransformsReqs.html
>
> AG: I kind of put some basic usage scenarios in there
> ... I'm not sure if anything more needs to be done
> ... want feedback
>
> ED: there should be mention of and links to the CSS transforms
> proposal
>
> CM: change that requirement 3.1 to mention supporting SVG DOM access
> to these transforms instead of a scripting feature set
>
> DS: we should make sure to ask the CSS WG and browser vendors what
> their use cases and requirements are
>
> AG: the scripting change should be easy
> ... I've done a bit more work on the transforms spec itself doing
> bits and pieces
> ... trimmed the specification down
> ... JF and I agreed to remove translateX/Y/Z and scaleX/Y/Z
>
> JF: translateX/Y is part of the CSS specification but that's just
> syntactic suger
>
> AG: we proposed a translate3D that takes three parameters
>
> DS: why don't we just use 'translate' and extend it to allow it to
> take 3 parameters
>
> AG: at the moment in our proposal translate3D has optional 2
> parameters
>
> CM: the syntax in the spec at the moment says it can have one or
> three
>
> DS: rotate is different
> ... but scale and matrix...
>
> AG: JF is right, it can be smaller
> ... to answer CM's question, the reason the the CSS specification is
> 4x4 is to allow perspective and 3D transformations
> ... in our proposal we've separated out the syntax to have a
> separate 3D and perspective transform
> ... in the spec you can specify one vanishing point per object
>
> [AG draws on whiteboard to demonstrate separation]
>
> CM: you're saying the 12 component version is more compatible with
> OpenVG?
>
> <ChrisL> presumably opengl can also use the 3x3. i doubt openvg is
> an incompatible superset
>
> AG: OpenVG uses 3x3, OpenGL uses 4x4
>
> CM: is it because restricting the matrix to have all zeros in the
> third row of the perspective matrix means that when you multiply it
> by the 3D matrix it reduces down to a 3x3 which matches the OpenVG
> interface?
> ... and that's because you can't specify a general 4x4 matrix, and
> ...
> ... having general 3D effects isn't useful
>
> AG: [yes]
>
> DS: we can still do animations?
>
> AG: yes
>
> DS: are we going to cut ourselves off from future effects?
>
> AG: not that I can think of
>
> DS: are there two matrices or one, and what will getCTM return?
>
> ED: we would extend the SVGMatrix interface to get at all the values
> of the matrix, so still the same object we're return, but with more
> accessors
>
> AG: so, as a note, the reason we put SVGMatrix3D in there was to be
> compatible with SVG 1.1 matrices
> ... in answer to whether we'll miss out in stuff in future, the
> answer is still no, but currently the model we've got makes things a
> bit easier, because in CSS you can get | rotate perspective
> translate perspective |
> ... (repeated perspective)
>
> DS: I thought theirs was separate
>
> AG: they have both
>
> DS: what's the use case
>
> AG: I haven't seen any
>
> DS: we should get them
>
> ED: I think if we have rotate3D et. al, we'd probably want the same
> naming for translate and scale, that is having the suffix 3D there
> too
>
> DS: but how would you do it, what would the syntax be?
>
> AG: you need a rotation vector
>
> CM: the restriction that you can't specify general 4x4 means that
> you are compatible with both OpenVG and OpenGL because 3x3 is just a
> subset of 4x4
>
> DS: why do we need matrix3D?
>
> ED: there is one reason: older user agents won't misinterpret it
>
> CM: maybe we want to introduce forwards compatible parsing of
> transform lists so that individual transforms that are not
> recognized are ignored
> ... not sure if you can have useful results by ignoring them
>
> AG: it's probably feasible, since the old matrix has 9 values
>
> CM: I think that's a bit different from what I said
> ... still not sure if it's useful
> ... if the document needs to have perspective transforms to look
> right, is it useful?
>
> ED: it will probably look incorrect either way
>
> DS: if you use a matrix with 9 values in Firefox it throws away the
> entire transform
>
> ED: Opera does the same probably
>
> DS: [tests] actually Opera applies anything that comes before the
> matrix with 9 values, but not anything after
> ... Safari does the same as Firefox
> ... Batik pops up an alert
> ... if implementations all behaved like Opera, you could fake
> perspective with an initial skew and rotate, then undo the skew and
> rotate in the matrix that does the real perspective transform for
> newer user agents that support it
> ... extending 'matrix' or introducing matrix3D seems to make no
> difference in what implementations do
>
> ED: if we extend, then rotate3D would be the only odd one out
>
> <ChrisL> +1 to that
>
> <ChrisL> assuming "that" gets minutes (hint)
>
> DS: we could extend 'rotate' and make it depend on the number of
> parameters that are passed
>
> <shepazu> rotate(<rotate-angle> <nx> <ny> <nz> [<cx> <cy> <cz>])
>
> CM: CL, what were you +1'ing?
>
> CL: what shepazu just said
>
> <heycam> Scribe: Cameron
>
> <heycam> ScribeNick: heycam
>
> JF: we introduced a transform-origin property
>
> DS: is this in css as well?
>
> JF: yes
> ... it's essential for 3d transforms
> ... without this property it's difficult to handle 3d
> transformations
> ... it's actually an extension and useful for 2d transforms
>
> <anthony>
> [13]http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#tr
> ansform-origin-property
>
> [13] http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#transform-origin-property
>
> JW: a vanishing point?
>
> JF: no
>
> JW: how is this diferent from premultiplying a 3d translate?
>
> JF: that's all it is
>
> ED: it's also in the css proposal
>
> JW: what's the advantage of having it separate?
>
> ED: you have to write more if you do it in the transform list
>
> AG: when you do translate, you need to work in that user space, but
> with transform-origin, you can put it in an object and say that it's
> the center of the object
>
> DS: it's in the outer coordinate space
>
> AG: it would allow percentages, too, object bounding box coordinates
>
> ED: one question, is transform-origin in this spec exactly the same
> as in css transforms?
>
> JF: very useful for transform origin, especially if we set the
> transform-origin as 50%,50%
> ... you can rotate or scale about the center point
> ... very convenient
> ... the initial value of this property is defined as 50%,50% in css
> transforms
> ... but we are thinking whether we should use this intiial value
> ... if we don't specify a transform-origin, it should rotate about
> the origin
> ... maybe it should be 0,0
>
> JW: is css transforms spec
>
> s/spec a rec already?/
>
> CM: no they're about to publish a FPWD
>
> DS: otherwise it changes how svg transforms work currently
>
> AG: you can specify keywords, percentages and lengths in
> transform-origin
> ... but would the length be offsets from the origin or the bbox of
> the object?
> ... is that too overloaded?
>
> CM: i think that would be confusing
>
> <ChrisL> yes, thats too overloaded. just changing the unit should
> not change what parameter it is
>
> AG: it seems a bit overloaded
>
> DS: the 50%,50% initial value is at odds with existing percentage
> syntax in svg
> ... that would be viewport relative
>
> ED: but in some cases they are relative to bboxes
>
> DS: we could have something like transformUnits="objectBoundingBox"
> ... transformOriginUnits
>
> AG: then you'd need to use both properties in pair
>
> DS: the default is "userSpaceOnUse", for lengths
>
> AG: relative to the origin
>
> DS: and "objectBoundingBox" would make the lengths be relative to
> the bbox of the object
> ... the default should be userSpaceOnUse
> ... i don't mind this overloading
>
> CM: why can't we have the transformOriginUnits value inside the
> transform-origin?
>
> DS: it would be harder to parse, maybe more confusing for authors
> ... what if you want to animate the transform-origin?
> ... would you need to keep those transformOriginUnits keywords in
> the animation too?
> ... we should have these userSpaceOnUse/objectBoundingBox
> functionalities though
>
> CM: you could have these keywords repeated in the transform-origin
> to use different references for the different axes
>
> JW: css would have three values for this units attribute/keyword:
> the equivalent of objectBoundingBox, nearestContainingBlock and
> initialContainingBlock
>
> CM: which one does userSpaceOnUse correspond to?
>
> JW: probably nearestContainingBlock
>
> ED: for transform-origin, if you had scale and rotate in the same
> transform, would the origin apply to both of them together? or each
> individually?
>
> CM: it gives a pre and post translation for the whole transform
> ... in css transforms
>
> ED: our one should say something about that
>
> CM: be nice to have matrices and worked examples in the spec
> ... perspective-origin in the css spec
>
> AG: in ours, we can just put the perspective origin in the
> 'perspective' property itself (giving three values)
>
> ED: so you're changing all the matrix3d() to just matrix() with 12
> values?
>
> JF: i think we should consider this, examining the current
> implementation
> ... if it's ok, we're happy to change
>
> ED: but for the other ones, we're dropping the "3d" suffix to them?
>
> JF: i think we should carefully examine that
>
> AG: we'd need to investigate how feasible these changes are
>
> CM: how about backface-visibility which is in the css spec?
>
> [14]http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#ba
> ckface-visibility-property
>
> [14] http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#backface-visibility-property
>
> JF: i think that property is useful for some use cases
> ... currently we have no strong opinion about this
>
> CM: without it, you would need to animate and compute at what times
> to hide the two faces
>
> ED: i agree it would be useful in some places to have this property
> ... i don't think there's anything unsuitable for it being used in
> svg too
>
> AG: should we have layeredGroup?
> ... it's like a restricted form of z-index
>
> DS: what about 3d models, like rotating a cube?
>
> AG: layeredGroup would handle this case, as well as the
> backface-visibility case
>
> ED: backface-visibility is a css property, but layeredGroup wouldn't
> be
>
> <ChrisL> backface culling is common on real 3d systems, as the
> amount of data to be sent down the pipe can often be halved. but
> where is the back geometry coming from, in 2D?
>
> DS: so we may as well have backface-visibility, since we'll already
> have it in css
>
> CM: should we be adding these as properties or attributes?
>
> DS: well if we're having these css ones, then we may as well have
> these as properties too
> ... and make 'transform' a property
>
> JW: then we really need to make the two (the svg and css
> 'transform') compatible
>
> [15]http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#tr
> ansform-property
>
> [15] http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#transform-property
>
> they don't have TransformRef values
>
> DS: maybe it just wouldn't work with css boxes
> ... so we really need separate rotateX, rotateY, rotateZ?
>
> AG: the regular rotate() in svg rotates around the z axis
>
> CM: so rotateZ() is just the same as rotate()
>
> ED: so it would make it slightly simpler than the one we're
> proposing, since we need to specify the vector to rotate around?
>
> JF: if you have individual rotates, it's easier to do animation on
> these rotateX, rotateY
> ... you could do animateTransform type="rotateX"
>
> CM: so it's a similar sugar as having both matrix() and translate(),
> e.g.
> ... and the css spec has these too
>
> DS: i don't mind rotateX, Y, etc.
>
> AG: in our spec, rotateX, rotateY and rotateZ can all take two
> optional center point coordinates
> ... in the css spec they don't have that
>
> DS: their 'transform-style' property allows you to do the cube
> rotation example
>
> CM: would we then prefer layeredGroup over transform-style and
> backface-visibility, or vice versa?
>
> DS: we could have both, and talk about how they interacts with
> layeredGroup
>
> AG: layeredGroup would allow you to specify the z-indexes of each
> child
>
> CM: so that seems to be less usable than transform-style, which will
> work out the right z-order itself
>
> JF: i agree
> ... but i'm not sure if this 'transform-style' with preserve-3d
> works or not
> ... it will choose which to display based on the z coordinate
> ... but sometimes objects are not parallel to the x/y plane
> ... so it's difficult to define one specific z position of the
> objects
> ... the objects might intersect
>
> CM: maybe it would take the center of the bounding box (bounding
> cube?) to determine the z coordinate
> ... so layeredGroup would allow you to specify the exact ordering of
> the objects in the z axis
>
> JF: i think we need further investigation of this
>
> ED: should we try to publish what we have?
> ... or should we coordinate more?
>
> CM: we'll do that mail on friday in that coordination session
>
> <scribe> ACTION: Anthony to draft an email to send to the CSS WG
> summarising our thoughts about transforms [recorded in
> [16]http://www.w3.org/2009/02/16-svg-minutes.html#action01]
>
> <trackbot> Created ACTION-2467 - Draft an email to send to the CSS
> WG summarising our thoughts about transforms [on Anthony Grasso -
> due 2009-02-24].
>
> CSS Animations spec
>
> <ed__> [17]http://dev.w3.org/csswg/css3-animations/
>
> [17] http://dev.w3.org/csswg/css3-animations/
>
> DS: we'll discuss these later in the week, give us a chance to read
> them
>
> ED: on thursday
>
> CM: so we should read both animations and transitions
>
> DS: also please read the vector effects, filters, layout reqs
> documents for thursday
>
> Compositing spec
>
> <anthony>
> [18]http://dev.w3.org/SVG/modules/compositing/master/SVGCompositingP
> rimer.html
>
> [18] http://dev.w3.org/SVG/modules/compositing/master/SVGCompositingPrimer.html
>
> <anthony>
> [19]http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.
> html
>
> [19] http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.html
>
> AG: i think we need to put clipping and masking in the spec, since
> that's what we resolved
> ... but we could add it later, and publish this now
> ... it is publishable as it is
> ... the other day i sent an email out to benjamin who had posted
> that question about the soft-light equations
> ... i went to the pdf spec and got the new equations for color-dodge
> and color-burn, and soft-light
> ... but i didn't quite agree with his equation for soft-light, how
> he derived it from the pdf spec (for the alpha case)
> ... so i sent my derivations of the equations
> ... i think we are ok to publish what we've got
> ... the compositing spec follows the adobe compositing model
>
> [20]http://www.w3.org/mid/4994BF8F.1050302@cisra.canon.com.au
>
> [20] http://www.w3.org/mid/4994BF8F.1050302@cisra.canon.com.au
>
> AG: benjamin's and my equations come up with slightly different
> numbers
>
> CM: could you create a pdf file and check the colours to determine
> which is correct?
> ... did asv6 support these compositing features?
>
> CL: don't know, i think it did but i'm not sure
>
> CM: but you're ok with publishing with the equations as they are at
> the moment?
>
> AG: yes
>
> ED: the equations are in the primer. does that mean they're not
> normative?
>
> DS: i think the primer should be a shorter document that gives the
> examples
>
> ED: especially in the case of the equations, then they should go in
> the language spec
>
> CL: you can have non normative stuff in the language spec, but no
> normative text in the primer
> ... it should purely be expository, pretty examples, etc.
>
> AG: maybe about an hour or two's work
>
> <scribe> ACTION: Anthony to move the equations over to the language
> spec [recorded in
> [21]http://www.w3.org/2009/02/16-svg-minutes.html#action02]
>
> <trackbot> Created ACTION-2468 - Move the equations over to the
> language spec [on Anthony Grasso - due 2009-02-24].
>
> ACTION-2468: For the compositing spec, that is.
>
> <trackbot> ACTION-2468 Move the equations over to the language spec
> notes added
>
> DS: explain what is compositing, what you'd use it for
> ... almost like use cases and requirements
>
> CL: it's a good place to explain why certain decisions were made, so
> that implementors don't think "oh that's stupid, i'll do it this
> more logical way" without realising why it was done that
>
> JW: definitely rationale should be recorded
>
> JF: is it useful to have the version number "1.2" in the
> specification?
>
> AG: just call it "Compositing"
>
> DS: same with "Filters"
>
> RESOLUTION: Pending moving the equations, we will publish the
> Compositing spec and primer
> ... Add clipping and masking at some later point to the Compositing
> spec
>
> Comments from roc
>
> JW: regarding suspendRedraw, what we've said sounds reasonable
> ... he's still not sure why it is needed in browsers though
> ... html+css says that nothing is rendered in the middle of a script
> block
>
> DS: what about when doing scripted animation?
>
> JW: you'd use setTimeout(), when each invocation of the timer
> handler is finished, you'd get a rendering
> ... so suspendRedraw and unsuspendRedraw in the same script block
> isn't useful
>
> ED: what happens in firefox if you have say a mouse event triggers a
> listener, and the function takes a long time to execute, would you
> have any updates?
>
> JW: currently not
>
> ED: not 100% sure if that's what we did before, in opera
>
> JW: you might interrupt the script for a repaint?
>
> ED: i'm pretty sure that in opera 9.2 or so we would do a repaint if
> the script is taking too long
> ... i think the newer strategy is to do what firefox is doing
> ... i don't want to say for sure, but i think we're doing something
> like that now
>
> JW: so roc is wondering what the use cases are for, to have
> suspend/unsuspend in a different script invocations
> ... he doesn't see why svg should be different from html+css in this
> regard
> ... re clipping of filters, we'll go ahead and make that change
>
> ED: i think we still need to discuss the actual solution
> ... i'd rather wait for the WG to make a decision on it
>
> AG: so that's calculating their own values for clipping filters?
>
> JW: so the width/height attributes wouldn't determine the size of
> the offscreen buffer, but they would still define the coordinate
> system for the filters to work within
> ... also we would need to alter feFlood to fill only the filter
> region
>
> ED: i'd like to review JW's proposed text before going ahead with it
>
> JW: he also had questions about LOD functionality
>
> DS: the idea is that LOD has no effect on transform, it only
> responds to the currentScale DOM attribute
>
> JW: what about a foreignObject with an SVG inside that? the
> currentScale in the inner document didn't change, but the outer one
> did?
>
> DS: if you zoom in the outer one, i would not expect to change the
> LOD of the inner one
>
> ED: i think that would make most sense for authoring
>
> DS: i don't think it's reasonable to expect complex document
> fragments like that to behave in some complicated way
> ... i could see always looking at the outermost currentScale, don't
> think it's the most useful way though
>
> [doug draws on the board]
>
> SVG 1.1 errata
>
> <ed__> [22]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml
>
> [22] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml
>
> ED: we have actions for all of the draft errata
> ... nothing to report on the tangents one, but it's not defined well
> enough in 1.2T either, so there's no wording to backport
> ... i think we discussed a bit in the telcon about changing the
> implementation requirements chapter for animateMotion with zero
> length path segments
> ... currently the text is specific to things that render, paths
> ... i still don't think we have a conclusion on ACTION-2362
>
> ACTION-2362?
>
> <trackbot> ACTION-2362 -- Erik Dahlström to backport the zero length
> path wording from 1.2T to this "Reword F.5 Tangents" erratum -- due
> 2008-12-04 -- CLOSED
>
> <trackbot> [23]http://www.w3.org/Graphics/SVG/WG/track/actions/2362
>
> [23] http://www.w3.org/Graphics/SVG/WG/track/actions/2362
>
> <ed__>
> [24]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#bzwidth
>
> [24] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#bzwidth
>
> ED: next on the list is sizing of the outermost svg
>
> ACTION-2370?
>
> <trackbot> ACTION-2370 -- Erik Dahlström to go through the e-mailing
> thread for errata item "Sizing of the outermost svg" and update the
> item discussion -- due 2008-12-08 -- CLOSED
>
> <trackbot> [25]http://www.w3.org/Graphics/SVG/WG/track/actions/2370
>
> [25] http://www.w3.org/Graphics/SVG/WG/track/actions/2370
>
> ED: so i added those discussion/comment links
> ... i think tiny 1.2 defines all that boris wanted
> ... do we need to port that back to 1.1 in an erratum?
> ... so the issue about intrinsic sizing and use of svg in css
> ... so we have a whole section on intrinsic sizing in 1.2T
>
> JW: are we publishing a 2ed soon?
>
> CM: yes
> ... incorporating just the errata
>
> <scribe> ACTION: jwatt to flesh out the intrinsic sizing erratum
> with text backported from 1.2T [recorded in
> [26]http://www.w3.org/2009/02/16-svg-minutes.html#action03]
>
> <trackbot> Created ACTION-2469 - Flesh out the intrinsic sizing
> erratum with text backported from 1.2T [on Jonathan Watt - due
> 2009-02-24].
>
> <scribe> ACTION: jwatt to Review the spec for the consisten use of
> glyph and em square/cell, and get rid of character cell [recorded in
> [27]http://www.w3.org/2009/02/16-svg-minutes.html#action04]
>
> <trackbot> Created ACTION-2470 - Review the spec for the consisten
> use of glyph and em square/cell, and get rid of character cell [on
> Jonathan Watt - due 2009-02-24].
>
> [discussion about perhaps postponing this erratum]
>
> ED: after this F2F we could mail the list to point out the errata
> that we have at "proposed", and that we will fold these in to SVG
> 1.1 second edition
> ... and that we're not planning to fix other things with the second
> edition
> ... but still get comments on those errata
>
> [we decide to postpone that one, reassigned the action to SVG Core
> 2.0]
>
> <scribe> ACTION: Erik to send the mail announcing the errata and 1.1
> second edition publication plans [recorded in
> [28]http://www.w3.org/2009/02/16-svg-minutes.html#action05]
>
> <trackbot> Created ACTION-2471 - Send the mail announcing the errata
> and 1.1 second edition publication plans [on Erik Dahlström - due
> 2009-02-24].
>
> <ed__>
> [29]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#svgzoomev
> ent-interface
>
> [29] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#svgzoomevent-interface
>
> JW: seems like the right thing to me to drop zoomrectscreen
> ... it assumes that you implement zooming in the way that ASV did it
>
> DS: i think zooming still needs more discussion with implementors
>
> JW: it's quite underspecified at the moment
>
> DS: taking out, to me, gives the impression that we don't want that
> feature at all
>
> ED: we don't implement the rectangular selection zooming. we could,
> but not all UAs will want to do that.
>
> JW: i think it should be the rectangle where x and y is the position
> of the top-left coordinate of the viewport in user space
> ... established by the target of that zoom.
> ... so you can position an element relative to what is the new
> viewport
>
> ED: when you do this kind of zooming, what does it change? the
> viewBox? the currentScale/currentTranslate?
> ... is it possible to get the same information some other way?
>
> JW: the viewport DOM attribute
>
> ED: there's currentView as well
>
> CM: maybe that's something different, what the currently linked to
> <view> element is?
>
> JW: you want the zoom event to be dispatched just after the
> currentScale etc. attributes change, but just before a repaint
> ... does opera implement previousScale/previousTranslate?
>
> ED: i don't think so
>
> JW: i think all of the context information is redundant, be would
> would keep the zoom event
> ... i think mozilla's is the most complete implementation of
> SVGZoomEvent
> ... adobe didn't implement those properties
> ... we just do {previous,new}{Scale,Translate}
> ... maybe we shouldn't remove it all just now
> ... but in SVG.next, it seems like it would simplify implementations
> and the spec to remove them
> ... so remove zoomRectScreen?
>
> ED: yes
>
> JW: you can use viewport instead
>
> DS: i don't mind removing it. i think how zooming is handled in svg
> needs more work, though.
>
> JW: we could add a note to say that we will deprecate
> {previous,new}{Scale,Translate}
>
> CM: i think we should remove rather than deprecate
>
> ED: we could say in the erratum how to do this (caching those
> values)
>
> RESOLUTION: Dropping all context info and attributes from
> SVGZoomEvent, and explain how you can get
> {previous,new}{Scale,Translate} by other means, but still having the
> event
>
> ED: so those three errata could be combined
>
> ACTION-2386: join these three errata and drop the context info and
> other attributes from SVGZoomEvent
>
> <trackbot> ACTION-2386 Investigate the "SVGZoomEvent - Interface"
> errata item further notes added
>
> ACTION-2386?
>
> <trackbot> ACTION-2386 -- Jonathan Watt to investigate the
> "SVGZoomEvent - Interface" errata item further -- due 2008-12-25 --
> OPEN
>
> <trackbot> [30]http://www.w3.org/Graphics/SVG/WG/track/actions/2386
>
> [30] http://www.w3.org/Graphics/SVG/WG/track/actions/2386
>
> ED: final erratum is "currentTranslate-currentScale on nested SVG"
>
> [31]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#currenttr
> anslate-currentscale-nested-svg
>
> [31] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#currenttranslate-currentscale-nested-svg
>
> DS: being able to zoom in on individual <svg> elements ...
>
> [doug draws]
>
> JW: i don't think currentScale/currentTransform are good anyway
> ... you might want to keep the center centered, then zoom
> ... or maybe zoom to a rectangle
>
> ED: you can use predefined <view> elements
>
> JW: if you click on the plus button in doug's example, you don't
> want to just make currentScale larger, you need to also mess with
> currentTranslate
>
> DS: right, but having both of them, plus a zoomToRect() method would
> be handy
>
> AG: could add that to 2.0 Core
>
> ED: would it have to use currentTranslate/currentScale? could it use
> viewBox instead?
> ... you can modify viewBox with script already
>
> DS: so how does a viewBox work with regards to transforms and
> regards to LOD?
>
> JW: it's part of the stack of transformation matrices
>
> DS: related is when linking to a #fragment, when the element is too
> big to fit in the viewport
>
> ED: should we address that now, or later?
>
> DS: later. what do we do with this issue?
>
> <scribe> ACTION: Doug to fill in the currentTranslate/currentScale
> erratum to explicitly make using those attributes on inner <svg>
> elements undefined [recorded in
> [32]http://www.w3.org/2009/02/16-svg-minutes.html#action06]
>
> <trackbot> Created ACTION-2472 - Fill in the
> currentTranslate/currentScale erratum to explicitly make using those
> attributes on inner <svg> elements undefined [on Doug Schepers - due
> 2009-02-24].
>
> close action-2368
>
> <trackbot> ACTION-2368 Propose wording for the change that addresses
> the errata item Current Translate Current Scale on nested SVG closed
>
> CM: there are seven other actions for errata stuff
> ... we'll go through them to decide whether to handle them now or
> not
>
> ACTION-2067?
>
> <trackbot> ACTION-2067 -- Anthony Grasso to add Eriks proposed
> wording to the Errata. Link to ACTION-2066 -- due 2008-06-19 -- OPEN
>
> <trackbot> [33]http://www.w3.org/Graphics/SVG/WG/track/actions/2067
>
> [33] http://www.w3.org/Graphics/SVG/WG/track/actions/2067
>
> ED: this is about extending the background image outside the
> viewport
> ... this is about if you have filter content outside the viewport,
> whether that is clipped
> ... you specify in enable-background a rectangle
> ... or you can just say "new". opera is clipping to the viewport.
>
> ACTION-2066?
>
> <trackbot> ACTION-2066 -- Erik Dahlström to propose wording that
> clarifies the use of background image outside of the viewPort bounds
> -- due 2008-06-19 -- OPEN
>
> <trackbot> [34]http://www.w3.org/Graphics/SVG/WG/track/actions/2066
>
> [34] http://www.w3.org/Graphics/SVG/WG/track/actions/2066
>
> ED: i would be ok with postponing this for a bit
> ... and just put it into the filter spec
> ... the question is how often do you need to use enable-background
> for content outside the viewport
>
> ACTION-2358?
>
> ACTION-2367?
>
> ACTION-2372?
>
> ACTION-2404?
>
> ACTION-2450?
>
> ACTION-2451?
>
> <trackbot> ACTION-2451 -- Erik Dahlström to modify the current
> errata item on SVGTransform.matrix that addresses ISSUE-2210 -- due
> 2009-02-16 -- OPEN
>
> <trackbot> [35]http://www.w3.org/Graphics/SVG/WG/track/actions/2451
>
> [35] http://www.w3.org/Graphics/SVG/WG/track/actions/2451
>
> ACTION-2367?
>
> <trackbot> ACTION-2367 -- Erik Dahlström to propose an errata item
> for rx and ry -- due 2008-12-08 -- OPEN
>
> <trackbot> [36]http://www.w3.org/Graphics/SVG/WG/track/actions/2367
>
> [36] http://www.w3.org/Graphics/SVG/WG/track/actions/2367
>
> ACTION-2372?
>
> ACTION-2372?
>
> <trackbot> ACTION-2372 -- Doug Schepers to propose revised wording
> for the errata item "Capturing pointer-events with a zero opacity
> mask" to clarify it with clip-path -- due 2008-12-11 -- OPEN
>
> <trackbot> [37]http://www.w3.org/Graphics/SVG/WG/track/actions/2372
>
> [37] http://www.w3.org/Graphics/SVG/WG/track/actions/2372
>
> ACTION-2404?
>
> <trackbot> ACTION-2404 -- Doug Schepers to add errata item for root
> overflow -- due 2009-01-22 -- OPEN
>
> <trackbot> [38]http://www.w3.org/Graphics/SVG/WG/track/actions/2404
>
> [38] http://www.w3.org/Graphics/SVG/WG/track/actions/2404
>
> ACTION-2450?
>
> <trackbot> ACTION-2450 -- Cameron McCormack to make an errata item
> that aligns the pace animation in 1.1 Full with that in 1.2 Tiny --
> due 2009-02-16 -- OPEN
>
> <trackbot> [39]http://www.w3.org/Graphics/SVG/WG/track/actions/2450
>
> [39] http://www.w3.org/Graphics/SVG/WG/track/actions/2450
>
> ACTION-2451?
>
> <trackbot> ACTION-2451 -- Erik Dahlström to modify the current
> errata item on SVGTransform.matrix that addresses ISSUE-2210 -- due
> 2009-02-16 -- OPEN
>
> <trackbot> [40]http://www.w3.org/Graphics/SVG/WG/track/actions/2451
>
> [40] http://www.w3.org/Graphics/SVG/WG/track/actions/2451
>
> ACTION-2358?
>
> <trackbot> ACTION-2358 -- Doug Schepers to propose wording for the
> clip path pointer-events erratum and masking/compositing module
> change -- due 2008-12-04 -- OPEN
>
> <trackbot> [41]http://www.w3.org/Graphics/SVG/WG/track/actions/2358
>
> [41] http://www.w3.org/Graphics/SVG/WG/track/actions/2358
>
> <ed__> ACTION-2367: Added testcase
> [42]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-rect-03-t.s
> vg as a starting point
>
> [42] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-rect-03-t.svg
>
> <trackbot> ACTION-2367 Propose an errata item for rx and ry notes
> added
>
> <ed__> ACTION-2451: Added draft testcase
> [43]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/coords-dom-f-01.sv
> g
>
> [43] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/coords-dom-f-01.svg
>
> <trackbot> ACTION-2451 Modify the current errata item on
> SVGTransform.matrix that addresses ISSUE-2210 notes added
>
> <shepazu> jwatt:
> [44]http://lists.w3.org/Archives/Public/www-svg/2008Nov/0064.html
>
> [44] http://lists.w3.org/Archives/Public/www-svg/2008Nov/0064.html
>
> close ACTION-2450
>
> <trackbot> ACTION-2450 Make an errata item that aligns the pace
> animation in 1.1 Full with that in 1.2 Tiny closed
>
> <shepazu> jwatt:
> [45]http://lists.w3.org/Archives/Member/member-svg-editors/
>
> [45] http://lists.w3.org/Archives/Member/member-svg-editors/
>
> <ed__> trackbot, close ACTION-2451
>
> <trackbot> ACTION-2451 Modify the current errata item on
> SVGTransform.matrix that addresses ISSUE-2210 closed
>
> Summary of Action Items
>
> [NEW] ACTION: Anthony to draft an email to send to the CSS WG
> summarising our thoughts about transforms [recorded in
> [46]http://www.w3.org/2009/02/16-svg-minutes.html#action01]
> [NEW] ACTION: Anthony to move the equations over to the language
> spec [recorded in
> [47]http://www.w3.org/2009/02/16-svg-minutes.html#action02]
> [NEW] ACTION: Doug to fill in the currentTranslate/currentScale
> erratum to explicitly make using those attributes on inner <svg>
> elements undefined [recorded in
> [48]http://www.w3.org/2009/02/16-svg-minutes.html#action06]
> [NEW] ACTION: Erik to send the mail announcing the errata and 1.1
> second edition publication plans [recorded in
> [49]http://www.w3.org/2009/02/16-svg-minutes.html#action05]
> [NEW] ACTION: jwatt to flesh out the intrinsic sizing erratum with
> text backported from 1.2T [recorded in
> [50]http://www.w3.org/2009/02/16-svg-minutes.html#action03]
> [NEW] ACTION: jwatt to Review the spec for the consisten use of
> glyph and em square/cell, and get rid of character cell [recorded in
> [51]http://www.w3.org/2009/02/16-svg-minutes.html#action04]
>
> [End of minutes]
> _________________________________________________________
>
>
> Minutes formatted by David Booth's [52]scribe.perl version 1.133
> ([53]CVS log)
> $Date: 2009/02/17 07:05:54 $
> _________________________________________________________
>
> [52] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
> [53] 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 [54]http://dev.w3.org/cvsweb/~checkout~/2002
> /scribe/
>
> [54] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
>
> Guessing input format: RRSAgent_Text_Format (score 1.00)
>
> Succeeded: s/we're saying//
> Succeeded: s/ think if we have scale3D et. al, we'd probably want the s
> ame for rotate/ think if we have rotate3D et. al, we'd probably want th
> e same naming for translate and scale, that is having the suffix 3D the
> re too/
> FAILED: s/spec a rec already?//
> Succeeded: s/whether it's possible to change our implementation/how fea
> sible these changes are/
> Succeeded: s/AG/JF/
> Succeeded: s/the own value/their own values/
> Succeeded: s/ED: i think that would make most sense/ED: i think that wo
> uld make most sense for authoring/
> Found Scribe: jwatt
> Inferring ScribeNick: jwatt
> Found ScribeNick: jwatt
> Found Scribe: Cameron
> Found ScribeNick: heycam
> Scribes: jwatt, Cameron
> ScribeNicks: jwatt, heycam
>
> WARNING: No "Present: ... " found!
> Possibly Present: ACTION-2367 ACTION-2386 ACTION-2451 ACTION-2468 AG CL
> CM ChrisL DS ED JF JW anthony chuckle ed__ heycam joined jun jwatt scr
> ibenick shepazu svg trackbot
> You can indicate people for the Present list like this:
> <dbooth> Present: dbooth jonathan mary
> <dbooth> Present+ amy
>
>
> WARNING: No meeting chair found!
> You should specify the meeting chair like this:
> <dbooth> Chair: dbooth
>
> Found Date: 16 Feb 2009
> Guessing minutes URL: [55]http://www.w3.org/2009/02/16-svg-minutes.html
> People with action items: anthony doug erik jwatt
>
> [55] http://www.w3.org/2009/02/16-svg-minutes.html
>
> End of [56]scribe.perl diagnostic output]
>
> [56] 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 Monday, 23 February 2009 23:09:45 UTC