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

PDF Blending Algorithms (was RE: Minutes Sydney 2009 F2F day 2)

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Mon, 23 Feb 2009 14:57:19 -0800
To: Erik Dahlstrom <ed@opera.com>, "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Message-ID: <D23D6B9E57D654429A9AB6918CACEAA97C2F40D21C@NAMBX02.corp.adobe.com>
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 22:58:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 February 2009 22:58:27 GMT